-
Bug
-
Resolution: Unresolved
-
Medium
-
Severity 3 - Minor
-
0
Issue Summary
When cloning an issue through Automation rule, the security level is copied even though this is not applied to the destination project, what makes the created issues unaccessible.
Steps to Reproduce
- Create a security scheme and apply this to project A
- Create a security scheme and apply this to project B
- Build an Automation rule using Clone action, being issue from project A the trigger issue and cloning this to project B
- Make sure security level is applied to the trigger issue and that this security level is not applied to project B
- After the Clone Issue action, add a Most recently created issue branch and within this add any action as Log Action, for example
- Automation rule won't be able to find any issue within branch even though an issue was successfully created by the rule
Expected Results
Since security level is not applied and available in created issue's project, an error message should be shown and issue should not be created.
Actual Results
When cloning the issue in project B, the security level value is copied even though this is not available in project B. Due to this, the created issue is unavailable to be accessed, even though the user has the needed permissions.
Workaround
Two approaches to mitigate this:
- If the destination project is using an Issue Security Scheme as well, specifically set a level during the clone action that is accessible in that project
- Clear the value using smart values during the clone action
More granular information on the above can be found in the following KB:
[AUTO-404] When cloning an issue through Automation rule, security level value is copied even though the security level is not available in the created issue's project
| Remote Link | New: This issue links to "Page (Confluence)" [ 998363 ] |
| UIS | Original: 1 | New: 0 |
| Remote Link | New: This issue links to "Page (Confluence)" [ 961226 ] |
| Labels | Original: Automation_Move_JSW jsw-s13 | New: Automation_Move_JSW jira-dependency jsw-s13 |
| Link | New: This issue was cloned as AUTO-1375 [ AUTO-1375 ] |
| Description |
Original:
h3. Issue Summary
When cloning an issue through Automation rule, the security level is copied even though this is not applied to the destination project, what makes the created issues unaccessible. h3. Steps to Reproduce # Create a security scheme and apply this to project A # Create a security scheme and apply this to project B # Build an Automation rule using Clone action, being issue from project A the trigger issue and cloning this to project B # Make sure security level is applied to the trigger issue and that this security level is not applied to project B # After the Clone Issue action, add a Most recently created issue branch and within this add any action as Log Action, for example # Automation rule won't be able to find any issue within branch even though an issue was successfully created by the rule !image-2021-06-21-14-41-22-933.png|width=481,height=197! h3. Expected Results Since security level is not applied and available in created issue's project, an error message should be shown and issue should not be created. h3. Actual Results When cloning the issue in project B, the security level value is copied even though this is not available in project B. Due to this, the created issue is unavailable to be accessed, even though the user has the needed permissions. h3. Workaround Two approaches to mitigate this: # If the destination project is using an Issue Security Scheme as well, specifically set a level during the clone action that is accessible in that project # Clear the value using smart values during the clone action More granular information on the above can be found in the following KB: * [Cloning issues with Issue Security Scheme levels via Automation|https://confluence.atlassian.com/servicemanagement/cloning-issues-with-issue-security-scheme-levels-via-automation-1188772874.html] |
New:
h3. Issue Summary
When cloning an issue through Automation rule, the security level is copied even though this is not applied to the destination project, what makes the created issues unaccessible. h3. Steps to Reproduce # Create a security scheme and apply this to project A # Create a security scheme and apply this to project B # Build an Automation rule using Clone action, being issue from project A the trigger issue and cloning this to project B # Make sure security level is applied to the trigger issue and that this security level is not applied to project B # After the Clone Issue action, add a Most recently created issue branch and within this add any action as Log Action, for example # Automation rule won't be able to find any issue within branch even though an issue was successfully created by the rule !image-2021-06-21-14-41-22-933.png|width=481,height=197! h3. Expected Results Since security level is not applied and available in created issue's project, an error message should be shown and issue should not be created. h3. Actual Results When cloning the issue in project B, the security level value is copied even though this is not available in project B. Due to this, the created issue is unavailable to be accessed, even though the user has the needed permissions. h3. Workaround Two approaches to mitigate this: # If the destination project is using an Issue Security Scheme as well, specifically set a level during the clone action that is accessible in that project # Clear the value using smart values during the clone action More granular information on the above can be found in the following KB: * [Cloning issues with Issue Security Scheme levels via Automation|https://confluence.atlassian.com/jirakb/cloning-issues-with-issue-security-scheme-levels-via-automation-1188772874.html] |
| Labels | Original: Automation_Move_JSW | New: Automation_Move_JSW jsw-s13 |
| Labels | Original: Automation_Move_JSW jsw-s13 | New: Automation_Move_JSW |
| Labels | Original: Automation_Move_JSW | New: Automation_Move_JSW jsw-s13 |
The severity of this Bug may be too low since the generated issue clone in this scenario is fully inaccessible (AUTO-404 is a fitting issue key!) – even for product/site admins and atlassian-addons-project-access members (i.e. Automation for Jira, Scriptrunner for Jira) – to even just correct or clear its security level, which means any project configuration changes that involve these inaccessible issues, such as workflow status removals or custom dropdown field option removals, will also be fully blocked. My understanding is that the only resolution in these cases is to have the inaccessible (but possibly unknown) issues modified directly in the database (i.e. via Atlassian support/engineering).
FWIW, the issue clones in this scenario do appear in Atlassian Analytics, but, of course, this is a read-only view, and without https://jira.atlassian.com/browse/ANALYTICS-146, we cannot generally search for (nor exclude) these issue clones based on security levels.