TL;DR: In Jira, Status and Resolution are different fields. Depending on your workflow, Jira may prompt you for a resolution… or it may not. That’s how teams end up with issues that are Done but still Unresolved. I shipped a small fix in imdone-cli 0.28.0 so moving to Done doesn’t require another decision.
It’s amazing how many developer interruptions come from tiny “paper cut” fields.
This one shows up right when you’re trying to wrap up work.
You do the right thing: move the issue to Done.
And then… you’re suddenly staring at a drop-down asking you to pick a Resolution.
Or worse: you don’t get asked, you assume it’s fine, and later someone says “why is this still unresolved?”
Same feeling either way: you were finishing the work, and Jira found one last way to pull you out of the zone.
Status vs Resolution (the thing nobody explains clearly)
Jira separates two concepts that many teams treat like one:
- Status: where the issue is in the workflow (To Do → In Progress → Done)
- Resolution: why the issue ended (Fixed, Won’t Fix, Duplicate, etc.)
That means this state is totally possible:
status = Doneresolution = Unresolved
And it’s not just “cosmetic.” It leaks into dashboards, filters, and sometimes workflow rules.
The nuance: Jira doesn’t always prompt you
This is where people talk past each other:
“Jira always prompts you for a resolution.”
“No it doesn’t.”
Both can be true, because prompting is not a universal Jira behavior. It’s workflow configuration.
In the wild you’ll find all three:
Prompting
The transition screen includes a Resolution field, so Jira asks you to pick one.Auto-setting
A post-function or automation sets Resolution behind the scenes. No prompt.Not set at all
No prompt, no automation, no post-function… and you end up Done + Unresolved.
If you’ve got multiple projects, inherited workflows, or “just one tweak” done years ago, you can end up with inconsistent behavior across boards.
Why it matters (even if you hate dashboards)
This mismatch creates a bunch of low-grade pain:
1) “Resolved” reporting gets weird
Some reports/gadgets treat “resolved” as “has a resolution,” not “is in Done.”
2) JQL starts lying to you
People write filters like “show me unresolved issues,” and Done issues sneak in. Or you filter for Done work and a chunk is still “unresolved.”
3) Transitions get blocked on some projects
Some teams add validators that require resolution on the Done transition. Others don’t. So developers get different friction depending on which project they’re working in.
Quick check: do you have “Done but Unresolved” issues?
Try a query like this (tweak project key and status names):
project = PROJ AND statusCategory = Done AND resolution = Unresolved
If your instance doesn’t support statusCategory, try something like:
project = PROJ AND status in (Done, Closed) AND resolution = Unresolved
If either query returns results, you’ve got the footgun in your workflow somewhere.
How teams usually fix it (in Jira)
The standard fixes are all admin-side:
- Add a post-function to set Resolution on Done transitions
- Add a validator requiring Resolution before the transition can complete
- Add automation: “when status category becomes Done, set resolution (if empty)”
Those can work great.
But they also tend to fail in the exact way “paper cuts” fail:
- it’s different per project
- it’s easy to forget which workflows have what
- it requires admin attention
- edge cases happen and you’re back to manual cleanup
Scratching an itch (the developer-side fix)
So here’s the thing: the path developers use the most should be the path that’s hardest to mess up.
Moving an issue to Done is a “closing ritual.” It should be quick, consistent, and not require one more decision unless you explicitly want it.
That’s what I shipped in imdone-cli 0.28.0.
What changed in 0.28.0
When you move an issue into a Done status category, imdone-cli will:
- automatically set Resolution = "Done" if the issue has no resolution
- never overwrite an existing resolution
- stay non-blocking: the move succeeds even if resolution setting fails
- only attempt this when moving to a status in the Done category
In other words: move it to Done and keep coding.
Commands
Default behavior (automatic)
imdone move PROJ-123 Done
Set a specific resolution
Sometimes you do want to be explicit:
imdone move PROJ-123 Done -r "Fixed"
Skip resolution entirely
If your Jira workflow already handles it, or you want to leave it alone:
imdone move PROJ-123 Done --no-resolution
Prompt me (interactive)
If you want a choice, make it a choice:
imdone move PROJ-123 Done -p
The interactive mode:
- fetches available resolutions from the Jira API (with descriptions)
- includes a Skip option
- falls back to common resolutions if the API call fails
The real point: fewer interruptions
This isn’t about being “more compliant with Jira.”
It’s about removing one of those tiny context switches that happen right at the end of a work loop.
If your Jira already prompts or auto-sets resolution, great. But if you’ve ever been bitten by:
- “why is this still unresolved?”
- “why didn’t that chart move?”
- “why did this transition fail on this project but not that one?”
…this is a small, practical way to make “Done” mean what developers think it means.
Question for you
On your team, does Jira:
- prompt for resolution
- auto-set it
- or ignore it entirely?
I’m genuinely curious how common each setup is across real teams.
Docs for the move command (all options + details):
https://www.npmjs.com/package/imdone-cli#user-content-move--move-issue-to-new-status
Top comments (0)