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!
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!
Hmm, that sounds odd - I've used much larger installations and not seen any degredation of speed on create issues.
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?)
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!
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):
<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!
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
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)
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)
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
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs