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

Status change the Resolution

KirstenManica

Hi! I am trying to map Issues so that 1 action completes a 2nd action. I have a field named "Status" on my Issue screen, and a field named "Resolution". One of the statuses that I have created is named "Done". I want to have a change in the field Status to "Done" to change the field Resolution to "Resolved". Can anyone help?

Accepted answers

All comments

Nic Brough -Adaptavist-

There is a general answer that you'll need some code to do this, specifically, javascript to get the browser to make those changes automatically. Or, you install something like Behaviours (it's a module of the ScriptRunner add-on) which can handle this.

However, there's another couple of problems here...

1. Status is not a field, and you can't change it with simple edits

2. The Resolution field should never be placed on most screens. It is only for transition screens for transitions going into a "closed" type status (the ones shown as green)

Steven F Behnke

You're doing it backwards. Use a Resolution of DONE and a status of RESOLVED.

KirstenManica

Thank you. As I read what you wrote in #2, it caught my attention b/c we are in fact using the transition screens to go into a "closed" type status, the green kind

One of my engineers and I sat side-by-side and we went into the workflow that was configured for the project in question. We opened the workflow in text format, opened a draft view, opened the transition in question, went to the 4th tab "Post Functions", and added a post function that indicated that after every status change of Done, it would update the Resolution to Done as well.

One of the things I was really going after was to get the line-through that occurs when an Issue's Resolution field becomes "Done" as opposed to "Unresolved". Does that make sense? It's like the strike-through look in a typical document. That line-through gives us a nice view on our Sprint board. It was happening sometimes but not others.

KirstenManica

Hi Steven! Thank you for your input. I just replied to Nic and it sounds like you and I would need to pow-wow more before we'd be on the same page. I look forward to seeing you in the Community some more.

Steven F Behnke

No worries! I try to advertise this Status/Resolution non-sense because it's often confusing. I could have been more detailed!

Status is WHERE in the workflow should we report the status.

Resolution is WHY the issue is in a DONE/COMPLETED state. (Done, won't do, canceled, etc)

KirstenManica

Got it! We are at a stage that our team wants me to pare it down to such a simplified workflow.. So in effect we're using only Status and they wanted Resolution to leave us alone! So automating it so that it did whatever the Status Done did is what shook out.

Cool that you're a Community Champion!

Nic Brough -Adaptavist-

Absolutely!

The trick here is understanding what the resolution field is. I think Steven has helped you get there faster than I could.

Just on the technical side though... Most of JIRA works on the principle that when the database entry for the resolution of an issue is empty, the issue is "unresolved" (and it displays that, rather than an empty field). When the resolution is filled, it is "resolved", with the content telling us why.

Even if you don't want to use the resolution field, you should still set and clear it appropriately, or a lot of the reporting looks odd or wrong. Which is what you've now set up, with the post-functions :-)

KirstenManica

Got it, your explanation helps give a feel for the way JIRA "thinks". Half the battle is figuring out the other entity's language and how it/they think!

Cool that you already knew Steven

Welcome!

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

Quick Links

Find more posts tagged with

jira

workflow

resolution