Issue Summary

When using the workflow properties commenteditall and commenteditown in combination with group denied do not deny a member of that group if the user has Admin permissions, noting other workflow properties do adhere to the denied argument

HOW THIS SHOULD WORK:

A workflow property takes the following format.

jira.permission[.subtasks].SYSTEM_PROPERTY_PERMISSION.GRANT_TYPE[.suffix]

 .SUBTASKS and .SUFFIX are optional.

SYSTEM_PROPERTY_PERMISSION values can be found in $jira-install/atlassian-jira/WEB-INF/classes/system-project-permissions.xml. Those values correlate with short keys, returned by the systemProjectPermissionKeyByShortName method.

The possible short name values for a SYSTEM_PROPERTY_PERMISSION are:

assign, assignable, attach, attachdeleteall, attachdeleteown, browse, close, comment, commentdeleteall, commentdeleteown, commenteditall, commenteditown, create, delete, edit, link, managewatcherlist, modifyreporter, move, project, resolve, scheduleissue, setsecurity, transition, viewversioncontrol, viewvotersandwatchers, viewworkflowreadonly, work, worklogdeleteall, worklogdeleteown, worklogeditall, worklogeditown

GRANT_TYPE is a permission holder, and the list of permission holder types can be found here. It's worth noting that denied and reporter are seperate grant types; and denied cannot be applied to the reporter.

You can use denied as a value when a type isn't already set. So, for example, these are valid:

# Prevent ANYONE from deleting their own comments:
jira.permission.commentdeleteown.denied

# Allow the reporter to delete their own comments at this step:
jira.permission.commentdeleteown.reporter

These are invalid:

jira.permission.commentdeleteown.reporter.denied
jira.permission.commentdeleteown.reporter = denied

The goal of the suffix is to ensure that each key is unique - so multiple properties can be present. For example, if you wanted a group with an ID of 10000, and a Group of ID of 20000 (NOTING you can use the group name in place of ID) to be able to delete their own comments, you'd use:

jira.permission.commentdeleteown.group.1 = 10000
jira.permission.commentdeleteown.group.2 = 20000

Those keys would make sure that only members of the two groups could delete their own attachments at the specified step.

Additionally, if you wanted to deny access to any member of a Group with ID of 20000 to be able to delete their own comments or add new comments the following are valid and will function as intended blocking the users ability to access this permission when the user is also a member of a second group that also has these permissions:

jira.permission.commentdeleteown.denied.group.1 = 20000 
jira.permission.commentdeleteall.denied.group.1 = 20000
jira.permission.comment.denied.group.1 = 20000

What fails:

If you add the same structure to commenteditall and commenteditown the rule will be bypassed by users with additional permissions For Example this will fail if a user is a member of 2 groups with this permission:

jira.permission.commenteditall.denied.group.1 = 20000 
jira.permission.commenteditown.denied.group.1 = 20000

Steps to Reproduce

1. As a user that is a member of two groups in this example the user is a member of the 2 following groups, and both groups have project permissions to add, edit, and delete comments:
   1. jira-software-users
   2. administrators
2. Select a status such as DONE to apply the following properties 
   1. Add the following Controle properties to show what does function correctly:
   2. jira.permission.commentdeleteown.denied.group.1 = jira-software-users 
   3. jira.permission.commentdeleteall.denied.group.1 = jira-software-users
   4. jira.permission.comment.denied.group.1 = jira-software-users
3. Add the following properties to see the permission bypass occur:
   1. jira.permission.commenteditall.denied.group.1 = jira-software-users 
   2. jira.permission.commenteditown.denied.group.1 = jira-software-users
4. Make sure to publish the workflow for the properties to take effect
5. Navigate to an issue that is in the done status

Expected Results

The control values to add new comments and delete comments are respected as well as the option to edit your own comments and other users' comments meaning you are not able to Edit, Add, or Delete a comment

Actual Results

The control values to add new comments and delete your own comments are respected, HOWEVER, you can still edit comments where this should be denied if you are a member of the group that is denied.

Workaround

Currently, you cannot deny these two permissions by group and can only use the following format to deny ALL users the ability to edit comments

jira.permission.commenteditown.denied = true
jira.permission.commenteditall.denied = true