Don't force a change in "Resolution" when Bulk transition issues to close

[Christina Fausbøll]

When I bulk change issues and transition them though our workflow from Resolved to Closed ( to remove them from my boards") i would like my issues to keep the resolution code they already were set with, when I resolved the issues. 

But as it is now, I have to Change the Resolution when i move the status. I can't unmark the "Change Resolution" and I need to choose a new value, which overwrite the value that the issue already has. 

Does anyone knows how I can change this, or if it is possible. 

When I close the issue from the issue card, the resolution option is kept, without a force to change.

 

[Radek Janata · Accepted solution]

Unfortunately, there is no solution for this problem. Resolution field (when set on a screen) is always required and this cannot be changed (see also this question). This causes bulk edit/transition action to always require filling resolution (and therefore overwrite other resolution if they are different).

Atlassian doesn't not seem to resolve this in near future:

• JRASERVER-34902 (Won't Do)
• JRASERVER-43564 (Gathering Interest @ May/2020 + duplicate to Suggestion above)

All you can do is to vote & watch & comment the latter issue.

[Jack Brickey]

WARNING: Editorial....

I don't think this is the correct answer or at least it is incomplete. You should not make the Resolution mandatory in the Field Configuration screen. As Nic so eloquently put it below...

NEVER do that.  And in a similar vein, NEVER put the resolution field on any screen other than a "transition to a closed type status".

If you make it mandatory then it is ALWAYS required and that includes bulk update. There is no way to avoid other than not make it required which is the proper solution.

[Ricky Lin]

All Atlassian needs to do is to give us the same "Retain Value" option during bulk transitioning and it'll save a lot of trouble...  Anybody might know why this isn't an option when it's available for other fields?

As of now, we're getting around this limitation by via 2 days:

• Bulk-transition the tickets grouped by Resolution.  So if 100 tickets yield to 5 different Resolution values, we'll need to do this 5 separate times.
• Temporarily change the Close screen to one without Resolution field on it and bulk transition.  This is quite an inconvenient workaround since we need to do it afterhours.

[Radek Janata]

> you should not make the Resolution mandatory in the Field Configuration screen

@Jack Brickey, you cannot make Resolution field (a system field) as non-mandatory via Field Configuration. It's always mandatory and you cannot change it.

[Nic Brough -Adaptavist-]

Technically, no, it's actually the opposite.  Resolution is an optional field.  In Jira the difference between mandatory and optional is that an optional field can be left blank, but a mandatory field must have content, from the point of issue creation and throughout its lifecyle.

But, as you know, the resolution is empty at first and only gets a value when you resolve the issue.  As it can be empty, the field is definitely not mandatory.

What is actually happening is that when the field is put on a screen for entry, there is no row in the list of options for "empty".  So it defaults to a value and the user is assumed to have selected the default if they don't change it. 

The field is optional, but you end up setting it if it is on a screen you are using to create, update or transition an issue.

[Radek Janata]

I think I can't agree. Although, the Resolution field is not marked as required/mandatory on Field Configuration (it cannot be, it's a special system field), it always behaves as a mandatory field (red asterisk nearby and the field must be always filled in if it's on a screen).

As it can be empty...

Yes, it can be empty (unset) after the issue is created, but once the field appears on any screen, it must be filled in.

[Nic Brough -Adaptavist-]

It's not a matter of opinion, it's a fact.

A mandatory field in Jira must have a value at all times. 

Resolution is empty/null for part of the lifecycle of an issue.

Therefore it is not a mandatory field and does not behave as one.

[Radek Janata]

If it's not a mandatory field, then is it optional? How one can set the empty field then? No one can.

So we can agree on that it's not a typical mandatory field the same way it's not a typical optional field. It's something in between as it's a system field and not configurable via field configuration.

In short, the Resolution field is always mandatory/required since the field appears on a screen. After setting the value, it can never became empty again (unless changed via a workflow post-function or a script).

[Nic Brough -Adaptavist-]

You do not seem to be understanding this.  I will simplify it down as much as possible:

• Mandatory means that the field must have a value at all times that an issue exists
• Resolution is empty (null) for most of the lifecycle of an issue

Therefore Resolution cannot be mandatory. 

It can be empty, and will be for most of the active life of an issue.  So it is not mandatory.

[Ricky Lin]

@Nic Brough -Adaptavist-I can see where you and Radek are coming from when it comes to the technicality of what being mandatory/option means, but do you know if there there's a reason why the "Retain Value" button doesn't exist for bulk transitioning (this ties everything back to the original thread)?

Resolution is being forced to be updated (regardless of an existing value) as long as Resolution is on the transition screen, which will screw up the meta data quite a bit if you're doing this with tickets with different existing resolutions.

[Nic Brough -Adaptavist-]

Because your transition is set up to set the resolution to the value the person puts in the field.  Retain values doesn't do anything because it's overwritten by the transition process.

[Nic Brough -Adaptavist- · Accepted solution]

Your screen shot implies you have made the resolution mandatory in your field configuration.

NEVER do that.  And in a similar vein, NEVER put the resolution field on any screen other than a "transistion to a closed type status".

(Well, not quite "never", there's a couple of edge cases, but for most Jira systems, it breaks it completely)

[Jack Brickey]

@Nic Brough -Adaptavist-, I certainly understand the second never but why do you suggest the first? It seems to me that in some scenarios you want to require the user to select a resolution when closing an issue. Is it because once mandatory in the field config it is mandatory for all possibly? And the alternative approach is use the validation property to require it for the specific WF?

[Nic Brough -Adaptavist-]

Yes, it's exactly that.  If you make the resolution mandatory, you have to fill it in (i.e. resolve the issue) when you create the issue, and you can't blank it out!

[Christina Fausbøll]

Thanks for the input.

Our "Resolved" status is when an issue has been resolved. We just move them to Closed when we don't want them to figure om out boards anymore. So it is only on screen where we resolve/close the issue. 

I'm pretty sure that it is set up by our consultant who has helped us make out workflow schemes. 

I will discuss with my team of how to change this, and I think that the validation in the transition, might be a better idea for make sure that it is filled out, than it being mandatory- with the examples that you have given us. 
@Nic Brough -Adaptavist- do you see an issue in doing this instead? As far as I have understood there is some Jira logic that handle issues with the resolutions code " Unresolved" in a particular way.  

[Nic Brough -Adaptavist-]

Yes, there is a bit of a problem.  Jira has a simple flag for "resolved" - if the field is empty, an issue is unresolved.  If the field is filled, the issue is resolved.  That logic affects dashboards, reports, searches and the display of issues in a lot of places.

You need to make your workflow and edits account for that.  Even if you never ask your users to fill a resolution, you should set it in the workflow appropriately, so that resolution is set or cleared correctly.

A properly configured Jira will:

Not have resolution on any screen other than ones used for transitions

Have resolution set as optional

Set the resolution on going into "closed" type status (generally, the ones you've got in green), either by offering the user a screen with resolution on it, or by post-function

Clear the resolution when going from a closed type status to an open type one (green to blue or yellow)

[Tom Hawkins]

We use "Resolved" to indicate "Ready to go live" (with Resolution) and "Closed" for "Live and believed to be working", so I think that it would still be a useful feature for the bulk update to have the untick which @Christina Fausbøll mentioned or some other "Retain current" (would be ok if it didn't support retaining None) even after reading the above comments and warnings, and indeed, that's how I found this page. Does anyone know if there is an Atlassian Jira ticket requesting this? Thanks

[Jack Brickey]

I would not expect to see such a suggestion. Are you saying that the Resolutuon code changes from Resolved to Closed. I would suggest that Resolution in your case would be applied at transition to Resolved and then transition to CLosed would be done when issues are “released”. This equates to removing any requirement on updating resolution on transition to Closed.

[Tom Hawkins]

Hello @Jack Brickey thanks for coming back to me. RE: "Are you saying that the Resolutuon code changes from Resolved to Closed." No, I don't WANT resolution to change, but it may do if I only run one bulk transition action and have multiple resolution entries in that bulk list.  RE: "I would suggest that Resolution in your case would be applied at transition to Resolved" Yes. 

Example Use Case:

I have 10 issues, all in RESOLVED status, 7 with FIXED resolution, 2 with WON'T FIX resolution and 1 with DUPLICATE resolution. I want to bulk transition them to closed maintaining the same resolutions. Because of facing the same as @Christina Fausbøll mentions above, I can't see a way of doing all 10 in one bulk transition, (would need one per existing Resolution value, eg. 3) 

A related issue is that I have seen instances where someone has inadvertently updated some of their resolutions because of making a single selection in that screen for a list where multiple values applied at RESOLVED point. I've now found https://jira.atlassian.com/browse/JRASERVER-43564 and am voting and commenting on it, @Christina Fausbøll suggest you do the same! 

Thanks, Tom  

[Jack Brickey]

if the Resolution is set when transitioning to Resolved status then it will not change when moving to Closed unless you specifically have something configured to require it be updated or some automation, etc. A single transition or a bulk transition from Resolved to Closed should have no impact on the resolution value at all. If you are seeing the Resolution updated during either of these actions then it needs to be analyzed to understand why.

[Tom Hawkins]

It's mandatory to be populated and not null, n Resolved > Closed, believe that is the only relevant setting, and think that is what is driving the greyed out tick, but mandatory doesn't preclude the availability of a "keep same as before even if different for different issues in my filter" option, if you see what I mean. Thanks. 

[Jack Brickey]

I think I'm still missing something here. My point is to make the requirement to add the Resolution when transitioning to Resolve only. Don't have any requirement from Resolution to Closed. Unless your workflow can bypass the Resolve status and go directly to Close then you can be assured that the Resolution is set and unchanged at Closed. 

[Christina Fausbøll]

The solution we went with, was to remove the field " resolution code" in our workflow in the transition between resolved and closed. Because we set it when moving the issue to resolved. 

So @tom, we got around it by removing the fileds in the transistion. So we are doing as @Jack Brickey suggested. 
At the time I asked this question I didn't know that this was why the field was mandatory. 
We have transitions moving directly to closed, but when using these we are asking for a resolution in this transaktions, so i will be filled out, without passed the status resolved.  

Thanks for all you answers. 

[Radek Janata]

Resolution field is a system field and it can never be set as required/optional in field configuration scheme. When Resolution field is set on screen, it's always required.

Edit: My comment should have been placed under Nic's answer, not here under Tom's answer (but I can't delete or move it now).

[Moses Thomas]

@Christina FausbøllYour resolution field is set mandatory this is why you can set the resolution field to be optional in the field configuration scheme for the issue type. Then you will not be force to change resoulution

Best! 

[Radek Janata]

Resolution field is a system field and it can never be set as required/optional in field configuration scheme. When Resolution field is set on screen, it's always required.

[Jack Brickey]

Never make Resolution required in field config.

[Moses Thomas]

@Radek Janata  Yep that's right! well most likely but , I thought some time ago  it could be optional