Pre-populate project field in CreateIssueDetails

[Dmitry Nechayev]

I wonder if it is possible to pre-populate project field in CreateIssueDetails dialog with some target value other than a project from the last created issue?

The use case is the following: we are migrating old bug tracking system into Jira and would like to use component values from the old system to select project values for Jira issues. On UI, the first dialog would select an old component (and, possibly, Jira issue type) and using an association between old components and Jira projects, would automatically populate Jira project value in CreateIssueDetails form which would subsequently be invoked

Would it be possible to implement using standard plugin types? Any hints how?

Thank you in advance!

Dmitry

[Nic Brough -Adaptavist- · Accepted solution]

Not really.

The problem is that Jira needs to know what the Project and Issue-type are before it can do anything else. The "components" field in Jira is dependent on Project, and not the other way around. So you can't pick a component and derive a project from it. It gets even more difficult if you remember that you can put the same component (name) in more than one project.

What you could do:

• Have one project for each of your old components
• Educate your users to raise everything in one catch-all project, then write a listener that catches "issue created", looks at the component(s) they select, and moves the issue into the relevant project for you.

(There may be other fixes, those are just two that sprung to mind for me)

[Dmitry Nechayev]

Thanks a lot - this is an opinion that we need. In fact option #1 from your reply has been a candidate for a while and the only blocking factor for implementing it was performance considerations. We have approximately 3500 components now and in our preliminary experiments we determined that Jira performance (Create operation in particular) degrades almost linearly when number of projects starts to exceed 500. Therefore we began to look in other solutions

#2 though looks like an interesting alternative. Do you think it may be possible to override CreateIssueDetails class so that we can set that catch-all project for it and spare users from necessity to educate/remember it? Also, do you think it may be possible to use workflow logic (or, say functionality from Behaviors plugin) to accomplish the task of reassigning the project after creation?

Thanks a lot!

[Nic Brough -Adaptavist-]

Hmm, that sounds odd - I've used much larger installations and not seen any degredation of speed on create issues.

I imagine you can override the create issue page. I would actually keep it simple and not try to override anything other than the default. If you always want to set it to "project X" (but still leave the user free to change to other projects if they need to), you could probably do that with a spot of javascript.

Doing a move in workflow is quite difficult, that's why I went for a listener (the Behaviours plugin certainly can't do it, are you thinking of the script runner?)

[Dmitry Nechayev]

Interesting. I used a simple fresh Jira install tuned to a dedicated MySQL DB with only 1000 users configured (no issues, no custom fields, no versions, etc). Then I started to increase number of projects in 500 increments and monitor performance. CreateIssue was surely the most affected: just the time to open a dialog after clicking on CreateIssue link increased to ~15 sec with 3500 projects configured; delay inside the dialog after selecting (changing) a project was also considerable. I replicated then a config to a production grade environment at reputable Jira hosting provider but got even worse performance. Some simple permissions tweaking (like replacing jira_users with Anyone) had no effect

Anyway, this is a subject of a separate thread for sure. Thanks for helping me with this question!

[Renjith Pillai]

3500 projects? Seems to be a big number. And how many issue types do you have?

[MattS]

The easiest way to approach this is probably a custom issue create screen. You could have a components input field, and use some mapping to select the JIRA project. Then the user clicks Create and everything is as before.

[Renjith Pillai]

Going back to your original question, I assume that you mean by 'old components' is a fixed list of components coming from your old system. Am I right? And also that this component decides which actual JIRA project the issue finally goes?

My thoughts (very similar to what Nic's second option):

• Create an umbrella project which contains all the components from your old system in the JIRA component.
• Make the Component field mandatory.
• Have only one issue type.
• Use Script Runner plugin to have post function to create the issue on the right project, close this issue with a comment getting added with the issue id of the new one (or why not even do a 'Move Issue' to the right project).

https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner

[Dmitry Nechayev]

<continuing from the last comment>

In this thread I was mostly interested in the 1st customization. Thank you for your advice - I will deinitely try it out

At the same time I wonder if it would be feasible/possible to simply override createissuestart dialog/class (or, better, createissuedetails) and add component input field with a logic to populate project upon choosing a component. I gather it would be more involving than simply to use a Script Runner but if we care about final user experience and performance, then it might be more preferable - unless you don't recommend it for some other reasons

Sorry for the long post. Thanks a lot!

[Dmitry Nechayev]

Thanks a lot for your attention!

Question about #of issue types: I used a vanilla Jira config for my performance tests - all out of box, except for users (1000) and projects (3500). I do not expect issue types to proliferate much in our production version

Now going back to the original question. You were right in your assumptions. Let me give more background to this - I am sure this will sound familiar to you (saw similar posts already). Our "old" components (3500 in number) are entities (software, doc, localization) existing in the form of versioned builds against which bugs are opened. As such they very much qualify to be represented as Jira projects. However, on the other end, these components are logically grouped in products (~70 in number) with, usually, a single team behind them. More to that: product features are usually registered against products and then eventually get broken down on improvements against particular components (where they are implemented in specific builds). From that end, it would be probably logical to have products as Jira projects

Now after playing with different options we started to lean to an idea of having our products represented as Jira projects and our components as Jira projects' components. However, to make this usable, we need to make at least two major customizations in Jira:

· Precede project selection with component selection on Jira UI (as bugs are opened against components). Project would be picked automatically then based on existing component->product (=Jira project) association and would ideally be made read-only. To implement component (and project) change, it might be perhaps easier to create a new operation in relatively simple plugin

· Customize all version fields (affects, fix) so that only a limited selection of versions from a project (=our product) pool relevant to a given component will be shown/made available

[Renjith Pillai]

Okay going by your statement that the products now map to JIRA projects, the umbrella project concept should suffice. Also why not try out to remove 'Create Issue' permission from all the product-projects so that it is not possible to directly create an issue in a product-project. Everyone has to go via the umbrella project to create an issue which gets moved automatically to the appropriate product-project.(I have not tried this myself though).

The last point, I guess you need to develop a custom field to handle versions based on selected component (may be Behaviours Plugin can help, with some kind of validation)

https://studio.plugins.atlassian.com/wiki/display/JBHV/JIRA+Behaviours+Plugin

[Renjith Pillai]

Choosing a component first will not be logically possible in JIRA. So it would work like this:

• User selects the umbrella project
• Select the component from the 3500 components (this is going to be a performance issue and administrative pain :(
• Creates the issue
• It gets moved to the right project/component in the post function.
• You need to store the old-component vs jira-project/component in some external data source to refer in the post function.

Writing a plugin to override the Create issue is beneficial as it can show all the components from all the projects in the first screen and in the next screen re-direct to the original create issue with Project and component pre-filled (only doubt I have is that, once we override the createissue screen, I am not sure, whether we can still refer to the default create issue screen of JIRA)

[Dmitry Nechayev]

Great! Thanks! I will definitely try it out in the next few days and will let you know results

[Dmitry Nechayev]

Well, I did not succeed. I tried both listener and post function as described, for example in:

https://bitbucket.org/jamieechlin/scriptrunner-public/src/7c7cb23511a2/src/main/resources/com/onresolve/jira/groovy/listeners/MoveIssueListener.groovy?at=default

after adjusting to 5.2 API I got the same exception in both cases (this is the top of the stack only - to fit the comment size). Could not really find any advice on the boards or elsewhere how to use MoveIssue operations and how to avoid this exception. So I am stuck...

2012-12-25 17:54:51,230 http-bio-8180-exec-19 ERROR [500ErrorPage.jsp] Exception caught in 500 page Cannot forward after response has been committed
java.lang.IllegalStateException: Cannot forward after response has been committed
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:339)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:329)
at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.dispatchView(JiraWebworkActionDispatcher.java:314)
at com.atlassian.jira.web.dispatcher.JiraWebworkActionDispatcher.service(JiraWebworkActionDispatcher.java:205)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at

[Renjith Pillai]

Could you please post the post function code here?

[Dmitry Nechayev]

I uploaded a script (create_post.groovy). Looks like the exception is caused by a call to moveIssueConfirm.doExecute(). When I removed that line, the exception disappeared, but neither was any update applied to an issue