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:
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!
Reply
Eli Durayski
9/19/2016 11:03:53 am
Very nice indeed Sir!
Reply
arch
1/16/2017 01:08:46 am
no success. I tried jira.permission.close.projectrole.1 on closed step.
J-Tricks
2/28/2011 06:22:23 pm
It is indeed :) Glad it helped!
Reply
Erik
3/7/2011 05:32:09 am
What would be the proper use of Lead?
Reply
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?
Reply
J-Tricks
3/7/2011 06:45:05 am
Erik,
Reply
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.
Reply
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.
Reply
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!
Reply
Holger
5/24/2011 07:39:04 pm
What would be the proper use of reporter?
Reply
J-Tricks
5/25/2011 03:51:42 am
Holger,
Reply
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?
Reply
J-Tricks
6/8/2011 09:14:41 pm
Suki,
Reply
Mirko
7/20/2011 05:30:13 am
Nice trick!
Reply
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).
Reply
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.
Reply
J-Tricks
7/20/2011 10:31:32 pm
Hello Mirko,
Reply
Mirko
7/21/2011 12:02:03 am
Thanks for you answer, but I had added on the step :/
Reply
Mirko
7/21/2011 12:07:49 am
I've also tried a combination with
Reply
MIrko
7/21/2011 12:41:21 am
I have a workaround:
Reply
J-Tricks
7/21/2011 01:46:17 am
Mirko,
Reply
Yuri
8/17/2011 07:09:12 am
I"m trying to add:
Reply
J-Tricks
8/17/2011 07:23:28 am
@Yuri Yes, left is the key and right is the value.
Reply
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.
Reply
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.
Reply
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.
Reply
Yuri
8/25/2011 11:07:19 am
Never mind on last question. It works!
Reply
jair
10/5/2012 11:57:16 pm
How you solve your problem?
Reply
Sabi
3/23/2018 09:59:25 am
@Yuri, how did you solve the problem? It is not working for me neither.
Reply
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
Reply
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!
Reply
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.
Reply
J.H.
11/15/2011 02:18:00 am
Please note that permissions of the form
Reply
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
Reply
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.
Reply
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.
Reply
J-Tricks
11/21/2011 01:22:32 pm
@Joe Interesting! I haven't tried this one but I thought that would work.
Reply
Joe P
11/22/2011 12:01:30 am
I'm on 4.1.2. Could that be the problem?
Reply
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!!
Reply
J-Tricks
12/22/2011 03:17:43 am
Frankly, I am not sure. I would definitely try it out!
Reply
Helen
1/15/2012 08:59:24 am
Hi!
Reply
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.
Reply
Fabian
7/2/2012 09:06:05 pm
This does not work because of the outstanding work for:
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.
Reply
J-Tricks
1/17/2012 02:31:54 pm
Thanks Adam. Yes, easy thing to gloss over. I had done that first myself!
Reply
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!
Reply
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.
Reply
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:
Reply
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?
Reply
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.
Reply
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.
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 ;)
Reply
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:
Reply
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!
Victor
2/12/2012 11:27:00 pm
Hi!
Reply
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?
Reply
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
Reply
Victor
2/13/2012 03:27:42 am
Thanks a lot! Exactly what I needed
Reply
3/10/2012 06:10:11 pm
Hi,
Reply
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.
Reply
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,
Reply
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 ;)
Reply
dsilve
4/16/2012 01:04:35 am
Hello,
Reply
J-Tricks
4/17/2012 03:46:51 am
jira.permission.edit.user=ds
Reply
dsilve
4/18/2012 04:10:13 am
Hi again,
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!
Reply
dsilve
4/18/2012 08:12:31 pm
ds is the username of the user. I also tried using the full name.
Reply
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.
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.
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.
J-Tricks
8/15/2012 03:54:22 am
That should work. jira.permission.edit.group=admin-group should do the trick!
Bryan
4/23/2012 08:06:54 am
Hi,
Reply
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!
Reply
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?
Reply
J-Tricks
5/16/2012 10:48:19 am
Kalynn,
Reply
Kalynn
5/21/2012 02:52:42 pm
Thanks for the clarification. Appreciate it!
Do you know how to get a group's ID to reference for a permission?
Reply
J-Tricks
5/21/2012 03:50:43 pm
You don't need id for group. You should be using the group name.
Reply
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?
Reply
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.
Reply
Hi,
Reply
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.
Reply
Chris
6/26/2012 12:04:49 pm
Thanks...
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!
Reply
J-Tricks
7/9/2012 09:29:22 am
I don't think it is possible. You can add it only on steps.
Reply
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.
Reply
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).
Reply
J-Tricks
7/20/2012 12:27:59 pm
Casey,
Reply
Vadim
8/29/2012 10:06:49 pm
Hi J!
Reply
J-Tricks
8/30/2012 10:38:05 am
Yes, it should work!
Reply
hope
9/10/2012 08:25:52 pm
when i try the jira.permission.comment=denied it doesn't work any ideas?
Reply
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.
Reply
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
Reply
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?
Reply
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.
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.
I would like to block creation of sub-tasks in a state.
Reply
Fabian
10/30/2012 03:41:18 am
You cannot because it is broken, please see Helen's comment (and my response):
Reply
J-Tricks
10/30/2012 04:17:39 am
Subtasks doesn't have a separate create operation and that won't work I guess.
Reply
Sergey
12/11/2012 02:10:18 am
What is the syntax of customfield "userCF" with spaces like "custom users"
Reply
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?
Reply
G-Lap
8/28/2013 04:56:37 am
the customfield_12345 works. It allows only the user contained in the custom field 10704.
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.
Reply
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.
Reply
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?
Reply
J-Tricks
12/18/2012 12:28:38 pm
You cannot do the first - there is not issue when the user clicks on create.
Reply
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
Reply
J-Tricks
5/13/2013 06:41:28 am
Hi,
Reply
derek
5/15/2013 05:34:11 pm
@J-Tricks
Reply
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.
Reply
Hi, all
Reply
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.
Reply
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.
Reply
Marcus
12/23/2013 11:54:15 pm
Hey guys,
Reply
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
Reply
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?
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! 2/24/2014 02:40:47 am
Hello,
Reply
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.
Reply
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.
Reply
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 :)
Reply
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
Reply
Gaby
8/24/2014 11:26:39 pm
Properties could be used also for transitions? In the same way?
Reply
J-Tricks
9/2/2014 06:29:52 am
No. These only work on steps, not transitions.
Reply
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.
Reply
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.
Reply
Areg
9/7/2014 06:12:58 am
Hi
Radim
10/17/2014 12:14:25 am
Hi all,
Reply
J-Tricks
10/20/2014 02:28:15 am
Radim,
Reply
JIRA 4.4.3
Reply
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.
Reply
prasad
10/28/2014 06:10:35 pm
Hi,
Reply
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?
Reply
prasad
10/30/2014 06:53:07 pm
something like follows
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,
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,
Reply
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.
Reply
manap
12/9/2014 01:36:11 pm
Hi,
Reply
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.
Reply
manap
12/10/2014 11:49:18 am
Thanks for your reply.
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.
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?
Reply
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.
Reply
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?
Reply
Eric Sebian
2/27/2015 01:34:58 am
Any word on this? Can you please elaborate?
Reply
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!.
Reply
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.
Reply
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.
Reply
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?
Reply
Catalyn
2/26/2015 09:09:36 pm
Hello,
Reply
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).
Reply
Hi J-Tricks,
Reply
Georges
3/29/2015 09:04:04 pm
Can you please add the priority to the list of permissions.
Reply
J-Tricks
3/30/2015 01:04:59 am
What do you mean by Priority?
Reply
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,
Reply
J-Tricks
4/29/2015 09:38:44 am
No, it is not. Create transitions doesn't support workflow conditions or properties like this.
Reply
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?
Reply
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.
Reply
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
Reply
Flout
7/8/2015 08:16:37 pm
Hi,
Reply
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.
Reply
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.
Reply
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.
Reply
Prash
7/21/2015 12:06:30 am
Thanks for the info.
Rok
10/27/2015 08:57:51 am
Hey peeps,
Reply
J-Tricks
10/28/2015 08:44:31 am
Unfortunately, that is not possible using workflow properties.
Reply
Yoga
12/31/2015 12:17:36 pm
Hi,
Reply
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 :)
Reply
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.
Reply
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?
Reply
J-Tricks
9/26/2016 04:59:36 pm
Hi,
Ian B
4/1/2016 06:03:26 pm
Hi,
Reply
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.
Reply
Ian B
4/4/2016 12:10:53 pm
Thanks for the quick response!
J-Tricks
4/4/2016 09:32:20 pm
Yes, correct. 4/1/2016 07:26:02 pm
Hi,
Reply
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:
Reply
valeria cruz
4/12/2016 02:02:13 pm
HI!
Reply
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.
Reply
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.
Reply
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.
Reply
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!
Reply
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?
Reply
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.
Reply
Tom Lister
9/14/2016 06:46:10 am
Hi
Reply
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.
Reply
Sue
12/2/2016 01:45:11 pm
I'm a bit new to all of this!
Reply
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.
Reply
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.
Reply
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”)?
Reply
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.
Reply
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.
Reply
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".
Reply
Tushar
1/31/2018 02:56:14 am
Hi Team,
Reply
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!
Reply
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?
Reply
J-Tricks
2/3/2018 10:55:53 am
Unfortunately, no. JIRA doesn't support permissions based on field values.
Reply
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,
Reply
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.
Reply
Hello,
Reply
J-Tricks
3/1/2018 07:14:37 pm
Can you try:
Reply
Kenneth
3/1/2018 05:19:59 am
I cant seem to get this to work.
Reply
J-Tricks
3/1/2018 07:15:56 pm
Can you try:
Reply
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)
Reply
Tushar
3/2/2018 01:03:33 am
Hello J Tricks,
Reply
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.
Reply
Matthew Page
3/6/2018 11:52:18 am
Can you update the permissions list above to include "transition"? Seems to work well.
Reply
J-Tricks
3/6/2018 10:00:28 pm
That's good to know. Will update that. Thanks!
Reply
Marcel Plomp
3/28/2018 07:04:56 am
Type can be "userCF" which stands for....?
Reply
J-Tricks
3/28/2018 12:27:43 pm
User Custom Field.
Reply
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 :
Reply
Elif Alverson
4/25/2018 10:53:20 am
Hello,
Reply
Elfi
4/27/2018 07:25:38 am
Hello,
Reply
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.
Reply
J-Tricks
9/14/2018 12:37:31 pm
Maybe you can try this:
Reply
Swati Gupta
9/25/2018 02:32:15 pm
Hi Team,
Reply
J-Tricks
10/15/2018 05:57:15 pm
Can you try,
Reply
10/15/2018 07:21:38 am
Hello,
Reply
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.
Reply
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?
Reply
Romain
1/25/2019 07:55:47 am
Hello J,
Reply
J-Tricks
1/25/2019 04:21:33 pm
jira.permission.work=assignee should work. Couple of things to check:
Reply
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.
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.
Reply
J-Tricks
3/18/2019 09:50:11 pm
Hi Lynn,
Reply
AdrianoSC
7/16/2019 03:51:48 pm
I'm trying to use "jira.permission.assignable.projectrole=10300" and it's a bit weird.
Reply
Your comment will be posted after it is approved.
Leave a Reply. |
AuthorJobin Kuruvilla - Works in Adaptavist as Head of DevOps Professional Services. Categories
All
Archives
October 2016
|