Hello,
We have been using the condition.is_issue_editable context parameter to check if the issue is editable.
However, we have found that if you restrict editing by using the jira.permission.edit.projectrole workflow status property, condition.is_issue_editable still returns true when the issue isn’t editable to the current user.
We ended up testing condition.has_issue_permission(permission=EDIT_ISSUES), which correctly returns false in this use case.
What’s the difference between these two conditions?
Which one is more correct to check if an issue is editable?
Is there any situation where the results are reversed? I.e. condition.is_issue_editable returns false but condition.has_issue_permission(permission=EDIT_ISSUES) returns true.
3 Likes
@PatriciaPereira – Did you ever find an answer to this question?
@ibuchanan – What’s the recommended procedure for getting a question like this escalated to the right person inside Atlassian? This is an important question to help resolve a customer-facing bug in a Marketplace app.
I apologize if it was inappropriate to tag you, but I’ve seen you helpfully connect community members to the right places so many times before. 
Hello @AaronMorris1 and @PatriciaPereira
Was the user in question the Assignee for the Issue?
If Issue-level Security has been enabled and a group of users, who are not in any project roles with edit issue permission, has been given global issue view rights in the project, those users have permission to view all the issues, but to only edit those assigned to them.
@AaronMorris1,
You can report bugs to developer support. I advise posting to them whatever context you have. The original post is simply too open and context free to be able to answer. I don’t know what the difference is, or why they both exist.
1 Like
Hi @ibuchanan – Thank you for the direction! Much appreciated.
Hi @sunnyape – Thank you for stepping in. Unfortunately, I don’t think that is the source of the issue. Here’s some more context:
Question: What is the recommended strategy for programmatically determining the current (human) user’s edit permissions on the current Jira Cloud issue. Specifically when permissions are governed by workflow properties rather than a Jira permission scheme. Is it condition.is_issue_editable, condition.has_issue_permission(permission=EDIT_ISSUES), or something else?
General context: A user might be prevented from editing an issue based on the Jira Workflow Properties of the current issue status. In this case, a third-party app will need the ability to verify whether the current user can make edits to the Jira issue before allowing that user to modify the app’s data associated with that Jira issue. (Fictitious example: If a user is not allowed to modify a story in the Done status (based on workflow properties), then a checklist app should also be able to prevent the issue’s checklist from being modified by that user.)
My Specific Context: In regulated industries, it is common practice to determine issue editability in part based on the current Status value. For example, an issue is created in an open state, it gets worked on, and then it is locked and routed for signatures. (It’s fairly common practice to prevent editing a record after it has been signed.)
However, in Jira, it is often beneficial to allow Jira Automation, third-party apps, or system admins to make controlled updates to a locked record, even while editing by regular users is disallowed. (Even the act of writing the electronic signatures is an example where programmatic writing is desired while general editing is prohibited.) This configuration can be achieved through Jira Workflow properties that explicitly allow editing based on project role, user groups, etc.
So, back to the question, what is the best way for a third-party app to determine whether the current user can edit a Jira record (in the current status), regardless if the app itself has edit access?
(I apologize if made things less clear instead of more clear. 
)
@AaronMorris1,
Your expansion for @sunnyape gave me some good context:
Specifically when permissions are governed by workflow properties rather than a Jira permission scheme. Is it condition.is_issue_editable , condition.has_issue_permission(permission=EDIT_ISSUES) , or something else?
I think the short answer is, Jira can’t/doesn’t know what is the potential outcome of workflow transitions.
The longer answer is that Jira delegates workflow transitions to arbitrary functions that are only executed on an actual transition, which could have arbitrary cases like “only allow transitions at 11:11.” Twice a day, you can edit that issue if you hit the clock just right, all other times, it appears not editable. I’m sure such a non-deterministic answer is not appreciated in regulated industry!
If I were building an app or Jira configuration for that context, I would not trust workflow properties based “locks”. Here’s how I would categorize “editability” for Jira (say, as a calculated field or similar “signal” on issues):
- User does not have the permission: NOT EDITABLE
- User has the permission, and there are workflow postfunctions: INDETERMINATE
- User has the permission, and no workflow postfunctions: EDITABLE
In other words, don’t use workflow functions if you need to know editability for a fact.
1 Like
Hi @ibuchanan – Thank you for the follow-up. Another clarification: I’m referring to workflow status properties rather than workflow transition properties. (For example: jira.permission.edit.projectrole) Sorry, I didn’t specify that.
Given that clarification, it is my understanding that workflow status properties are the only option for controlling editability of a Jira issue based on status. Is that incorrect? Is there another strategy that Jira supports? (Specifically Jira Cloud)
Thank you again!
@AaronMorris1,
I did misunderstand the details of your clarification. I don’t know the answer to your question.
Maybe the solution is a new assertion: Make it explicit that you expect apps to work with the jira.issue.editable as their status-locking mechanism. I think it is the best answer; I just can’t assure that it’s the only one.
1 Like
And now we’ve come full circle back to the OP’s question, but hopefully with greater clarity.
The jira.issue.editable property works easily with the API. However, it locks the issue to everyone without the ability to create exceptions for Jira Automation, signature apps, system admins, etc. It’s only when using the conditional workflow status properties that the different values are returned by the different API properties.
But I do sincerely appreciate your guidance. Thank you!
@AaronMorris1 Thanks for the detailed response, I get what you mean now.
This is a really interesting topic! I often am involved in doing user permission audits and have never even remotely considered that I needed to take into account what impact an automation workflow / external app might have on their permissions for a set of issues at a given time or circumstance.
If you do ever manage to log a feature request for this information to be available through issue properties, please post the information back here.