Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-11006

When an issue is created/updated/after an SLA recalculation, any SLA goal that contains iqlFunction() will not be applied to issues as expected until the issue is edited and refreshed

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 10.2.0
    • 4.13.11, 4.21.0, 4.13.13, 4.20.3, 4.13.15, 5.5.0
    • SLA

      Issue Summary

      When an issue is created/updated via email (comment is added)/after an SLA recalculation, any SLA goal that contains iqlFunction() will not be applied to issues as expected until the issue is edited and refreshed.

      Steps to Reproduce

      Scenario 1

      1. To be able to reproduce this issue, we need a JSM issue with an Insight custom field filled with an Insight object that has some attributes to be filtered on using iqlFunction().
      2. Configure an SLA goal that contains iqlFunction(), make sure the JQL returns the issue(s) as expected.
      3. Save the SLA goal. SLA recalculation will be triggered automatically (a bar will appear under SLA on the left settings bar) and when it's done, view the issue and check the SLA goal.
      4. Result: The SLA goal is incorrect.
      5. Edit the issue by adding a label or assign the issue. Refresh the issue and check the SLA goal again.
      6. Result: The SLA goal changed and the correct one is applied.
      7. If you perform another SLA configuration change to repeat step 2 and check the issue again, you will find that the SLA goal is again incorrect until another edit issue action is done.
        Screen Recording 2022-01-07 at 20.07.45.mov - Timeline
        Time Description
        00:00 ITSD-31 has the Time to Resolution SLA goal of 4h, which is as expected.
        00:17 ITSD-31 fulfilled the condition to have an SLA goal of 4h.
        00:26 Added a new SLA goal so that we can trigger an SLA recalculation.
        00:54 ITSD-31 is still fulfilling the condition for the 4h goal, however, the goal has changed to 24h which is for issues not fulfilling any conditions.
        01:06 Assigned ITSD-31 to trigger an issue update. This action "corrected" the SLA goal.
        01:29 Edited SLA again to trigger another SLA recalculation to reproduce this bug again

      Scenario 2

      1. Set up email request for the JSM project so that requests can be created via emails.
      2. Follow all steps in scenario 1 to reproduce the issue and fix the SLA, ensure the right goal is applied.
      3. Add a comment to the request that has the right SLA goal via email.
      4. Notice that the SLA goal is changed to an incorrect one, one without any iqlFuntion().
      5. Edit the request manually and the right SLA goal will be applied again.
      6. For all the subsequent comments via emails, the wrong SLA goal will be applied and a fix is needed every time.

      Expected Results

      The correct SLA goal is applied after SLA recalculation without having to edit the issue manually

      Actual Results

      The correct SLA goal is only applied after a manual edit of an issue after SLA recalculation. Only SLA goals with JQL that contains iqlFunction are affected
      For issues updated via emails, this bug will occur to the issue every time after the issue is updated.

      Root Cause

      The SLA JQL queries are performed assuming the customer permissions on the issue, but also customer permissions on the Schema to which the AQL query applies. From version 10.2 SLA calculations will run in their own context in order to display correct SLA values.

      Workaround 1

      Add all customers to user permissions of the object schema or enable the JSM customer Portal access on the affected schema.

      Workaround 2

      Use automation rules (Automation for Jira, JSM Automation or other plugins that provide this functionality) to trigger issue update that will fix the SLA. As this bug could happen on a single issue multiple times, different rules might be needed to fix the SLA of an issue until the SLA stops. Here are 2 example rules we recommended:

      Edit issue when an issue is created

      1. Create a custom field of type Text Field or use the Labels field.
      2. Create a rule with configurations below.
        1. When: Issue is created
        2. If: (try to be specific with the condition)
        3. Then: Edit issue --> Search for the newly created field/Labels --> Update it with a value
      3. Enable the Automation Rule.

      Edit issue whenever an issue is updated (Scenario 2)

      1. Create a rule with configurations below.
        1. When: Issue is commented
        2. If Issue matches JQL: project = ITSD and issuetype in ("Incident", "Problem") and "Time to resolution" = running()
        3. And If User condition: User who triggered the event is not Issue Reporter
        4. Then: Edit issue fields --> Add/remove a value

      Tips: The workaround might add too many entries to the issue history. You could have the rules to also check if a label is present in the issue and edit the issue by adding a label or removing it.

            [JSDSERVER-11006] When an issue is created/updated/after an SLA recalculation, any SLA goal that contains iqlFunction() will not be applied to issues as expected until the issue is edited and refreshed

            Satej Mirpagar made changes -
            Resolution New: Fixed [ 1 ]
            Status Original: Waiting for Release [ 12075 ] New: Closed [ 6 ]
            Bartosz Ornatowski made changes -
            Description Original: h3. Issue Summary
            When an issue is created/updated via email (comment is added)/after an SLA recalculation, any SLA goal that contains [iqlFunction()|https://confluence.atlassian.com/servicemanagementserver/insight-jql-functions-1087513360.html#InsightJQLfunctions-iqlFunction(iql)] will not be applied to issues as expected until the issue is edited and refreshed.

            h3. Steps to Reproduce
            h4. Scenario 1
             # To be able to reproduce this issue, we need a JSM issue with an Insight custom field filled with an Insight object that has some attributes to be filtered on using [iqlFunction()|https://confluence.atlassian.com/servicemanagementserver/insight-jql-functions-1087513360.html#InsightJQLfunctions-iqlFunction(iql)].
             # Configure an SLA goal that contains [iqlFunction()|https://confluence.atlassian.com/servicemanagementserver/insight-jql-functions-1087513360.html#InsightJQLfunctions-iqlFunction(iql)], make sure the JQL returns the issue(s) as expected.
             # Save the SLA goal. SLA recalculation will be triggered automatically (a bar will appear under SLA on the left settings bar) and when it's done, view the issue and check the SLA goal.
             # *Result:* The SLA goal is incorrect.
             # Edit the issue by adding a label or assign the issue. Refresh the issue and check the SLA goal again.
             # *Result:* The SLA goal changed and the correct one is applied.
             # If you perform another SLA configuration change to repeat step 2 and check the issue again, you will find that the SLA goal is again incorrect until another edit issue action is done.
            (i) [^Screen Recording 2022-01-07 at 20.07.45.mov] - Timeline
            ||Time||Description||
            |00:00|ITSD-31 has the Time to Resolution SLA goal of 4h, which is as expected.|
            |00:17|ITSD-31 fulfilled the condition to have an SLA goal of 4h.|
            |00:26|Added a new SLA goal so that we can trigger an SLA recalculation.|
            |00:54|ITSD-31 is still fulfilling the condition for the 4h goal, however, the goal has changed to 24h which is for issues not fulfilling any conditions.|
            |01:06|Assigned ITSD-31 to trigger an issue update. This action "corrected" the SLA goal.|
            |01:29|Edited SLA again to trigger another SLA recalculation to reproduce this bug again|

            h4. Scenario 2
            # Set up email request for the JSM project so that requests can be created via emails.
            # Follow all steps in scenario 1 to reproduce the issue and fix the SLA, ensure the right goal is applied.
            # Add a comment to the request that has the right SLA goal via email.
            # Notice that the SLA goal is changed to an incorrect one, one without any iqlFuntion().
            # Edit the request manually and the right SLA goal will be applied again.
            # For all the subsequent comments via emails, the wrong SLA goal will be applied and a fix is needed every time.

            h3. Expected Results
            The correct SLA goal is applied after SLA recalculation without having to edit the issue manually

            h3. Actual Results
            The correct SLA goal is only applied after a manual edit of an issue after SLA recalculation. Only SLA goals with JQL that contains iqlFunction are affected
            (!) For issues updated via emails, this bug will occur to the issue every time after the issue is updated.

            h3. Workaround
            Use automation rules (Automation for Jira, JSM Automation or other plugins that provide this functionality) to trigger issue update that will fix the SLA. As this bug could happen on a single issue multiple times, different rules might be needed to fix the SLA of an issue until the SLA stops. Here are 2 example rules we recommended:
            h4. Edit issue when an issue is created
             # Create a custom field of type {{Text Field}} or use the Labels field.
             # Create a rule with configurations below.
             ## When: Issue is created
             ## If: (try to be specific with the condition)
             ## Then: Edit issue --> Search for the newly created field/Labels --> Update it with a value
             # Enable the Automation Rule.

            h4. Edit issue whenever an issue is updated (Scenario 2)
            # Create a rule with configurations below.
            ## When: Issue is commented
            ## If Issue matches JQL: project = ITSD and issuetype in ("Incident", "Problem") and "Time to resolution" = running()
            ## And If User condition: User who triggered the event is not Issue Reporter
            ## Then: Edit issue fields --> Add/remove a value

            (i) Tips: The workaround might add too many entries to the issue history. You could have the rules to also check if a label is present in the issue and edit the issue by adding a label or removing it.
            New: h3. Issue Summary

            When an issue is created/updated via email (comment is added)/after an SLA recalculation, any SLA goal that contains [iqlFunction()|https://confluence.atlassian.com/servicemanagementserver/insight-jql-functions-1087513360.html#InsightJQLfunctions-iqlFunction(iql)] will not be applied to issues as expected until the issue is edited and refreshed.
            h3. Steps to Reproduce
            h4. Scenario 1
             # To be able to reproduce this issue, we need a JSM issue with an Insight custom field filled with an Insight object that has some attributes to be filtered on using [iqlFunction()|https://confluence.atlassian.com/servicemanagementserver/insight-jql-functions-1087513360.html#InsightJQLfunctions-iqlFunction(iql)].
             # Configure an SLA goal that contains [iqlFunction()|https://confluence.atlassian.com/servicemanagementserver/insight-jql-functions-1087513360.html#InsightJQLfunctions-iqlFunction(iql)], make sure the JQL returns the issue(s) as expected.
             # Save the SLA goal. SLA recalculation will be triggered automatically (a bar will appear under SLA on the left settings bar) and when it's done, view the issue and check the SLA goal.
             # *Result:* The SLA goal is incorrect.
             # Edit the issue by adding a label or assign the issue. Refresh the issue and check the SLA goal again.
             # *Result:* The SLA goal changed and the correct one is applied.
             # If you perform another SLA configuration change to repeat step 2 and check the issue again, you will find that the SLA goal is again incorrect until another edit issue action is done.
            (i) [^Screen Recording 2022-01-07 at 20.07.45.mov] - Timeline
            ||Time||Description||
            |00:00|ITSD-31 has the Time to Resolution SLA goal of 4h, which is as expected.|
            |00:17|ITSD-31 fulfilled the condition to have an SLA goal of 4h.|
            |00:26|Added a new SLA goal so that we can trigger an SLA recalculation.|
            |00:54|ITSD-31 is still fulfilling the condition for the 4h goal, however, the goal has changed to 24h which is for issues not fulfilling any conditions.|
            |01:06|Assigned ITSD-31 to trigger an issue update. This action "corrected" the SLA goal.|
            |01:29|Edited SLA again to trigger another SLA recalculation to reproduce this bug again|

            h4. Scenario 2
             # Set up email request for the JSM project so that requests can be created via emails.
             # Follow all steps in scenario 1 to reproduce the issue and fix the SLA, ensure the right goal is applied.
             # Add a comment to the request that has the right SLA goal via email.
             # Notice that the SLA goal is changed to an incorrect one, one without any iqlFuntion().
             # Edit the request manually and the right SLA goal will be applied again.
             # For all the subsequent comments via emails, the wrong SLA goal will be applied and a fix is needed every time.

            h3. Expected Results

            The correct SLA goal is applied after SLA recalculation without having to edit the issue manually
            h3. Actual Results

            The correct SLA goal is only applied after a manual edit of an issue after SLA recalculation. Only SLA goals with JQL that contains iqlFunction are affected
            (!) For issues updated via emails, this bug will occur to the issue every time after the issue is updated.
            h3. Root Cause

            The SLA JQL queries are performed assuming the customer permissions on the issue, but also customer permissions on the Schema to which the AQL query applies. From version 10.2 SLA calculations will run in their own context in order to display correct SLA values.
            h3. Workaround 1

            Add all customers to user permissions of the object schema or enable the JSM customer Portal access on the affected schema.
            h3. Workaround 2

            Use automation rules (Automation for Jira, JSM Automation or other plugins that provide this functionality) to trigger issue update that will fix the SLA. As this bug could happen on a single issue multiple times, different rules might be needed to fix the SLA of an issue until the SLA stops. Here are 2 example rules we recommended:
            h4. Edit issue when an issue is created
             # Create a custom field of type {{Text Field}} or use the Labels field.
             # Create a rule with configurations below.
             ## When: Issue is created
             ## If: (try to be specific with the condition)
             ## Then: Edit issue --> Search for the newly created field/Labels --> Update it with a value
             # Enable the Automation Rule.

            h4. Edit issue whenever an issue is updated (Scenario 2)
             # Create a rule with configurations below.
             ## When: Issue is commented
             ## If Issue matches JQL: project = ITSD and issuetype in ("Incident", "Problem") and "Time to resolution" = running()
             ## And If User condition: User who triggered the event is not Issue Reporter
             ## Then: Edit issue fields --> Add/remove a value

            (i) Tips: The workaround might add too many entries to the issue history. You could have the rules to also check if a label is present in the issue and edit the issue by adding a label or removing it.
            Bartosz Ornatowski made changes -
            Fix Version/s New: 10.2.0 [ 109023 ]
            Bartosz Ornatowski made changes -
            Status Original: In Progress [ 3 ] New: Waiting for Release [ 12075 ]
            Bartosz Ornatowski made changes -
            Assignee New: Bartosz Ornatowski [ bornatowski ]
            Bartosz Ornatowski made changes -
            Status Original: Short Term Backlog [ 12074 ] New: In Progress [ 3 ]
            Marc Dacanay made changes -
            Labels Original: lts10 lts10nth New: lts10nth
            Bartosz Ornatowski made changes -
            Sprint New: LTS Sprint [ 7234 ]
            Bartosz Ornatowski made changes -
            Labels Original: lts10 New: lts10 lts10nth
            Bartosz Ornatowski made changes -
            Labels New: lts10

              bornatowski Bartosz Ornatowski
              michin Michelle Chin
              Affected customers:
              17 This affects my team
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: