[CFF] add planning feature project management, gantt chart


I would like to develop/contribute an entirely new feature, to visualize roadmaps or development progress. This is a call for a request (CFF) if this is in your interest and has the potential to be merged.


In every project (which uses Jira), project planning is a big question. There are robust tools out there since centuries, like Gantt charts. Many plugins for Jira exists, which bring this functionality. In many companies, Jira is a centrally managed software and adding a plugin, even is they are for free, is not an option ... because of security or not enough capacity to maintain them. This feature should enable individuals to quickly visualize epics, stories, etc .over time and additionally provide quick editing features.

The value for the user would be to not waiting for central IT dept. and being instantaneously enabled to visualize or mass edit tickets.

Users with the highest interest might be freelancers, consultants or any other people who frequently change projects and can't wait for long-running application and installation processes. Also, "regular" Jira user might use it when for some reason they are not able to get other Jira plugins centrally installed.

User stories

  • a freelancer wants to provide a visual representation of the tickets he/she is working on, showing dependencies and milestones
  • a project manager wants to update many tickets, because of changed timeline in the project
  • a project manager wants to verify tickets are in the right order and dependencies are correct
  • a team lead wants to make tasks dependencies, lead time and parallelism within his/her team transparent to everyone

Core ideas / features

(using MoSCoW prioritization scheme, https://en.wikipedia.org/wiki/MoSCoW_method)

  • [must] provide predefined queries, to e.g. fetch all epics in a Jira project
  • [shouls] let a user define custom queries, to select
  • [should] support custom fields for start/end and grouping
  • [must] support 'batch-like' mass edit, means first many tickets can be moved within the timeline, then there is a separate SAVE button which uploads all changed tickets to the server
  • [could] support multiple parallel planning scenarios
  • [should] support grouping by teams defined in Jira Assistant (existing feature)
  • [should] support grouping by users on the ticket itself
  • [won't] custom styling or white-labeling of the graph
  • [could] export data to other visualization tools, like https://online.officetimeline.com/ or others
  • [could] support show/hide of columns (customization of the visualization)
  • [could] support milestones for visualization
  • [could] support phases for visualization

Implementation ideas

  • use default fields in tickets, like
    • implementation start / end -- to define
    • "blocks ticket ..." or "is blocked by ..."
    • completeness (in percent)
  • Where possible re-use existing open source libraries, like https://github.com/robicch/jQueryGantt

This feature looks to be pretty interesting and definitely you can go ahead with it. But I would like to know few more details based on which I had to plan for something:

  1. What was your estimated effort for development and are you alone planning to work on it?
  2. What kind of support would you expect from me other than review and merging of pr?
  3. As you are planning to use some 3rd party libraries, please ensure about its licensing.

For you to work on this feature, I would suggest you to use a separate branch itself having base as develop. Once entire development and testing is done that can be merged with develop


thank you for your feedback. Regarding your questions and comments...

  • branches ... absolutely, I already forked into my account ;)
  • I'm planning to work alone on it ... but would greatly appreciate any kind of pair programming (XP) and feedback. Means preferably working in a team, just that I'm alone at the moment ;)
  • if you could have a look from time to time into my branch, that would be great. I want to make sure, the coding style is aligned etc.
  • for sure, I will raise some questions over time. Maybe I just follow up the issue here, so you can watch out for notifications
  • also, I prefer intermediate reviews over final "final" ones. If you don't mind, I will create some PRs and we can decide for intermediate merging or just closing a PR without merging but made a review only.
  • 3rd party libs ... yes for sure. ATM I'm looking at https://github.com/robicch/jQueryGantt, which is under the MIT license - so no issue.
  • regarding effort, I estimate 10 to 20 men days of straight work. considering the fact, I this is my spare time, it might be 1-3 months lead time.

In terms of merging back to your develop branch and release ... I'm a big fan of smaller (intermediate) releases, which reflect a Minimum Viable Feature (MVF).
It would be great if e.g. I start on a "read-only" view first and release this as "beta" feature. This could be possible within 2-3 weeks maybe. And we would be able to gather feedback. On top of that, the next release could include some custom filters OR some editing options. etc. What do you think about that approach?

sure, that shouldn't be a problem.

hi @nitram509 , Hope everything is good. I would like to let you know that their were lots of changes in repository and I would suggest you to have your branch updated always so that you will not have any issue using the existing services. Their were lots of fixes from the time you had forked the repository and so would request you to use an updated version before continue with your activity.


thanks for letting me know - I will do.

I have some little progress. I managed to add a new menu item " Roadmap View" and started to insert jQery Gantt Editor (from TWProject). It's quite a challange to rewrite the un-modularized jQuery code and make it compile in a React context.

So good new, I was able to include the sources and make the JA compile ... but still working on showing something ;)

Unfortunately, I only managed to make it compile by altering package.js -- to reduce the compiler severity level. I'm new to React, so still need to learn more about it's lifecycle.

            "no-unused-vars": "warn",
            "no-unreachable": "warn",
            "eqeqeq": "warn",

Just wanna share a little progress ... 1 picture say more than 1000 words ;) The first time something useful is loaded ;) Unfortunately, the splitter does not work yet ;)

<img width="1680" alt="Screenshot 2019-08-27 at 11 16 27" src="https://user-images.githubusercontent.com/1189394/63804478-8982eb00-c917-11e9-8b0c-47521511ce22.png">

Another dev snapshot ... got the jQery Gantt Editor almost completely working Commit check sum is 8766bab3761b2f81bfa31095a3a72a76bd307ac6

<img width="1680" alt="Screenshot 2019-09-08 at 18 53 34" src="https://user-images.githubusercontent.com/1189394/64491560-448d7b80-d26a-11e9-8841-96d450019474.png">

Development notes ...

  • evaluated https://www.npmjs.com/package/react-gantt -- does not support grouping, so considered not a good candidate to use
  • re-evaluated the grid view ... came to the conclusion, that reworking the grid might work best with using https://www.npmjs.com/package/react-data-grid ... this is a very sophisticated lib which support in cell editing, click actions, inline images, tree views, high performance, freeze headers, etc.
  • its a goal to get ridd of jQuery code (incl. libs), since it's heavily tangled with the application code and gives stress in maintaining a proper react state
  • it's a goal to use proper react state and separate application logic from view logic
  • decision made: will switch to use the react-data-grid as full replacement for the left-hand-side grid.
  • will re-evaluation right hand side chart view later

Development notes/update...

I dropped the former approach of using jQuery Gantt Editor fo these reasons

  • even after a lot of refactoring, the jQuery code base was difficult to integrate into the React world.
  • some stuff didn't work anymore (because event listeners were commented out, in order to make code work
  • the code base itself was not well separating UI and business logic, which cause some features where disabled
  • the jQuery code base wasn't meant to be modular or to be integrated in something else
  • I did re-estimated the development effort and it seems more logical to start from scratch

Currently looks like this ... (the button 'load tickets' already works ;) )

<img width="1680" alt="Screenshot 2019-09-29 at 22 13 58" src="https://user-images.githubusercontent.com/1189394/65838810-5ad9a500-e307-11e9-8c6e-1baabe146e4a.png">

Development update: due to some private reasons, I want to spend my remaining spare time this year on other projects. I definitely plan to continue this feature, but for now: paused.

Sorry to spoil the party, I'm just wondering. There are gant charts in next gen Jira projects. They work excellent. I suppose not everybody uses Jira cloud. A lot of legacy projects use Jira locally. Maybe for them it makes sense. image

Hi Adrian, thanks for pointing that out. Indeed there are many plugins for Jira on-premises available, as well as the one you mentioned in Jira cloud offerings. Nevertheless, I'm regularly facing the situation, where such can't be used and hence my motivation was to start such an alternative solution. Unfortunately, my spare time for coding is limited.