Uploaded image for project: 'Automation for Cloud'
  1. Automation for Cloud
  2. AUTO-436

Automation for Jira does not display the current count of components

    • Minor

      Issue Summary

      The Automation rule does not display the count of rule components. There are few "hidden" components that are available in the JSON export and one particular type (jira.condition.container.block) actually counts towards the service limit. This creates a problem when you are still expecting the count has not hit the limit.

      Especially, if the rule includes the If..else component (jira.condition.container.block).

      More details and context on the following article:

      Steps to Reproduce

      1. Create a new rule
      2. Add components with if..else conditions (say ~58 of them)
      3. The Rule won't allow you to add any more component irrespective of the count from the UI search suggest that the total count is less than the service limit of 65.

      Expected Behaviour

      Users should be able to clearly see the number of components currently used in their rules and possibly restricted from creating a new component once limit is reached.

      Actual Results

      • Adding any new component will result in the below error even though visually you seem to have less than 65 components
      • Here is an additional understand if your rule is impacted due to this problem
        • Download the JSON file for the rule
        • Look for the count of - "jira.condition.container.block" element. This is the additional component being taken into consideration by the validation logic towards the count of components.

      Workaround

      None as this is a usability bug. However, if you are hitting the service limit then you may need to split the rule.

            [AUTO-436] Automation for Jira does not display the current count of components

            Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            Tobias Bosshard added a comment - Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            Greetings!

            With the recent changes to the packaging / usage limits for automation rules, one way customers try to manage usage is by combining rules using if / else blocks.  Having an accurate count in the UX helps them decide when to merge / split up rules, and so the component count needs to be accurate.

            Thus this defect is no longer a usability defect: it impacts customer usage and licensing limit responses.

            Kind regards,
            Bill

            Bill Sheboy added a comment - Greetings! With the recent changes to the packaging / usage limits for automation rules, one way customers try to manage usage is by combining rules using if / else blocks .  Having an accurate count in the UX helps them decide when to merge / split up rules, and so the component count needs to be accurate. Thus this defect is no longer a usability defect: it impacts customer usage and licensing limit responses. Kind regards, Bill

            I´ve encountered this issue today. Everything important was already said before.

            I have no idea why I bother myself reporting this since I don´t expect Atlassian to ever fix this.

            Dominik Březina added a comment - I´ve encountered this issue today. Everything important was already said before. I have no idea why I bother myself reporting this since I don´t expect Atlassian to ever fix this.

            Ian Brown added a comment -

            This is creating serious issues with my automated task development process.

            Please increase the importance of addressing this bug. It is making for serious confusion trying to develop tasks when you cannot accurately estimate if you're going to accidentally exceed an invisible miscalculated value for component modules.

            If you cannot fix the bug, at least add a running counter that counts down the number of components remaining so that automation flows and the creation of additional automation tasks can be optimized to only making what is necessary and not cluttering up the automation library.

            Ian Brown added a comment - This is creating serious issues with my automated task development process. Please increase the importance of addressing this bug. It is making for serious confusion trying to develop tasks when you cannot accurately estimate if you're going to accidentally exceed an invisible miscalculated value for component modules. If you cannot fix the bug, at least add a running counter that counts down the number of components remaining so that automation flows and the creation of additional automation tasks can be optimized to only making what is necessary and not cluttering up the automation library.

            please reconsider the priority of this issue.

            automations are a critical component of the usage of JSM in our support activity.  

            this is a limitation that needs to be fixed.

            Michael Smith added a comment - please reconsider the priority of this issue. automations are a critical component of the usage of JSM in our support activity.   this is a limitation that needs to be fixed.

            Jason M. added a comment -

            We are more often coming across the 65 component limit in automation rules, and part of planning large rules is understanding the context where we will need to limit or break our rules out into multiples. But as a user we have no insight other than manually counting each component when the 65 threshold will be hit. Either that or just keep going and find out after the fact that we have too many components, then we have to manually count anyways to subtract components to meet the threshold.

            Overall this is just a really inefficient way to operate around a limit/maximum. There should be a counter or something so we can know at first glance where we are on rule component counts & make it easier to plan & break these up. 

            Jason M. added a comment - We are more often coming across the 65 component limit in automation rules, and part of planning large rules is understanding the context where we will need to limit or break our rules out into multiples. But as a user we have no insight other than manually counting each component when the 65 threshold will be hit. Either that or just keep going and find out after the fact that we have too many components, then we have to manually count anyways to subtract components to meet the threshold. Overall this is just a really inefficient way to operate around a limit/maximum. There should be a counter or something so we can know at first glance where we are on rule component counts & make it easier to plan & break these up. 

            Rahul Kumar added a comment - https://codebarrel.atlassian.net/browse/AUT-2234

              9df7f128cb98 Eshaa Sood
              bb22faff10c5 Rahul Kumar
              Affected customers:
              42 This affects my team
              Watchers:
              40 Start watching this issue

                Created:
                Updated: