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

Moving issue to statuscategory "done" but not filling resolution.

jeroen.wilmes

I'm looking for advice and like to learn from the community how best to handle.

We have at least two levels of integration of our software product (increments).

Two components have their own releases. The two component have to be integrated into a solution.

If the customer or the integration team finds a bug in one of the components they raise the bug in the component project, the lowest level. When the bug is "solved" and tested on component level it may be released. After releasing the new version will be integrated and the integration gets tested and they need to confirm/validate that the bug is solved not only on the component level (that has been done at component level) but at solutionlevel.

My problem statement: To release the component with the bug fix I need to report the bug as done, to get it in the release(notes). But in fact I want to keep it open to get the feedback from the integration team or customer that the problem is really fixed on their level.

My idea is now to create two statuses in statuscategory done; the first is 'awaiting validation' with no resolution set. An the second is "done" with a resolution set, that bug has been validated at integration level.

Has any one experience with level of integration and how do you handle bugs?

Accepted answers

Dorian ALEXANDRE

Hello,

Integrating a regression status into your workflow is a good solution! However, it’s important to understand the clear difference between the status and the resolution fields.

Basically, if an issue is marked with the Done status, it doesn’t automatically set a resolution, this must be handled through a transition or automation.

If you want to mark an issue as Done without updating its resolution, you can simply adjust the workflow’s Post Function so that the resolution is only set during specific transitions.

If you want to set the resolution manually, you can either create another transition or set up an automation rule to fill in the resolution field.

Don’t hesitate to share if you have another idea about this!

Marc -Devoteam-

Hi @jeroen_wilmes

In my opinion a workflow complements a process a needs to serve team members/stakeholders to show an issue in an identifiable and meaning status.

Ig you think that in relation to your process and WowW and extra status will help to enrich the process, my advice is to do this.

The same usually applies in an ITSM process, where an issue is set to Resolved, this to provide the customer the option to re-open the issue and later on Close the is to finalize the issue.

All comments

Dorian ALEXANDRE

Hello,

Integrating a regression status into your workflow is a good solution! However, it’s important to understand the clear difference between the status and the resolution fields.

Basically, if an issue is marked with the Done status, it doesn’t automatically set a resolution, this must be handled through a transition or automation.

If you want to mark an issue as Done without updating its resolution, you can simply adjust the workflow’s Post Function so that the resolution is only set during specific transitions.

If you want to set the resolution manually, you can either create another transition or set up an automation rule to fill in the resolution field.

Don’t hesitate to share if you have another idea about this!

Marc -Devoteam-

Hi @jeroen_wilmes

In my opinion a workflow complements a process a needs to serve team members/stakeholders to show an issue in an identifiable and meaning status.

Ig you think that in relation to your process and WowW and extra status will help to enrich the process, my advice is to do this.

The same usually applies in an ITSM process, where an issue is set to Resolved, this to provide the customer the option to re-open the issue and later on Close the is to finalize the issue.

Suraj Aderogba_sfd2f4

Hi @jeroen_wilmes , Nice of you reaching out.

I believe the best practices for handling bug resolution and validation across Integration levels and based on my experiences are:

1. Understanding the Resolution Field in Jira:

The Resolution field is critical in Jira: when set, Jira treats the issue as resolved and it impacts boards, reports, and filters. Issues in a "Done" status category without a resolution set can cause confusion, such as appearing as open in reports or not being removed from boards.
Never create a resolution called "Unresolved" or "None", Jira treats an empty Resolution field as unresolved, and adding such values can lead to reporting errors.

2. Workflow Recommendations for Multi-Level Validation
Your idea of using two statuses in the "Done" status category .i.e. one for "awaiting validation" (no resolution set) and another for "done" (resolution set) is not recommended. According to Atlassian best practices:

All statuses in the "Done" category should have the Resolution field set. If you have a status in "Done" without a resolution, Jira will definitely treat it inconsistently, leading to issues in boards, reports, and filters.
If you need to distinguish between "awaiting validation" and "fully done," use a status in a different category (e.g., "In Progress" or a custom category) for "awaiting validation," and only move to a "Done" status (with Resolution set) once validation is complete.

3. How best to Implement a Validation Step

Add a status like "Awaiting Validation" before your "Done" status. This status should not be in the "Done" category, and the Resolution field should remain empty.
Once validation is complete (e.g., integration or customer confirmation), transition the issue to the "Done" status and set the Resolution (e.g., "Fixed").
Use workflow conditions or validators to ensure the Resolution is only set when moving to "Done".

4. Why This Matters

This approach ensures your reports, boards, and filters work as expected, and you avoid the pitfalls of having "Done" issues without a resolution or unresolved issues marked as "Done".
It also provides a clear audit trail and process for multi-level validation without breaking Jira's reporting and workflow logic.

Reference: Best practices on using the "Resolution" field in Jira Cloud

Suraj

jeroen.wilmes

Thanks Dorian,

That is indeed what I was planning to do.

In standard way of working there is a caveat. Not bringing an issue into a Statuscategory status, blocks you from adding that issue to a release (fix version) you either have to move it to another release or just ignore it. Both are not what I want. Because if I don't add it to the release, it will not become available for integration and validation by the next level.
If I just close it, it will get 'resolved' in Jira and it more or less disappears.

That is why I make the combination bring it to a separate status in statuscategory "done' but don't set any resolution.

The bugfix gets released, the release notes show status 'awaiting validation'.
The bug remains on the board of the teams.

I make an notification mail for integration team to validate

and only change status to done, with a resolution after positive feedback.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud