How to see all possible transitions in workflow button on issue page?

[Tarlan Mustafayev]

Hi everyone. I have a Jira Project with a very complex workflow with more than 70 transitions altogether. I have 26 statuses, 50 transitions on the normal workflow, and I also have all-to-all transitions for each of the 26 statuses (only admins are allowed to perform this transitions). So, normal users doesn't have any issues as they can see up to 5 transitions from the normal workflow (for example from Backlog to Analysis, Development, Cancelled etc). We have 2 transition buttons and the rest nest inside the workflow button. Everything's fine. But the admins are allowed to perform all all-to-all transitions (which is 26 tranisitons) + the normal transitions from the specific status that the given issue is in. So, for a given issue, an admin can perform up to 32 transitions, and the workflow button can only nest up to 25 transitions, it seems. The remaining 7 transitions are lost. How can I fix this? 

I know it's not a good practice to have 70+ transitions in one workflow, but that's what the team wants and I have to find a solution to this. I advised them that they can change perform the transitions through bulk change if they need to perform one of the lost transitions, but interestingly these transitions were not an option in the Bulk Change's transition issues option either. 

What can I do to make all possible transitions visible inside the workflow button?

For this specific case I think taking 4-5 transitions out of the Workflow button could help, I mean they can be on the issue page before the workflow button, and the rest can fit inside the button. But that would require shutting down the instance and would cause some problems. So, please help me finding another solution.

[Tarlan Mustafayev]

I think the optimal solution to this specific case would be limiting the number of all-to-all transitions and only keeping the necessary ones. For example keeping all-to-all transitions only to to do type statuses, so, if an issue is accidentally transitioned to another status the admin can fix this mistake by returning the issue to the nearest to do status and the actual assignee can transition it to an in progress type status when he or she actually starts to work on it. This way admins would still have the flexibility they need, and no transitions would be lost. If there won't be any better ideas to address this issue, I think this could be a viable options for those who face the same issue in the future.