|
"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. Each of our projects have different Status and resolutions that are specific to our line of business. However, we cannot presently have resolution and status per project. This is becoming a limiting factor for some of projects to be moved from a legacy system to JIRA.
Hi Arganjan.
You can have different Status in different projects - in fact you can do it by project and then issue type. So not only can you have different workflows for each project (Status is determined by workflow), you can also have different status by project AND issue type within project. e.g. "bug" in project 1 can have a different set of Status to "bug" in project 2!. However, please bear in mind that I've only ever used the "Enterprise" edition of Jira (since 2.6.1). I've got a feeling that if you are using Standard, you can't change the workflow and Status at all, and if you're on Professional, although you can change it, you can only have one global workflow. You might want to investigate an upgrade? But you're right about resolutions (and priority) - exactly why I commented, voted and am watching this request. It's the very first item that went on my "I can has" list since I started using Jira and has always been at the top of the list. to add to the above ... it is possible to have resolutions per project as well, as I stated above. But it's a workaround, and difficult to maintain because every time you add a new resolution to the system you have to edit the workflow to exclude it.
different projects for multiple teams - all are currently using the same priorities - please atlassian add this
 - Voted. We would be happy with a first step in the near future: Priorities on a project level in the same manner like issue types.
Why is this feature still not implemented? Currently the only way for our seperate teams to use JIRA is to purchase multiple copies of the software, which is totally unacceptable. We should not be forced to shell out another $6,000 because of a feature limitation.
Nick,
Thank you for your feedback. The main reason for why this is not done, is that we have a lot of fature requests, and while we would love to get to all of them, at the moment we are trying our best to implement as many features as we can, as quickly as we can, with the resources that we have. Cheers, P.S. An Enterprise version of JIRA will currently set you back US $4,800, but I know this is not the main issue. Anton,
We all probaply know that there are offcourse many feature requests that need to be worked on, and bugs/issues to be solved for new release(s). i Sincerely hope Atlassian will try and implement this in the near future, we have been waiting for a long time. Kind Regards and keep up the good work, Maarten van Wensveen For me the issue is less about cost, and more the logistics of running multiple JIRA instances – the ability to migrate data between them is extremely limited.
If this has to be done in stages, I would vote Resolution per Issue Type to be at the top.
If indeed this has to be done in seperate stages i think the proper order should be like mentioned above by other people.
Priorities allways beeing the highest priority, because effectively this is the only part of JIRA that can not be controlled by customizing workflows. (wel...ok i could be done but it would defenatly not be a good solution) I tend to agree with Maarten on this.
I'd like to add my voice in support of this. We're just configuring JIRA Enterprise and Confluence Enterprise for our site and the values we'd prefer for Resolution are quite different between (say) the helpdesk and the dev team.
The ability to configure a scheme for Resolution, and to a lesser extent (for us) Priority would be a great usability aid. We are also in great need of this feature. We host on our Jira system multiple customer projects and not all have the same resolutions and priorities.
It might need more votes, or I don't know. When 240 customers ask for a feature, normally it should be an important one, but maybe Atlassian has more than 1 mil customers and 240 are too few to bother?
I'd like to comment this as well. We are using JIRA with many different projects, and it is frustrating not being able to create individual priorities and resolutions for the different projects. Hope that Atlassian are planning to do something about it.
For companies like ours who use JIRA in a multi-tenant environment, project specific priorities and resolutions are a must.
Status is already covered (in Enterprise, you can have multiple workflows, and status is a function of the workflow), but priorities are the most important for us - there's no workaround other than replacing it with a custom field, which renders half the built-in reporting useless. We work round Resolutions by not using the field, except to set/unset it silently in the workflow.
Ditto to my forebears' thoughts.
Is there a good writeup anywhere on how to use custom workflow mods for this? I have only one of many projects for which I need custom Resolutions values. The rest of our 30-some projects are fine. Can I copy the ootb resolution workflow and use a custom field in place of the ootb Resolutions? I'm sure I've seen a detailed write up somewhere, but I can't find it now.
You've got the right idea though, copy existing workflow, hide "system" resolution for the project, and create your new resolution custom field. Then, in your new workflow, identity the points at which an issue is regarded as "resolved" or "unresolved", and look at the transitions, adding a post-function to set or clear the "system" resolution as appropriate (e.g. in the default workflow, the resolve transition should set resolution, and the reopen should clear it again) Any plans for when this will be added? My company has about 29 projects in JIRA right now (and counting!) and could really use different priorities between projects.
We are waiting also ...
Any news? Cheers, On my side, I do not yet find a clean way to do it by overriding components.
With more than 250 projects (more than 1000 scheduled) configured with 10 Issue Type Schemes, we are very interested by a such feature. We are ready to use an temprary patcj to resolve this requirement. Rgds This would be huge for use. In our company, we have 15 or so products that use JIRA. Of course, not all products like to use the same priorities and resolutions. It would be great just to have the priorities as we worked through the resolutions.
When can this be implemented? Is there work beeing done on this issue?
This issue has been raised 4 years ago, carries 273 votes and has an amazing 149 people watching it....i think it is obvious this is something that Atlassians Cliënts and community really wants added.. The flexibility in creating projects with these added functionalities is something we at our company and our Cliënts that use JIRA aswell really are looking for, i think i can go as far as saying that this flexibility is something that at least one of our cliënts see as a go/no-go feature in choosing for JIRA as an Issue registration system and Business Process tracking system. The last time this issue recieved an update visible for us was: 5 months ago. Could you please give some insight in why this feature is still on the "Unscheduled" part of the planboard? Critical for me as well. Up to now I've been thoroughly impressed with the flexibility of Jira, but this limitation runs counter to that whole premise. It basically forces multiple instances to accomplish anything close to a domain specific issue management system.
Hope this makes it into the next release. Thanks, Just to add one more interested watcher to this issue.
I'm running into the same trouble while trying to separate priorities for our software development project and our customer ticket handling project. This is an automatic reply. I am out the office through April 29th. I will read your message when I return.
Thank you, What happened? This was to be in a release in October 05 (is 3.4 correct?) <http://jira.atlassian.com/browse/JRA-3821?focusedCommentId=41367#action_41367
>, and here we are almost 3 years later and it is pending.
Please give an update. Legendary Support is falling down here. JIRA has incredible flexibility, but here we are seeing a major breakdown. It is as it were, "half baked", with respect to the ability to customize at a project/issue/status/resolution/state level. You are half the way there. Please close the gap! Thank you - Jordan Atlassian should note this issue has been open since 2004, has 302 votes (number 4 in popularity). How about some indication of when this gap in configurability will be closed.
I should that the request for this functionality is indicated in numeroud linked issued and unlinked issues. If you add up all the votes its probably over 500! Would love to see this feature added. Most lacking features in the past I have been able to work around by writing custom plugins but really need Atlassian to sort this one out. Is starting to cause more pain as the size of my JIRA implementation keeps expanding and each project manager wants different config for their area.
Amazes me with all the schemes in JIRA that there aren't any for the priorities, resolutions and statuses. Like others have re-iterated given the number of votes and how long this issue has been around would be great to see some movement on this. Thanks Hello,
Any news on this issue? A priority scheme by project and issue is really needed - we're forced to use custom fields and clients are confused and irritated having to fill out two priority fields. Kind Regards, I'd like to add my voice to the throng of people requesting this feature. It's very important for my company to be able to completely federate our project workflows and priorities/resolutions goes hand in hand with this. This issue could easily be a deal breaker for us every using the product company wide.
Thanks We'd love to see this feature added as well.
Previously in our company, we've used JIRA primarily for a bug management system. But more recently we've also been using JIRA for other product management. With these new additions, more project managers are utilizing JIRA and each have their own request to configure their project differently (especially when dealing with priorities). Ditto to the other comments regarding the need to be able to tailor priority schemes by project in order for JIRA to truly be useful in an enterprise environment (or even for a medium size group of users with different workflow needs.
"Resolution Scheme", that's exactly what we need.
Too many resolution options confuse users and offen let them make a wrong choose. Then hurt the value of statistics result. This is the 2nd hottest improvement request now. Hope to see a resolution soon. The ability to tailer Priority by project would be most welcome, I second all these posts. Our reason is that, unless your projects all happen to software development projects/bugs, the Global values of "blocker" just don't make any sense. For a simple task-tracking project, e.g., we'd like to use A,B,C.
I too have had internal customers requesting the ability to create the following for each project:
Hi, adding my vote. Resolution schemes is an absolute necessity for us, as our users get more and more confused by the rising number of needed resolutions. Please provide an update about Atlassians stand on this one.
Kind regards, Niklas Hagen 3.13 is really great and has lots of issues fixed... this blog entry (http://blogs.atlassian.com/news/2008/09/announcing_jira.html
) highlights the important issues fixed in that release
Shareable Dashboard ( but there is almost 350 votes on this issue. it was supposed to be in 3.4 and then 3.7 and now? if this is a revenue issue, say it. if it's too hard to implement let us know, but the silence is deafening... atlassian please respond. I'd love to see this fixed but my second preference would be to know why it's not thanks, i still love and recommend all your products. New user here. Just voted for this issue since it impacts our ability to use the enterprise version for, well, our enterprise. Without it, it is more of a departmental tool requiring multiple Jira instances. When is this scheduled to be released?
We are evaluating JIRA whether it can be used in our company. And this feature is essential to make decision whether to buy it or continue using Bugzilla.
On 09/Oct/05 Nick Menere [Atlassian] wrote: Sorry but these did not make it into 3.4. This was three years ago.
We are at 3.13 now and still this basic, fundamental feature is not yet implemented. What is this? It does not take a support professional to understand that this is a feature that should have been implemented in ver. 1.0. Does Atlassian developers have the wrong focus? Does Atlassian know what their customers need and want? Hurry up now guys/girls get this done ASAP ( skip the coffee break if necessary ). //Michael We are evaluating JIRA whether it can be used in our company too. And this feature is essential to buy it.
Atlassian,
Please let us know the status of this New Feature request. We would need ability to have different Priorities per Jira projects and we would need it now. /Olle Also just ran into a case where we wish to differentiate resolution choices per project. I'm amazed at how long this request has been outstanding, but added my vote regardless – robert
Hi, it would be great to have this as well.
Someone in our team also raised it almost 3 years ago regarding resolutions. If it is not possible for you to split all of these areas for the next release, how possible is it to split one area per release? regards, Of course it would make live "comfortable" is this issues would be developed, however we were forced to implement a "scheme" by using the properties (triggers) of transition. Therefor you "attach" the desired values of resultion, status, priority even.
We've implemented this succesfully within our organisation, off course you must define more transitions than you would normally do, but it forces one to think thouroughly concerning your "workflow design". "Prior 1 - development" of "Prior 1 - Risk" have not only a different meaning but are implemented in their specific "workflow". It also enables a (business) environment to mature. It forces one the "specify" prio 1. We would welcome the development of this issue, however it isn't a constraint on our development with JIRA Some developers approached me and asked if I could change the priorities for their issues in their projects, and I naturally assumed that it is easy since JIRA is so flexible with these matters. But it looks like I was very wrong, this basic core feature is missing for the last 3 years. Is it too difficult to implement, or what?
Same as with Evgeny. I was utterly surprised that it is not possible to change the default priority on a per project basis. Vote +1.
And, even more disappearing, no comment from Atlassian on this since 28/Aug/07 03:52 AM. Votes: 383 Should be quite a motivation, eh? Carsten This was actually requested as far back as '02.
https://63.246.22.60/browse/JRA-980 If you don't want to go to a site with a bad cert, here's the general idea: Participants: Mike Cannon-Brookes [Atlassian] and Objectware Description Mike Cannon-Brookes [Atlassian] added a comment - 19/Nov/02 01:16 PM Thanks for the report - we have considered this before, but won't be including it in 2.0. It makes the UI just too confusing in too many places. One workaround is to define a custom field to represent priority or resolution for the particular projects you want to specialise in. Another alternative is just to use a different copy of JIRA for each client - we are working to make this more seamless at the moment - links between JIRA copies etc. This is our recommended method (obviously it depends how many clients you have!) Cheers, Honestly, 6 years? Come on guys. Vote +1, this functionality is essential but looks to have dropped off the radar.
This would actually make the User UI LESS complex and/or confusing. Example; we have two issue types, Defect and Question. Defect Resolution type is generally 'Fixed' and Question resolution type is generally 'Answered' They mean the same thing but one is just more logical. Having both just adds confusion.
The admin side would be gaining complexity, but at this point, I am fully familiar with the idea of a 'Scheme' for certain configurations and that a Scheme is tied to a project. Vote + 1. Issues Priority schemes please.
Since we have 406 votes this issue is number 2 on the list of open, most voted issues. Maybe this helps....
btw separate values for Link options (from the Issue Links) would also be handy.
I am really surprised that for the last several version this was not implemented. I do not believe this will break much.
This would "clean up" a lot for us. We don't like users seeing every resolution possible in the system and it promotes confusion among the project users.
looking at the list of comments, it seems this has been a long standing request. We also have an enterprise jira installation and the ability to customize the priorities on a per project basis would really improve our usage of JIRA. Due to a lack of this feature, we are actually not able to use JIRA for certain projects.
Come on guys, 5 years and no progress on this? That's a bit sad, this is a great bit of functionality for software architects to use this for workflows outside of development teams.
I have bought this jira product for three different companies I have been at, get this in the roadmap ASAP!!! Can somebody please stop the mailflood from Sasken ?
lol - so is there a Jira ticket for this calamity?!?
The louder the customer base, the more attention this might get. This is a Critical priority in my opinion, and only because I can't create a priority scheme for my projects with different priority types! We use JIRA for software development and helpdesk and we've had to work around this problem for some time now!
This is very much needed so we can start using JIRA on the "business" side of our company - We're pretty much keeping it to IT for now.
Has anyone thought about doing a .vm hack for this? For instance, the velocity macro file to show the resolutions could decide which ones to show based on the issue type, current project etc.
After 4.0 is released (which will resolve JRA-1560) this will be the highest voted for request.
We will look to break this issue up into smaller deliverables. In reading all of these comments, it seems most of you would prefer priorities per project, so our focus would probably be there first. Please comment if you think otherwise. I have moved this issue to our short-term roadmap, we will estimate what is required to introduce priorities per project and weigh this issue up against all other issues that we are considering for our first feature release after 4.0. I understand the frustrations that many of you have due to the length of this issue being open. As we progress internally with this issue, I will be sure to keep all of you updated. Regards, Brian I think Resolutions are more important than Priorities.
Thank you for the update.
I'd agree with Mark above that Resolutions are more important. If I had to choose between having Resolutions per project or Priorities per project, I'd say Resolutions too. My reasoning is that priorities are almost always a linear thing from High to Low, but resolutions are much more varied, and much more dependent upon the local process in place.
I agree with the Matt, the resolutions are more important to me as they tend to vary per project while the priorities are a company wide standard.
I also vote for resolutions. Thanks for keeping us in the loop! I would vote for priorities, but I want to be very clear that I would like it to follow the "scheme" format that the other "per project" things have, such as Notification Scheme, Issue Security Scheme, etc. Our users see issue types as configurable per project and wonder why priorities can't be done the same way (especially our help desk which does use a different priority scheme than low to high).
I also think that the resolutionsw should have a higher importance than the priorities.
For us, priorities are more important. This is because we are using Jira both for our helpdesk ticketing (with SLA) and for development/QA. Both have different kinds of priorities. As for resolutions, they are pretty similar.
Please concentrate on resolutions first! We use several workflows with very different resolutions. Up to now we "disabled" the resolutions which are not used using the properties per workflow step. But each time new resolutions are added, we have to change the properties of nearly all workflow steps of all workflows. That is an amount of work!
I think priorities, resolutions and last but not least issue type per projects are all in the same importance level, because a regular issue tracker cannot tie the projects with global properties.
Our jira projects live in different cycle, so we have to customize every properties or we have to make a compromise for our clients. The second one is wrong way unless you want dissatisfactions for the users. Defenatly priorities for us. We are running a multitude of development projects which can have different priorities depending on the clients priority scheme which in most cases we have to follow.
I find both Priorities and Resolutions should be selected and managed per project, just like issue types. This would clean up alot of the current clutter in the Jira projects for us ( and I´m sure for most admins/users ).
For me, "Resolution per Issue Type" is the most important (yes, yes, this is enclosed in the summary of this issue!).
Otherwise, Resolution and Priorities per scheme , but certainly not only by Project ! Also, something critical, otherwise, we would have a regression, is to keep the ability to search and filter issues of different projects (or relying on different schemes) alltogether, based on their Priority and/or Resolution,. Also, we need the ability to sort or Priority Finally, I'm wondering about the utility, and moreover, the usability of dealing with different Priority "schemes". Indeed, let's imagine a developer working on two projects, whose Priority Scheme are "High, Medium and Low" and "Major, Important, and nice-to-have" respectively. Should he first work on the High issues, or on the Major ones??? In other word, How should and would behave a "Sort by decreasing Priority" on the issues he is assigned to ??? So, again, for me, despites it looks convenient to have several priority schemes, I'm afraid, at the end, it will only be a pitty to manage. Only Resolution per issue type are meaningful. And if several Priorities "schemes" are implemented, coherence between them should be supported (filtering, sorting). Concerning priorities (previous post), if it is implemented in a good way, I don't see a problem in managing priorities. It would be nice if priority schemes implement SLA's in some way.
How about you just cradle this ticket, create two new ones (one for priorities and one for resolutions) link them here and see which one gets more votes.
As I'm using jira in large organizations, I think that Priorities are more important. If you implement HelpDesk,development and other projects in Jira, you must use different priorities. Resolutions can be managed with custom fields with very little effort.
I agree with Mattew Block, close this issue and create 2 new ones. I want priorities and resolutions both fixed with schemes at the same time, since they are equally important for our corporate implementation of JIRA. Status schemes aren't has important for us, but a welcomed improvement.
I solved the priority problem with a custom "severity" field. I am using priorities to put the issues in order, and severity shows me what the customer would like in SLA.
Salutations,
Any news for the resolution per issue type? Thanks. Resolutions based on Issue Type are the highest priority for us. We are using JIRA for bugs as well as JIRA with GreenHopper for all of our task tracking. We need to prevent people from marking Tasks as fixed and Bugs as completed.
Both things,please...
Priority schemes, please.
Resolutions per Issue Type would be great.
As seems to be the case for many users, we (would like to) use JIRA for many things, from bug tracking to task management and Q&A. [BNPPARIBAS - CM - GECD]
resolution per issue type would very fine, Currently, we use custom field in waiting this improvement. Hi,
Priorities Scheme become a urgent matter for us as well. We have a totally different system for different teams. Do you have any ETA about this ? Will this be implemented in Jira 4.0 or not ? Please Atlassian, give us a feedback about this issue. Thanks Martin Poirier |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Short Term Roadmap
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".