Permissions based on Workflow Status

2/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 ;)

258 Comments

Marcelo Mrack

2/28/2011 03:30:54 pm

Huh!

Its a very nice trick!

Eli Durayski

9/19/2016 11:03:53 am

Very nice indeed Sir!

arch

1/16/2017 01:08:46 am

no success. I tried jira.permission.close.projectrole.1 on closed step.
I wanted only lead to close the permission. no member allowed to close the issue.

J-Tricks

2/28/2011 06:22:23 pm

It is indeed :) Glad it helped!

Erik

3/7/2011 05:32:09 am

What would be the proper use of Lead?

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

Erik

3/7/2011 05:44:21 am

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

3/7/2011 06:45:05 am

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

3/28/2011 11:45:23 am

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.

Sandy Toler

8/23/2022 05:40:06 pm

@Roland, have you tried removing the assignee field from the edit screen and add it to the view only screen. Having it on the view only screen keeps anyone from editing the value in the field.
Then you can create a "custom transition screen" that pops up when a user transitions to the next step--the screen should include the assignee field.

J-Tricks

3/28/2011 07:24:24 pm

@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

5/24/2011 07:39:04 pm

What would be the proper use of reporter?

jira.permission.attachdeleteown.reporter=granted

J-Tricks

5/25/2011 03:51:42 am

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

6/8/2011 03:48:12 pm

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

6/8/2011 09:14:41 pm

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

7/20/2011 05:30:13 am

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 10:27:23 am

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

Rusi Popov

12/18/2015 02:57:10 am

Actually jira.permission.assign=denied means nothing and causes RuntimeException as it lacks the <type> part of the permission.
The proper syntax is:
jira.permission.assign.denied = whatever
as in the case or "denied" type the value is not considered.
Also to mention that
jira.permission.assign.user = denied
is also wrong (seen many times), giving access to the user with "denied" name.

J-Tricks

7/20/2011 10:31:32 pm

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

7/21/2011 12:02:03 am

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

Mirko

7/21/2011 12:07:49 am

I've also tried a combination with

jira.permission.comment=granted

that also dosn't work

MIrko

7/21/2011 12:41:21 am

I have a workaround:

jira.permission.assign.user=auserwhodosentexist

now it's fine :)

J-Tricks

7/21/2011 01:46:17 am

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

8/17/2011 07:09:12 am

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

8/17/2011 07:23:28 am

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

Yuri

8/17/2011 07:23:47 am

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

8/18/2011 06:03:08 am

@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

8/25/2011 10:56:01 am

@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

8/25/2011 11:07:19 am

Never mind on last question. It works!

jair

10/5/2012 11:57:16 pm

How you solve your problem?

Sabi

3/23/2018 09:59:25 am

@Yuri, how did you solve the problem? It is not working for me neither.

MiQ

8/29/2011 09:24:02 pm

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

J-Tricks

8/29/2011 11:57:14 pm

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

zajt

11/13/2011 08:49:53 pm

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 02:18:00 am

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 03:41:09 am

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 04:09:19 am

@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 06:42:32 am

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 01:22:32 pm

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

Joe P

11/22/2011 12:01:30 am

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

J-Tricks

11/22/2011 11:15:42 am

@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 03:08:16 am

Hi,
Thanks for this tips !

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

J-Tricks

12/22/2011 03:17:43 am

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

Helen

1/15/2012 08:59:24 am

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

1/16/2012 06:26:44 am

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.

Fabian

7/2/2012 09:06:05 pm

This does not work because of the outstanding work for:
https://jira.atlassian.com/browse/JRA-10077

I have filed a Bug:
https://jira.atlassian.com/browse/JRA-28797

Can someone running JIRA 5.x please check if it works and leave comment in the bug?

Adam Saint-Prix

1/17/2012 12:12:40 pm

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

1/17/2012 02:31:54 pm

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

Michael link

1/17/2012 08:23:39 pm

You have to set

jira.permission.assign.denied = denied

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

zouli

1/30/2012 02:14:47 pm

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

2/5/2012 02:55:32 pm

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

2/14/2012 04:38:35 pm

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

J-Tricks

2/3/2012 12:54:07 am

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

2/6/2012 06:49:44 am

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

2/6/2012 01:34:09 pm

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

2/10/2012 09:35:36 am

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

2/10/2012 02:43:10 pm

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

Andrew

2/11/2012 04:09:08 am

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

2/11/2012 11:10:59 am

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

2/12/2012 11:27:00 pm

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

2/13/2012 12:50:31 am

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

2/13/2012 02:53:03 am

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

2/13/2012 03:05:40 am

@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

2/13/2012 03:27:42 am

Thanks a lot! Exactly what I needed

Denis Weerasiri link

3/10/2012 06:10:11 pm

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

3/11/2012 01:13:18 am

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

3/11/2012 05:56:39 pm

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

Dieter

3/24/2012 07:08:34 am

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

3/24/2012 10:46:10 am

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

dsilve

4/16/2012 01:04:35 am

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

4/17/2012 03:46:51 am

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

4/18/2012 04:10:13 am

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 :(

Max Weißböck

10/5/2016 05:02:47 am

Did you find any solution for this? I have the very same Problem. Issue needs to be NOT editable, but log work should be possible.

J-Tricks

4/18/2012 04:26:15 am

@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

4/18/2012 08:12:31 pm

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

4/19/2012 12:53:21 am

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!

Chaya link

8/15/2012 03:23:25 am

Same issue for me too. We are using 5.0.1. I tried group name, user name. but no luck. If I do this:

jira.issue.editable=true

Every body can edit, which I don't want to do :(

Added group and user's name in Edit Issue permission.
Any update on this issue?

J-Tricks

8/15/2012 03:37:53 am

@Chaya It should work fine in 5.0 as well. What access did you try to provide? As I said in the blogpost, you can't grant new access. You can only limit the current access.

Is that what you are trying to do?

Chaya link

8/15/2012 03:51:18 am

Thank for your quick response. I am not granting new access. I added the group and users names(2) in project specific scheme. I have devlopers and admin group. But I want to restrict Edit Issue access only for Admin group after an Issue has been closed.
I gave the property in closed Issue transition properties.

Am I missing some thing ??

This helps me a lot...!

J-Tricks

8/15/2012 03:54:22 am

That should work. jira.permission.edit.group=admin-group should do the trick!

i.e. property key will be jira.permission.edit.group and value will be admin group name.

Bryan

4/23/2012 08:06:54 am

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

4/23/2012 08:33:36 am

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

5/15/2012 08:28:49 am

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

5/16/2012 10:48:19 am

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

5/21/2012 02:52:42 pm

Thanks for the clarification. Appreciate it!

Kalynn link

5/21/2012 03:11:18 pm

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

Kalynn link

5/21/2012 03:11:54 pm

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

5/21/2012 03:50:43 pm

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

Kalynn link

5/21/2012 03:52:49 pm

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

Kalynn

6/21/2012 12:42:15 pm

Are you able to lock down comment visibility but allow the rest of the jira issue to be viewable?

J-Tricks

6/21/2012 03:32:49 pm

Unfortunately, No. There is no permission that drives comments separately from issue visibility. You can hide individual comments using the 'Viewable By' option but that is not for all comments on the issue. That cannot be driven by this workaround either.

Having said that, you might be able to do this by some Javascripts. Look for the status and hide the comments div!

Chris link

6/24/2012 05:10:43 pm

Hi,

What does the pickusers permission do? We have a few User Picker type custom fields, which allow any user in the database being selected, it would be nice to specify only particular groups to be selected (ie. jira-users) in these custom fields, will this permission help? If not how can I specifiy user groups in User Picker fields (ie. like the assignable user..)

J-Tricks

6/25/2012 01:39:50 am

Nope, This permission won't be useful for your requirement. You will have to create a customfield to handle this.

Chris

6/26/2012 12:04:49 pm

Thanks...
When you say "create a customfield" do you mean I need to create a new type or is there a custom field type already available which does this that I can use? If the latter, what type is it?

Cheers

J-Tricks

6/26/2012 01:11:55 pm

I meant to create a new type!

Verena

7/9/2012 09:26:53 am

Hi!

Is it possible to use jira.permission.assignable.projectrole on transitions instead of workflow steps? For steps it works fine for me, but I'm actually trying to restrict the list of assignable users for the initial transition, i.e. the users I can select from the assignee field when I create an issue. If anyone has an idea how to do this, I'd appreciate any hints!
Thanks!

J-Tricks

7/9/2012 09:29:22 am

I don't think it is possible. You can add it only on steps.

JAson

7/17/2012 09:03:44 am

You could set a permission scheme and set the permission "Assignable User" to the users you wish to be assignable. This of course would then be project wide.

Casey

7/16/2012 03:30:19 am

This looks like it would be really helpful, but I can't get it to work for our setup (I'm not sure what I'm doing wrong).

I want to limit the ability to comment to administrators only once a ticket moves to a certain status. Our administrator group is called ATE-administrators - would I set the Property Key as

jira.permission.comment.group=ATE-administrators

Do I need to put anything in the Property Value field?

J-Tricks

7/20/2012 12:27:59 pm

Casey,

The key will be jira.permission.comment.group and value will be ATE-administrators

See if that works for you.

Vadim

8/29/2012 10:06:49 pm

Hi J!
Lots of interesting information in this thread. Thanks for that!
What I need to do is to cut out Log work field from the workflow screen when the issue is transitioned out of certain workflow steps (not all of them). Issues in these steps do not need to be worklogged.
I was thinking of adding a step property something like: jira.permission.worklog.denied. Do you think it'll work? I'll appreciate any help/advice.

J-Tricks

8/30/2012 10:38:05 am

Yes, it should work!

Btw, I have seen lot of people saying denied doesn't work in latest versions but you can try it. In the worst case, limit it to a non-existant user as some one suggested above!

hope

9/10/2012 08:25:52 pm

when i try the jira.permission.comment=denied it doesn't work any ideas?

J-Tricks

9/11/2012 01:41:40 am

Make sure you added the property on the step and not transition. If that doesn't work, try the workaround people used.

jira.permission.comment.group=GroupThatDontExist

Fabian

9/11/2012 02:11:40 am

I thought it's jira.permission.comment.denied without any value

J-Tricks

9/11/2012 02:36:17 am

It worked for me in the past but some people above have reported that it doesn't work in some JIRA versions.

jair

10/6/2012 12:02:09 am

hi
i set state property jira.permission.assignable.group in my custom workflow, but it works an not work.
the default Assign Screen work fine but my custom Screen by assinee field not worked and show all users.
please help me.
Thanks

J-Tricks

10/10/2012 02:45:17 pm

That's strange. It is supposed to work even on custom screens. Are you sure you have the assignee field on the screen and you can use it to assign?

SiliconLunch

11/1/2012 05:10:08 pm

I'm seeing the same strange behavior. I have added a property to a step jira.permission.assignable.user=foo. When i visit the issue and click on the built-in JIRA Assign button, I only see foo as the allowable user (correct). however, when i click on a transition button, which has a screen containing Assignee, I see a full list of all possible assignable users - not just foo as expected. And i'm able to assign to anyone in that list. Is this a bug? I'm testing on 4.4.3

J-Tricks

11/2/2012 02:00:53 am

Can you add the same property under the transition as well and see how it goes?

SiliconLunch

11/2/2012 02:20:05 am

I did try adding this same property to the workflow transition, but it had no effect.

J-Tricks

11/2/2012 04:26:15 pm

I just tried it. It works on the transition screen only when both the source step and destination step has that property.

Transition doesn't need that property.

It maynot be useful if you don't want transition step to have the assignment restricted. Maybe removing assignee from transition screen is a better option!

SiliconLunch

11/6/2012 06:30:47 pm

Works like a charm! Thank you!!!

SiliconLunch

1/21/2013 12:06:31 pm

It turns out that requiring jira.permission.assignable property in BOTH the source & destination steps is a problem for us. Because, when the issue is in the source step, it cannot be freely assigned anymore. We don't want to limit assignment in any particular *step*. It's the *transition* we want to apply the restriction on. Because this works in the Issue View screen, but not a transition screen, it seems like a bug. I wonder if there can be any workarounds?

J-Tricks

1/21/2013 01:51:37 pm

That is indeed a limitation I guess. You will have to raise a feature request with Atlassian to allow it on a transition as well.

Vishnu link

10/24/2012 10:36:28 pm

I would like to block creation of sub-tasks in a state.
How to do this ?

I tried

jira.permission.subtasks.create=denied
jira.permission.subtasks.create.group= some-non-existing-group
jira.permission.subtasks.create=false etc.
Could you point where I was I wrong ?

Fabian

10/30/2012 03:41:18 am

You cannot because it is broken, please see Helen's comment (and my response):
http://www.j-tricks.com/1/post/2011/02/permissions-based-on-workflow-status.html#comment866210691226687755

J-Tricks

10/30/2012 04:17:39 am

Subtasks doesn't have a separate create operation and that won't work I guess.

Sergey

12/11/2012 02:10:18 am

What is the syntax of customfield "userCF" with spaces like "custom users"

J-Tricks

12/11/2012 02:55:23 am

Did you try the customfield_12345 format where 12345 is the unique id of the user custom field?

G-Lap

8/28/2013 04:56:37 am

the customfield_12345 works. It allows only the user contained in the custom field 10704.
key : jira.permission.comment.userCF
value : customfield_10704

I'm much interesed in deny comment to the user contained in this custom field !
Any idea ?

J-Tricks

8/28/2013 06:46:33 am

Unfortunately, that won't be possible I guess. You can only restrict access to X but cannot provide access to everyone except X.

Tony

12/11/2012 12:02:21 pm

So jira.permission.comment=denied seems to be working just fine in that its not allowing comments.

I don't want to allow comments in the Resolved or Closed state, but some of our users use email to try to add comments. If the issue is in either state, the comment isn't added, but also there is no feedback to the users that the comment wasn't added and they need to reopen the issue if they want to add the comment.

Is there a way to do this? Trigger a CommentAddFailed event?

J-Tricks

12/11/2012 12:46:25 pm

Unfortunately, I don't see a way to handle this. Once disabled, you won't be able to add comments, whether it is via UI or via other methods like email, remote APIs etc.

An event is triggered only if a comment is successfully added. So you won't be able to catch a failure unless you write your own mail handler!

Tony

12/11/2012 12:52:10 pm

That's what I was thinking. We're using OnDemand, so that's not an option for us. Thanks!

Laura

12/14/2012 03:45:26 am

Is there a way to use this on the "create" step to deny creation of an issue to a certain group? Is there a way to make the worklog non-editable through step properties also?

J-Tricks

12/18/2012 12:28:38 pm

You cannot do the first - there is not issue when the user clicks on create.

But you should be able to stop adding / editing worklogs using step properties.

Eric Sebian

5/10/2013 05:22:57 am

Can you tell me what the property key and property value would be for the following: group A has been granted assign permissions via the permissions scheme. I want to deny that assign permissions at the "Close" transistion of the workflow to keep them from trying to assign it to someone else. I think the property value would be: jira.permission.assign=denied but I'm not sure of the key. Please advise. Thanks. ejs

J-Tricks

5/13/2013 06:41:28 am

Hi,

Please go through the comments. There are lot of examples for denied and some work arounds as well.

derek

5/15/2013 05:34:11 pm

@J-Tricks

My setup:
I'm using JIRA (v5.2.11#854-sha1:ef00d61)

devGroup = Dev1, Dev2
HDGroup = HD1, HD2

Project 1 - assignable user = devGroup, HD Group

In one of the Status of workflow:
jira.permission.assignable.group = devGroup

At that status, when assign:
1. Yes the assignee field drop down did show only - Dev1 and Dev2
2. But if I type in HD1 (the userid)
3. Click the "Assign" Button
4. Ticket got assigned to HD1 !!!

Look like the control only apply at the assignee drop down and if user direct key in a userid, it will not kick in.

J-Tricks

5/16/2013 02:01:54 am

Interesting. Not sure if it is a bug that was introduced in 5.2 or not. You should take it up with Atlassian and see what they says.

mrp link

9/18/2013 10:13:28 pm

Hi, all

I'm trying to restrict browsing an issue in a particular status to groups that are assigned to perform their part from the whole issue ( e.g. 2 steps with custom statuses "assigned to MRF" and "performed by MRF" are done by the MRF group another 2 steps with custom statuses "received by DFG" and "processed by DFG" are done by the DFG group

I want that only these groups could see/search in the navigator the issue in the corresponding statuses and no one else.

permission Browse is set in the permission scheme for both of them

I'm using

jira.permission.browse.group=MRF ( set on "assigned to MRF" and "performed by MRF" )

and

jira.permission.browse.group=DFG ( set on statuses "received by DFG" and "processed by DFG" )

does it have sense ? it's not working

JIRA 5.0.4

mrp link

9/24/2013 07:24:30 pm

jira.permission.browse.group1
jira.permission.browse.group2

Izzy

10/31/2013 04:34:00 am

Hello.What I have to do to set that the users just can see an amount of the Workflow Steps?? Thank you.

J-Tricks

10/31/2013 07:31:00 am

Setting permission on for workflow transitions if easier than you think. You can just make use of the workflow conditions. Conditions control who perform a transition and under what circumstances.

See https://confluence.atlassian.com/display/JIRA/Advanced+workflow+configuration#Advancedworkflowconfiguration-addingaconditionAddingacondition.

Marcus

12/23/2013 11:54:15 pm

Hey guys,

Can anyone confirm jira.permission.assignable.group still works in JIRA 6?

I've done this in the past but can't seem to get it working in JIRA 6.

Any leads?

J-Tricks

12/27/2013 09:53:25 am

Worked fine on 6.1. Make sure you are testing it correctly. assignable permission is used when you want to assign a ticket to selected people only. If you are trying to limit the "Assign" permission, use jira.permission.assign.group

Marcus

12/27/2013 01:16:03 pm

Have you tried typing names of people who weren't supposed to be assignable on that step?
The suggested users displayed only assignable users (correctly)m but i was still able to assign the ticket to whoever I wanted.
I did the same thing in 5.2 and worked fine, so i do know how it's supposed to work :)

J-Tricks

3/6/2014 03:48:54 pm

Missed this comment earlier. I haven't tested it that way. Must be a bug then!

Nathan [Valiantys] link

2/24/2014 02:40:47 am

Hello,

you can add "groupCF" as a type in your article. This works well! It allowed me to set the list of assignable user from a Group Custom Field.

Thanks for your article, it helped me a lot!

Arne Schirmacher link

6/12/2014 05:06:42 am

I want to disable commenting and uploadintg attachments to an issue after it is closed, so I added the property keys jira.permission.comment.group and jira.permission.attach.group both with values jira-developers in my workflow step properties.
This disables commenting for jira-users and allows it for jira-developers (this is what I want) but surprisingly I can still upload new attachments as jira-user. This should not be the case.

Any thoughts?

Arne Schirmacher link

6/12/2014 08:16:07 pm

Hi, please delete / disapprove my yesterday posting. The attachment permission works now, I have no idea why it did not work yesterday. I made sure that each workflow modification has been published.
best regards, Arne

J-Tricks

6/13/2014 01:07:22 am

Glad to know it is working. I will leave the other comment as it might help someone else :)

Sergei P. link

7/23/2014 04:38:53 am

Please review article, cause of https://jira.atlassian.com/browse/JRA-32715 and https://docs.atlassian.com/software/jira/docs/api/latest/com/atlassian/jira/security/WorkflowBasedPermissionManager.html
For Example "jira.permission.comment=denied" should be just "jira.permission.comment.denied" with empty value field

Gaby

8/24/2014 11:26:39 pm

Properties could be used also for transitions? In the same way?
I tried to blocked the comment in the transition using:
jira.permission.comment.denied, without success

J-Tricks

9/2/2014 06:29:52 am

No. These only work on steps, not transitions.

Areg

9/5/2014 04:43:21 am

I am trying to restrict the "Create Sub-Task" functionality to assignee only but I am not sure that the jira.permission.subtasks.create.assignee=granted or jira.permission.subtasks.create=assignee is correct.

J-Tricks

9/7/2014 01:40:05 am

As mentioned in the comments, "granted" will not work at all. The second format is correct.

But, create on subtasks is not restricted by the create permissions on the subtask itself. It is restricted by the edit permission on the parent issue.

Areg

9/7/2014 06:12:58 am

Hi

I have two separate workflows for main issue types and sub-tasks.

Now I am trying to give a permission to some people to raise issues but would like to limit the subtasks only to the main issue assignee.

Will try to play.

Thanks,
Areg

Radim

10/17/2014 12:14:25 am

Hi all,

I used "jira.permission.edit.group" for specific user groups. But there is another user groups, who wants to have the permission to change one customfield. Is this possible?

Thank you in advance!

J-Tricks

10/20/2014 02:28:15 am

Radim,

You can't achieve field level security using this technique. For that, you will need plugins like the field security plugin.

Brian link

10/21/2014 03:04:14 am

JIRA 4.4.3

I would like to prevent the Reporter from Transitioning an issue from a particular state, i.e only a user that is NOT the reporter can Transition.

I haven't found a way to do this using Permission Scheme or Transition properties, the best I could come up with is to use a Condition on the transition so that only the assignee may use the transition, AND to prevent the Reporter from being the assignee via
jira.permission.assignable.denied=reporter.

Is this correct? Do you have any suggestions for a better way to accomplish this? Thanks

J-Tricks

10/22/2014 03:28:24 pm

This won't work. You can only specify who "can" do the transition. You can not specify who "can not" do it.

The best way to do what you want is to add a workflow condition that says the current user is not reporter. When you do that, the transition won't be visible to the reporter.

prasad

10/28/2014 06:10:35 pm

Hi,

we are using few of the permissions properties on our workflows, those are working fine!
the problem is it is printing all the user names in log file(catalina.out), not sure why it is printing and not sure how to stop that?

Thanks for sharing good tricks!!

J-Tricks

10/30/2014 02:56:07 pm

Hmm, never seen that before. Are you sure it is not coming from elsewhere? How is it printed in the logs? Can you add a snippet here?

prasad

10/30/2014 06:53:07 pm

something like follows
2014-10-31 00:45:22,418 http-bio-80-exec-6091 INFO prasad 45x2015399x3 18sh52k 100.65.245.96 /secure/EditAction!default.jspa [atlassian.jira.security.WorkflowBasedPermissionManager] attach granted by permission scheme and workflow perm granting attach to Project Role '10010'
[prasad, david, john,......]

J-Tricks

10/31/2014 01:07:20 am

Oh, never noticed those. Maybe you can reduce the log level to WARN to hide all those noise.

Kathrin B.

7/1/2015 02:38:23 am

Hi,
I'm getting the same log messages for edit right permissions on workflow step. But unfortunately it is causing further problems on my side.

I do have a workflow with several steps:

- Open
- Submitted
- Accepted

Open has no permission restrictions. Everybody can open an issue and send it to a dispatcher when submitting it. In Status Submitted just a dispatcher should be allowed to make changes and send it to accepted.

Submitted and Accepted do have jira.permission.group.edit=DISPATCHER and jira.permission.group.move=DISPATCHER. Transition conditions are also set just for the dispatcher
Meaning any user not in Group Dispatcher is not allowed to do any further changes.

When triggering workflow transition from Open to Submitted with a Non-Dispatcher User I’m getting the same INFO Log Messages, as described by the users before but a lot more for the edit permission than for the move permission and my browser ends in loop.

When cancelling and reloading in browser the issue has the correct status and everything seems to be all right, but it is not an option to have the user to cancel the browser page loading all the time.

Unfortunately it was not an option to just set the log-level to WARN, even shutting it off doesn’t make any change on the loading problem.

When kicking the edit-permission for Submitted it works fine of course.

Can you help me with that?
Thanks a lot

J-Tricks

7/4/2015 01:12:21 am

I am suspecting this comes directly from the code and so we won't be able to override those log messages. Might want to raise it with Atlassian!

Dennis

11/25/2014 10:34:38 pm

Hi,

do you have an Idea how i can allow to assign an issue to me but to
prevent that i can assign it to others (PULL instead of PUSH)?

The status has to remain in its state.

With jira.permission.assign.user=nobody i don`t have the "assign to me" link that i would need.

J-Tricks

12/25/2014 04:08:33 am

You can use the two different permissions, "assign" and "assignable". But someone must have the "assign" permission because there should be someone who can assign it to you.

Right now, you are removing "assign" permission from everyone and it doesn't matter who has the "assignable" permission because nobody will see the assign operation.

manap

12/9/2014 01:36:11 pm

Hi,

I would like to restrict to "comment" in "Resolved" status, then i tried, jira.permission.comment.user=denied , which is working no comment allowed when the issue is in the "Resolved" status.

but when transitioning status to resolved, we set the pop-up screen for resolution. when i try to input the comment on that, it does not allows to comment , with the error message showed up, no permission to comment. if i proceed without comment input, it works to move to the Resolved status.
I am wondering if i have a way to comment on the transition.
Does it work as expected?
probably if no comment is allowed in the resolve issue transition either, then comment field should be invisible, as this will occur a confusion.

Please give me a clue to solve this.
I am looking forward to hearing from you.

regards,
manami

J-Tricks

12/10/2014 01:20:37 am

It is weird that JIRA is not allowing the comments on transition before it reaches "Resolved" status. Maybe you should report to Atlassian. Ideally, comments should be restricted noly once the status is reached.

Haven't tried it before and so not sure how it was in older versions of JIRA.

manap

12/10/2014 11:49:18 am

Thanks for your reply.

I see, as you supposed, it works weird,
yes, it should be working on the "resolved" status.
we are working on the JDC, v6.3.10.
I am going to ask Atlassian why it happens.

thanks,
manami

EJ Sebian

2/22/2015 08:58:38 am

Hi Manap. Did Atlassian ever get back to you with a solution? Or does anyone else have a viable solution? I am having the same problem, where I dont want to allow the developer to be able to comment unless it's during a transition. This forces them to click the transition button to communicate as opposed to just commenting.

thanks.

Frank

1/9/2015 12:47:17 am

I have the same problem with "log work". We have restricted the possibility to log work in status "resolved" and "closed". That works fine. However, it seems that this restriction also is enabled during the transition from "in progress" to "resolved". On our Resolve Screen, which appears on this transition, users are asked to enter solution, final comment and log work. But the field value from "log work" is not processed. Any ideas?

spectre

1/8/2015 09:15:37 am

I've run into this issue as well. It appears during one of the updates the order of processing during a transition got switched and it now changes the status before checking permissions and applying comments. I've found rather than deny comments to all when a ticket is closed I need to allow the developers project role 10001 so they can comment during transition to closed status.

EJ Sebian

2/23/2015 02:22:38 am

Then how do you limit comments outside of the transition? Are you denying comments through the step name properties or somewhere else?

Eric Sebian

2/27/2015 01:34:58 am

Any word on this? Can you please elaborate?

EJ Sebian

2/5/2015 05:27:29 am

Hola! Is there a way to direct comments to a specific person or group at a specific step? I have users commenting on requests from the outlook email (therefore no @mention) and I want their comments on a "Proofing" step to go to the proofing team. If I add the proofing team to the comments notification they get ALL of the comments. which usually dont pertain to them. Oh, and they are not the current assignee. Thoughts? Thanks in advance for the help!.

J-Tricks

2/5/2015 07:29:22 am

Unfortunately, that is not possible without coding. You will have to handle that in a listener and use custom events to direct notifications.

EJ Sebian

2/5/2015 08:27:58 am

Thanks. Not the answer that I was looking for, but it's good to know. :(

meysam

2/21/2015 06:08:13 pm

im use Group Picker (single group) cf with customFieldId=11200 for group assigne in issue.
What does the pickugroup permission do? when select group in cf, user allow any group in database select.

J-Tricks

2/22/2015 03:26:39 am

Not sure if I understood the question. Are you trying to restrict the group that can be selected on the custom field?

Catalyn

2/26/2015 09:09:36 pm

Hello,
Is there any possibility to limit a group of users to change their status from new to open (ex). But other groups that have this permission can change further.

J-Tricks

2/27/2015 12:21:10 am

That is easy! You just need to use a "workflow condition" to make sure the user is in the selected group (s).

George link

3/1/2015 11:02:19 pm

Hi J-Tricks,

thanks for describing the great trick here. Is there any chance that you can update your article with the most current permission and type keywords? Yours is still referring to JIRA 4.3. This would also make sense because your page is directly linked to from the current JIRA manual.

Best regards,
George

Georges

3/29/2015 09:04:04 pm

Can you please add the priority to the list of permissions.

J-Tricks

3/30/2015 01:04:59 am

What do you mean by Priority?

Georges

3/30/2015 01:10:18 am

I mean how to set permission to allow certain group to change the priority of the request.

Patrice

4/28/2015 01:31:27 am

Hello there,
is it possible to restrict creating sub-tasks in a certain status?
We do not want to allow creating sub-tasks if the issue's status is Resolved.

Tests with the following properties did not have any effect:

jira.permission.subtasks.create.user=denied
jira.permission.subtasks.create.denied=true

Do you have any ideas on how to solve this problem?
Should I omit subtasks in order to get it working?

Thanks!

J-Tricks

4/29/2015 09:38:44 am

No, it is not. Create transitions doesn't support workflow conditions or properties like this.

An alternative might be to add a workflow validator on the subtask workflow to check the status of parent issue. Not pretty but will get the job done.

Douglas

5/3/2015 09:41:18 am

I am attempting to prevent a group from having the ability to clone an issue and making the change specific to a step in a workflow. I am entering: jira.permission.create.clone.denied = QA (where QA is the group). The results are all groups and users now do not have the ability to clone. What is the proper syntax for this to be effective on a single group?

J-Tricks

5/6/2015 02:04:44 am

It is the other way. Denied means denied for all. You will have to instead grant it only for the group of people who should have access.

Use group.1, group.2 etc to grant access to more than one group.

Cengiz

4/17/2020 12:08:05 pm

Although this thread is too old, I still use this page as a reference most of the time! Correct use is for clone: jira.permission.createclone.denied

Ref: https://jira.atlassian.com/browse/JRASERVER-62200

Flout

7/8/2015 08:16:37 pm

Hi,
I'm having a trouble setting special permission for JIRA and this article looks promising but still can't manage to do what I'm looking for. Could you take a look?

I have two projects: Project A and project B. I have also two user groups: Group for A and Group for B. Group A members have full access to Project A issues and same for group B.

But we have a need for Group A members to also view issues in project B that are in workflow status approved (not all issues). How can I do this?

I have set up Browse permission for Group A members in project B but now they can see all the issues..

I really appreciate the help.

J-Tricks

7/16/2015 03:53:53 am

This is slightly tricky. You cannot grant permissions by workflow properties, you can only restrict them.

In this case, you have to grant view permissions to "Group A" members as you did right now and then restrict the browse permission to "Group B" on workflow states prior to approval.

By doing that, Group B will not be able to see the tickets, even if they have brows permission on project level, until the tickets are approved.

Another option is to make use of security levels (issue security schemes). You can change the security level to public after an issue is approved. That seems to me as the best option.

Prash

7/15/2015 01:18:33 am

We are using JIRA On-Demand and we tried using the property conditions mentioned above but it did not work.
Scenario 1:
Reporter should be able to delete own attachments until the issue is approved. Once the issue is approved, the reporter should not have the access to delete own attachment.

Scenario 2:
Reporter should be able to edit the issue (description, issue type, etc, etc..) until the issue is approved. Once the issue is approved, the edit should not be visible or should be restricted.

Solutions tried:
jira.permission.<type>.denied=reporter

Let know if this can be achieved on JIRA On-Demand.

Thanks!!

J-Tricks

7/16/2015 03:50:20 am

Yes, the workflow properties work on onDemand. But you are not doing it correct. Do you want to restrict it just from the reporter or completely disable the edit and delete own attachments option.

Whatever is the case, you either deny it for everyone or change the permissions to a subset of roles/users. You can not deny it for one role (like reporter).

Hope that makes sense.

Prash

7/21/2015 12:06:30 am

Thanks for the info.

Rok

10/27/2015 08:57:51 am

Hey peeps,

I would really want to know if it's possible to restrict which groups can be selected in the custom group picker field with Workflow properties?

Cheers,

Rok

J-Tricks

10/28/2015 08:44:31 am

Unfortunately, that is not possible using workflow properties.

Yoga

12/31/2015 12:17:36 pm

Hi,
I would like to get all worklogs through API. But I am unable to get the worklogs entered under "Restricted To Developers". It seems some permission issue.

Ex:/rest/api/2/search?jql=key=OP-179&fields=worklog

Do you have a solution on this?

Thanks,
Yoga

J-Tricks

1/1/2016 11:42:07 am

Unfortunately, there isn't much you can do other than to give the required permissions. Permissions are there for a reason :)

Aron

3/23/2016 12:06:30 pm

I would like to disable removing issue links after the issue was closed while allowing to link issue in close transition.

I was able to figure out on how to disable removing issue links after an issue was closed and is in the closed status by using workflow properties jira.permission.link.group.1=some-group.

However this will restrict from linking an issue while transitioned to close status, seems the permission is applied to destination status not the source status.

Any workaround for this?

J-Tricks

4/2/2016 08:14:58 am

Are you putting the property on the transition? If so, can you try adding it on the Closed "step", not transition?

art link

9/26/2016 06:59:18 am

Hi!
Could you help, I need to restrict to delete link issue from view screen.
I added in the step Closed the properties: jira.permission.unlink.group.1=some-group. But it doesn't work :(

J-Tricks

9/26/2016 04:59:36 pm

Hi,

There is not separate pemission to unlink. Deleting a link is possible when the user has permission to link.

Ian B

4/1/2016 06:03:26 pm

Hi,

Excellent resource, but I am having trouble with a permission property that doesn't work as expected in a workflow step. I am using JIRA Cloud.

I have 2 groups with issue edit permissions. They also have schedule permission in the permission scheme.

In this step I want to give one of the groups complete edit permission but I want to restrict the second group to only be able to edit the due date (and possibly the asignee).

I have the following permissions setup for the workflow step in question:

jira.issue.editable true
jira.permission.1.editable.group administrators
jira.permission.2.scheduleissue.group Committee

So group 1 ends up with the edit ability I want, but group 2 doesn't seem to have the ability to edit the due date.

It does give edit permission if I replace scheduleissue with
jira.permission.2.editable.group Committee

but that is not really what I want.

Is there some kind of conflict with these permissions?

J-Tricks

4/2/2016 07:49:16 am

Yes. If you need to edit due date, you need both Edit and Schedule permissions. Just the Schedule permissions is not enough to make it editable on the screen.

The field itself requires only Schedule but Edit is a global permission used for every field.

Ian B

4/4/2016 12:10:53 pm

Thanks for the quick response!

Your answer suggests to me that you cannot restrict editing to just due date for a particular group using permissions. Am I correct?

J-Tricks

4/4/2016 09:32:20 pm

Yes, correct.

You might want to explore setting due date only using workflow actions. In that case, you can use workflow conditions to limit it.

Adolfo Casari link

4/1/2016 07:26:02 pm

Hi,

I have this scenario:

reporter has edit permission is project permission scheme. Some reporters can belong to group X. I would like to retrict those reporters belonging to group X to edit in a given state. Is this possible?

Also, I have group names with blanks, how should I enter these in workflow property?

Thanks!

J-Tricks

4/2/2016 07:52:30 am

Unfortunately, no. You will need a workflow condition which checks that user is in group. You can also make it an AND condition:

Reporter Only and User is in Group.

valeria cruz

4/12/2016 02:02:13 pm

HI!

I need only project lead can create a subtask in a determinare status

I used jira.permission.subtasks=lead
but is not work

Sebastian

4/20/2016 09:53:49 am

Hi, I am looking for an option to hide fields while beeing in a certain state of the worklow.

E.g. the Workflow looks like this

a->b->c->d

I want field X to be visible in workflow-step a, but not in b and c and visible in d again. I know you can choose different screens, but they are limited to create issue/view issue and edit issue, am I right?

J-Tricks

4/20/2016 09:39:10 pm

Unfortunately, field security cannot be achieved using workflow properties. It can only make use of the existing permissions.

Sebastian

4/21/2016 01:21:14 am

snap, thanks for your fast reply anyways!

sandra

5/10/2016 11:48:06 am

Hi, I am looking for an option to stop voting while beeing in a certain state of the worklow.

E.g. the Workflow looks like this

a->b->c->d

I want to be able voting on a and b state, but not when the issue is in c and d state. I know you can choose properties to do this, but they are running for us.
We are writting in the state c and d property: jira.permission.vote.denied.

But users can still voting

Do you have any suggestion?

Thanks

J-Tricks

5/10/2016 09:12:03 pm

Voting is not a separate permission. So, you can not use this technique to disable voting!

Adolfo Casari

7/7/2016 04:38:15 pm

What is the right setup to avoid a group or project role to create an issue type?

jira.permission.create.projectrole=XXXXX

where is this added? To the first status after Create or in the Create transition?

J-Tricks

7/7/2016 09:59:27 pm

I haven't tried it recently but this doesn't work on Create. You can only setup the project permissions appropriately to prevent Create.

Tom Lister

9/14/2016 06:46:10 am

Hi
I want to control edit permissions based on a group picker but can't find a syntax that works. I can set it for hard coded groups or userCF.
tried
jira.permission.edit.userCF=customfield_10404
jira.permission.edit.group.2=customfield_10404
where 10404 is a group picker

is this possible?

J-Tricks

9/15/2016 10:18:50 pm

Group custom field is not supported. For type, the values can be group, user, assignee, reporter, lead, userCF, projectrole. groupCF is not an option.

Sue

12/2/2016 01:45:11 pm

I'm a bit new to all of this!

I'm trying to restrict adding / deleting attachments once work has started on a task.
jira.permission.attach.denied works but for obv everyone. I only want it restricted to a group of users or even reporter, but don't think I can get the syntax quite right.

jira.permission.attachdeleteown.denied
jira.permission.attach.reporter.denied
jira.permission.attachdeleteown.reporter.denied

don't work - am I getting the syntax correct? I have a project role but not sure what the syntax is to remove for a project role.

Any advice appreciated.

J-Tricks

12/5/2016 02:34:46 pm

When denied, it is denied for all. The only other option is to grant it to a subset of users so that it is denied for every one else.

Instead of denying to a group, you will have to grant it to anyone but that group!

Eric Sebian

4/26/2017 12:15:30 pm

Can you tell me the best way to restrict the creation of a subtask after a certain status? thanks.

Venkata Sarath Pulipati

10/16/2017 05:16:32 pm

Is it possible to disable editing on certain fields (like Acceptance Criteria) if the ticket is in a certain status (like don’t allow editing of AC if Status is “In development”)?

J-Tricks

10/16/2017 09:55:42 pm

Using this mechanism? No. Field level security is not possible in JIRA without plugins. The best you can do will be to restrict editing of that field to selected workflow transitions. You will have to remove the field from the "Edit" screen but you can use workflow conditions and validators to restrict users based on the transition.

Yogesh

1/3/2018 09:00:00 am

We have a status called Approved and once the ticket is in this status only the Approver project role should allow to edit the ticket.

can we achieve this using workflow property.

J-Tricks

1/3/2018 08:51:47 pm

You should be able to do it with the help of workflow properties. Edit the workflow and add the following property on the workflow "step".

jira.permission.edit.projectrole=1xxxx

where 1xxxx is the project role id.

Tushar

1/31/2018 02:56:14 am

Hi Team,

What will be the property to block the reporter to perform the approval in customer portal of Jira Service Desk.

I used property like "approval.user.reporter"=denied". But some times it works and sometimes its not working.

Please suggest us correct property to block reporter to see approval button.

Maggie

2/2/2018 03:24:32 am

Is there a way to lock the edit according to Componets != "XXX"? Maybe like: jira.permission.edit.component != "XXX". I don't find the right settings in "Add New Property". Is this possible? Thanks!

Maggie

2/2/2018 03:51:13 am

Used jira.permission.edit.component.XXX = denied, it won't work. Dose this support disable edit the issue when Components has one specific valune like XXX?

J-Tricks

2/3/2018 10:55:53 am

Unfortunately, no. JIRA doesn't support permissions based on field values.

Maybe you can try some workaround by hiding the Edit button when the component has a specific value but it will still allow you if people do it via other means. For example, from the agile board or using an API.

Another option might be to restrict 'Edit' as a whole but then provide 2 workflow actions, based on component values, to move the issue to different status where you can use screens similar to 'Edit' screen. Not the best option but a practical one!

Maggie

2/5/2018 01:12:26 am

I will try. Thanks Team for your prompt reply!

Lisa

2/16/2018 04:50:12 am

Hi,

I have a 4 step workflow. First step is Open. I want to restrict the reporter from editing all except open.

I have given reporter permissions in permission scheme. Do I use this on the open status (property key = jira.permission.edit.reporter Property Value = reporter) OR do I apply on all others? It doesn't seem to work.

Am I just using the wrong syntax above?

Thanks in advance.

J-Tricks

2/17/2018 04:31:57 pm

This is something you can't achieve using the step properties. Restrictions has to be done at all steps other than Open but you are trying to open it to everyone except reporter. Unfortunately, that is not an option. You can only set who is allowed on that step, not who is restricted. By setting the property value as reporter, you are telling JIRA that only reporter can edit it.

You can probably do this with the help of a plugin by adding or removing the reporter from a group/role when the issue is statuses other than Open and then set the workflow property to that group/role.

Marcin link

2/19/2018 06:36:51 am

Hello,
I'm trying to deactivate comments for closed issues. I tried this solutions:

Property Key Property Value
jira.permission.comment.denied ''
jira.permission.comment.denied=jira-users ''
jira.permission.comment=jira-users denied

It does not work. What am I doing wrong?

J-Tricks

3/1/2018 07:14:37 pm

Can you try:

jira.permission.comment.denied = denied

Seems the syntax changed in the latest versions.

Marcin link

3/5/2018 08:17:56 am

I tried many combinations but it still does not work...
Here you can see what I'm doing:
https://cloud.vector.net/index.php/s/d8spNzCgGyr4nAX

Kenneth

3/1/2018 05:19:59 am

I cant seem to get this to work.

I´ve used properties in transitions before, and they work flawlessly.

Now i´m trying to add the jira.permission.work.denied to the Closed status (i dont want to have people registering time spent on closed issues) but jira ignores this property, can you tell me what i am doing wrong?

J-Tricks

3/1/2018 07:15:56 pm

Can you try:

jira.permission.work.denied = denied

Seems the syntax changed in the latest versions.

Adolfo Casari

3/2/2018 06:35:35 am

Are you using JIRA SERVER or CLOUD? There is an issue with CLOUD, workflows properties are not working (https://jira.atlassian.com/browse/JRACLOUD-67800)

Tushar

3/2/2018 01:03:33 am

Hello J Tricks,

Do you have any comment for my earlier question.
I am interested to know, how to restrict reporter to view the Jira Service Desk Approval buttons in customer portal if the reporter and approver is same user.
Thanks.

J-Tricks

3/6/2018 10:06:12 pm

This has nothing to do with permissions. What you will need is a workflow condition that checks if the current user (who is seeing the approve button, aka approver) is also the reporter or not. The button should be visible only if the current user is not the reporter.

Unfortunately, it is not available by default in JIRA. You might have to leverage a plugin for this.

Matthew Page

3/6/2018 11:52:18 am

Can you update the permissions list above to include "transition"? Seems to work well.

J-Tricks

3/6/2018 10:00:28 pm

That's good to know. Will update that. Thanks!

Marcel Plomp

3/28/2018 07:04:56 am

Type can be "userCF" which stands for....?

J-Tricks

3/28/2018 12:27:43 pm

User Custom Field.

Marcel Plomp

3/29/2018 01:24:05 am

Ah..... Did not know that. THX

Matthew Page

3/28/2018 01:50:49 pm

Also note I've discovered that some of the properties work when affecting normal operation but break when you do bulk actions. It seems the bulk edit also steps through the workflow properties but has a different required schema for the property. For example this works to prevent changing the dates in a particular stat :
jira.permission.scheduleissue denied
but then try to do bulk edits involving those issues and it says its a syntax error :
java.lang.RuntimeException: Error parsing meta attribute <meta name='jira.permission.scheduleissue'>denied</meta>. Name format is 'jira.permission.[subtasks].<permission>.[group|user|assignee|...]'

this means instead I went :
jira.permission.scheduleissue.group.1 no_group_exists_here

(and the "no_group_exists_here" is just random word of a group that doesnt exist)

Elif Alverson

4/25/2018 10:53:20 am

Hello,

I am trying to give " edit ( assign Jira Issues, change the status of Jira issues) " permissions to the IT team for a specific issue type for a project. The permissions scheme allows only the Jira Admins to edit all issue types related to this project.

I modified the transition properties as " Property Key = jira.permission.edit.group , Property Value = IT " for all the available status changes available in the workflow of this specific issue type.
However IT team is not able to make any changes on these issue types? Why? What am I doing wrong?

If I change the Permission Scheme and add IT for " edit " permissions, then they will be able to edit all the issue types related to this project.

Any suggestions????

Thank you.

Elfi

4/27/2018 07:25:38 am

Hello,

It is not possible to grant additional permissions using workflow properties. You can only restrict already existing permissions.

James

9/11/2018 07:44:40 pm

I am running JIRA 7.11. I have the following workflow: Open-->Incomplete-->In Peer Review-->In QA Review-->Closed.

Only QA and admins have permission to close. This hasn't stopped a normal user from being able to close problems for some reason...

I am trying to do the following:
- Prevent everyone from editing the issue after it is passed the Incomplete stage.
- Allow anyone but the reported be assigned the task for the Peer Review stage.
- Allow only QA to be assigned the task for the QA Review stage.

I have tried the following properties (and variations of them), and they most either break the functionality or don't do anything:
jira.issue.editable false
jira.permission.edit.reporter false
jira.permission.resolve.reporter false
jira.permission.assign.lead true
jira.permission.assignable.group QA

The only option I have been able to get work partially is the editable flag. What am I doing incorrectly? Is the list no longer applicable to this version of JIRA?

J-Tricks

9/14/2018 12:37:31 pm

Maybe you can try this:

- Prevent everyone from editing the issue after it is passed the Incomplete stage.

This can be easily achieved using "jira.issue.editable=false" by applying this property on the workflow steps.

- Allow anyone but the reported be assigned the task for the Peer Review stage.

Can you try this on the workflow steps? jira.permission.assignable=reporter

- Allow only QA to be assigned the task for the QA Review stage.

Can you try this on the workflow steps? jira.permission.assignable.projectrole=NumericIdOfQARole

Swati Gupta

9/25/2018 02:32:15 pm

Hi Team,

I have a query regarding JIRA. I am using jira.permission.edit.projectrole = 10050 (which worked) property to allow Change Manger to edit an issue when it is closed, but I want to assign Change Builder and Release Manager the same functionality and I used jira.permission.edit.projectrole1 which does not worked. Kindly help me asap. Its very urgent

J-Tricks

10/15/2018 05:57:15 pm

Can you try,

jira.permission.edit.projectrole.1=10050
jira.permission.edit.projectrole.2=xxxxx

And so on?

Tobi Oluwole link

10/15/2018 07:21:38 am

Hello,

I am trying to modify the assignee for escalations to a single user.
I have tried different approaches with no success.
The property key and values I have tried are:

jira.permission.assignable.group
jira.permission.assignable.group=site-admin

jira.permission.assignable.projectrole
jira.permission.assignable.projectrole=Escalations

jira.permission.assignable.user
jira.permission.assignable.user=tobxxxxxxx.com

jira.permission.assignable.assignee
jira.permission.assignable.assignee=tobxxxxxxx.com

Please help point me in the right direction

J-Tricks

10/15/2018 05:55:30 pm

Are you trying to set the assignee to a specific user after the workflow transition? If so, it should be done in the post function.

Or are you trying to restrict the workflow transition to a user? In that case, you can use:

jira.permission.assignable.user=username

Anthony

11/14/2018 10:58:31 am

I'm trying to restrict comments to the Service Desk Team only, but I'm struggling. Can anyone help?

Hugo Feltrin da Silva link

1/15/2019 08:15:12 am

Thanks guys, very usefull!

Romain

1/25/2019 07:55:47 am

Hello J,
Very useful. I would like to restrict the work permission on a status to the Assignee only and forbid it for anybody else.

I tried
jira.permission.work =assignee
jira.permission.work.assignee = true

But it doesn't work. Because here I am allowing some people and I would like to deny to everyone except assignee.
Thank you for your help

Romain

J-Tricks

1/25/2019 04:21:33 pm

jira.permission.work=assignee should work. Couple of things to check:

1. Is it added under the workflow step?
2. Is the updated workflow published?

Romain

1/28/2019 06:19:33 am

Thank you for your quick answer. Workflow is correctly published. I put "jira.permission.work" as the property and "assignee" as the value. It is added to the status and not to the transition.
But even when I assign the issue to me, now chance to log work. When I remove that property, Log work option is back.
I tried jira.permission.work.denied on another status and this is working correctly: no one can log time.
If you have any idea, let me know. Thank you

Lynn Mindak

3/18/2019 06:16:34 pm

Hello! I cannot get this to work. I'm sure it's something silly on my part. I'm trying to deny the developer role to be able to DELETE an issue type.
Key is jira.permission.(type).(projectrole).
jira.permission.denied.projectrole.1=10300

J-Tricks

3/18/2019 09:50:11 pm

Hi Lynn,

I would try "jira.permission.projectrole.denied=10300" but there are comments that states that this doesn't work in the later versions of JIRA. Still worth a try though.

If that doesn't work, try allowing the delete only to another role, say administrators. i.e. try restricting to another role instead of preventing developers.

AdrianoSC

7/16/2019 03:51:48 pm

I'm trying to use "jira.permission.assignable.projectrole=10300" and it's a bit weird.

On a particular project, only two users have the assignable projectrole in question and I have several users beeing able to be assigned the issue in status they aren't supposed to... and at the same time there are other users that this is working as intended(unable to be set as assignees).

Do you have any ideas what could be the cause?

Jonathan Kvanvig link

11/26/2021 05:27:11 am

Thanks for sharing valuable info with us!

Your comment will be posted after it is approved.

Permissions based on Workflow Status

Leave a Reply.

Author

Categories

Archives