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.
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
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.
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.
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.
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.
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, 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?
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)
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.
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.
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.
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...
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!
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,
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"
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.
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?
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.
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).
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
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
...+ reading Fantasy). The same is true for him at the bank he works for: Efficiency is key when time literally equals money. Read on to learn how Sergey makes most of the time he has by...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs