Details
-
Bug
-
Resolution: Not a bug
-
Low
-
None
-
6.2.6
-
6.02
-
2
-
Severity 3 - Minor
-
1
-
Description
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
Attachments
Issue Links
- is related to
-
-
- Closed
-