Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Resolution field cannot be set

Hello, we were having an issue with the satisfaction survey not being sent by mail.

After looking into it, we noticed that our issues with the status category "done" were not interpreted as resolved. This was confirmed by the following JQL Query returning almost all issues we ever created:

project="IT Service Desk" AND resolution is EMPTY

That would explain the mail not being sent. Our issue types and workflows are 100% custom so the Jira standard types, workflows and states do not apply.

Now we had two issues:

  1. We do not use resolution in our internal processes but Jira Service Management needs this field for the satisfaction survey, so we had to set it up automatically
  2. For past issues we should clean up and set up resolution to some value for the sake of Jira Service Management interpreting them correctly as closed when we make a query. 

Regarding issue 1:

The resolution field was missing in our screens so we added it since it is needed by Jira Service Management. Now we have a button on the issue screen to set the resolution manually. Also, we set up a post function on the transition that leads to the last status of our Workflow to set the resolution as something fixed as described in this Best Practices article. This takes care of the issue for the future.

Regarding issue 2:

We thought of solving the issue by setting the resolution field to something fixed automatically with a loop transition and a bulk modification as described in this Best Practices article under the section "The following instructions are meant to correct previous issues that have the resolution field incorrectly set", however setting the resolution field to something fixed instead of removing the value. 

However, this seemed to have had no effect at all so repeated the steps twice, deleting the value of the resolution field in the first iteration and then setting the value to something fixed in the second iteration, just in case already existing values would create conflicts.

This also seemed to have had no effect at all so we set an automation rule to set the resolution field of all issues with a status category "done" to something. Now the automation rule fails with an explanation: It appears that the resolution field does not exist for many of the issues:

2021-11-14 14_46_24-Project automation - PackJira und 17 weitere Seiten - Geschäftlich – Microsoft​ .png

This translates to "unknown fields during processing. Those are possibly not available for the project/the issue type. Please check your configuration for custom fields. ignored fields:
Resolution (resolution)"

Any ideas how we could solve this?

2 answers

1 accepted

2 votes
Answer accepted

@Idriss Brockmann-Serbis -

Resolution is always set via your WF (e.g move to the terminal status transition) via post-function.  If you have modified your WF properly - example setting up a post function against the transition movement to your terminal status (i.e. DONE/CLOSED etc...) and set the resolution field value + publish the WF changes, then you can conduct a bulk update of your existing impacted issues by transition them (i.e from Done/Closed) to a prior status (i.e. In Progress etc..).  Afterward, you will bulk update the same set of issues and transition them to the terminal status, thus getting the resolution field populated.

For all of your new issues created after the WF changes, their resolution field will always be populated when they move to the terminal WF status.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Infrastructure Applications Team

Viasat Inc.

@Joseph Chung Yin thank you for this hint. The now know for sure that the workflow has been set properly since new issues have been resolved as expected and survey mails have been sent accordingly. 

Regarding the past issues: bulk update was unfortunately not possible. To avoid problems due to different issue types and/or structure, we tested that out on one single specific issue that we tried updating via bulk update. Here ee get the following error message: "HINWEIS: Sie sind nicht berechtigt, die gewählten 1 Vorgänge zu bearbeiten, oder zumindest ein Vorgang weist einen Status auf, der die Bearbeitung untersagt." which translates to "HINT: You are not allowed to modify the chosen 1 issue or at least one issue has a status that does not allow modifications." 

Regarding permissions we did that with the organization owner which is also jira administrator and project administrator. Regarding the Status, we tried the following:

  • Copying the current workflow
  • Adding a new transition from the final status back to a previous status
  • Assigning the new workflow to the impacted issue type

Unfortunately, doing that does apparently not impact past issues, which keep being linked to the previous version of the workflow.

@Idriss Brockmann-Serbis -

By default, when an issue reaches the final (terminal status), the issue is locked down for editing.  You can change the default configuration by accessing your WF and click on "view properties" associated to the step (status) - by deleting the properties "jira.issue.editable".  NOTE - This is not recommended, but you can use it to fix your issue, then re-add it back when finished.  Remember to republish the WF after you modify the WF.

2021-11-17_7-26-08.png2021-11-17_7-24-29.png

In regards to your second question.  If you applied the new WF to your project + issue type and publish the WF schema, then the new WF will always be applied.  So, you must have not done the publishing or associating the new WF properly.

Hope this helps.

Best, Joseph

Like Idriss Brockmann-Serbis likes this

Thank you very much, this has worked perfectly. And indeed, the workflow itself had been published but not the workflow schema had not been published.

@Idriss Brockmann-Serbis -

Excellent.  Glad to be able to assist you.

Best, Joseph

1 vote
Jack Brickey Community Leader Nov 14, 2021

Hi @Idriss Brockmann-Serbis , just to be clear you are saying that you created a loop transition on your done status and you used a post function in that loop transition to set the resolution to done. Is that correct? Then if you execute that transition you are saying the resolution remains unresolved. Is that correct? I assume that you are not trying to set any other fields on that loop transition.

Hi @Jack Brickey Thank you for your input. Yes, this is correct. We created the transition from status "all" to "itself", so from done to done, plus we defined a post function so that the resolution would be set to something fixed. After executing the transition we check with a JQL query "resolution is EMPTY" if the resolution was correctly set. This is unfortunately not the case.

Apart form that, we only have the standard 5 post functions which come with every new transition in Jira. We have not added any other function to modify anything else than the resolution field.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Service Management

Next level incident management in Jira Service Management

Hello Atlassian Community! We’re thrilled to announce some exciting changes to incident management in Jira Service Management Cloud, in order to give your teams extra muscle during incidents, and ...

1,743 views 21 12
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you