How to get jira strikethrough closed issues instead of resolved ones ?

[Anjali S]

How do you customize JIRA to strikethrough only closed issues and not the resolved ones? I have read answers that say modify the workflow and remove the Resolved status altogether. But that is not what I want to do.

I want to keep the resolved status because we use it to indicate completion of development work WITH pending QA verification.

Once an issue is verified by QA, we move it to closed state. Striking through a resolved issue which is not closed yet gives a false impression about work done when in fact it is not.

[Nic Brough -Adaptavist- · Accepted solution]

You don't.  An issue is struck out when it has a value set in the field "resolution".  It has nothing to do with status.

For your case, where you want the resolved status, but don't want the issue to show as resolved, then you need to

1. Change the workflow screen in use for transitions INTO resolved so that they use a screen that does NOT include the resolution field
2. Check the workflow post-functions to make sure they do not set the resolution as you go INTO resolved
3. Remove the workflow post-functions that clear it on the way OUT of resolved
4. Make sure all transitions INTO Closed either set the resolution on a post-function, OR go through screens that include the resolution field

[Nicolas Bourdages]

This answer is more complete than mine. No wonder you have 173k points :)

[Anjali S]

Nic, thanks for clarifying this and for the steps. We may not be able implement it this way in our environment. Setting the field "resolution" when resolving a ticket sounds more appropriate than setting it when closing the ticket; that is how we let QA testers know the developers' decision about the ticket. If there is a way to make the strike-through independent of the field "resolution" and instead make it dependent on the field "status", I would be interested in that.

[Nic Brough -Adaptavist-]

Nope, that's why I answered the way I did. The whole of JIRA is coded to assume that "resolution is set means the issue is resolved", you'd pretty much have to rewrite half the system.

[Andy Jordan]

I fell for the same issue, using "resolution" as a step by step through the workflows but came to the understanding any value set in that field means the issue is resolved. Passing it to QA etc means the issue is still not resolved/satisfied/closed.

[Geoff Wilson]

As a note, I performed a formative usability test on our numerous JIRA changes (and achieving certain goals within JIRA itself to see what we could improve w/ add-ons), and found that often users developed a mental model from their Boards that all closed/resolved issues should appear crossed out / strikethrough.  However, immediately following that they went to the Issue Navigator and were trying to filter by resolved issues and they kept thinking they were doing something wrong / getting the wrong results because all issues displayed were not struck through.  This caused a disconnect in what they expected to see when glancing at a list of issues in distinguishing closed vs open. 

[Nic Brough -Adaptavist-]

Yep, that's why you need to make sure your resolution is handled correctly in the workflows.

[Craig Cockburn]

The simple solution would be to amend the strikethrough behaviour so that an issue is only struck through when it is closed. Strikethrough when there is still work to be done on it is confusing and putting something in the "resolution" field should only be valid if the issue is resolved. It isn't resolved if it still has to be QAd, in that case is "dev complete" or similar.

[Nic Brough -Adaptavist-]

I have workflows that don't include "closed". 

You're absolutely right that "Strikethrough when there is still work to be done on it is confusing and putting something in the "resolution" field should only be valid if the issue is resolved".  That's why you should not set the resolution until it really is done.

[Holly Meza]

Hey Nic, 

Do you know of any way to visually differentiate between issues with certain resolutions in the issue list?

Use Cases 1: Issues in Resolved with a Closed-Fixed resolution will be greyed out in issue list. 

Use Case 2: Bugs with a Class = A will show as red text in issue list.

Any ideas/help is, well, helpful! :) 

[Nic Brough -Adaptavist-]

Not without rewriting chunks of JIRA's core code.

[Greg Hoggarth]

Nic, Atlassian's design for the Jira Resolution field simply doesn't match most other bug tracking tools, or the workflows that most companies adopt (as a result of those tools).

A typical workflow is for testers to raise an issue, developers to work on it and come to a resolution, whether that be Fixed, Not A Bug, Duplicate, Not Reproducible or something else and the ticket then goes back to the testers to confirm the developer's work - either to re-test the original issue and the fix, or to confirm if they agree with the Not A Bug / Duplicate / etc result.

As such, it is natural for the developer to set the Resolution field to one of those values, before it goes to the tester. This means the tester is now working on an issue that is displayed with a strikethrough on it. It doesn't make sense.

If the tester determines that the Developer's resolution was wrong (which typically happens in less than 10% of issues), then they reject the resolution, which sends it back to the developer and clears the resolution field, removing the strikethrough as a consequence.

Saying "That's why you should not set the resolution until it really is done." is saying that Jira is working properly, when in actual fact IT is the outlier and doesn't work the way that most other tools and therefore existing company workflows work. Company's shouldn't have to adapt themselves to the pecularities of the tool.

