Jira tickets with a strikethrough

[Jason Chayer]

I have read a lot of comments/discussions around this topic, but I cannot seem to find a solution for what I am running into. Some of my issues have strikethroughs, some do not. They will have the same issue type, and in the same project. How could some have this and others not? The workflows, post functions are obviously the same, as they are in the same project. Also, a common thing I have found in the activity of the issues that have the strikethrough, is that each time it mentions the resolution field was changed. How can this be when the resolution field is not editable? Sometimes it mentions it was changed when we just added an original estimate, and others it was changed when we just changed the task description.

[Nic Brough -Adaptavist- · Accepted solution]

>How can this be when the resolution field is not editable? 

Your different projects, and possibly issue types within them have different settings.  Some might have an editable resolution, some might be putting it in front of the user for setting it on close, some could be setting it.  Hopefully all of them are clearing it on re-open.

> Sometimes it mentions it was changed when [...]

In both of these cases, you'll find the resolution field has been put on the "edit" screen.  When the field is on an edit screen (of any type - create, edit or transition), then it will be set.  So your users are inadvertently setting it.

You are going to need to review your screens and workflows to see how the resolution is getting set.

[Jason Chayer]

@Nic Brough -Adaptavist- - I will look at this again. I reviewed a task that had the strikethrough and one that did not, in both cases, I went to edit and the resolution field was not there. I also created a task to see if it appeared, but the field was not there either.

This could have been on the screen previously, we did some cleanup not long ago, and could have removed it then. Maybe this is a task that was before it was removed.

[Jason Chayer · Accepted solution]

I am not sure if this is related, but I also read in Resolutions under Admin, there should not be an Unresolved resolution. I have one listed, but it states Unresolved (Default), is this set up by Jira, or should I remove that?

[Nic Brough -Adaptavist-]

Argh!  No!  That should never have been added.

Rename it to "do not use" immediately.

[Jason Chayer]

@Nic Brough -Adaptavist- - once I remove that, do I then need to set up a loop in the workflow transitions to remove the strikethrough?

[Jason Chayer]

Once fixed, will I still be able to run a jql that will return all tasks with the resolution as Unresolved?

[Nic Brough -Adaptavist-]

Yes - spot on, although you do have other options.  Also, I would not correct the data until you've fixed all the places that are letting it go wrong.

It's not a fun job, but start by working through all the screens.  Remove resolution from all screens EXCEPT screens that might be being used for "transition to a closed status" - that's the only time you put resolution on screen.  (Don't worry about view screens - Jira displays resolution whatever you stick on a view screen)

That's likely to fix most of the problem, but you should also take a look at the workflows.  Your suggestion that a looped transition with a "clear resolution" post-function implies to me that you know what you're doing here!  (But feel free to ask more if you're not sure)

The trick here is understanding what is in the database.  When the resolution field contains:

• <Anything> then the issue is resolved.  Doesn't matter what the value is.  "Unresolved (Default)" is a value, so issues with that on them are resolved!
• <null> then the issue is open.  Literally an empty field.

(For what it's worth, this is a bit different to custom fields.  When a custom field has a value, there's a row in a database table for the content.  When it's empty, it's not null, there isn't any row to keep the null in!)

So, you can see why the following JQL works:

... and resolution is empty 

will fine unresolved issues.  So will "resolution = Unresolved" when you've not got a an option called "Unresolved", but that's Atlassian hard coding an alias which makes it a bit more intuitive to use.

[Jason Chayer]

@Nic Brough -Adaptavist- - thank you for the detailed feedback. I will try this out and see if it solves the issue. And thanks for the reminder on the jql "and resolution is empty", I did forget about that.

[Jason Chayer]

@Nic Brough -Adaptavist- -  to confirm, and I am only testing on a few tasks so I do not completely mess it up, my loop will consist of a post function to clear resolution? I can then do a bulk move and transition those, once those are transitioned back, I will then go in and remove that post-function and bulk move them back to the appropriate status?

[Jason Chayer]

@Nic Brough -Adaptavist- - scratch my last question, I got it figured out. I just needed the loop to transition to itself. Once I cleared all the resolutions, I then went back and deleted those loop transitions. Thanks again.