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

Resolutions are being automatically changed to "Done" when the User Picker field is changed?

Molly Wraight

When I assign someone in the "User Picker" field for stakeholder review or QA, the resolution automatically updates to "Done" and a line goes through the ticket number, even while it is still in our sprint. Manually resetting the resolution status to "Unresolved"does not remove the line from the ticket number. This board has been in use in its current state for at least four months, and this just started happening two weeks ago. It seems like there is now a post function but we didn't set it, and we can't find where to remove it.

Has anyone dealt with similar issues or the user picker field and triggers for it?

Accepted answers

All comments

Mikael Sandberg

First place to look is in your workflow to see if you have a post function on one of you statuses that sets the Resolution to Done.

Molly Wraight

We have, but it's not a status change that triggers it, it's selecting a user from the user picker that triggers the change in resolution -- and we can't figure out where to look at the workflow that captures that field. It doesn't seem to be in the normal workflow

Mikael Sandberg

Are you using Cloud or Server? What apps are you using? Check and see if any of those are causing this behavior. If you are using Scriptrunner check your listeners and behaviours. If you have Automation, check the rules for it.

Nic Brough -Adaptavist-

Someone has added the resolution field to the edit screen. Remove it immediately. It should NEVER be put on anything other than a transition screen.

You also say "Manually resetting the resolution status to "Unresolved"does not remove the line from the ticket number". That suggests an inexperienced admin has added "unresolved" as a resolution. You need to rename that to something like "do not use me".

After fixing those, you now have some damaged issues to think about repairing, but at least it won't spread further.

Bill Stockbridge

Hi all - I work with Molly and thought I would add a bit more detail. Here is our setup -

Jira Cloud - Application 3.3.0-OD-1000.2449.0

Issue started appearing 3 weeks ago. Steps to Reproduce:

Issue Type: Story

Note: Resolution is "Unresolved" as expected

1. In active sprint view, drag a story from "In Progress" status to "Ready for Code Review"

2. PT: Assign Code Reviewer screen appear

Screen Shot 2017-11-06 at 11.12.53 AM.png

This screen is only shared with one project - ours, ProdTech, see below.

Screen Shot 2017-11-06 at 11.18.12 AM.png

3. Assign a code review and tap "ready for code review"

Expected: Resolution states - "Unresolved"

Happens: Resolution states - "Done"

We have checked post function and there is no indication that resolution status is auto updated - at least in the frontend UI

Screen Shot 2017-11-06 at 11.36.13 AM.png

Note: there is a trigger function, but this is only for pull request in BitBucket to update ticket status not resolution. User must assign a code reviewer when moving in Jira

More Info:

I looked at the history and seeing resolution changing when user is assigned in any review state. We have Ready for Code Review (with tigger), Ready for Stakeholder Review and Ready For QA (both without triggers). All these statuses have a transition screens to assign a person but do not have a resolution field to update.

However, resolution is consistently being updated to "Done" on the backend somehow.

Also checked to make sure we only have a resolved state at the final status in the workflow:

Screen Shot 2017-11-06 at 11.46.36 AM.png

Hope this helps to get more feedback and possible solutions. Its driving our team crazy and not sure how to resolve.

Thanks

Bill

Nic Brough -Adaptavist-

Ok, let's concentrate on one thing at a time. Pick one of the changes that is causing the resolution to change and look *just* at that single transition. What are the post functions? What is the transition screen? (In your post, it looks like you are doing that, but looking in different transitions)

Three other things to check too

Are you using a simplified workflow here?

Do you have any listeners configured?

Do you have any automations configured?

Bill Stockbridge

Thanks Nic. Picking just one transition would the code reviewer flow; thats all the screen shots are from.

We started off with simplified but as the team has gotten more advanced we updated and changed out work flow.

Where can I check about listeners and automations?

Nic Brough -Adaptavist-

Sorry, I misread something. It's all the same transition, so ignore that first bit.

So the workflow is not simplified, that's good, but was that done at the time you noticed it starting to set resolution all the time?

Another random thought (a very long shot) - do you have the resolution field hidden in field config?

Listeners and automation have their own sections in the admin area. I can never remember my way around those properly, so just try going to admin and typing "listen" and "auto" into the search.

Bill Stockbridge

Soo I think we figured it out, my default screen for create, edit and view - had the resolution screen there, but it was hidden in the transition screens.

Screen Shot 2017-11-06 at 3.16.18 PM.png Screen Shot 2017-11-06 at 3.18.41 PM.png

I removed the resolution field from this and now when I use the transition screens, resolution is not being set to the default as "done" anymore. So even though the resolution field was not on the transition assign reviewer screens, it was selecting done on the backend since this was apart of my create, edit or view scheme and set to default to "done"

Not sure if any of that made sense, but short answer is "its fixed" and we verified with sever tickets.

Thanks soo much!

Welcome!

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

Quick Links

Find more posts tagged with

jira

user-picker

resolution