Permissions confusion wrt assigning issues.

NickW July 1, 2012

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...

Many thanks

Nick

2 answers

1 accepted

3 votes
Answer accepted
Thomas Schlegel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 1, 2012

Hi Nick,

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.

Cheers

Thomas

NickW July 1, 2012

Hi Thomas

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?

thanks

Nick

Thomas Schlegel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 1, 2012

Hi Nick,

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.

Cheers

Thomas

NickW July 1, 2012

Hi Thomas,

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.

So....

Is it possible to remove/hide button A?

Is it possible to give them identical behaviour i.e. adhere to workflow?

thanks

Nick

Thomas Schlegel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 1, 2012

Hi Nick,

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.

Cheers

Thomas

Thomas Schlegel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 1, 2012

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...

NickW July 1, 2012

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!

Nick

Thomas Schlegel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 1, 2012

I would be careful with this. If your workflow does not provide an adequate transition (and maybe one day I'm sure your have more than one workflow with lots more than one project), you can't assign an issue at all.

Alex Taylor
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 1, 2012

Button A can be disabled by going to the System Plugins, finding the Issue Operations plugin and disabling these two modules:

  • View Issue Ops Bar Assign Link
  • View Issue Ops Bar Assign To Me Link
Alex Taylor
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 1, 2012

Indeed :-) I disabled the modules because we use 'Assign' transititions in all our workflows; the act of assigning moves the issue to 'In Progress', and unassigning moves it back to 'Pending'.

NickW July 2, 2012

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?

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 2, 2012

Yup - write a listener that kicks off a transition when the users trigger an "issue assigned" event...

0 votes
Petra Goldstein August 24, 2014

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?

Mike

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 24, 2014

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

Petra Goldstein August 24, 2014

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.

Thanks!

Mike

Suggest an answer

Log in or Sign up to answer