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

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?

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

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

Nic Brough -Adaptavist-

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

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.

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.

Welcome!

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

Quick Links

Find more posts tagged with

server

jira

jira-server