nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Ability to change resolution

Alexey_gudeo1

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?

Accepted answers

All comments

Alex Fox_gv1ddv

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_gudeo1

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_gv1ddv

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_gudeo1

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.

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_gudeo1

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_gudeo1

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

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.

Alexey_gudeo1

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
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.

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_gudeo1

@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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management