I have read and read and re-read multiple websites and JIRA administration on how to add a group to a transition, but it seems to have steps missing, or I am not reading it correctly. I would love a walk through (NOT JUST MULTIPLE links) as I have tried it multiple different ways to not allow an issue to close without it going to the QA group/project role.
Any and all help is appreciated.
There's not actually a huge amount to do for this one, but it's not quite clear what you are aiming for.
We don't know what your process flow is really, and that's what we need in order to be able to translate it into a workflow. But I can have a go at the principles for you.
Let's say your process is broadly New problem -> developer stuff -> dev done, needs testing -> QA people test it and sign off.
That translates into a JIRA workflow with status such as Open -> in development -> Needs testing -> closed.
What you are interested in here is the last transition from "needs testing" to "closed". In this case, the only thing you need to do is add a condition for the transition that says "Only members of the QA role". So no-one outside that role will be able to close the issue.
I suspect there's more to this question, but I can imagine too many scenarios, and I don't want to make my RSI worse, or bore you to death while explaining a load of options you really don't need. So, if you could tell us why "add condition to the close transition" is not what you need, then we could probably give you more focussed advice.
Thank you Nic. Just a bit of a background - I'm VERY new to JIRA and in my mind I think workflows would be fairly easy, but I'm having a hard time translating it to working in JIRA for me for the way I have it set up.
I went through the notes you wrote and think I have my workflow, workflow scheme linked/conditions set up correctly, but I am unfortunately still missing something
I have a workflow set up (TP: Software Development Workflow) that has New -> In Development -> In Review - > Done
I have added a condition to my 'Start Review' transitions to be for Individuals within the project role of Quality Assurance, that is the only condition I have. I only have one individual in the Quality Assurance Project Role, and I am not logging in as myself (administrator) or the QA person, but as a developer for my testing and when tested this work flow in my testing project and it doesn't seem to assign nor make it go into review/or close by project role of Quality Assurance, it just stays on current user (who is a jira-developer).
Could it be with how I have set up my user roles? Could it be I have my transition set up incorrectly? Could I be missing a link somewhere between the workflow, workflow scheme and user permissions? Do I need to set this up as a ticket for a different level of help?
Ok, I think there's two things here. First, I've talked about the condition above. The condition stuff is *just* covering "who can do what". It doesn't change the data itself, it really does just say "only a QA person can do this". You should find that if you log in as your developer, they do not have "in review" as a workflow option when you look at an issue that is currently "in development". But the QA person does get the transition! Who an issue is assigned to is totally different. That's a field on the issue that names a user. Most of the time, humans set fields to what they want, but it sounds like you want an automatic update when the transition is executed? To do that, you'd want to run a "post function" to set the field after a user confirms that they want to do the transition. There is quite a lot of complexity here (it gives us a lot of power in the application), so have a think about what you are trying to achieve in terms of "who can do what" and "what data I want to set automatically without a human" and how they interact, and then have another look (and post again, of course ;-) )
I'm glad you brought up Post Functions as I thought that might be the case, BUT (again, it may be user issue with still learning) I can't seem to actually say I want a particular project role - or at least not where I'm currently looking.
Here are the Post Functions for my 'start review' transition, with the condition to only allow project role of Quality Assurance:
The following will be processed after the transition occurs
So how do I get it to change from current user to 'project role' if I don't have that as an option in my Add Post Functions. and just an fyi (again maybe be my craziness) when I log in as my developer I can see 'In Review' and I don't have anything when I log in as my qa person. Do I have my condition set on the wrong transition? Do I need to change something with my project roles? Have I completely messed up my workflow? sigh Is it better to just inactivate this project (thankfully a test project) and start from a blank test new project?
Ah, hang on, there's an assumption there, and it's not right. You can NOT assign issues to a role (or a group). Only a user. It's trying to assign the issue to the current user. There are functions in a couple of plgins that allow you to assign to the last user who touched the issue from a particular role, but it's still a single user. For the transitions, it just sounds like you've got it the wrong way around - the condition is a "must", so if your condition says "Role of QA", the user must be in that role to use it. Check that you really do have the developer NOT in the role of QA, and that your QA person IS in it too.
I figured it out with a google search and on one of the answers there was a comment/answer to add an individual to post-function with the 'Update Issue field' with the assignee being my QA person. Yes instead of a group. I tried to reply to this thread yesterday but couldn't because I don't have enough points and had already posted 3 times in 24 hours. sigh.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot