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
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:
(There may be other fixes, those are just two that sprung to mind for me)
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
3500 projects? Seems to be a big number. And how many issue types do you have?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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):
https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
<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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Choosing a component first will not be logically possible in JIRA. So it would work like this:
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Great! Thanks! I will definitely try it out in the next few days and will let you know results
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Well, I did not succeed. I tried both listener and post function as described, for example in:
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Could you please post the post function code here?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.