• Icon: Bug Bug
    • Resolution: Answered
    • Icon: Low Low
    • None
    • 1.2.6.1
    • SLA

      Experienced Behavior:

      Issues moved to a JIRA Service Desk project do not show SLA information when the SLA would be in a stopped state after the issue is moved.

      • SLA does show when it would be in a paused or started/running after the issue is moved.

      The SLA will appear if there is a start condition that allows the SLA to restart and, after the move, an action is taken that meets this condition. In this situation the SLA appears and begins to count down as expected however the first SLA cycle icon does not appear.

      Expected Behavior:

      SLA value is calculated and displayed for all issues moved to Service Desk project regardless of SLA state after the move.

      Steps to reproduce:

      • Create two projects, one of which is a Service Desk
      • Create issue in non service desk project
      • Take an action on the issue that would meet Service Desk stop condition
      • Move issue to service desk project
      • The SLA does not appear when viewing the issue

      Use Case Example:

      "We have a project that is NOT using Jira Service Desk (JSD). If we "work" on it, assign it, comment on it, etc and then move it to a project that is using JSD, the time to first response SLA is not displayed."

            [JSDSERVER-747] SLA not appearing on issues moved to Service Desk project

            Tanya B. added a comment -

            Suggestion logged: JSDSERVER-6835

            Tanya B. added a comment - Suggestion logged:  JSDSERVER-6835

            Hi,

            SLAs work in that they execute on events at the time that it happens.

            It is not possible to construct an SLA if the events are missed. When an issue is moved from 1 project to another, it has no associated SLA data and is not able to construct that data, as the events required have been missed.

            It might be possible to construct SLAs from historical data, but they would only be created against the current settings as it is impossible to know what the configuration was at the point in time of when the events actually ran.

            Therefore I am closing as not a bug, since it is working as designed and if we were to construct historical data from the current SLA configuration, it's actual relevance can not be guaranteed. In many ways it is safer to not mess with history, than to mess with it in a way that can be unknown.

            If it is felt that this is a problem that should be revisited, can I please suggest raising it as a Suggestion or reopening this as a Suggestion, rather than a bug?

            Regards

            Matthew McMahon (Inactive) added a comment - Hi, SLAs work in that they execute on events at the time that it happens. It is not possible to construct an SLA if the events are missed. When an issue is moved from 1 project to another, it has no associated SLA data and is not able to construct that data, as the events required have been missed. It might be possible to construct SLAs from historical data, but they would only be created against the current settings as it is impossible to know what the configuration was at the point in time of when the events actually ran. Therefore I am closing as not a bug, since it is working as designed and if we were to construct historical data from the current SLA configuration, it's actual relevance can not be guaranteed. In many ways it is safer to not mess with history, than to mess with it in a way that can be unknown. If it is felt that this is a problem that should be revisited, can I please suggest raising it as a Suggestion or reopening this as a Suggestion, rather than a bug? Regards

              Unassigned Unassigned
              tevans Tim Evans (Inactive)
              Affected customers:
              1 This affects my team
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: