Resolution field cannot be set

[Idriss Brockmann-Serbis]

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:

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?

[Joseph Chung Yin · Accepted solution]

@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.

[Idriss Brockmann-Serbis]

@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.

[Joseph Chung Yin]

@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.

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

[Idriss Brockmann-Serbis]

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.

[Joseph Chung Yin]

@Idriss Brockmann-Serbis -

Excellent.  Glad to be able to assist you.

Best, Joseph

[Jack Brickey]

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.

[Idriss Brockmann-Serbis]

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.