I am trying to find out if JIRA can support the following situation:
Here it gets nasty:
And despite this workflow me and my team need at least the following insights:
Does JIRA support this workflow?
Additional information: Right now we are using MantisBT as our issue tracking system. After we tried the "product-matrix" plugin , that did basically what we wanted, but was not very well integrated, we thought about implementing a plugin for Mantis that would have worked the following way:
But as implementing this seems like very hard and we were already thinking about moving away from Mantis (too old, too inflexible [workflow]) I thought it would be best to ask the community about better solutions to our problem.
I have a similar issue for the system I have set up. Most solutions either involve...
And of course either can work when they are not needed for most issues but when they are needed more often, the users naturaly push back on all the work needed to connect the dots.
The only other solution I have come up with is this:
So, now the process is a bit more light-weight and all the x-project info is in one place instead of x-linked all over. Also, each project can find these x-project issue easily using the Cross-Project field of the Cross-Project Subtask.
Still some major negatives here...
What this offers is an easier way to create these x-project dependencies without clones/links where all the info about the issue is in one place instead of cloned/linked to each project.
I am going to demo this to the team and see but its still a pretty clunky solution. I wish that Atlassian would take a task to figure out a better way to create cross-project dependent tasks and custom fields that could refrence x-project versions to implement them.
Honestly though I think having cross-project dependencies is an indicator that what you really need are common projects with there own versions and there own project (like a Graphics Library with a Version) and you only track the bugs in that one project that is used in other Products. Then each product has a manifest of versions of the components being used.
I think that is the only good manageable solution as things scale up. And its the way most large open source projects work. For example, you may have a bug in your Web Store front that relates to a MySql bug. But I don't think you are going to track all the MySql bugs in your Web Store project. You would probably just track a customer issue and you would state that the issue relates to a MySql bug (put a ref in there) and it will be fixed when a new version of MySql is incorporated etc.
Its a tough problem with large organizations that use a lot of common code but don'e do symantic, independent versioing of the common code/libs.
Already a thanks for your answer, I will have to think about it a little bit before answering.
"Good" to hear I am not the only person searching for a solution to this problem. I tried to understand the solution you described, but still have some questions:
I don't really agree with your conclusion that this situation indicates the need for real project plus smaller components as their own projects, as the products we have really are 'implementations' of the framework/template project. I'm sill looking for an analogy to explain this better, what we do, but I can't find one. It's too mangled and connected to really have this seperation. That's why I'm even not sure if I better have one big project with indication in the issues, or several projects with some form of linked issues.
Sorry, but I'm still a bit confused, probably because I didn't use JIRA before. These "cross-project subtasks", how do they work? Is there one main issue and 2 subtasks?
In JIRA (out of the box) issues can have one or more sub-tasks. I am just talking about creating a custom sub-task which is also possible with basic JIRA.
First thoughts, provided I understood your situation correctly.
And with Rapidboard in Greenhopper you could prioritize across multiple projects for teams to focus as per priority.
Thanks Renjith, you understood the situation absolutely correctly. The process you describe is quite similar to how we handle the project with our current setup in Mantis right now. But it has some major problems:
If there was a way to automatically synchronize changes from one project's issue to another, then maybe this could work. But as far as I know, there isn't.
Since you need to handle the correction independently for each product, somehow we need to have seperate issues per product. Another option could be then sub-tasks.
Then it will mean, a single project for everything, and sub-tasks getting created to track the corrections in each product. This also means, you need a custom field to indicate which product this belongs to. Again, this becomes a bit messy with you losing all the built-in features of handling each product seperately. Roadmaps, release notes, project overview etc. A kind of workaround could be to have product specific filters and creating one dashboard per product which summarizes all the issues using the product filters.
Going back to option 1, if you are okay with some coding, you can develop a plugin which can then keep the fields synchronized across all the linked issues. Overview of the issues across all the projects should not be an issue in first approach as each issue will show the status of all the linked issues while viewing it. And the cloning of issues will be handy to create issues for multiple projects, of course, you need to clone and move the issue to mark it for a different project.
I only need to change priority, status and other attributes depending on the product, issue title and comments or discussion stream can/should be shared.
Basically you propose 2 possible solutions:
Did I understand that correctly?
Any pointers for how it would be possible to code a "issue content synchronization" plugin for option 1? Maybe it is even possible to simplify the issue creation...
(Thanks for you help, really appreciate it)
Yes, that is what I meant.
Regarding issue content synchronization, what was done in one of our cases (not a similar one), we used to regularly run a external script which connects to Jira over SOAP, pulls out the Jira ids using the required filters. Also additionally load the xml feed of the filter (as SOAP does not support Issue Links) and then do a comparison of the contents. And if needed update the required issues. In your case it's a bit more complicated as you expect the Summary/Description to get updated in any of the items. Then you may need to look into the updated date (and probably issue history to check whether these fields are really changed) to make the updates. SOAP does not support issueHistory, but REST does (getHistory/getActivity).
For issue creation, in another case, was also achieved in a similar manner using SOAP (in my case, the users wanted to quickly transform emails into Issues - with some changes). So an Outlook Plugin was written again picks up an existing email and transforms the subject, mail body and attachments to an issue. A similar stuff could be done with the possibility to select multiple products to be selected during issue creation.
I also looked into the available APIs, but I don't think taking the ticket creation step outside the issue tracking system is a good idea. When we switch to JIRA, I want it to be fully integrated and matching our workflow.
I found a plugin that lets you "Synchronize fields for two linked issues": https://studio.plugins.atlassian.com/wiki/display/JCALP/JIRA+Create+Issue+And+Link+Plugin Maybe it even lets you create issues (sub issues) when creating an issue, I didn't really understand that part yet.
Another plugin gives a "Collapsable Check Boxes" that could be useful to select the connection between the parent ticket and several child issues in a nice way: https://plugins.atlassian.com/plugins/com.palm.jira.plugin.palm-custom-fields-plugin I have no idea how you could create these tickets then, but maybe there is a ticket for that, too.
The "Parent status field" custom field in this plugin would be really useful in the child issues: https://plugins.atlassian.com/plugins/com.innovalog.jmcf.jira-misc-custom-fields
And last, but not least with this plugin I think I get the power to require the users to fix all child issues first before being able to close the parent: https://studio.plugins.atlassian.com/wiki/display/JBHV/JIRA+Behaviours+Plugin
So basically I think I have all necessary parts but the automated child issue creation and deletion on selecting a checkbox on the parent issue. And of course I need a way to dynamically create and administrate the 'projects' for which child issues can be created.
Does this make any sense? I'm a total newbie to JIRA...