As a project admin, how can I change an issue status without a transition

[0h8324f98n34]

I'm a project admin, but not a system admin, so I cannot edit the workflow, nor do I wish to create an entire set of transitions only available to admins.  I am aware of the workflows, and what changes during each transition, so I can set the fields and values correctly, as if it should be in that state.  I used to be able to do this with Move issue, but now the Move issue workflow skips past step 2 of 4 (Select new status) and forces the current status from the current workflow into a completely different workflow.

How can I, as a project admin with all project admin permissions, update the status of an issue?

[Nic Brough -Adaptavist- · Accepted solution]

You can not "edit" a status.  The only way to change status is to use a transition.

I'm afraid @Robert Wen_Cprime_ 's suggestion is wrong - if you use bulk edit -> edit, you will, and already have, find that the status "field" (quotes because it is not a field), is not offered as something you can edit. 

But you can use bulk edit -> transition to change the status of many issues in one go.

There are technically two ways you could do this though

• Export your issue(s) to CSV, delete them from Jira, edit the status column, and then re-import the CSV, mapping the status on to what you want.  And probably losing a lot of data.
• Change your workflows such that a new one does not have the status you want to move from, and map the new workflow on to the project.  Jira will demand that you migrate to different status, but there's no transitions involved here.

Neither of those are good things to do.  You really should be transitioning your issues between status, not trying to just jam them in and bypassing your processes.

[0h8324f98n34]

I used to be able to bulk update status and resolution as part of bulk changes, not plan for temporary workflow transitions just to get issues where I need them as part of a migration.  This is the very definition of an administrative action, and I can't imagine why it was removed for almost all circumstances.  When changing issue types "In Progress" does not always mean the same thing.

Thank you for the answer.

[Nic Brough -Adaptavist-]

You've not been able to use "edit" to change status since Jira 1 <mumble> years ago, and that was removed because it broke the workflow.  When you think you could edit the status, you were still transitioning the issue, and when you can do it, you'll find you are only offered a status that exists for the end of a transition.  Try narrowing your selection of issues down to issues that are in a single status and using the same workflow.

Resolution is a different matter - you can edit it directly, if it is on the edit screen for the issue type.  But you should never put resolution on the edit screen for an issue type, because editors will automatically resolve issues by editing anything, which is never the right thing to do.

If you "used to be able to bulk update resolution", you were working on a Jira that was intrinsically mis-configured and broken.

[0h8324f98n34]

I agree it was not possible to use Edit to update status, but it was possible with Move, both executed on individual issues and in bulk.  The Move issue process now skips past step 2 of 4 (Select new status) and forces the current status from the current workflow into a completely different workflow.

The only work-around I see outside of creating excessive invalid transitions limited to admin users is to create a copy of my project using same issue and field schemes, but a completely different workflow with no status overlaps to the actual workflow.  I can move issues to that project, and map the status as needed when moving them back.

[Nic Brough -Adaptavist-]

Move does not transition issues, it does indeed edit the status directly.  But it only does it when the target issue type has a workflow that does not contain the current status of the issue, so that it makes the data compatible with the new issue type settings.

To change the status of an issue, you must transition it.

Why is this a problem for you?  Why are you trying to bypass the right way to change status?

If you can't transition an issue to the status you want directly, then your workflow is wrong.   Ask your admins to change it.

[Robert Wen_Cprime_]

The only way I can think of doing this is if project admins have the permissions to perform a bulk edit of an issue which would allow you to choose a new status.

This means that you have to be in a group that is allowed to perform Bulk Changes, a global permission.

[0h8324f98n34]

I do have the ability to perform bulk operations, however the first screen asks for the action and my meaningful choices are "edit", "transition" or "move".  Edit doesn't seem to display the status for update.  Transition only allows changes within defined transitions.  Move doesn't seem to have any capacity to map status.

[Vamsi Kandala]

Hi @0h8324f98n34

In order to change to any specific status, the transition has to be there between the source status to the target status.  Else, it will not show up when doing bulk update.

So, you can edit the workflow and select the 'Allow all statuses to transition to this one' option.

Then, this will show up and after you update the status of the ticket(s), you can remove the 'Allow all statuses to transition to this one' option in the workflow.

Hope this helps.

Thanks,
Vamsi

[0h8324f98n34]

The typical workflow is present and enforced.  The exceptions are not defined.  To define the exceptions will quadruple the number of transitions possible, and add the complexity of restricting them to specific roles.  I need a way to say Role X (admin) can transition any status to any status.  Perhaps that exists without defining 50+ transitions, but I haven't found it.

[Nic Brough -Adaptavist-]

To change the status of an issue, you must transition it.

Why is this a problem for you?  

If you can't transition an issue to the status you want directly, then your workflow is wrong.   Ask your admins to change it.