|
History
| Log In
|
|
|
|
"Priority" and "Resolution" are the most important parameters, which I would like to be project (scheme) specific.
It would be very helpful. Hi,
These will be implimented in the 3.4 release, due out in mid October. For other features due out in 3.4, please refer to: Cheers, Narrowing focus in subject, since issue types / project is done for 3.4 (see
Is there a Fix Version for this yet?
Desparately waiting, Stuart,
Sorry but these did not make it into 3.4 due to the size of implementing Issue Types per project. We still have not scoped any future releases as we try to make this as flexible process aspossible and only scope those issues we consider most important for that release. As such, we can not give a version or date that this is planned for. We will post any updates to this issue as comments. Cheers, Nick Our preference would be thus:
1. Priorities Resolutions by project would be a great feature.
Our company bought Jira for the software development departmente but now other people wants to use Jira, for example the people who care of buildings. So resolutions for software development are different from building care. Alvaro Alonso I agree that this is needed.
Our company not only uses JIRA for software development but to track business processes and projects as well. This feature would definately aid in the flexibility of JIRA for us. Cheers, Michal. We're most interested in restricting resolution values based on issue type. For example, tasks can be completed but not fixed, whereas bugs can be fixed but not completed. Priorities and status by type might also be helpful, but we don't have an immediate need for those features.
Same feeling as predecessors... priority and resolutions should be more flexible (via schemas), and could be associated with projects, at first, and then also with issue types.
cheers, Given that the most of the other attributes in the application are configurable and additionally since the Enterprise version is marketed as being able to support separate groups, this functionality seems to be lacking in support of the latter. We have other groups within our organization that have distinctly different requirements than we do and we simply cannot share same Priorities, Resolutions and Status' globally across the installation. This is something that we need and seems like a reasonable and logical extension to JIRA.
Regards, Please add Priority Schemes soon! I think everyone will find it very useful when implementing JIRA in different contexts in the same installation (i.e., software dev, end user support, etc).
Different resolution types per project would be great for our work, too. Is there any progress?
I fully agree with all my predecessors
Especially when counting in projects facing different customers, the need for adjusting the environment (such as priorities, naming conventions, etc.) is essential.
Could you please give a time estimate on the implementation of these features? Thank you very much! Regards Andreas,
In regards to this issue, it wont be done in the next 6 months. In order to do this we first need to clean up the administration area. If we did it now, the administration area would be a nightmare. We are planning on a simplification of the admin area in the release after 3.7. We are planning on a revamp of the whole filter area in a future release along with project administration. We have no concrete dates as of yet. Cheers, We host mulitple software and hardware projects. Each project is different and therefore they all need a different default for Priority.
Thanks Agree with the comments previously posted. We also have the need to have separate priorities by project. It would also be benefical to have this flexibility not only at the "Project" level but also at the "Project Catagory" level. Also would find this beneficial for all the schemes and not just the ones noted throughout this case.
We here at SecondFloor use JIRA for a wide scale of different development and project management projects for a range of different clients. To continue delivering the best results and solutions to our clients we really need this implemented.
So Atlassian please help us out and implement Priority and Resolution scheme's as soon as possible, i couldn't imagine other JIRA owners not wanting to have this possibility in place ! I understand the need to revamp the admin screens - they're getting more complex each release - but the lack of project-specific resolutions (and by reading comments above apparently for lots of other people as well) a major limiting factor in everybody's use of JIRA in projects other than software development. please reconsider putting this higher on your list!
For our teams the sequence of these requirements priorities are:
I just spent a dozen hours getting my head wrapped around IssueTypes and Screens...easy...then IssueType Schemes and Screen Schemes... ouch, my heads starting to hurt... next up, IssueTypeScreenSchemes.
Arrrrrgh! Must...stay...calm. Breathe. Okay... I can deal... Next up, create some custom fields and a custom Workflow... oh man, I'm gonna need some Ibuprofen for the pain. And after all of this, I can't change the resolutions...so my cool looking Custom IssueType, with it's custom Create and Edit screens, only in the context of my project... has to use the global resolutions. Please just shoot me now for telling the Boss, "Sure, Jira is flexible enough to create a seamless user experience for more than just your basic 'bug'!" Sign me up as a beta tester for this when/if it gets scheduled. Tim - as a seasoned JIRA user, I still get a little flustered with setting up the screen schemes and field configurations, but eventually I sort it out
 . It's the old software axiom - with greater flexibility comes increased complexity. Anyway, I am using the resolutions per workflow successfully. What I didn't understand is why you would want/need them on a create/edit screen? Surely you can't have a resolution on a Create screen, and don't need one (and shouldn't have one) on an Edit screen. Resolutions should only be modified by a workflow operation, in which case it works great. I even have a workflow transition step called "Correct Resolution" so I can fix a resolution. If you can't figure out how to get the resolutions per workflow working, post a note on the user forum. Thanks Neal – the resolutions per workflow hack is interesting, but I may not be able to use it.
Why not? It relies on "exclude", not "include" – so any new Resolutions will pollute the screens of every project unless I update the workflow for all of them. With ~300 projects, adding more daily, with many workflows, that could turn into a maintenance nightmare. This is similar to the Global Issuetype pool that dumps new issuetypes into every flippin project that isn't associated to a custom issuetypescheme. PS. I'm not putting the resolution on the Create/Edit Screen... I was just noting some of the flexibility and customizations I've made... and I'm sad to see that resolutions are not as flexible as most everything else. Indeed. The Exclude "hack" is not enough. But I also need different default resolution values for different projects.
In a lesser degree this also goes for priorities and status. Ray - I'm with you on the Resolutions and Priorities
The resolution exclude hack works, but I've got 75 projects and nearly as many workflows, and I can confirm Tims comment about a maintenance nightmare. I actively tell people it can't be done to avoid it! Resolution/Priority scheme by project would solve most of my problems with them, and doing it by issue would be good too. But Status is determined by where an issue is in the workflow - you could have a hundred status on your list, but if your project/issue is only using three, you'll only see those. Is there something I'm misunderstanding? This feature is very much required for us. Waiting for it!
We got the "impact" custom field, and i want to select an option like "high", and i need the priority to change its status to blocker (for example) automatically. If i choose the impact minor, the priority must be low.
Flávio, I don't think that's anything to do with this improvement request. We're asking for the ability to have different lists of resolutions and priorities by issue and/or project (rather than the current global list).
I think you need to look at writing a post-function for your workflow to do this for you. I had commented, according to the issue JSP-12907.
Could you help me on it? Flávio, we're just JIRA users. We don't have access to your support request. And I agree with what Nic said. Even if this improvement were implemented it would not accomplish what you want. On the other hand, it would perhaps eliminate the need for the custom field, as users could only select priority Blocker or Low for the project, assuming you don't have one list for some users and another list for other users.
Neal, I can't let the users select the priority he guess.
The users will always select blocker, to have their issues priorized. So i created the field "impact", then according to the impact selected, i need the priority set automatically. I think this is not possible. tks Flávio,
This is not really the right place to discuss this - the improvement request will not really help you much with your requirement. Can you try searching and posting in the fora instead - http://forums.atlassian.com/forum.jspa?forumID=46 Just registered my vote for this. After migrating a load of other processes into Jira, we're looking at moving our customer support call logging across as well. Our support is dictated by SLAs, which are defined in terms of different priorities than those currently used in our Jira installation.
I guess we could get round this by implementing a new custom field to hold the Support priority, but that's going to lead to a lot of confusion for people. Resolutions come a close second. We need to pick different resolution values for customer issues than those we'd put against internal IT issues for example. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Open
Major
Priorities, Resolutions and Statuses per project / issue type
So it would be possible to say, that only certain resolutions are presented when an issue is moving to a given status. For example, only present "cannot reproduce" and "invalid" resolutions when the issue is being transitioned into the "Rejected" status, and the "Fixed" resolution when the issue is being "Accepted".