How to reset resolution field to "unresolved“ using the REST API

[Sven Wiegand]

I want to set an issue's resolution to "unresolved" using the REST API, but I don't know how.

I'm able to set the resolution to any resolved state using a PUT request on the affected issue with a body like this:

{
  "fields": {
    "resolution": { "name": "Done" }
  }
}

But if I try to reset the resolution using a body like this:

{
  "fields": {
    "resolution": null
  }
}

The the request fails with the error message:

Could not find valid 'ID' or 'name' in resolution object

Question: How to reset the resolution field to unresolved using the REST API?

Background

Why do I want to do it? Well, we have a bunch of workflows looking like this:

It is easy here to set the resolution (in the transition to "Gelöst" or the direct transition to "Geschlossen"), but the resolutions needs to be reset in nearly every of the other transitions. As this is only one of 13 workflows in our system and each of them contains about 7 transitions which require to reset the resolution I would need to add a postfunction to reset the resolution manually to about 7*13 ~ 90 transitions.

Thus I decided to implement a script listener using ScriptRunner for cloud which resets the resolution to unresolved on every issue update if the affected issue is not in one of the resolved states (in the example above these are "Gelöst" and "Geschlossen").

Unfortunately this doesn't work at the moment as I don't know how to reset the resolution.

[Fazila Ashraf]

Hi @Sven Wiegand

As you already have the script runner, why don't you run the fix one time using the built-in script - https://scriptrunner.adaptavist.com/4.3.19/jira/builtin-scripts.html#_bulk_fix_resolutions ?

You will have to choose 'new resolution' as 'none'..

[Sven Wiegand]

@Fazila Ashraf: How should this solve my use case? I want a continuous solution that resets the resolution whenever the ticket isn't in a resolved state. Further on even the scriptrunner script doesn't provide a feature to reset the resolution. It only provides the option to set a resolution.

[Fazila Ashraf]

Sorry, i missed that you were looking for a continuous solution. 

I will check on how to empty the resolution value through a REST call to use in a script listener.

Note:  The built in script do reset the resolution. You have to set to it value 'None'

[Sven Wiegand]

@Fazila Ashraf: Thanks for further investigating this.

Please keep in mind, that we are using JIRA cloud. In the cloud version of ScriptRunner I can only select one of the possible resolutions in the built-in-script. The option "none" is not available.

[Sven Wiegand]

@Fazila Ashraf: Anything new here regarding how to reset the resolution via REST?

[Nic Brough -Adaptavist-]

What you're trying to do is fundamentally broken here.

You say "I want a continuous solution that resets the resolution whenever the ticket isn't in a resolved state."

The way an issue gets into an incorrect state is through a broken workflow or screen definition.  You should fix all the workflows and screens that allow issues to get like this first, then do a one off clean up of the broken issues.  As long as you don't create or break any more workflows that fail to set/clear resolution, you won't need to do it again.

The way to "reset" the broken issues over REST is move them through the workflow.

[Sven Wiegand]

Hm, in (not only) my opinion JIRA is the problem here, as it forces workflow designers to handle the resolution status manually.

Take a look at the workflow I've showed above. It would mean that I would have to add a "clean resolution field" post action to six transitions. I have 12 other workflows which are designed similarly in that they allow transition from each status. So in sum I would have to manually add the "clean resolution field" post function to about 90 transitions. Further on we need to remember for each new transition to also add the post function there.

I am just trying to find a maintainable solution for something which should be done by JIRA itself. There are tons of threads out in the internet discussing this resolution field issue in all its facets since years. Unfortunately there is still no working solution in JIRA.

[Nic Brough -Adaptavist-]

I'd agree with the principle.   The done/not-done flag should be based on a  meta-status (with a flexible relative modifier for reporting), and the resolution field used only to describe the reason for closure.  Then we wouldn't have to do anything in the workflow.  That should have been done in Jira 2, when we were given the ability to create our own workflows.

But, we're stuck with it.  The only maintainable solution is to slog through your workflows and put the necessary post-functions in them, and train your admins to do it when they're working on workflows.

Not doing that means that even if you run a "correction" regularly, you have a system where your information is incorrect for periods of time in between runs.  Which is not a maintainable solution.

[Sven Wiegand]

I think the solution would be feasible, as the correction of the resolution field would be executed by ScriptRunner each time an issue is updated. So the timeframe of the inconsistency would be very small to not existing.

But after all it looks as if clearing the resolution field simply isn't possible via REST. And unfortunately ScriptRunner for JIRA cloud only support manipulation via REST. 

[Nic Brough -Adaptavist-]

It's feasible, but horrible, as you're constantly working to plaster over cracks and writing history that you don't need or want instead of preventing the data going wrong.

But, as you say, Cloud doesn't support it at all, so your only option is to fix your workflows and screens.