I am confused about the ability to 'assign' an issue.
I have created a permissionschema in which only two groups can assign issues - namely teamleaders and productowners:
When I login in and look at an issue as a developer I see two 'assigned' buttons next to the workflow dropdown. When I click on these, the buttons disappear and are replaced by a resolved button and its status becaomes assigned to the project lead. - image attached
So if I am logged in as a member of the developer group why do I still have the ability to assign? Why are there two assign buttons?
NOTE ADDED: Sorted the two buttons.. the workflow had an identical transition assigning the bug which was hidden under the the first one... not sure how that happened!! Operator error I guess... doh!! The permission part of this question still stands though...
the buttons are your workflow transitions, you have to look at your workflow to identify, why there are these buttons.
Among other things, "Assign isue" controls the visibility of the "Assign" Button on the left side of "Comment". This is not visible in your screenshot, so I think, the permission is set correctly.
What is your "Assigned" workflow-transition doing ? Is it really changing the assignee of the issue ? Or is it just called "Assigned" ?
Look at your workflow and I think you will find the answer to your question.
Thanks for the reply. I spotted the duplicate transition - our posts must have crossed.
I remain confused though... The remaining button (which needs renaming to "assign" as that is what the transition is doing appears next to the workflow button as shown above (yes the resolved button should read resolve!!!). My expectation was that this would not be shown due to the settings in the permissionscheme but you seem to be saying otherwise? How would I stop the developer role/group being able to assign bugs?
the visibility of the workflow transition is not controlled by the permission out of the box. You have to set a workflow condition to the workflow transition.
Set a permission condition to the workflow transition (https://confluence.atlassian.com/display/JIRA/Configuring+Workflow#ConfiguringWorkflow-Applyingconditionstotransitions) . Then, users without assign permissions should not see the workflow transition.
Many thanks!! I now pretty much get the desired behaviour (as far as I have tested ;-) ).
So just to be clear (and sorry if this is getting painfull but I am a noobie at this)..
1. If a user has assign permissions, an assign button will appear to the left of the comment button (A) but this action is unrelated to the current issue state? So the issue can be in the assigned state but assignee can be changed?
2. If the work flow has a transition called assign this will appear in the workflow buttons block (B) clicking this button forces a state transition.
Is it possible to remove/hide button A?
Is it possible to give them identical behaviour i.e. adhere to workflow?
I would not remove Button A, since this is a System behaviour. BTW, I think you cannot remove this button out of the box.
If your workflow transition is doing nothing else than assigning the issue to someone else, I would remove the workflow transition. In my opinion of a workflow, assigning should be no transition, because the issue itself has no other state after the assignment than before. It is just assigned to someone else.
ok, then the name of the transition might not be the best. It always confuses people if there are two buttons with the same text. Maybe you find a better name for the transition.
And yes, of course you can have unassigned issues. This is a global Jira setting under General Configuration (Allow Unassigned Issues). But take care of issues that are unassigned and so get lost because noone is looking at them...
I get what you mean although some might say there is a change of state in that the bug is now ready to be worked on.
As a matter of interest is it possible to have a bug thats unassigned? By default the issue seems to be automatically assigned to the Project Lead. We only like to have things assigned to a named person when they are actually being worked on?
Thanks for the ongoing support!
Thanks for the suggestions.
It sounds like we work in a similar way to you Alex but I am reluctant to restrict how we use the system in case we want to change things in the future and not have an 'assigned' state.
I am wondering if I altered my 'assign/assigned' transition/state to 'WorkOn/InProgress' (or some such) whether its possible to cause an automatic transition/state change if someone uses the system assign button and the re-open the bug if the user is unassigned. Is that possible?
Same issue here. Two "Assign" buttons. One is by virtue of the flow we created, and the other is the built in "Assign" function to just assign the issue to someone, with no state transition.
It would be helpful if I could simply rename the built in "Assign" button to "Re-Assign". Then my flow could work as designed, where "Assigned" is one of the fist states, and the "reassign" can be used as needed. Atlassian is right to provide the functionality to assign in general, but since this is a very common "action" name associated with state transitions, should have provided some flexibilty around it.
Is it really not possible to rename this button?
The button already has the right name, and if you rename it, you'll need something better than "re-assign", because it needs to cover both assignee A -> assignee B, AND unassigned -> assignee A.
If you use the translation function or edit the language files, the translation could leak into other places where it might make less sense.
I'm not sure that moving the assign functioninto the workflow as nothing more than an assign is "very common" - I've seen it and used it myself a few times, but I'd call it "infrequent" or "rare" mostly. And, of course, I've used different names, leaving "assign" for the standard function
Thanks for your response.
The source of this is that we are doing a quick switchover to Jira (wher 'quick' is important), and in order to make the leap seamless for people, using the same workflow we had before, and will change later. We are moving from Bugzilla, where the default workflow there includes an 'Assigned' state near the beginning. The name of the transition I am giving it is 'Assign' (In bugzilla you simply change the state rather than perform an action). I'll look for another name for 'Assign' in the flow.
I'll add - we have probably seen very different workflows.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs