• Icon: Bug Bug
    • Resolution: Answered
    • Icon: Medium Medium
    • None
    • 3.3.2
    • SLA

      Summary

      After updating SLA 'Pause On' condition, existing tickets with affected statuses are not updated.

      Environment

      JIRA 7.3.2
      JIRA Service Desk 3.3.2

      Steps to Reproduce

      1. Have a service desk project with issue statuses Waiting for Clarification and Waiting for Call Center.
      2. Have an SLA with Waiting for Clarification status in the Pause On conditions.
      3. Edit the SLA Pause On conditions: remove Waiting for Clarification and add Waiting for Call Center.

      Expected Results

      After SLA recalculates:

      • The SLA is no longer paused for issues with the status Waiting for Clarification.
      • The SLA is now paused for issues with the status Waiting for Call Center.

      Actual Results

      After SLA recalculates:

      • The SLA remains paused for existing issues with the status Waiting for Clarification.
      • The SLA is not paused for existing issues with the status Waiting for Call Center.
      • New issues and issues which are updated by the user see the SLA enter the proper state.
      • Only existing issues are affected.

      Workaround

      Since any change/update to affected issues causes the SLA to enter the correct state for those issues, a bulk change to all affected issues (for example, bulk add comment) will update the SLA state to reflect the rule change.

      Notes

      Locked reindex and JIRA restart have no effect on the SLA state. Screenshots attached.

        1. configuration.png
          configuration.png
          18 kB
        2. correct_states.png
          correct_states.png
          9 kB
        3. wrong_states_v1.png
          wrong_states_v1.png
          7 kB
        4. wrong_states_v2.png
          wrong_states_v2.png
          5 kB

            [JSDSERVER-4995] Existing tickets do not respect new Pause On conditions

            Hi nparks@atlassian.com

            I have tried to reproduce this, but have been unsuccessful.

            What I did:

            • Create a new project
            • Create some issues with a mix between 2 different statuses
            • Edited the Time To Resolution SLA to add one of the statuses as a Pause condition
            • Save
            • SLA updated correctly
            • Change SLA config to other status as Pause condition (remove existing condition)
            • Save
            • SLA also updated correctly

            Am I missing something?

            I would ask if possible to check a few things:

            • The SLA is configured in the correct project, and same project as issues that checking. SLA is project specific.
            • The instance does not have 2 or more statuses of the same name. The Status conditions work by comparing the Status ID (not name), and if there is 2 statues with same name, make sure that the same one is specified in the workflow and SLA.
            • Possible to try making any SLA configuration change again, and the Save (and Update) and change again. Doing a configuration change forces the ongoing SLAs for all issues on the project to be recalculated with the new configuration.

            Finally, I would suggest ensuring that the problem is not caused by JRASERVER-64067 which was fixed in 7.3.2, but if issues were created in affected versions of JIRA, then possible.

            To check this, please check that the Issue Status lines up correctly with the Status changes recorded in the Change History of the affected issues.

            This could explain the problem in my mind, as new issues are processed based on the current status recorded on the issue, whereas existing issues, are calculated from the Issue Change history. If the issue change history records the value it should be, but the transition actually failed due to that bug, then this seems like it could happen.

            Would be interesting to know if with any new issues created since being on 7.3.2 or newer, does the problem still occur when changing the Pause On conditions?

            I hope that all this helps, and I am confident from my testing that JRASERVER-64067 may be the problem, and therefore will close this an Answered.

            If this is not the case, then please respond to this ticket, and I will reopen. But to be able to accurately investigate, would require a data backup that exhibits the problem.

            Regards
            Matt
            JIRA Service Desk developer

            Matthew McMahon (Inactive) added a comment - - edited Hi nparks@atlassian.com I have tried to reproduce this, but have been unsuccessful. What I did: Create a new project Create some issues with a mix between 2 different statuses Edited the Time To Resolution SLA to add one of the statuses as a Pause condition Save SLA updated correctly Change SLA config to other status as Pause condition (remove existing condition) Save SLA also updated correctly Am I missing something? I would ask if possible to check a few things: The SLA is configured in the correct project, and same project as issues that checking. SLA is project specific. The instance does not have 2 or more statuses of the same name. The Status conditions work by comparing the Status ID (not name), and if there is 2 statues with same name, make sure that the same one is specified in the workflow and SLA. Possible to try making any SLA configuration change again, and the Save (and Update) and change again. Doing a configuration change forces the ongoing SLAs for all issues on the project to be recalculated with the new configuration. Finally, I would suggest ensuring that the problem is not caused by JRASERVER-64067 which was fixed in 7.3.2, but if issues were created in affected versions of JIRA, then possible. To check this, please check that the Issue Status lines up correctly with the Status changes recorded in the Change History of the affected issues. This could explain the problem in my mind, as new issues are processed based on the current status recorded on the issue, whereas existing issues, are calculated from the Issue Change history. If the issue change history records the value it should be, but the transition actually failed due to that bug, then this seems like it could happen. Would be interesting to know if with any new issues created since being on 7.3.2 or newer, does the problem still occur when changing the Pause On conditions? I hope that all this helps, and I am confident from my testing that JRASERVER-64067 may be the problem, and therefore will close this an Answered. If this is not the case, then please respond to this ticket, and I will reopen. But to be able to accurately investigate, would require a data backup that exhibits the problem. Regards Matt JIRA Service Desk developer

              Unassigned Unassigned
              nparks@atlassian.com Nathan Parks
              Affected customers:
              1 This affects my team
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: