Permissions based on Workflow Status

02/15/2011

Ever wondered how to enforce permission checks based on workflow status? JIRA gives us a big set of options to restrict many of the operations (like edit, comment etc) on the issue or its subtasks depending on the issue status.

Yes, I am talking about JIRA Workflow Properties.

If you need to enforce a particular permission check at any stage in the workflow, all you need to do is to add the jira.permission.* property on the concerned workflow step. Following are the steps:

Login as a JIRA Administrator
Navigate to Administration > Global Settings > Workflows
Create a draft of the workflow if it is active. Navigate to the step which needs to be modified.
Click on the View step's properties link.
Enter the permission property into the Property Key field. The property is of the form - jira.permission.[subtasks.]{permission}.{type}[.suffix] where:
- subtasks is optional - If included the permission is applied on the issue's subtasks. If not the permission is applied on the actual issue.
- permission - is a short name specified in Permissions class. Following are the permitted values as on JIRA 4.2
  
  admin, use, sysadmin, project, browse, create, edit, scheduleissue, assign, assignable, attach, resolve, close, comment, delete, work, worklogdeleteall, worklogdeleteown, worklogeditall, worklogeditown, link, sharefilters, groupsubscriptions, move, setsecurity, pickusers, viewversioncontrol, modifyreporter, viewvotersandwatchers, managewatcherlist, bulkchange, commenteditall, commenteditown, commentdeleteall, commentdeleteown, attachdeleteall, attachdeleteown, viewworkflowreadonly
- type - type of permission granted/denied. The values can be group, user, assignee, reporter, lead, userCF, projectrole
- suffix - An optional suffix to make the property unique when you have the same type added more than once! jira.permission.edit.group.1, jira.permission.edit.group.2 etc

Enter the appropriate value in the Property Value field. If the type is group, enter a group. If it a user, enter a user name and so on.

It might be useful to give a few examples here:
- jira.permission.comment.group=some-group
- jira.permission.comment=denied
- jira.permission.edit.group.1=some-group-one
- jira.permission.edit.group.2=some-group-two
- jira.permission.modifyreporter.user=username
- jira.permission.delete.projectrole=10000
- jira.permission.subtasks.delete.projectrole=10000
You can even use the value as denied when the type is not used. For example, jira.permission.comment=denied means the comment feature is disabled at this state.

Go back and publish the workflow if it was active. If not, associate the workflow with the appropriate schemes.

When a purticular permission property is tied to a workflow status, JIRA looks at it and enforces the same. It is to be noted that workflow permissions can only restrict permissions set in the permission scheme, not grant permissions.

For example, if you have the Edit permission restricted to jira-administrators in the permission scheme, adding jira.permission.edit.group=jira-users wouldn't grant the permission to jira-users. But instead, if you had both those groups in the Edit permission, only jira-users will be allowed to Edit as defined in the workflow permission.

Now take this opportunity and remove some of the code in your issue operations plugin that displays operations based on status ;)

Comments

Marcelo Mrack

02/28/2011 8:30pm

Huh!

Its a very nice trick!

J-Tricks

02/28/2011 11:22pm

It is indeed :) Glad it helped!

Erik

03/07/2011 10:32am

What would be the proper use of Lead?

jira.permission.comment.lead=(name of component with lead associated)

Erik

03/07/2011 10:44am

I now realize that lead is associated with the Project itself, not necessarily a component. Would there be a way to restrict who can resolve/perform actions on a task based on the components associated with the task?

So if I have 'Component A' associated with a task, only the lead of that component can perform operations?

J-Tricks

03/07/2011 11:45am

Erik,

AFAIK, it is not possible. You can include only what is available on the 'Add Permissions' page. Please check out http://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions#ManagingProjectPermissions-AddingUsers%2CGroupsorRolestoaPermissionScheme . group, user, assignee, reporter, lead, userCF, projectrole only are supported where lead is project lead!

Roland Stens

03/28/2011 3:45pm

Also keep in mind that a step property setting will be enforced for all the transitions that belong to the step.

In my case I limited the assignment permission but then I have a transition that requires a person to assign and the assignment field did not show up.

I have opened it up again, but I'd wish to limit the assignment in the step and open up the assignment capability for all the transitions.

I'll take suggestions.

J-Tricks

03/28/2011 11:24pm

@Roland Yes, that won't work because step properties checks for the status of the issue before it applies the permission. Even on the transition screen, it checks the current status before adding the assignee field and prevents it in your case!

