Hello world!
I have a couple of workflow questions that I thought I'd put out into the universe here to try and get some help on.
We are in the process of adding an "On Hold" transition to some of our ticket type workflows and had some questions around how we can restrict certain things for this transition. So I wanted to know if some of the below were even possible within Jira.
Can we restrict the ability to make a certain transition in a workflow to specific users or a specific users group?
In turn, can we restrict the transition so that whoever made that transition is the only one allowed to transition it back?
And even further, can we restrict the transition from "On Hold" so that it can ONLY go back to the source status? (e.g if the status went from "In Progress" to "On Hold" then it can only back to "In Progress")
Thank you to whatever beautiful soul tries to answer my questions!
I have just one comment on @M Amine answer for the first bullet: Use project roles, not users. Eventually the user will need to be changed and you'll have to touch the workflow. If you make it a project role you can simply assign a new user to that role. And you can add a user if the primary goes on vacation. This should be considered a security issue and best practices is not to directly give people permissions. Give a role/group permission and put people in roles/groups.
Half of the Jira admin courses/training boils down to "use roles"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, so many problems people have they wouldn't if they used roles and if Atlassian didn't by default give the 'logon' group permissions to everything.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes @Joe Pitt you r right, using project roles is better and advisable. Using a specific user, although permitted, is not a very good practice.
But there are a lot of situations where are forced to assign to a specific user and only give the permission to that specific user in order to transition the issue.
Of course, with a third party plugin (like Insight) you can implement what I described in a more scalable way and not depending on a workflow modification (and JIRA Admin rights) in order to maintain the specific user who has rights to approve and to which the issue has to be assigne. But, as I said, you will have to rely on a plugin and some clients, due to budget limitations, want to have the feature right away and decide after if a plugin is suitable or not.
cheers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Why can't you just put the one user in the project role? You don't trust the project admins to follow procedures and not add others to the role?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The case is that the same client has multiple teams (A1, A2, A3, A4 ...Etc). For each team, when a team member raises a request we have to :
thank you Pitt
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Usman,
cheers
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @M Amine! Thanks for taking the time to answer my questions.
on the second bullet I had a question. If in the workflows, I have the transitions to "On hold" set so that it goes from one status to "on hold" and "on hold" back to the source status, wouldn't that make that restriction already there, without the need for a plug in. I don't have the "allow all statuses to transition to this" checked off for the "on hold" status, instead, I created the transitions to on hold and back for each different status. wouldn't that negate the need for a plugin?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.