Transitioning of linked issue (Service Desk) is not stopping SLA timer
Hi,
we are struggling with Service Desk SLAs when using "Write field in linked issues". In the past we had a similar issue #33. This time the problem is manifested when we transition a linked service desk issue (either through Status or Transition virtual fields) which has a SLA stopping condition that is the target status of the transition (Entered Status: XXX).
When the transition is executed manually through the UI the SLA stops. When using the toolbox post function the SLA is not stopping.
Haven't found a workaround yet for this.
Cheers, Aggelos
Comments (19)
-
repo owner -
reporter - attached Edit_—_HST_Service_Desk_Generic_Incident_Workflow_-_JIRA_Service_Desk.png
- attached Transition__Done_-_JIRA_Service_Desk.png
- attached SLAs_-_Service_Desk.png
When a Field Service issue is done the "Field Service Done" transition is executed on the Service Desk ticket.
The Time to Resolution SLA definition for the SD ticket is also attached here.
Cheers, A.
-
repo owner Hi Aggelos,
I have tried a similar configuration in JIRA 7.2.3, JSD 3.3.2 and JIRA Workflow Toolbox 2.2.33, and it works as expected, i.e., the SLA Stops when transition is executed.
I post some screenshots:
Which versions are you using?
-
reporter JSD 3.3.2 ? is is compatible with JIRA 7.2.3 ?
Our tests are with JSD 3.2.6 and JIRA 7.2.6 and 3.2.7 and 7.2.7.
-
reporter It seems the problem is caused by the delayed execution. Can you please test it?
-
repo owner You are right, Aggelos. The problem appears with delayed execution. I will investigate it.
Why do you need to use delayed execution? There is always a way to avoid delayed execution. Please, give me the details, and I will tell you how to do it.
-
reporter I general we use the delayed execution to avoid situations where the target transition has some kind of validators that might not allow the transition to execute unless the source issue transition is completed. Isn't this the reason delayed execution was implemented in the first place?
-
repo owner It should be used when there is a condition or validation in the transition that will be automatically executed that requires the current issue to be in the destination status of the transition that is being executed manually.
It's always better to use delayed execution when it's really necessary, because it usually results in changes not being reflected immediately in the UI, and sometimes requires a browser refresh.
Please, try avoiding delayed execution in this case.
-
reporter I believe the use case you describe is quite common, no?
SD project Status: In Progress Transition "Resolve" (In Progress => Resolved) with Condition: All linked issues (Blocked by) in status Resolved
FS project: Status: In Progress Transition "Done" (In Progress -> Resolved) with Post Function: Transition linked issues (blocks) Execute "Resolve"
This post function has to fire using a delayed execution to work, right? Is there any other way?
-
repo owner Yes, it normally requires delayed execution, but we can use non-delayed execution by setting Filtering by field values parameter with the following boolean expression:
count(filterByResolution(linkedIssues("is blocked by") EXCEPT issueKeysToIssueList(%{00015}), "")) = 0
where %{00015} is field code for Issue key.
You should also set Skip validation when in the validator like shown in the screenshot:
If you are using a condition instead of a validator, please attach a screenshot of the configuration, and I will tell you the changes to do.
By the way, you can also remove your first post-function (the one for setting Ephemeral string 1), and input the target status directly in Write field on linked issues or subtasks post-function.
-
reporter The classic condition is similar to the following one:
Nice trick with the validator. For customer using them we'll definitely going to apply it.
For the ephemeral thanks, the workflow was created the early days when we had no option to set the value directly ;)
Lastly, could you please elaborate on the filter? Where we suppose to add it?
-
repo owner You should set parameter "Filtering by field values" in "Write field on linked issues or subtasks" post-function like it's showed in the screenshot:
You should replace your current "Condition on linked issues" with "Boolean condition with math, date-time or text-string terms" condition using the following boolean expression:
isJwtTriggeredTransition() OR count(filterByStatus(linkedIssues("is blocked by"), "Pending Closure, Closed")) = count(linkedIssues("is blocked by"))
-
reporter I understand the condition part. What's the purpose of the filtering expression?
-
repo owner Since the condition now doesn't work when the transition is being automatically executed by a post-function, we add a boolean expression to the post-function in order to filter issues to be transitioned if they don't have all the blocking issues with resolution set (actually all the blocking issues except current issue, which has not yet been resolved), which in practice should be equivalent to the condition which is being bypassed.
-
reporter So to summarize:
- We replace delayed execution with normal execution (status or transition) on "write field on linked issues" post function
- The "filter by field values" is applied in the post-function "write field on linked issues" in order to prevent execution on issues which have blocking linked issues.
- When we use validators in target issues to be transitioned we have to check the "Skip validation" option
- When we use conditions in target issues to be transitioned we have to replace "Condition on linked issues" with "Boolean condition" using the expressions similar to the one supplied above.
-
repo owner That's right. An you should use "Issue status" or "Transition issue" virtual fields in target field parameter in "Write field on linked issues or subtasks" post-function.
-
reporter Just updated the comment above. You were faster!
Thanks a lot. Cheers/A.
-
repo owner It's not possible to make delayed execution to trigger the SLA, since it runs in another thread.
Please, close this issue if the alternative solution provided works correctly for you.
-
repo owner - changed status to resolved
- Log in to comment
Hi Aggelos,
Can you please attach a screenshot with the SLA stopping condition? I would like to see the exact configuration you are using in order to reproduce the problem.