Ability to change resolution

[Alexey]

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?

[Nic Brough -Adaptavist-]

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? 

[Alexey]

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.

[Nic Brough -Adaptavist-]

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)

[Alexey]

@Nic Brough -Adaptavist-thanks for the tips, meanwhile, how to enable the option seen on a screen in my original post?

[Nic Brough -Adaptavist-]

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.

[Daniel Ebers]

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.

https://docs.adaptavist.com/sr4jc/latest/features/built-in-scripts/bulk-fix-resolutions

Please be advised that you would need to have the App on your instance - so probably this convenient option is not suitable at all.

[Alex Fox]

Doing this will likely end up corrupting your data. The resolution field shouldn't be editable outside of transitions/workflows. Why do you feel the need for users to be able to switch through resolutions on an issue?

[Alexey]

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.

[Alex Fox]

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.

[Alexey]

Actually, those pointless status roundabouts to change resolution corrupts my data because we count how many times a task was on each step.

Thanks for the warning, but my question remains the same.

[Alexey]

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.

[Nic Brough -Adaptavist-]

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.

[Alexey]

@Nic Brough -Adaptavist- 
This solution provided by Atlassian support and it works for me as intended.

[Nic Brough -Adaptavist-]

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.

[Alex Fox]

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.

[Alexey]

@Alex Fox Dunno, I have resolution only on closed tickets thus no problem with 'special role', everything working as intended.

[Nic Brough -Adaptavist-]

And what are you doing about the open issues that are resolved?