Anyway, you mentioned here https://community.atlassian.com/t5/JIRA-questions/Re-No-strikeout-of-issues-after-they-are-resolved/qaq-p/308107/comment-id/128959#M128959 that someone had custom CSS that removed the strikethrough from "resolved" issues. I've done some googling but haven't been able to find workable code for this, would you have any chance of finding this CSS?

[Nic Brough -Adaptavist-]

Nope.  You should simply leave the resolution out of it until it's done.

Now, my argument is that using resolution to determined "done" is essentially wrong, it should be based on a metastatus with the resolution reduced to a "reason for done" (and disallowed until you reach a metastatus to prevent confusing "it's done but not").  But we're stuck with Atlassian's poor resolution rule, so no, you *must* leave it empty until an issue reaches the true end of the cycle.  Use other fields for your "not quite done" resolutions - I still say "done" really should only kick in when something really is at the end, but I'd like to see use of metastatus, and, on top of that, role-based meta status (so a tester sees a developers "done" as "ready for test" - something we can only do in text at the moment)

The CSS I've got is for version 5 I'm afraid (and I had to yoink it out as it confused everyone who had used JIRA before)

[Greg Hoggarth]

The weird thing is, Atlassian already have the right components to make a solution - they added categories to Statuses not too long ago, so there's the To Do, In Progress and Done status categories.

The strikethrough should be associated with any status that is in the Done category. Then every workflow can have their own stauses that map to done which receive strikethroughs.

[Nic Brough -Adaptavist-]

