Retaining Epic Link in Jira When Default Issue Security Hides the Issue Post-Creation

Summary

This article provides a workaround for the known bug "Epic Link is not saved if the issue security hides the issue after its creation" in Jira. This bug causes the epic link to not be saved when an issue is created and subsequently hidden due to the default issue security settings. JRACLOUD-81396 - Epic Link/ Parent is not saved if the issue security hides the issue after its creation.

Diagnosis

The issue occurs when a user creates an issue with a default issue security that hides the issue from the reporter. The issue is hidden as expected, but the epic link is not saved. This is contrary to the expected result where the epic link should be retained since it is not a post-function.

Cause

The issue arises from the sequence of post-issue creation events in Jira. If a reporter does not select a 'Security Level,' the issue will be set to the default security level. Jira then checks if the issue is a child or parent issue by looking at the Epic Link field. However, Jira handles the Epic Link as a post-execution step and not part of the issue creation process. As a result, if the user cannot access the Epic issue, the link is rejected due to lack of permission, and the issue is created as a standard one. This prevents child issues and their Epic issues from being accessible by the user.

Solution

A possible workaround involves creating an additional issue security level that allows anyone to see the issue and automating the security level change. Follow these steps:

1. Create a new issue security level that allows 'anyone to see the issue.'

2. Create an Automation rule that changes the issue security to the current "default" after issue creation. This hides the issue from users, not in the allowed actors at the security level.

With this setup, the Epic link will be retained on issue creation and will be hidden from non-allowed actors after the Automation rule updates the security level.

Disclaimer: Please note that while this workaround is effective, it might lead to an information leak. Regular backlog items that might be sensitive are exposed until the automation runs or if the automation fails. Therefore, use this workaround with caution and only when necessary.