"SLA for existing issues" with "Only first execution"

Issue #215 closed
Markus Hein created an issue

Hey Tuncay,

it seems to me, that the new flag "Only first execution" (#184) confuses the report "SLA for existing issues".
I've found following constellation after the report was running:
SLA-3a3d (time first action) is defined from "New" to "In work", "Only first execution" is checked, multiple transitions: no, SLA Value is 3 days
SLA-3b16d (time to resolve) is defined from "In Work" to "Resolved", "Only first execution" is not checked, multiple transitions: yes, SLA Value is 16 days, "Customer Action" is the only paused status.

An Issue was created on 2016-04-06 at 17:17.
First change of status (from New to "In Work") was on 2016-04-07 (next day) at 07:27.
Our working hours are Mon - Fri 09:00 to 17:00
This means that the time for first action was completely done in the "non-working-hours" and the SLA was MET.
Next changes:
2016-04-07 at 07:27 (about 6 seconds after the previous transition): technical transition from "In Work" to "In Work" (in the background an other issue in the development project is created and linked)
2016-04-07 at 11:31: from "In Work" to "Customer Action".
2016-04-26 at 15:07: from "Customer Action" to "New"
2016-04-26 at 15:39: from "New" to "In Work"
2016-04-27 at 11:32: from "In Work" to "Resolved"

As you can see on the screen shot the SLA for first action (SLA-3a3d) is presented as failed (this is wrong) and is still running !?
The time to resolution (SLA-3b16b) may be correct - I didn't calculate in detail.

TTS_20160504a.JPG

TTS_20160504b.JPG

TTS_20160504c.JPG

Please help!
Thanks, Markus

Comments (20)

  1. Tuncay Senturk repo owner

    Hi Markus,

    SLA generation for existing issues and the new ones should act the same. But as far as I understood, SLA generation does not work as expected, but the normal scenario does.
    Is that right?

  2. Markus Hein reporter

    Hi, yes, you are right!

    I tried the same constellation with a new ticket last night (first action in the non working period) and proceeded the next transitions today morning - only the time in "Customer Action" was extremely shortened from 13d to few minutes ;-)
    Everything worked as expected...

  3. Markus Hein reporter

    No !?!?
    The only difference between these 2 issues is, that the first (wrong) one was created under release 5.15.0 with different SLA definitions: The new flag did not exist and we used "TTS - reset SLA" post function in the workflow.
    During the upgrade this post function was deleted in the assigned workflow, and the sla definition was changed...

  4. Markus Hein reporter

    With "No !?!?" I meant, that I tried to generate SLA for this issue, but the values did not change...
    (and I don't understand why)

  5. Markus Hein reporter

    Hi Tuncay,
    we still have troubles with this issue.
    Today the "overdue time" is still running:

    JIRA_20160510b.JPG

    and

    JIRA_20160510f.JPG

    Also the shown dates / times in this "SLA indicator field" are interesting:
    the issue was created on 06.04.2016-17:17:

    JIRA_20160510c.JPG

    The working hours are Mon-Fri 09:00 to 17:00. So, I expect, that the "expected date" should be Mon, 11.04.2016 - 17:00.
    And also interesting: the actual date is correct and the SLA-time should stop at this date/time:
    JIRA_20160510e.JPG

    I do not understand, what's going wrong, here are the definition of this SLA:

    JIRA_20160510g.JPG

    Please help!

  6. Kubilay Karpat

    Hi Markus,
    I tried to reproduce your issue, however it seems to be working as expected.
    Could you please verify in which transition you defined SLA Reset post function?
    We think the problem is there. Also, is this the only issue you get this problem or can you reproduce it for other issues?

  7. Markus Hein reporter

    Hi Kubilay, the "SLA Reset" post function WAS defined in following transitions:

    Customer Action --> New,

    Closed --> Reopened,

    Resolved --> Reopened,

    and at this time there where two status for start or this sla: "New" and "Reopened".

    you can see a picture or the workflow in #182. This configuration worked in TTS until release 5.15.0. with the upgrade to 5.16.0 we changed the configuration because of the new functionality "Only first execution". Now this SLA has only one start status "New" and all "SLA Reset" post function are deleted in all work flow steps.

    It seems, that this is the only issue, where we have the problem. As I wrote on May, 4th the same SLA works correct for new issues (created with release 5.16.0)...

    But nevertheless, we need a solution to stop the SLA for this one issue and we need to correct sla-indicator to "MET", because our customer don't trust the other sla-information at the moment...

    If you need, here is the complete history of the transitions:

    06.04.2016 - 17:17 create (--> New)

    07.04.2016 - 07:26 New --> In Work

    07.04.2016 - 07:27 In Work --> In Work (technical transition)

    07.04.2016 - 11:31 In Work --> Customer Action

    26.04.2016 - 15:07 Customer Action --> New

    26.04.2016 - 15:39 New --> In Work

    27.04.2016 - 11:32 In Work --> Resolved

    The upgrade to 5.16.0 was done on 03.05.2016 about 19:00

    I hope, this can help you...
    Otherwise we can arrange a lync-meeting with screen sharing...

    Thanks, Markus

  8. Markus Hein reporter

    Hi, some additional information: As I wrote, the SLA is still running. The "Time to SLA" - Field is visible in the issue:

    TTS_20160511a.JPG

    The details to that field offers following:

    TTS_20160511b.JPG

    It shows, that as start date the second transition to status New is used, witch is the first "New" in the working hours...
    But then the second "In Work" (26.04.2016 - 15:39 New --> In Work) is ignored...
    Both should not happen...

    Greetings, Markus

  9. Markus Hein reporter

    Hi, now I can reproduce this problem! It's independent from the upgrade but depends on the change of the configuration!
    What have I done (Release 5.16.0):

    I defined 2 SLA's, one for "first action" (with "a" in the description) and a second for the time to resolve (with "b" in the description):

    TTS_20160512b.JPG

    SLA-Demo_3b8d has following paused status:

    TTS_20160512c.JPG

    and a special calendar for this test with a short working time:

    TTS_20160512d.JPG

    and the "TTS - SLA Reset" post function (only for "SLA-Demo_3a1h") was added to the workflow transition "Customer Action" --> "New".
    With this configuration I created a new issue today morning with following transitions within and without the working hours:

    12.05.2016 - 09:33 create (--> New)

    12.05.2016 - 09:34 New --> In Work

    12.05.2016 - 09:35 In Work --> In Work (technical transition)

    now the working hours starts...

    12.05.2016 - 09:41 In Work --> Customer Action

    12.05.2016 - 09:44 Customer Action --> New

    12.05.2016 - 09:46 New --> In Work

    12.05.2016 - 09:48 In Work --> Resolved

    Then I changed the configuration to following:

    TTS_20160512e.JPG

    with following paused status for SLA-Demo_3b8d:

    TTS_20160512f.JPG

    and I removed the TTS-SLA-Reset post function from the workflow and executed the "Report for existing issues" for this issue only (key = ...)

    --> Yep, the SLA-Demo_3a1h is running again!:

    TTS_20160512g.JPG
    TTS_20160512h.JPG

    ... the "SLA Start Date" is the second transition to "New" within the working hours!
    ...and the countdown is still running...
    I an few minutes it will exceed the SLA...

    I hope you can reproduce the problem with this information...

    Thanks, Markus

  10. Tuncay Senturk repo owner

    Hi Markus,

    Thanks for the comprehensive details. We got the same result as well, and soon we will be fixing the problem.

    Thanks
    Tuncay

  11. Kubilay Karpat

    Hi Markus,

    We reproduced your problem and it will be fixed on next release.

    Thanks for your help.
    Kubilay

  12. Tuncay Senturk repo owner

    Hi Markus,

    You can find the fix in the latest applicable version.
    Thanks for the cooperation.

    Cheers

  13. Log in to comment