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

PLEASE Stop Requiring Resolution In Order to Show Done Issues (Edited for Clarity)

Stacy Gardner_z41ib8

I understand that my Done issues do not show when a Resolution value is not set, but I don't understand WHY a resolution is required for the issues to show in Advanced Roadmaps.

I do not have control over other teams' boards, so I cannot dictate that they change their workflows to enforce setting a resolution value for all tickets in their board when they move tickets to a final state, when the tickets I'm managing are a subset of theirs.

It makes it incredibly difficult to manage an initiative across several projects when tickets constantly disappear once they're complete. Please at least help me understand the why so I don't give up completely on your product.

Comments

Nic Brough -Adaptavist-

This is going to start out as being very very grumpy and pedantic.

Please stop saying things like "resolution status"

The phrase is meaningless in Jira-speak. Resolution and Status are two (technically) unrelated things and "resolution status" is useless because it cannot tell us which one you are actually talking about.

There is a long boring essay I really really need to write up so I can point at it instead of having to explain it repeatedly, but the shorter version is:

Resolution and Status have nothing to do with each other.
- Jira does not care about status.
- An issue is unresolved/open if the resolution field is empty. Meaning "it needs more attention"
- An issue is resolved if the resolution is set (even if an inexperienced admin has created an "unresolved" value, it's set, so it is still resolved)
Jira Software (Scrum and Kanban boards)
- Do not care about reolution
- The last column on your board is "done" and the column is based on the status
To make Jira be consistent, you should set a resolution on the issues that go into the last column on your board, and clear it when they move back in the flow.

But please stop mixing status and resolution up!

Danno

@Stacy Gardnerit sounds like you hit a nerve with Nic. 😁 and Jira has hit a nerve with you.

That said if you consider his explanation of Resolution and Status, your initial problem explanation seems weird. I'll assume you are talking about an issue visibility problem with a board. The most basic reasons for an issue not showing up on a board would be the filter for that board and what column a Status is assigned to.

If an issue has a resolution it is considered complete regardless of Status. If you make the resolution field visible for your issues you will find that you can set the resolution regardless of status. I have created automation rules that clone an issue and have forgotten to clear the resolution so that I ended up with a bunch of issues in the backlog and/or To Do with a resolution of Done. Very confusing for the users.

One last thing I just realized is that this post is in the Advanced Roadmaps discussion. Is this problem of visibility only in your Plan? If so, I would look at the filters to be sure you aren't filtering plan issues by a resolution. See my screenshot here.

resolutions filter.png

Stacy Gardner_z41ib8

Thank you both for your response. I apologize for not being more clear - I typed this up throwing a bit of a tantrum because I had to reopen issues that should be closed just so they would show up on the Advanced Roadmap. Everywhere I said Resolution Status, I meant Resolution.

When the ticket is moved to an end-state, if the workflow does not require a Resolution value, the default outcome is for the ticket to be considered closed without a resolution. Tickets that are in the "final" state (whether that be Done or another end state) that have no Resolution value set (e.g. remain Unresolved) no longer show in Advanced Roadmaps.

This behavior is well-documented in Atlassian's documentation:

Issues in a completed status but without a Resolution set will not show up in plans Closed issues do not show up in Advanced Roadmap Plans.

My issue is that I cannot force other teams to modify their project workflows to force that a resolution value be set, and when those project issues close with Resolution = Unresolved, the issues no longer appear in Advanced Roadmaps. It's a feature design that I was voicing my frustration that I would like Atlassian to change, or at least explain why, so that I have rationale to lean on if I do have to go back to teams and ask that 10 different projects be updated to require Resolution values.

The ONLY filter I have set up on my board is to pull in tickets with a particular label, and I have Exclude any completed issues after set to 365 days (the max length allowed), so there is zero chance it's caused by an overly restrictive filter. There are also no exclusion rules set.

Nic Brough -Adaptavist-

Completely understandable, my rant about "resolution status" was on a day where I had wasted almost an hour on it (one of person, like you, was fine - they immediately answered "which one do you mean", the other was a nightmare refusing to listen to the explanation, so we gave up and removed their admin access). So I was a bit frustrated that day...

I'm afraid this is not going to change, Atlassian are not going to enforce resolution setting in a workflow, because

there are several ways you might be setting or clearing the resolution and apps can add more - they can't code for spotting all the ways a workflow might do it
it would reduce the flexibility of the workflows
they expect people who build workflows to know this (you shouldn't be letting inexperienced admins build workflows)
Most importantly, the resolution is hard-coded as the "done" flag throughout Jira - they would need to check and refactor almost every part of all three Jira applications to change the way it works

They have done a couple of things that help a bit. When you use a "simplified workflow", there's a tick-box for "set a resolution for this column".

They're also looking at the workflow editor, and for Team-managed projects, you can't actually break it. These workflows automatically set and clear resolution when you transition into or out of a "done" (green status category). Problem there is they don't let you choose a resolution, it's just "done", so you can't build workflows that do things like "set resolution to duplicate when the duplicate transition is used"

Anyway, I'm afraid your only option is to complain at your administrators - they need to fix all the workflows that are not taking account of resolution.

Danno

@Stacy Gardnerif you have admin permissions you could use automation to set the resolution on the project tasks that aren't set in the workflow. Or ask the admins to add it for you. I've included the rule here:

Set resolution for all issues.png

Stacy Gardner_z41ib8

Thank you both for taking the time to listen to my concern and give context that I previously did not have. Nic, to your comments, I wasn't expecting Atlassian to force resolution, more the opposite (remove the AR requirement that closed tickets have to have a resolution set in order to display). I still don't quite understand why, if workflow is done but resolution is not set, Advanced Roadmaps determines that it is no longer appropriate to view them (but is fine displaying tickets where the workflow is done and the resolution is set).

If the concern is that too many tickets display over time in AR, I would think that could then be managed via the scope filters that AR administrators and/or project admins are able to control without changing workflows, but perhaps I'm missing something else re: why AR requires that resolution must be set in order for the ticket to display once it reaches an end-state.

Re: my use case, I am not administrator of most of my company's projects (I work on several cross-function initiatives that require pulling in tickets from 10+ projects/boards at times), but the steps you outlined above should at least simplify my asks to the project administrators to set resolution status, as well as give clarity in how to implement the requested changes.

I will share this ticket/your guidance with them, since it should at least give me an actionable path forward for now. Thank you both again for your quick responses and thorough explanations!

Nic Brough -Adaptavist-

I know, this is something I've been whinging about for <mumble> years, and I've still not got around to posting (after updates) my essays on the subject which were not carried over from the previous incarnation of "community" (one rant on poor design, and a history explanation that sort of explains how we ended up here)

>I wasn't expecting Atlassian to force resolution, more the opposite (remove the AR requirement that closed tickets have to have a resolution set in order to display).

Yes, that's how I read it too, but the problem there would be that it would make AR work differently to the rest of Jira - you'd now have three different "definitions of done". It's bad enough that we already have two (but that can sort of work, it actually gives us a lot of cross-team flexibility)

>I still don't quite understand why, if workflow is done but resolution is not set [...]

Workflow does not really have "done". Core Jira works entirely off the resolution (and that extends into AR). Jira Software works off the last column on the board (which gives you the flexibility to pass things between teams - one team's "done" is another team's "to do")

A problem with AR is that because the rest of Jira doesn't really work off status as far as "done" is concerned, it is trying to stay in line with that, so that non-Jira-Software board stuff still works, or at least remains consistent.

>Re: my use case, I am not administrator of most of my company's projects (I work on several cross-function initiatives that require pulling in tickets from 10+ projects/boards at times), but the steps you outlined above should at least simplify my asks to the project administrators to set resolution status, as well as give clarity in how to implement the requested changes.

I feel that pain, my first Jira install was "you're the admin now, learn the hard way", but my second had a massive pile of problems, mostly rogue admins (meaning "we don't know, just let them do what they think they want", not deliberately rogue or malicious). I got a lot of help from this community in explaining to the admins that there are "quirks" in the system that they really need to understand better.

>Thank you both again for your quick responses and thorough explanations!

Glad we can help, despite all my initial grumpiness! Don't be hesitant in pointing people to the Community, there's a lot of (less grumpy) help here!