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
- 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().
- Configure an SLA goal that contains iqlFunction(), 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.
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
- 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.
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
- 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.
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
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
Resolution | New: Fixed [ 1 ] | |
Status | Original: Waiting for Release [ 12075 ] | New: Closed [ 6 ] |
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. |
Fix Version/s | New: 10.2.0 [ 109023 ] |
Status | Original: In Progress [ 3 ] | New: Waiting for Release [ 12075 ] |
Assignee | New: Bartosz Ornatowski [ bornatowski ] |
Status | Original: Short Term Backlog [ 12074 ] | New: In Progress [ 3 ] |
Labels | Original: lts10 lts10nth | New: lts10nth |
Sprint | New: LTS Sprint [ 7234 ] |
Labels | Original: lts10 | New: lts10 lts10nth |
Labels | New: lts10 |