Can't tnik of an easy way out here. Might have to handle in the View jsps if you want to hide the assign permission only from that page! Dirty hack :)

Holger

05/24/2011 11:39pm

What would be the proper use of reporter?

jira.permission.attachdeleteown.reporter=granted

J-Tricks

05/25/2011 7:51am

Holger,

This should give the reporter the permission to delete own attachments. But as we mentioned, you cannot grant a permission if it is restricted in the permission schemes! So this will not work if the reporter already doesn't have this permission (which might make it redundant!).

jira.permission.attachdeleteown.reporter=denied will however remove the mentioned permission from reporters even if it is granted via permission schemes.

Suki

06/08/2011 7:48pm

Referring to the last comment, my scenario is I granted permission to reporter on Create Attachment. But, I didn't allow them to delete own attachment in the Permission scheme. Now, I want to grant the permission to delete own attachment for a specific status. I can set the property value on the specific transition as following?
jira.permission.attachdeleteown.reporter=granted

J-Tricks

06/09/2011 1:14am

Suki,

No it wouldn't work. You can't grant a permission if it was not allowed in the permissions. Reverse only will work.

Mirko

07/20/2011 9:30am

Nice trick!

I would use it for our Feedback status - but it dosen't work.

I set

jira.permission.assign=denied

but the comment also disapear. not in the opsbar, but when you push "comment" there would be only the add-button without an input field. If I push the add button I get an error with this exception:

Cause:
java.lang.RuntimeException: Error parsing meta attribute <meta name='jira.permission.assign'>denied</meta>. Name format is 'jira.permission.[subtasks].<permission>.[group|user|assignee|...]'

What is wrong? Dosen't work the trick with JIRA 4.1?

Dietmar

12/26/2011 3:27pm

This error occurs in GreenHopper only. Atlassian calls this a "documentation bug": https://jira.atlassian.com/browse/JRA-26375 (I would call it something else).
According to the latest documentation in http://docs.atlassian.com/software/jira/docs/api/latest/com/atlassian/jira/security/WorkflowBasedPermissionManager.html, I think that the permission should be specified as jira.permission.assign.denied=denied

J-Tricks

07/21/2011 2:31am

Hello Mirko,

It should have worked in 4.1 as well. Where are you adding this property? On a workflow step or on transition?

jira.permission.assign=denied should be added no a step, not on transition.

Mirko

07/21/2011 4:02am

Thanks for you answer, but I had added on the step :/

Mirko

07/21/2011 4:07am

I've also tried a combination with

jira.permission.comment=granted

that also dosn't work

MIrko

07/21/2011 4:41am

I have a workaround:

jira.permission.assign.user=auserwhodosentexist

now it's fine :)

J-Tricks

07/21/2011 5:46am

Mirko,

That's an awesome workaround. Not sure why jira.permission.assign=denied didn't work though I am sure granted will not work at all.

Anyways, glad you got it working.

Yuri

08/17/2011 11:09am

I"m trying to add:

jira.permission.assignable.group=devteam

Is the left of the = the key, and the right of the = the value? Or is all of it added to the key?

Thanks.

J-Tricks

08/17/2011 11:23am

@Yuri Yes, left is the key and right is the value.

Yuri

08/17/2011 11:23am

I'm trying to restrict the list of users in the assignee field in transitions out of a certain step.

I'm trying to use this:

jira.permission.assignable.group=group-name

But, it's not working. Any insight?

J-Tricks

08/18/2011 10:03am

@Yuri You cannot add a group to this permission just by doing this. But if this group has the permission already given by project permissions, then adding this will restrict the assignable permission only for this group.

Does this group have the assignable permission before you added this in the step?

Yuri

08/25/2011 2:56pm

@J-Tricks, ok, I added that group to the Assignable users permission for that project, but still no luck. I see all users in the assignee drop down.

Yuri

08/25/2011 3:07pm

Never mind on last question. It works!

MiQ

08/30/2011 1:24am

jira.permission.comment=denied will break the activity streams if the property is defined on a resolved step

J-Tricks

08/30/2011 3:57am

@MiQ That is certainly news to me. You should report it with Atlassian because it doesn't make sense!

zajt

11/14/2011 1:49am

Anyone figured out how to resolve @MiQ identified problem?jira.permission.comment=denied works great, event with email comment handler, but the activity stream is a problem.

J.H.

11/15/2011 7:18am

Please note that permissions of the form
jira.permission.<type>=denied
do (no longer?) work. You need to use
jira.permission.<type>.denied=<value doesn't matter>
instead.

Joe P

11/18/2011 8:41am

I'm trying to restrict the assignable user list. I used the workflow property jira.permission.assignable.projectrole with the project role id of the Developer project role onthe transition. However it isn't working. In the permission scheme the project role users is assignable and all the users in the developer project role are also in the users project role

J-Tricks

11/18/2011 9:09am

@Joe Even if all the users in developer role is in users role, you should have the developer role explicitly added in the permission scheme.

Can you add that and see if it works after the property is added?

Joe P

11/18/2011 11:42am

I added the developer role to the assignable permission in the permission scheme. However, I'm still seeing all the users from other project roles that are also assignable.

J-Tricks

11/21/2011 6:22pm

@Joe Interesting! I haven't tried this one but I thought that would work.

Joe P

11/22/2011 5:01am

I'm on 4.1.2. Could that be the problem?

J-Tricks

11/22/2011 4:15pm

@Joe I just tried it in 4.1.2 just out of curiosity and it works!!

Is it still not working for you? If so, can you explain the steps you followed?

Poil link

12/22/2011 8:08am

Hi,
Thanks for this tips !

Is it possible to have a negative equal ? Example : jira.permission.create.projectrole != xxxx

J-Tricks

12/22/2011 8:17am

Frankly, I am not sure. I would definitely try it out!

Helen

01/15/2012 1:59pm

Hi!

I'm trying to restrict the subtask creation in a workflow step, but i didn't get it working. I tried to use these properties in the workflow step:
jira.permission.create=denied
jira.permission.subtasks.create.denied

I had also tried other combinations as:
jira.permission.create.group=group-name
jira.permission.create.user=username

and no one worked. What I'm doing wrong?
Can you help me?

Thanks in advances

J-Tricks

01/16/2012 11:26am

The Create Subtask operation doesn't honor this workflow permission and hence I am afraid it is not possible. I had a quick look and edits on the subtasks can be prevented using this technique but not the create. I would think that it is something Atlassian missed out.

jira.permission.subtasks.edit.group=some-group restricts the Edit feature to only members of some-group but jira.permission.subtasks.create.group=some-group doesn't restrict the create subtask option.

Adam Saint-Prix

01/17/2012 5:12pm

This is really helpful. Thanks for posting this. I hadn't used the jira.permission.edit.group workflow property before, but find it's a slick workaround for editing issues when they are closed.

To get this to work, I had to make sure 'MyGroup' had the edit-issue permission in the permission scheme. Jobin mentions this above, but it's an easy thing to gloss over. If the group you are specifying should have the ability to edit issues on a specific step, you need to make sure that specific group is listed in the 'Edit' Issue permission.

I also left the jira.issue.editable permission in so that issues can actually be edited. Again, easy thing to gloss over. After that, I just added in the workflow property jira.permission.edit.group = MyGroup and it worked.

MyGroup could edit closed issues, but no one else could.
Might be a bit redundant, but it took me a sec to figure that out and I thought it might help some other folks.

J-Tricks

01/17/2012 7:31pm

Thanks Adam. Yes, easy thing to gloss over. I had done that first myself!

Michael link

01/18/2012 1:23am

You have to set

jira.permission.assign.denied = denied

(Be aware of the doubled denied!)
to stop assigning issues in the given status.

zouli

01/30/2012 7:14pm

hi, in my case, we have a customerized status named "accepted", The workflow is from open->accepted->in progress. I wish to allow only a certain group to have the authority to set the status from open->accepted. Is that possible? I can't find the proper permission class. Thanks in advance!

J-Tricks

02/05/2012 7:55pm

This is pretty straight forward. You don't need the workflow properties for this. Simply use the 'User is in Group' workflow condition.

http://confluence.atlassian.com/display/JIRA/Configuring+Workflow#ConfiguringWorkflow-JIRAsbuilt-inconditions

zouli

02/14/2012 9:38pm

many thanks for the reply. That's what I want.

J-Tricks

02/03/2012 5:54am

Here is another example where it worked:

https://answers.atlassian.com/questions/33028/can-we-disable-alinking-issues-to-an-issue-when-it-is-closed

Andrew

02/06/2012 11:49am

When using the jira.permission.assignable.projectrole key, does the property value have to be a numeric id or can it be the name given to the role?

For example, if I have a role defined as Project Manager, can I use Project Manager as the value or do I have to figure out the numeric id for this role (no idea how to do this)? Is there an issue with having a space in the name? Using the Atlassian hosted stuff so am setting using their interface where the key and value are entered separately.

J-Tricks

02/06/2012 6:34pm

It has to be the numeric id. Finding the id is pretty easy. Go to Administration, Click on 'Roles' under the 'Users' drop down.

You will find the list of project roles there. Now click on 'Edit' on the required role and see the numeric id at the end of the url!

Something like: https://XXX/secure/project/EditProjectRole!default.jspa?id=10100 where 10100 at the end is the id.

Hope that explains!

Andrew

02/10/2012 2:35pm

Excellent. Finally got a chance to test and worked like a charm. Thank you very much. Wonder if they'll change it to the string a some point. I tried with groups and just used the string which worked fine.

Next one will be, are the properties or'd such that I can have jira.permission.assignable.projectrole = 123 and jira.permission.assignable.projectrole = 456
and the assignees can be in either role. If not, I'll just create a "combined" role that includes both groups.

Thanks again for your help.

J-Tricks

02/10/2012 7:43pm

@Andrew I am not sure about the OR'd part. Maybe you can test it out and let us know ;)

Andrew

02/11/2012 9:09am

Yes! You can do the OR'd part. Trick is to add a digit at the end of the key to indicate there are more than one - read that on a Jira forum sometime ago and managed to remember it. So the two keys look like this:
jira.permission.assignable.projectrole.1 = 123
jira.permission.assignable.projectrole.2 = 456

Thanks again for the help.

J-Tricks

02/11/2012 4:10pm

Cool.. I knew the numbers trick and it is mentioned in the examples. But I wasn't sure if it was an OR or an AND!

Thanks for posting back here. I am sure it will help someone.

Victor

02/13/2012 4:27am

Hi!

I'm going to implement "On-Hold" step, it'll have incoming transitions from numerous steps and outgoing transitions to them. The idea is to restrict permissions to perform only one transition that would bring the issue to step which it had before entering on-hold.

Thanks beforehand!

J-Tricks

02/13/2012 5:50am

Perhaps I didn't understand fully! Is there any reason why you can't use the workflow conditions? Can you explain a bit more?

Victor

02/13/2012 7:53am

I'm able to enter the "On Hold" step from several other steps, and I need to have a backward transition permitted only to step I entered from: i.e. it should be possible to go 1) "New" - (put on hold) -> "On Hold" - (put back to New) -> "New" or 2)"New" - (ready for review) -> "In review" - (put on hold) - > "On Hold" - (back to review) -> "In review", but it should bot be possible to go 3) "New" - (put on hold) -> "On Hold" - (back to review) -> "In review". It doesn't seem possible to implement with conditions since I need to store somewhere previous step name and use it for check

J-Tricks

02/13/2012 8:05am

@Victor Checkout the Previous State condition in JMWE plugin : https://studio.plugins.atlassian.com/wiki/display/JMWE/JIRA+Misc+Workflow+Extensions+Documentation

You might also want to look at http://www.minyaa.com/documentation/latest/Features/ModuleWorkflows/WorkflowFunctions/BackToPreviousStep.html but it is a commercial plugin.

Victor

02/13/2012 8:27am

Thanks a lot! Exactly what I needed

Denis Weerasiri link

03/10/2012 11:10pm

Hi,
Is it possible to to set workflow scheme via SOAP?. I'm using 4.3.3. Based on https://jira.atlassian.com/browse/JRA-17870 , seems it's not fixed at the moment. Please correct me if I'm wrong.

Denis Weerasiri

J-Tricks

03/11/2012 6:13am

You are right, workflow scheme cannot be changed via SOAP as it needs additional user input.

You can only create a new scheme via SOAP. Changing a project's scheme is not supported.

Denis Weerasiri link

03/11/2012 9:56pm

Thanks. I'll try this using a SQL command. If it works, I will update the thread.

Dieter

03/24/2012 11:08am

Hi Jobin,
I really like this page and often use it as a reference in a.a.c.
You might yet add the permission viewworkflowreadonly which is new since 4.4.
Regards,
Dieter

J-Tricks

03/24/2012 2:46pm

Thanks Dieter, I have added the permission to the list. Glad to know the page helps ;)

dsilve

04/16/2012 5:04am

Hello,
I am not able to make this parameters to work. What I want is something similar to what achieved by Adam Saint-Prix.
Basically I need closed tasks to be not editable for everybody except for one user that should have permission to add or change the logged worklogs.
What I did is to add the following property for the Closed step:
jira.permission.edit.user=ds
but it doesn't seem to care about this property. As a matter of fact if I have on the same step the property:
jira.issue.editable = false
Then nobody can edit (not even ds) and if this property is true then everybody can edit closed issues, of course also ds.
I also tried to use a group instead of a user but without success. Am I missing something?
The Jira version that I am currently using is v4.4.3#663-r165197.

J-Tricks

04/17/2012 7:46am

jira.permission.edit.user=ds

should work fine. Worked for me in 4.4.3! Can you make sure the workflow changes are effective when you do that?

dsilve

04/18/2012 8:10am

Hi again,
Yes the changes are published.
As a matter of fact if I add the property
jira.issue.editable=false
then i cannot edit a closed task. But I would like to have one user with the rights to edit the jira issues and to have this I should just be able to add to the Closed step the property
jira.permission.edit.user=ds
but it is simply doesn't care about this :(

J-Tricks

04/18/2012 8:26am

@dsilve There is certainly something wrong in what you are doing because it works fine for me!

So let me ask this. Is 'ds' the name of the user? Does that user has edit permission on the issue? Can 'ds' edit the issue when the property is not added?

dsilve

04/19/2012 12:12am

ds is the username of the user. I also tried using the full name.
Yes, ds can edit the task when editable is true or not set.

1) If I have:
jira.permission.edit.user=ds
Then everybody can edit and add worklogs. Even if "ds" was a wrong username I would expect that nobody could edit the task.

2) If I have:
jira.issue.editable=false
jira.permission.edit.user=ds
Then nobody can edit, not even ds.

3) If I have:
jira.issue.editable=true
jira.permission.edit.user=ds
Then everybody can edit like in 1)

Here you can see how the step tag looks like in the workflow xml.

<step id="8" name="Closed">

<meta name="jira.status.id">6</meta>

<meta name="jira.permission.edit.user">ds</meta>

..........

Anyway here (http://confluence.atlassian.com/display/JIRA044/Workflow+Properties) they say that these properties are not recommended, so maybe they don't work in all the releases?

J-Tricks

04/19/2012 4:53am

It is a bit strange because the same thing (option 1 above) worked for me in my 4.4.3 environment. Not sure what is going on here but sorry I am not of help.

Maybe you can write a workflow condition plugin to do this without wasting much time!

Bryan

04/23/2012 12:06pm

Hi,

I I'm trying to figure out something.

Is there a way to change who can be assigned to an issue based on priority level during ticket creation?

For example, if you create an issue, you can choose a person from the specified list. However, if you mark the ticket as a P1 (or however you flag an issue to be a true fire-drill), to assign the issue to a different list of people (say directors or what-not).

It sounds like I have some options obviously during workflow transitions... but I didn't know what to do exactly during issue creation itself.

Any tips appreciated!

J-Tricks

04/23/2012 12:33pm

I can't think of any trick to do that using Workflow Properties. You will have to write a new post function or listener that does the assignment based on the priority value!

Kalynn

05/15/2012 12:28pm

It looks like the permissions associated with Jira 5.0 have changed based on the link. Conseqeuently, if we are on 5.0, do we have to now update all of our workflows to use these new ones (e.g. admin vs administer, system_admin vs sysadmin, create_issue vs create). Thoughts?

J-Tricks

05/16/2012 2:48pm

Kalynn,

There are no changes in 5.0 for the names. I think you are talking about the statis varibale names but what you should really use is the short names that is returned in the getType method in that class.

Eg:

if (perm.startsWith("admin")){
return ADMINISTER;
} else if (perm.startsWith("use")) {
return USE;
}

Kalynn

05/21/2012 6:52pm

Thanks for the clarification. Appreciate it!

Kalynn link

05/21/2012 7:11pm

Do you know how to get a group's ID to reference for a permission?
If I go to the URL, I don't get an ID - I get a token https://phytel.jira.com/secure/admin/user/ViewGroup.jspa?atl_token=AG87-S37R-QM8W-6VWE|61b59bf02b158fb8c263cb2823a4980f6b02a3a4|lin&name=users

J-Tricks

05/21/2012 7:50pm

You don't need id for group. You should be using the group name.

Kalynn link

05/21/2012 7:52pm

Thanks so much! I thought we had to use the IDs for all of the value references. Much appreciated! Karie

Your comment will be posted after it is approved.

Permissions based on Workflow Status

Comments

Leave a Reply

Author

Categories

Archives