Such transition mechanism sounds like 'smart commit'[0] but attached to PR instead? Isn't simpler to just trigger transition directly from commit?
[0] - https://confluence.atlassian.com/bitbucketserver/using-smart...
[0] - https://confluence.atlassian.com/bitbucketserver/using-smart...
The issues I find (including speed) are really due to the incredibly flexibility of Jira, and things not being thought out by users. Ultimately, I feel like it's akin to the old adage about perl - it does everything including giving you the rope to hang yourself.. it's up to you if you hang yourself. That plus all my friends who insist one needs a PhD in Jira, to Jira... but I digress.
We're set up appropriately with issue types, differentiation between issues, bugs, tasks, (and our version of etc). We can plan sprints locally and remotely, and have all our dashboards and friends immediately update. Integrated (sanely) with confluence we get retrospectives, historic reports. We create bugs, move their states, deal with Agile and Kanban, have histories... the whole deal. To reduce the inherent pain in dealing with bug creation because it generally sucks, we have a slack integration I wrote to: a. Create a bug b. When you type ISSUE-ISSUE# into a channel, the robot picks up and gives us all the subject.
The combination above removed all friction. The one thing I wish would happen from a workload perspective is that when a PR is pushed upstream to bitbucket, for a branch matching an issue - the issue would move to the Code Review state. But that is our only point of friction, and one day I'll get off my rear and make our robot do it.