Uploaded image for project: 'Automation for Cloud'
  1. Automation for Cloud
  2. 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

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      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

      .Screen Shot 2022-04-29 at 2.47.32 PM.png

            [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

            Ignacio Pulgar added a comment - - edited

            Our most sincere condolences from Spain, e1fe5843b11f.

            Ignacio Pulgar added a comment - - edited Our most sincere condolences from Spain, e1fe5843b11f .

            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...

            Noah Dinlemez added a comment - 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...
            Charlie Gavey made changes -
            Link New: This issue is duplicated by AUTO-1294 [ AUTO-1294 ]
            Charlie Gavey made changes -
            Link New: This issue is duplicated by AUTO-1551 [ AUTO-1551 ]
            Charlie Gavey made changes -
            Link New: This issue is duplicated by AUTO-180 [ AUTO-180 ]
            Charlie Gavey made changes -
            Link New: This issue is duplicated by AUTO-1404 [ AUTO-1404 ]
            Charlie Gavey made changes -
            Link New: This issue duplicates AUTO-161 [ AUTO-161 ]

            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.

            André Stuhrmann added a comment - 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.

            Milad S. added a comment -

            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.

            Milad S. added a comment - 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.
            Charlie Gavey made changes -
            Link New: This issue is blocked by AUTO-420 [ AUTO-420 ]

              Unassigned Unassigned
              emccutcheon Earl McCutcheon
              Votes:
              81 Vote for this issue
              Watchers:
              31 Start watching this issue

                Created:
                Updated: