-
Suggestion
-
Resolution: Duplicate
-
None
Issue Summary
When modifying the name of an Issue Security Level, automations utilizing that Security Level fails to update with the new name. Instead, they remain connected to the previous name, seemingly relying on the Issue Security Level's name for reference rather than utilizing its unique identifier.
Steps to Reproduce
- Configure your project to use Security Levels by adding an Issue Security Scheme to the project and including the Security Level field on various View/Edit screens.
- Create a simple automation rule triggered by "Issue Created" and use the action "Edit Issue" to set the Security Level field to the one configured in the previous step.
- When an issue is created in the project, it will be assigned the configured Security Level.
- Go to the Issue Security Scheme and rename the Issue Security Level to a different name.
- Create a new issue in the project, and it won't be assigned the updated Security Level, resulting in a failure of the Automation rule.
- Inspect the configuration of the Automation Rule, and you will notice that it still references the previous Security Level name.
Expected Results
When a Security Level used in Automation Rules is renamed in the Issue Security Scheme, all automation rules should automatically update to reflect this change, ensuring they continue to work as expected.
Actual Results
After renaming the Security Level, the automation rules do not update, leading to failures and the following error message:
No fields or field values to edit for issues (could be due to some field values not existing in a given project): PKEY-1234
Workaround
Currently, the only resolution for this issue is to manually update the Security Level in every affected automation rule to prevent failures.
- blocks
-
AUTO-468 Support for field IDs instead of just field names in Automation, so rules don't break when fields are renamed, and to support custom fields with the same name
- Gathering Interest