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

[Alexey Studitsky]

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?

[Earl McCutcheon]

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:

• https://www.j-tricks.com/tutorials/permissions-based-on-workflow-status

Hope this information helps out.

Regards,
Earl

[Sergio Montávez]

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!

[Thomas Schlegel]

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]

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?

[Thomas Schlegel]

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

[Yousaf]

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

[zhaxi meng]

your answer helped me ~~

tks very much

[Joe Pitt]

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

[Yousaf]

Hello @Joe Pitt,

yes exactly.

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

[Ashlee Toney]

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

[Christian Humer]

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?


Here are all properties I set