Yes, those are the meta-status I've asked for.  Except I've asked for more functionality than that - I need to be able to define my own meta-status, and I need their view lensed by role, but with a fixed "this is an end state for everyone" flag.  (There's an essay solution here, and one that will probably never get implemented, despite working for everyone.  Ho hum)

But we're stuck with resolution.  Resolution made perfect sense in JIRA 1.  It stopped being a right solution the instant workflows became editable.

There is one minor problem with "status category == green = done", in that JIRA Software considers only the right-hand column on a board as "done".  A brute force solution is "if it's green, it's in the done column", but I don't think that works for a lot of people.  I think "allow the X right-hand columns to be done" is just as bad a solution, but I don't have anything better than them.

[Martin Sebesta]

Nic, thank you for all the answers here. For the communication with testers, we just introduced a new status 'In Testing', so we do not have these problems with resolution.

Where we do have problem (rather a confusion based on the displayed strikethrough font of issues) is the inconsistency of display of the strikethrough in the list of issues when i filter using the standard 'All issues' filter (Jira SW 7.4.2) - the list contains issues with resolution other than 'null' but those issues are still displayed w/o the strikethrough. The same is true (at least in our instance) for the display of the issue key in the main Issue screeen - there is the format <project> / <Issue-key> and the Issue key for issues with Resolution is still w/o the strikethrough. Where it works ok is the list of linked issues - there, we see the strikethrough as expected.

I would think, the display will be consistent on all places where an issue (or it's key - bearing the strikethrough) is shown...

Could you please help or is it a ToDo for develeopers?

Thank you, Martin.

[Nic Brough -Adaptavist-]

That's not how JIRA behaves.

I suspect you are not using the system resolution field.

[Martin Sebesta]

Hmm, I thought, it will be somewhere in the config - do you have an idea where? I configured the resolution workflow myself - so very probably, we are using the Resoltion field - i actually added the standard Resolution screen (with the resolution field) to the final state - just to give the programmers the possibility to tell 'will not be done/works for me/...' which is missing in the standard simplified WFL after the installation. But i could do something wrong....

Attached the situation as i see it in browser...

[Nic Brough -Adaptavist-]

Oh, hang on, you're not talking about the resolution being set, you're talking about the strikeout appearing in certain places.

It does not appear everywhere.  If the resolution is naturally on screen (such as in a filter result), it's not struck out.

Sorry, I missed that!

[Martin Sebesta]

ah, ok, my fault describing the situation....

But now, if you focus your eyes _only_ on the list of search results (just to decide if you have to click on an issue), you do not get the information whether the issue is Resolved (strikethrough) or not. So you are for a small moment uncertain - looking only at the issue Key. Similarily, if you open an Issue, you read it from top getting a wrong feeleing the issue is not Resolved but later on, you see it is Resolved.

It is a small usability issue - you have to bear in mind (always), that the key does not give you all the time the same information (key of linked issue is strokethrough, but if the key of the same issue is displayed with the additional info (somehere else, so you need to scroll, perhaps...) than the key is not strokethrough).

If can ask for, i would just like to have the same display routine being used everywhere when displaying the Issue key. It could have some performance hit - especially in the search results list - where jira will have to get the data from the database - but it is just one additional field - the Resolution.

Thank you a lot,

Martin.

[Nic Brough -Adaptavist-]

It was my reading, not your writing.

It's not about performance, it's usability.  The feeling from Atlassian was that the strikeout gets in the way of visibility, and should only be used when the information that an issue is resolved is directly and immediately useful.

In a search, it should not matter that much, as if the user isn't interested in resolved issues, they could add "and resolution is not empty" to their search.  Similarly, is it of any use when your search says "resolution is not empty"

[Martin Sebesta]

ok, now i got your point - or the Atlassian one - with the visibility (and readibility) of the issue key..... There is some rational in it as well.

As it is so small topic, i would just stop the discussion at this point....

Thank you a lot Nic for your work here.

Martin.

[Nicolas Bourdages]

It seems you were misinformed. The strikethrough is not on the Resolved status. It has nothing to do with status. It appears when there's any value in the Resolution field (Fixed, Won't Fix etc...).

To get this to work as you intend, only allow adding a resolution when you move from Resolved to Closed.

Also, don't forget to clear that resolution with a post-function if you need to move from Closed to Reopen for instance. Otherwise, the strikethrough remains.

[Anjali S]

Nicolas, thanks for clarifying this.

[Chris G]

I have a smiliar issue, but, it differs in that although the Resolution field is empty (displays as 'unresolved' within the defect view), but as soon as I create a new Defect, the Resolved date is populated (the same as created and updated). This seems to be causing the strikethough in our instance. I aslo use issue type Question - and these do not have a resolved date - and therefore remain without a srikethrough. Any ideas how I resolve this for us?

[Chris G]

and interestingly, Issues that are moved from Question to Defect - aslo don't have the Resolved Date field.

[Nic Brough -Adaptavist-]

It's not the resolved-date, that's completely irrelevant. The resolved date is just "date someone changed the resolution from <empty> to <something> The cause is simple - you've got resolution on the create/edit screen for Defects, so your users are inadvertently setting a resolution. If that is the case, remove the field from the screen (you should never have resolution on a screen unless it is a) view or b) a transition screen into "resolved"/"closed"/"done" type status) Please check Admin -> Issues -> Resolutions and make sure that the list of resolutions does NOT contain "unresolved". Because that is hideously broken and needs fixing.

[Chris G]

Hi Nic - thanks for your update: The Resolution field is already not on my create screen, and only appears on the transition screens that go to closed status, and the view screen. (and the 'edit' screen which i would like to remove it from, but can't find where to do that) I dont have unresolved in the resolution list. I am at a loss (though admittedly, am no expert at Jira Admin).

[Nic Brough -Adaptavist-]

I think it might still be the edit screen. Screens are well buried in Jira, there's layers of config for them, but to make sure you are looking at the right one... - (you will need to be an admin on the project and a Jira admin to do this) - Go to an issue which has a resolution strikeout - Go up to the project it belongs to - Go into the admin page for that project - Look for the "screens" section and click on the name of the "issue type screen scheme" currently set for the project - This will show you a listing of what "screen scheme" is in use for each issue type in the project (in expandable areas) - Find your issue type and expand the area - on the right, it should now list the screens in use for create/edit/view

[Chris G]

I've checked the above (thank you) - and it all looks correct to me. I don't actually see Resolved field when I go to the edit screen on my own session - I spotted that on someone esles screen - So perhaps a permissions thing - however, I'm still struggling with what is populating that resolved date. It's definately happening during the create process - the date and time stamp are the same as the created date and time stamp and don't change even if the issue is updated later on.

[Andy Jordan]

Sounds like you need to go through each of the workflow transitions to determine what field are set as users move from one transition to another.

[Nic Brough -Adaptavist-]

The resolution field is controlled by presence on screens, not permissions. So you need to check the create issue screen again. Also, look at the post-functions on the create-issue, in case you've got a resolution set there.

[Nic Brough -Adaptavist-]

Er, that has nothing to do with this question - may I suggest you delete it and re-do it as a question, so that it gets an audience other than the handful watching this thread. And perhaps include links and references?

[Infra Estrutura]

i created a new status "cancelled" for a specific workflow, and the resolution set "cancelled" too.

how can i get the cancelled issues with strikethrough?

[Nic Brough -Adaptavist-]

They should be struck out because the resolution is set to something.

[Andy Jordan]

I agree.

[Infra Estrutura]

it's not working, even with a resolution. and doesn't matter if the resolution is cancelled,, resolved or closed. the behavior is the same in all situations.

[Nic Brough -Adaptavist-]

Then you have a hacked copy of JIRA where someone has changed code to deliberately remove the strikeout