Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Ability to change resolution

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:[TEAM-143] Client onboarding process - Jira - Mozi.png

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?

4 answers

2 votes

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)

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

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.

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?

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.

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.

1 vote
Daniel Ebers Community Leader May 03, 2021

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, you are able to add a drop-down menu to edit existing resolutions if you add 'Resolution' to the issue screen
Configure Screen - Jira - Mozilla Firefox 2021-05-.png

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.

Like Alex Fox likes this

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

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.

Like Nic Brough _Adaptavist_ likes this

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

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

Suggest an answer

Log in or Sign up to answer
Site Admin

Community Events

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

Events near you