Hello, I want to keep the ability to edit resolution without moving tasks between statuses to clear and set new resolution via post-functions and screens. It produces too much spam for clients and takes too much effort to do it via bulk change (w/o e-mail notifications).
I managed to do that in the test project:
Problem is, it was a while ago and I was testing another thing, so can't recall how I did that :)
I've checked workflow, nothing there. Where I can enable the Resolution edit feature?
No, you do not want to do this.
Resolution should be empty when an issue is in an unresolved status, and set to something when you move the issue into a resolved status.
If you put it on edit screens, it will be set on any edit. This means that you're creating and editing issues that are already resolved/done/ended at the wrong point in their lifecycle.
So, as Alex mentions, you will corrupt your data.
You need to be setting and clearing resolution on transition, not by editing it.
This does beg the further question though - why are you editing resolutions?
One person mistakenly closed a task with the status Declined and the resolution 'won't do'.
The supervisor after a review of closed tasks decided to change the resolution to 'Not a bug'.
In order to do that, he needs to:
1. re-open the task to clear resolution and put it to Incoming
2. then move it through a couple of other statuses (and corrupt our report about statuses and deployment record which is used for PCI DSS)
3. then he needs confirmation from approvers (at least 2) because you cant bypass that stage (PCI DSS)
4. Finally land to 'Done' and in a pop-up window select the correct resolution.
So we corrupt at least 2 reports and the history of the task. I don't know what you guys talking about, srsly.
That's not corrupt, that's using it properly, but not having a sensible process for correcting mistakes. You've just got a user who had the wrong resolution - that's the "corruption" here, not the process.
You could easily reduce the impact of this though - add a transition from Declined to Declined with a screen on it for amending any data you want (including resolution)
For a team-managed (next-gen) project, I'm glad to say you can't do it. The system won't let you make that mistake.
For a company-managed (classic) project, you can edit the edit screen, and add the resolution. But you must remove it the instant you have finished correcting the issue, otherwise you will corrupt your data.
Why if any status can have any resolution? How that can corrupt data?
Because people tend to do I mistakes and select incorrect resolutions. We have complicated workflows, so in order to change the resolution, you need to bounce tasks over 5-6 statuses, sometimes including CAB and at least 2 confirmations from request participants.
Resolutions should only be on statuses that are considered "Done", definitely not any status.
When I say "corrupt your data", I refer to any reports you've generated with resolution statuses. You will see issues moving through different resolutions but remaining under one status, which is not how Jira is designed to work.
Changing a resolution and not a status is bad practice. The resolution should change with the status and not really need to move.
While I absolutely agree to all the warnings from Alex and Nic above using Script Runner we used to fix resolutions in the past several times.
This however needs to be a well-thought through action - probably this is why only admins can do it.
Please be advised that you would need to have the App on your instance - so probably this convenient option is not suitable at all.
It took a while but I've found all the necessary info. Here is a small recap in case someone will be looking for the same thing:
1. Here is a feature request https://jira.atlassian.com/browse/JRACLOUD-69556, you are able to add a drop-down menu to edit existing resolutions if you add 'Resolution' to the issue screen
2. How to add that to the screen? Follow this guide
3. About data corruption - all you need to remember is if an issue got resolution Jira considers it as 'closed'. So as long you are changing resolution within statuses which you treat as closed you are totally fine. I
Jira designed to be flexible, and my projects have multiple resolutions for each 'final' (green) status. For instance status 'Declined' means for our teams no one been working on it and resolution is an indicator WHY i.e.: Not a bug, Duplicate, Client Declined etc.
No, this is exactly what we said you should not do. It will corrupt your data.
Again, if you put the resolution field on the edit screen, then every edit will resolve your issues. You will be corrupting the data on every edit. Please see my answer and last comment in the thread from the 27th April.
So you're happy to corrupt your data, have unresolved issues that are resolved?
Atlassian support did not provide you with this solution. They will have told you what I said before - you can put the resolution on the edit screen temporarily and remove it later, before you corrupt your data.
It's very confusing that you are insistent on doing it this way. The feature request you linked even has a warning about doing this sort of thing:
It is important to note that this is not a good practice to use the resolution field on Jira
The behavior of not being able to set the resolution in the new issue view is more optimal to avoid the common configuration mistakes by users of setting the resolution field incorrectly in the old view. For a quick background in Jira, the resolution field plays a special role. When the resolution field is populated, the issue is considered to be closed in Jira. On the other hand, when then the resolution field is empty, the issue is considered to be open in Jira.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events