How to diagnose a permission error to transition a subtask

[Matt P]

All, there are several subtasks that I am unable to transition. What is interesting is that I can easily transition new subtasks I create in the same story. The initial subtasks were created a week ago, and none allow me to transition to the next status.

I've looked into re-indexing (no longer possible/necessary in Jira Cloud), permission schemes (I have several redundant permissions that should allow me to transition because of being admin/user combo), issue permission schemes, workflow settings, etc. Even if there was an issue here, it should show up in newly created issues, but it does not. I can also transition the main story.

We do have BigPicture add-in, could that be a factor?

I get this very helpful message when trying to move the issue in the backlog view of a Kanban board:

Error

Something isn't letting us move RDSTE1-106 to In Progress. Ask your project administrator to check the workflow settings and transition conditions.

Any idea what the problem might be or how I can go about diagnosing and fixing it? I'd rather not delete and remake these tasks, and want a way to handle this if it arises for our team in the future.

Thanks,

[Earl McCutcheon · Accepted solution]

Hi Matt,

If the issues are not allowing you to transition them there is more than likely a transition between the current status and the destination status does not exist or either  Conditions OR Validators exist on the transition your trying to execute where that value is not met on the issue you are trying to transition, can you check the workflow to first verify the status the issue is currently in has a transition to the in Progress status to allow you to execute the transition and to see if either a condition or validator is blocking the action of the transition vie the transitions configurations.

Also if you can grab a few screenshots of the settings, I can take a closer look to see whats happening.  Please include, a screenshot of the workflows in the text mode view as well as the boards column configuration where you are executing the transition, and note the source status your sub-task that cannot transition, is in.  also grab a screenshot of the conditions and validators on the transition between the source and destination statuses.

Regards,
Earl

[Matt P]

Earl, thanks for your response. As mentioned in the post, this is not a workflow issue. When I create a new subtask (or task for that matter) in the exact same location, it is easily transitioned (for your edification, there are no conditions or validators on the transition that exists between the current and desired status, checked just now). 

I tried to convert the original issue to a task today (from a subtask) and it also did not help. 

Do old issues use an old version of the workflow? That would not make any sense. Therefore, this is not a workflow issue. 

Any other diagnostic ideas?

[Earl McCutcheon]

Hi Matt,

Thanks for the additional info, and another possibility here; did you possibly import the issues from trello? as there is currently a BUG that lines up with this behavior that occurs when migrating issues from a trello board causing the step id mapped to backlog to have an id=0 on workflow triggering the error you are encountering, additional details on this bug can be seen here:

• https://jira.atlassian.com/browse/JSWCLOUD-16620

But if this is not the case I would still like to take a look at the workflow to see if I can spot anything out of place and looking at the text view of the workflow we could be able to see if a id=0 status exists, or some other config error as the error is clearly stating:

check the workflow settings and transition conditions.

And this is indicating the blocker is somewhere in the workflows configuration, so getting a verification on the settings is a good starting point.

One thing I am thinking is a possibility here is if the old issues somehow got stuck in a bad state from a recent workflow change or indexing error like you noted, where the issue in a duplicated status(id=x) but the expected status is status(id=y) currently with the same naming convention reflected in the UI front end but conflicting on the ID in the backend.

To check this we can try to pull some data about the issues from the API, Looking at a one of the newly created good sub-tasks that can be transitioned and compare it to one of the bad sub tasks that is stuck run the following api requests with a GET:

• https://<BASE_URL>.atlassian.net/rest/api/3/status
  • This will give us a list of all the status ID's
• https://<BASE_URL>.atlassian.net/rest/api/3/issue/<Insert Issue Key HERE>
  • Run this for the Stuck issue and the Good issue for a comparison point.

At the second API endpoint look for the following two sections and compare the "Status" ID and "Status Category" ID of the two issues to verify they match and if they do not match compare these values to the list on the first API endpoint to see which source status lines up with the current state of the issue:

"status":{"self":"https://<BASE_URL>.atlassian.net/rest/api/3/status/<#####>

"statusCategory":{"self":"<https://<BASE_URL>.atlassian.net/rest/api/3/statuscategory/<#>","id":<#>,

 A couple approached to try and clear this out:

1. Set the destination status to "Global" so all statuses can transition to the desired status, execute the transition on the stuck issues and then revert the workflow change.
2. Move the sub-task to a new parent issue, then back to the original parent issue, which may force the status change to align with the new project on a reindex operation that occurs during the move action.

Let me know what you find.

Regards,
Earl

[Matt P]

Earl, thank you for your thorough response. I deleted the tasks before being able to query the status and statusCategory through the API to clean things up, but I will keep this in mind if it happens in the future.

Note, I did try moving the task to another parent, changing the issue type, and all manner of other available transitions to try and "bump" it back into a normal state. I didn't import these issues from Trello, though it is good to know that bug exists. 

Matt