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 to retain the resolution of an issue as "Unresolved"

Manoj K1

When a sub task is created The default status of the issue is Open and resolution is Unresolved. However if we edit the task in order to change the task description or the estimate, the change results in the resolution becoming Fixed. How can I retain the resolution as Unresolved for minor edits.

My project template is set to scrum.

Accepted answers

All comments

Ivar

Are you saying that if you edit a sub-task, it automatically becomes Resolved?

If that is the case I would check the active workflow. Is there anything in the workflow that trigger this?

Nic Brough -Adaptavist-

Ivar is right about checking the workflow - if you're pushing the issue through a transition, then I half expect to find that the transition has "set resolution to fixed" as a post function.

If it's not a post-function, then you need to check through your listeners. They can update issues when they detect any changes.

Also, look closely at the issue history - does it tell you who made the unwanted change? Is it grouped with the change of description/estimate, or separate? That might tell you something.

JustinA

Have you looked through the screens in your instance, especially Edit Screen. There may be the Resolution field attach to it.

Normally, the Resolution field would only appear when you are resolving issues. Thus, if the field exists, then removing it would resolve your problem

Michael Tokar

Hi Manoj,

Are you doing your editing of the sub-task through the new Rapid Board, or through the older boards (Planning Board, Task Board, etc)?

If you are using the Rapid Board, this behaviour might be the result of a bug, which has been fixed.

Unfortunately, I cannot send you a link to the bug report as it was never filed.

What version of GH are you using?

Thanks,

Michael Tokar [Atlassian]

R Topp

I had the same issue. Jira's default screen mapping maps the Edit Issue operation to the Resolve Issue screen which has a post function of updating the Issue’s status to Resolved. (Atlassian devs, this design is pretty annoying for the user and can cause a lot of problems when someone just wants to correct something minor.)

You can fix this in Jira by configuring your project's Screen Scheme and remapping the Edit Issue operation to use the Default Screen (which doesn't carry a post function Resolution change).

My problem is that having fixed this in Jira, Greenhopper now has the same problem. When in Greenhopper, if you select an Open or In Progress card and choose "Edit in Jira", make a minor change then update, it forces a resolution - when the user did not want to Resolve the Issue.

How can we stop this from happening in Greenhopper please?

Thanks

JamieA

I had the same issue. Jira's default screen mapping maps the Edit Issue operation to the Resolve Issue screen which has a post function of updating the Issue’s status to Resolved. (Atlassian devs, this design is pretty annoying for the user and can cause a lot of problems when someone just wants to correct something minor.)

This is not actually the case... the edit issue uses the default screen in the out of the box default screen scheme.

Michael Tokar

Hi RMT,

Firstly, please let me address some of your questions:

Jira's default screen mapping maps the Edit Issue operation to the Resolve Issue screen which has a post function of updating the Issue’s status to Resolved.

Screens in JIRA do not trigger post functions by themselves. Only workflow transitions trigger post functions. You might be confusing the two because often a workflow transition will have an associated screen, e.g. the Resolve Issue Screen that comes with JIRA by default.

If you are wondering why a Resolution is automatically set on an issue after editing the issue with a screen, please ensure that you are not actually transitioning the issue through the workflow, using a transition which has the post function of 'set Resolution field'.

As for your issue with GreenHopper, I cannot tell from your post whether you are referring to GreenHopper Classic boards, such as the Planning and Task Boards, or if you are referring to the new GreenHopper Rapid boards.

If you experience this behaviour with the Rapid Boards, then as I mentioned above it could be due to a bug (that has already been fixed). This bug occurred when the user edited the issue from the Rapid Board's Detail View of the issue, using inline edit.

If however you are experiencing this behaviour on the GreenHopper classic boards, or while editing the issue through JIRA's interface (for example, the Quick Edit form), then this could be a bug we do not know about, and you should please raise it on jira.atlassian.com under the GreenHopper project. Please be sure to include all the necessary information to reproduce the problem, including screenshots if necessary.

Many thanks,

Michael Tokar [Atlassian]

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

transition