-
Bug
-
Resolution: Not a bug
-
Low (View bug fix roadmap)
-
None
-
6.2.6
-
6.02
-
2
-
Severity 3 - Minor
-
1
-
After investigating this bug and how it's supposed to work, we've determined that the functionality is working as intended, and will proceed to close this as not a bug.
The example outlined in this bug report hasn't been implemented correctly - the format is jira.permission.PERMISSION.GRANT_TYPE. In this example, the workflow property allows the reporter to delete their own attachments. The first example does not work because "Reporter" doesn't accept a parameter or value, while the second one doesn't work because the "Denied" value doesn't act as a negator - but is a suffix to make each rule unique.
Please see this comment for more details.
Steps to Replicate
- Remove any other entities from the 'Delete own Attachment' permission;
- Add the reporter to this permission;
- Add the following property to a workflow step:
jira.permission.attachdeleteown.reporter = denied
or
jira.permission.attachdeleteown.reporter.denied
- Publish the Workflow draft;
- Create a new issue, and;
- add an attachment to the issue when it is on the same step to which the property was added;
- Try to delete that attachment
Expected Behavior
JIRA wouldn't allow the reporter to delete it.
Actual Behavior
JIRA does allow the reporter to delete the attachment.
Workaround:
Use a group condition for example so the reporter won't be able to delete it:
jira.permission.attachdeleteown.group = bogus
- is related to
-
-
- Closed
-
[JRASERVER-38878] jira.permission.attachdeleteown.reporter Workflow Property doesn't Work
Thank you for the explanation. It was very helpful and explains why the properties don't work.
But, it stops short of explaining how to get it to work. So, how do we achieve this "jira.permission.attachdeleteown.reporter.denied" effect?
Hi Folks,
As a part of our efforts to make sure that our bugs are accurate and have workarounds where they can, I spent a bit of time digging into what's going on here. Part of the problem is that we haven't previously had a good deal of documentation on how this feature works in detail.
First up, how does this feature 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 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 attachments:
jira.permission.attachdeleteown.denied
# Allow the reporter to delete their own attachments at this step:
jira.permission.attachdeleteown.reporter
These are invalid:
jira.permission.attachdeleteown.reporter.denied jira.permission.attachdeleteown.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 to be able to delete their own attachments, you'd use:
jira.permission.attachdeleteown.group.1 = 10000 jira.permission.attachdeleteown.group.2 = 20000
Those keys would make sure that only members of the two groups could delete their own attachments at the specified step.
Why does the example not work as expected?
The permission scheme in the example given permits the user to delete their own attachments at any time. Next, at a specific step, there's a workflow property that states "The reporter is allowed to delete their own attachments". As described previously, the syntax will either create a unique rule (which means nothing) or create a rule with the value denied which doesn't apply to the "Reporter" field.
What happens next?
For folks who are still struggling with how to implement workflow properties correctly, please raise a Support Request (or raise a question in the Atlassian Community) outlining . your use case - as there's potentially a better way to achieve the results you are looking for.
Cheers,
Dave
Atlassian Support
This same problem affects jira.permission.delete.reporter on version 7.12.2
Unfortunately, we cannot use the workaround because it prevents everyone from deleting the issue.
Hi serverteam1! You'll need to remove the permission for the reporter to delete their own attachments (which would affect all projects that use that scheme, at all steps of the workflow) or use jira.permission.attachdeleteown.denied at that specific step (which would stop everyone from deleting their own attachments at that step). You could also use jira.permission.attachdeleteall.denied which would stop all attachment deletion at that step.
There's no way to explicitly say "the reporter cannot delete their own attachments at that exact step in the workflow" - so you'll need to consider your specific use case and look at alternatives. Since I'm not familiar with your exact requirements, workflow and use case, I can't speak with authority (and recommend you raise a support request, or post a question on the community to see how others are handling such a use case.
Cheers,
Dave
Atlassian Support