-
Suggestion
-
Resolution: Unresolved
-
None
Suggested improvements
- When creating an automation rule using an action to set a field, if a custom field is used any update to the field name (rename) will cause the field to be recognized as a deleted field in the automation rule. For example, if a field is named "Example id" and you change it to "Example ID" it will be recognized as a deleted field due to the capitalization if "id". In the field mapping for the automation rule use the field ID as the mapping variable instead of the field name when using the "Choose which filed to select..." option, so that when a filed name is altered the rule will still map to the renamed field
- When we create a new sub-task via automation, we should be able to set a parent id besides "current issue" or "trigger issue"
- Make it easier to work with fields, e.g. Improve Automation Rules so they accept keys and names for the Project and Issue Type fields instead of just the Ids
- Issue field compare condition should use the ID of Request Types
- Renaming an Issue Security Level does not update linked automations, causing failures
- duplicates
-
AUTO-161 Automation fails when it has two fields with the same name/type, showing the error "Found multiple fields with the same name and type:" and Additional fields contains invalid field(s) in 'update' or 'fields' section. <field_name>"
-
- Long Term Backlog
-
- is blocked by
-
- Closed
-
- Closed
-
- Closed
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Gathering Interest
[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
Oh my... This not being easier is a very very frustrating fact... I too am now doing half a days work because of some name changes. And I know there will be more name changes in the future... 
I would like to add that changed field values (including request type names) should not break automation rules. Thus, the field value ids should be used instead of hard-coded value names.
A warning with the list of affected components (automation/filter/form) would be great so admins can go and fix the problem.
However, I wish the custom field updates would automatically be reflected across different components (automation/filter) without needing to reference field IDs, teach project admins how to update automation/filters, figure out what automation/filters are actually affected, etc.
This is really frustrating for admins.
I am facing nearly half a day of work to update automations because of a simple custom field name change. This is ridiculous. Wouldn't tying to the field ID make more sense?
+1. Fixing this should not be a matter of popularity as if it really were a new feature request.
If something is implemented in such a way that multiplies the administration/maintenance efforts in an unlimited way, then, in my opinion, it is a Bug rather than a new feature request.
Imagine going through multiple Automation components referencing a renamed field in hundreds of rules. Since there is no easy way to see which rules actually made use of a given field, this is a nightmare.
Yes, we can export all rules to a JSON file, open it with a text editor, search for a given field, reformat the JSON file so that it is easily readable by a human, and try to identify the impacted rules, but that's far away from being an ideal scenario.
The "new feature" would just consist of preventing the rules to get broken. This is not providing a new capability, but implementing the very same thing the good way instead.
Please fix this ASAP.
Thank you in advance!
Ignacio
Our most sincere condolences from Spain, e1fe5843b11f.