jira.permission.edit vs jira.issue.editable properties

Alexey Studitsky January 18, 2018

What is difference between jira.permission.edit and jira.issue.editable workflow properties?

Are there any difference for jira issue where set one or another of these properties?

4 answers

5 votes
Earl McCutcheon
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 18, 2020

Hello All,

There have been a few newer questions come up recently asking for some clarification on this thread, and I wanted to make sure the information gets passed along incase anyone else runs into this with a similar question.

Particularly on the initial Question:

What is difference between jira.permission.edit and jira.issue.editable workflow properties?

The difference between the two properties is that one is a permission level property applied to the specified permission in the property, generally reserved for workflow opperations, and the other is a issue level property specified in the entity property which can be used in conjunction with Connect apps but also cross over to applicable actions in the workflows and do have some overlap as a result per the defined action if the defined entity property is permission based property.  They act as follows:

The workflow property jira.permission.<permission name here>.action can be used on alternate permission types and will provide additional restrictions on the specific Permission noted by the peoperty exe jira.permission.edit.denied  will block the edit permission where jira.permission.comment.denied would block the comment permission.

however the jira.issue.editable is doing a similar action restricting a issue level entity property being linked to a permission locking the edit permissions, And this one will be either a ON or OFF option, so it is in this case fully interchangeable if the only desired action is removing edit permissions to the issue.  

On the contrary though jira.permission.<extra.options....> there are a lot more configuration options possible like restricting to a specific group or splitting permissions between multiple groups or roles at a more granular level per status, and there is a really good article on the j-tricks website that offers up some varying use cases that I highly recomend looking over for a more detailed breakdown:

Hope this information helps out.

Regards,
Earl

Sergio Montávez April 6, 2021

Hi! Thanks for the info, but that link to permissions based on workflow status is not 100% accurate. I haven't been able to restrict the issue type creation based on a group by using:

jira.permission.create.group.groupA=A

Not working.

Can you provide more info around that? I'm avoiding creating a ticket since your message seems to be oriented to avoid more tickets around permissions.

 

Thank you!

Like # people like this
3 votes
Thomas Schlegel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 18, 2018

Hi Alexey,

jira.issue.editable= true/false means, that the issue is editable

jira.permission.edit.group= <any jira group> means, that only users belonging to this group are able to edit the issue

Alexey Studitsky January 19, 2018

Hi Thomas, thank you for your reply.

I need to restrict jira issue edit mode and I tried the following values:

1) Property: jira.permission.edit.denied

    Key: denied

2) Property: jira.issue.editable

    Key: false

So as I can see in 1st variant there is available "Attach files" option. In 2nd variant "Attach files" option is unavailable.

Are there any other differences in these cases?

Like Kalos Bonasia likes this
Thomas Schlegel
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 19, 2018

I would always use "jira.issue.editable" if you want to prohibit editing issues completely in a certain workflow state. Before you mentioned it, I didn't even knew the property "jira.permission.edit.denied".  So, no, I don't know the differences between them. 

If you want to restrict editing to a group. e.g. administrators, I would use "jira.permission.edit.group".

Like Jörg Keller likes this
Yousaf May 2, 2018

Hello Thomas,

 

I am also trying to set my workflow with jira.permission...

 

Only a certain group should have permission to edit a workflow from a specific status onwards. Before that status everyone can work on the issue.

 

I tried all of your suggestions but none has worked for me.

 

Any idea what could be the problem? 

 

Thanks and best regards

0 votes
zhaxi meng November 12, 2019

your answer helped me ~~

 

tks very much

0 votes
Joe Pitt
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
May 2, 2018

You keep saying 'edit a workflow'. Do you really mean edit an issue AFTER a point in the workflow?

Yousaf May 7, 2018

Hello @Joe Pitt,

yes exactly.

 

Check this Workflow for example. It should give the permission only to Controlling Group from the transition "To Controlling"Workflow.png

Ashlee Toney November 28, 2018

You may want to try using conditions as well. That limits who can transition the issue (controller group), etc.

Christian Humer May 17, 2023

Hello 

I still have the issue if I set the property 

jira.permission.comment.denied --> EMPTY

jira.permission.comment.user --> false

 

that the users can edit or delete existing comments.

Is there a property existing where I can block this one as well?
Screenshot 2023-05-17 165159.png

Here are all properties I set


Screenshot 2023-05-17 165340.png

Suggest an answer

Log in or Sign up to answer