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; } } }

How do I define which status should be considered "Done" statuses?

Justin Corcoran

I've created a number of custom statuses for my workflow. One status, for example, is "Requires Analysis," meaning that the issue needs more investigation before it can be completed. However, for some reason, JIRA is treating this as a "done" status, meaning that when I go to the planning board in GreenHopper, the Issue # has a line through it, and when I click "Hide Done Issues" issues with this status disappear.

How can I specify which custom statuses should be equivalent to "done" and which should not?

Accepted answers

Neal Applebaum

Hey Justin, according to this post:

http://forums.atlassian.com/thread.jspa?threadID=47676

Greenhopper uses a different method than JIRA itself to decide whether to strikethrough an issue or not. Here was the solution: "Take a look at the Task Board Mapping as that owns the 'definition of done' in GreenHopper.

All comments

Nic Brough -Adaptavist-

For each transition into a "done" status FROM a "not done" status, use the "resolve issue" screen, or add a post-function that sets the resolution.

For each transition from a "done" TO a "not done", use a post-function to clear the resolution.

Basically, the status has nothing to do with it - done/not-done, the decision is based on "is the resolution field filled in"

Dieter

The system field resolution, not status, decides if an issue is displayed as striked through. only if the resolution is null, the issue is not displayed as striked through. I asssume some transition that leads into the state "Requires analysis" sets the resolution. please check this if users cannot change the resolution status in some transition screen.

Dieter

Sometimes its really amazing to see each other writing the sames answer at the same time

Justin Corcoran

OK, thanks for the clarification around resolution/status. However, in looking at my workflow, I don't see why/where the resolution is getting set. For example, one possible move is from Awaiting Sizing --> Requires Analysis. In the "Awaiting Sizing" status, the resolution is null (presumably, as the issue isn't striked through). However, when I move the issue to "Requires Analysis" the resolution is getting changed, as it ends up striked through. I don't have a transition screen between these 2 statuses, nor do I want one.

I can post a screenshot of the details of the transition step if that's helpful. I'm still pretty new to this, so I really appreciate both of your help.

Justin Corcoran

OK, I can't see how to add an image here, so here's a copy past of the transition details:

Conditions

There are no conditions on this transition.

Validators

No input parameters checks will be done before this transition is executed.

Post Functions

Set issue status to the linked status of the destination workflow step.

— THEN

Add a comment to an issue if one is entered during a transition.

— THEN

Update change history for an issue and store the issue in the database.

— THEN

Re-index an issue to keep indexes in sync with the database.

— THEN

Fire a Generic Event event that can be processed by the listeners.

Dieter

Yes, it would be really helpful to see what post functions are called in this transition

Justin Corcoran

I can't seem to add comments at the moment, so I'll have to add this as an "answer".

The "Resolution" field on an issue in the "Requires Analysis" status says "Unresolved". There is also no transition screen presented to the user that would allow them to change the resolution.

Neal Applebaum

Hi Justin, JIRA automatically considers any issues with a non-NULL resolution as "Resolved" and will therefore show with striekthrough font in the interface. As the workflows are fully csutomizable, resolving an issue is not always the end of the issue's life. Indeed, it usually isn't. JIRA should link a particular set of transactions as those that cause it to be displayed in strikethrough. I am not familiar with Greenhopper, but the same applies there.

I logged this enhancement request (https://jira.atlassian.com/browse/JRA-7211) in 2005.

By the way, adding a transition to Correct or Clear the resolution is easy enough to do. I have both in my workflows.

Justin Corcoran

OK, thanks. I'm still not clear on WHY the resolution is getting set to not null. I'm also not clear on why this shows as striked through for "Requires Analysis" but when the issue is set to "Awaiting Sizing" the resolution is also "Unresolved" and this is NOT striked through.

That being said, can you please explain to me how to set the resolution to NULL as part of the transition? Thanks.

Nic Brough -Adaptavist-

Yeah, I can't post comments either - it just hangs.

>OK, thanks. I'm still not clear on WHY the resolution is getting set to not null

Because you're going through a process that sets it to something. Three possibilities

1) You are putting the resolution field on screen. It has no "none" option, so when it's on screen, it will get set if the user uses the screen, either as part of a transition, or on edit.

2) You've got a post function that is setting it as part of a transition

3) You've got a listener (which is the same as a post-function but runs outside the workflow)

>I'm also not clear on why this shows as striked through for "Requires Analysis" but when the issue is set to "Awaiting Sizing" the resolution is also "Unresolved" and this is NOT striked through.

Er, that's what we've all said to you. Unresolved = no resolution set = no strikethrough. The strikethough happens when the resolution is set to anything else.

As for status, you really do need to look at your workflow to see what screens are being used and what the post-functions are doing.

To set it to null, as I said before, use a post-function to clear the resolution as you move from a status where it should be set, to one where it should be unresolved. Have a look at the built-in default workflow - specifically, the "reopen" transition.

Justin Corcoran

>OK, thanks. I'm still not clear on WHY the resolution is getting set to not null

Because you're going through a process that sets it to something. Three possibilities

1) You are putting the resolution field on screen. It has no "none" option, so when it's on screen, it will get set if the user uses the screen, either as part of a transition, or on edit.

Nope. No resolution field on the edit screen. It DOES display on the screen when you're just looking at the issue. Is that something that should/can be changed?

2) You've got a post function that is setting it as part of a transition

Nope, see above. (in the comments above, not my response to #1)

3) You've got a listener (which is the same as a post-function but runs outside the workflow)

99% sure we don't, as I don't know how to set one up, and no one else in my company is playing around with JIRA at the moment.

>I'm also not clear on why this shows as striked through for "Requires Analysis" but when the issue is set to "Awaiting Sizing" the resolution is also "Unresolved" and this is NOT striked through.

Er, that's what we've all said to you. Unresolved = no resolution set = no strikethrough. The strikethough happens when the resolution is set to anything else.

See my comments above. When the issue has a status of "Awaiting Sizing" it has a Resolution of "Unresolved" and is not striked out. When the issue has a status of "Requires Analysis" it has a Resolution of "Unresolved" and IS striked out. Same resolution, different result.

As for status, you really do need to look at your workflow to see what screens are being used and what the post-functions are doing.

I did both of these. There are NO transition screens, and I've put the post functions in the comments above.

I actually did this just recently. It didn't seem to work. Here's the new Post Functions (maybe I set up the resolution clear wrong?)

The Resolution of the issue will be cleared.

— THEN

Set issue status to the linked status of the destination workflow step.

— THEN

Add a comment to an issue if one is entered during a transition.

— THEN

Update change history for an issue and store the issue in the database.

— THEN

Re-index an issue to keep indexes in sync with the database.

— THEN

Fire a Generic Event event that can be processed by the listeners.

Nic Brough -Adaptavist-

Ok, if I were you, the next step would be to test your new workflow thoroughly, taking a single issue through every transition, noting resolution before and after each transition. Try to establish a pattern, and check for consistency. Watch the log file while you are doing the steps, checking for errors on each one.

On the specific points.

>Nope. No resolution field on the edit screen. It DOES display on the screen when you're just looking at the issue. Is that something that should/can be changed?

No, don't worry about view, it only matters for edit/update screens

>3) You've got a listener (which is the same as a post-function but runs outside the workflow)

>99% sure we don't, as I don't know how to set one up, and no one else in my company is playing around with JIRA at the moment.

Go to Admin -> Listeners and check. You should have a handful of greyed out listener with "(internal)" after them, and you may have a labels and a couple of Greenhopper listeners if you've got plugins for them. These are not the problem, but if you have other listeners, you may want to read through what they're doing and if you can't identify any of them, remove them and re-test.

>>I'm also not clear on why this shows as striked through for "Requires Analysis" but when the issue is set to "Awaiting Sizing" the resolution is also "Unresolved" and this is NOT striked through.

>Er, that's what we've all said to you. Unresolved = no resolution set = no strikethrough. The strikethough happens when the resolution is set to anything else.

>See my comments above. When the issue has a status of "Awaiting Sizing" it has a Resolution of "Unresolved" and is not striked out. When the issue has a status of "Requires Analysis" it has a Resolution of "Unresolved" and IS striked out. Same resolution, different result.

Hmm. This sounds like one of two things

1) Someone has done something utterly vile to your system and added "unresolved" as a resolution. This is well worth checking - nip into the (unfortunately, global) resolution list in the admin screens and check the list. If it contains unresolved, then remove it, and then go hunt down the person that added it and hurt them.

2) Your index is corrupt for that issue and probably others. Try updating the issue (any edit will do, I usually add a full-stop or comma to the end of some text somewhere). That will trigger a re-index. But you'll be able to eliminate this possibility if you've stepped through the workflow because the resolution will be correct for the test issue.

>>To set it to null, as I said before, use a post-function to clear the resolution as you move from a status where it should be set, to one where it should be unresolved. Have a look at the built-in default workflow - specifically, the "reopen" transition.

>I actually did this just recently. It didn't seem to work. Here's the new Post Functions (maybe I set up the resolution clear wrong?)

>The Resolution of the issue will be cleared.

>— THEN

>Set issue status to the linked status of the destination workflow step.

>...

Looks absolutely correct to me, as that's what I've got in my workflows.

Justin Corcoran

So, I took a look at the listeners, and we don't have any but the internal ones. There also isn't a resolution called "Unresolved" so no physical harm is needed (which is good, because if it was there, I'd probably only have myself to blame).

I haven't made it all the way through my workflow, but in the bit I've done, I've found a couple things:

1) No matter what status the issue is in, when I move it to "Requires Analysis" it gets striked through, although it still has a resolution of "Unresolved". This says to me that there's something wrong with this status, not the transitions to it, since all transitions to it seem to result in this behavior

2) I have a global transition configured (using the workflow designer) that should allow every issue to be set back to "New", but I have 2 statuses (Completed, Not Needed) where this transition is not available. Issues in these statuses still have a resolution of "Unresolved" (which I'll need to change) and are NOT striked through (which should change when I change the resolution as part of the transitions into these statuses...I hope).

Any suggestions about how to fix a corrupt index? Re-index? Editing an issue in the "Requires Analysis" status still leaves it striked through.

Thanks for all your help so far (and hopefully your continued help)!

Neal Applebaum

I was also wondering if someone create a resolution called "Unresolved". Vile, indeed. Justin - did you check for that? If the issue is "Unresolved", the Resolution will be "None" - not Unresolved. Please clarify, perhaps a screenshot will help us help you.

Justin Corcoran

here's the screenshot, not sure why it didn't get uploaded the first time. I'm happy to provide screenshots of anything else you want to see...or set up a conference where i'll share my monitor with you...anything to get this figured out!

Justin Corcoran

Yes, I checked. No Resolutions called "Unresolved" and yet all of my items in this project have the resolution of "Unresolved". It says "Unresolved" when the issue is in a status where it's not striked through (basically all of them except "Requires Analysis") AND when the issue is striked through when it's in the status of "Requires Analysis".

Justin Corcoran

OK, no idea what's going on with the screenshot. I hit browse, find the file, say OK, and it spins for like 1 second and then nothing. I can email it to you I guess if you'd like...

Neal Applebaum

You can e-mail me at jiradmin at gmail dot com

Justin Corcoran

thanks, email sent.

Nic Brough -Adaptavist-

Ok, so

A simple edit (without changing status) doesn't fix it, so it's not indexing.
You definitely don't have a resolution of "unresolved"
There are no listeners

This really is a very interesting one :-)

Next things I'd look at are

The issue history - dig up an issue which has been through the two status (or push one back and forth a couple of times). Look at the issue history tab and tell us exactly what each change block says (well, for Resolution and Status anyway, the other fields aren't important. Yet)

Do you have read access to the database? Can you execute "select pkey, resolution, issuestatus from jiraissue where pkey in ..." where the ... means the keys of a few sample issues, a couple of ones that are unresolved and not struck through, and a couple that are struck through.

Justin Corcoran

Here's the history for an issue that went back and forth into the "Requires Analysis" status a few times: I don't see any mention of the resolution changing.

Justin Corcoran made changes - Today 3:12 PM

<th width="20%">Field</th><th width="40%">Original Value</th><th width="40%">New Value</th>

Status	New [ 10001 ]	Requires Analysis [ 10006 ]

Justin Corcoran made changes - Today 3:12 PM

Status

Requires Analysis [ 10006 ]

Awaiting Sizing [ 10004 ]

Justin Corcoran made changes - Today 3:12 PM

Status

Awaiting Sizing [ 10004 ]

Requires Analysis [ 10006 ]

Justin Corcoran made changes - Today 3:12 PM

Status

Requires Analysis [ 10006 ]

New [ 10001 ]

Justin Corcoran made changes - Today 3:12 PM

Status

New [ 10001 ]

Awaiting Information [ 10002 ]

Justin Corcoran made changes - Today 3:12 PM

Status

Awaiting Information [ 10002 ]

Requires Analysis [ 10006 ]

Justin Corcoran made changes - Today 3:12 PM

Status

Requires Analysis [ 10006 ]

New [ 10001 ]

Neal Applebaum

I agree .. nothing there about resolution. Can we see the view issue screen and can you create another issue and link to it, so we see if it shows as strikethrough by the linked issue? Maybe the problem is only in the Greenhopper part or some Greenhopperconfiguration parameter.

Neal Applebaum

Hey Justin, according to this post:

http://forums.atlassian.com/thread.jspa?threadID=47676

Nic Brough -Adaptavist-

Damnit, I completely missed the Greenhopper reference. Sorry it's taken so long to get to the bottom of it. The answer is, as Neal has said, "Jira is not doing anything with resolution, but Greenhopper is". Personally, I don't think GH should say "resolved", it should stick to "done"

Justin Corcoran

Brilliant! According to the help text, the rightmost column on the task board determines the definition of "Done". This is, of course, crazy, but it's great to know! I added a column for "Done", assigned it to statuses "completed" and "not needed" and voila! Problem solved. Thanks so much!

sclowes

Hi All,

Please note that the new GreenHopper Rapid Board does not use this approach, strikethrough is shown in the same manner as with JIRA itself. Just wanted to bring it to your attention so it doesn't surprise you if you migrate.

Thanks,

Shaun

Neal Applebaum

There's something really weird going on here. My post from yesterday doesn't show up. I referred to an older post (http://forums.atlassian.com/thread.jspa?threadID=47676) that said:

Take a look at the Task Board Mapping as that owns the 'definition of done' in GreenHopper. I think Justin got that in an email because he said it helped him resolve the issue, but it doesn't appear here in the thread. Anybody else see it? I checked on two different browsers.

Justin Corcoran

Did you check the first page of this thread? I still see your answer, it got "+1'd" to the top of the list.

Neal Applebaum

Oh OK - thanks! I didn't realized it got moved to the top pf page 1. I'll know for next time. I'm new to this new forum. Cheers.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software

status

done