The TaskSLACalculator provides a function to calculate retroactive pause time when a new SLA is attached to a task. To do this, it has to rebuild the history of the task the SLA is being created for so that the amount of pause time can be determined.

The history is generated by making a call to the "generate" method of the server side Java class "HistorySet" (accessed from Javascript by the GlideScriptable name "GlideHistorySet").

The constructor used by the script include to instantiate an HistorySet object is the one where a reference to a GlideRecord is passed as the only parameter and, in the case of the TaskSLAController, this GlideRecord is a reference to "current".

Problems can then occur because the HistorySet class uses the HistorySetLoader class, which contains the destructive method "getDisplayValue". This method makes changes to the state of the GlideRecord object passed to it by HistorySet, which is a pointer to current for the TaskSLAController.

This means that after the "_rebuildHistory" function in TaskSLAController has been called, there is a possibility that the state of the variable "this.taskGR" (which is a pointer to current) will have changed and it is this state that the SLA conditions are tested against, and can produce unpredictable results in the SLAs pausing/stopping.

Steps to Reproduce

  1. Ensure that you have the 2011 SLA engine enabled and that the property Compute prior SLA pause time for new, retroactive SLAs (2011 SLA engine only) is checked.
  2. Create two SLAs with start conditions that match with assignment group being set to different values and that have a pause condition of [Assigned to] is [not empty].
  3. Create an incident and set the Assignment group to match with one of your SLA Definitions. Enter a value in Assigned to and save.
  4. You should find that your incident has a single Task SLA record that is paused. This is correct because it has matched with the assignment group, but then immediately paused because the Assigned to is set to not empty.
  5. Update the incident to change the assignment group to the group that is specified in the start condition of your second SLA definition, and also clear the Assigned to field and save.
  6. You should find that the original Task SLA is now cancelled. This is correct because the start conditions no longer match. You will also see that your second SLA definition is now attached to the incident as a task SLA record (which is correct because of the assignment group change). However, it will be paused, which is incorrect, because the Assigned to field is empty.


- In Berlin:

Modify the Script Include: TaskSLAController function: _rebuildHistory changing code from:

var hs = new Packages.com.glide.audit.HistorySet(taskGR);


var hs = new Packages.com.glide.audit.HistorySet(taskGR.getRecordClassName(), taskGR.getUniqueValue());


- In Calgary:

Modify the Script Include: TaskSLAController function: _rebuildHistory changing code from:

var hs = new GlideHistorySet(taskGR);


var hs = new GlideHistorySet(taskGR.getRecordClassName(), taskGR.getUniqueValue());


Related Problem: PRB582222

Seen In

Aspen Patch 2 Hot Fix 5
Berlin Patch 12
Berlin Patch 4
Berlin Patch 5 Hot Fix 1
Berlin Patch 6
Berlin Patch 7
Berlin Patch 7 Hot Fix 1
Berlin Patch 8
Berlin Patch 8 Hot Fix 1
Calgary Patch 1
Calgary Patch 2
Calgary Patch 2 Hot Fix 4
Calgary Patch 2 Hot Fix 5
Calgary Patch 3
Calgary Patch 3 Hot Fix 1
Calgary Patch 4
Calgary Patch 7 Hot Fix 2
Dublin EA 1
Dublin EA 8
Dublin Patch 1
Dublin Patch 3 Hot Fix 1
Dublin Patch 4
Dublin Patch 7 Hot FIx 4
Dublin Patch 7 Hot Fix 5
Eureka Patch 11 Hot Fix 2
Eureka Patch 5
Eureka Patch 6

Fixed In

Calgary Patch 6
Dublin EA 0

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2016-02-01 03:52:39