Notifications

347 views

Description

If someone is On-Call, it is expected to not include that as working time in the Resource Management calendar.

Before Kingston Patch 8, if someone is covering for On-Call, the resource's existing schedule is wiped out and shows the on call hours as the only available/working hours. Covering on-call should not impact existing schedule or show as available hours. If both On-Call Scheduling and Resource Management are used, creating a schedule override for a user by using the On-Call Calendar to specify a user with time off, or as providing on-call coverage for another user, then that user will no longer display properly on the Resource Availability timeline, and may not appear at all.

- The reason this happens is the system generates a new Schedule record for the user for the On-Call schedule overrides.
- The new schedule is associated to the user by both name and by the schedule reference in the sys_user record.
- The new schedule takes precedence in calculating the Resource Availability timeline.
- The default creation of the new schedule does not contain any schedule entries for the user's availability, only the overrides, and the most common result is the user is not included as an available resource in the timeline.

ROTA uses sys_user.schedule to store time-off information, which conflicts with Field Service using the same field as agent work schedule. ROTA creates a schedule object when a time-off is created and stores it as a span in that object. The reference to this new schedule is in sys_user.schedule which conflicts with the way other applications may use this field.
The spans ROTA stores in this new schedule are all exclusions but they are stored as "Time-offs" type. Currently the platform calendar considers user as unavailable only if the time span is type is "Excluded", and other type of the spans are considered as available time span.
ROTA has business logic to explicitly exclude these time-offs but other applications will not have the same and would consider them as inclusions.

 

Steps to Reproduce

 

1) Activate the On-Call Scheduling and Resource Management plugins.

2) In On-Call Scheduling > My Group Schedules module, create a new Network rota for the out-of-box Network group; include all five members, and create a single roster.

3) In Resource Management > Resource Plans > All module, create a new group resource plan for the Network group; click the View Resource Availability related link to display the Resource Availability schedule page. Note how all five group members are shown.

4) In On-Call Scheduling > On-Call Calendars module, bring up the Network group in the Monthly view, double-click on one of the days of the month, and create a schedule override record by selecting "Provide on-call coverage for another roster member".

5) Navigate to the resource plan you created in step 3, and click the View Resource Availability related link to display the Resource Availability schedule page. Note how only four group members are now shown; the user you specified for the on-call coverage no longer appears on the Resource Console.

Workaround

Please review the Fixed In section to determine the latest available patch your instance can be upgraded to. The workaround described below was adopted before the fix was available.

  • Resource Management requires a schedule, and a default Resource Management Schedule is included in the plugin.  
  • The schedule used for Resource Management is specified in a system property, and can be changed.
  • If you include the Resource Management schedule as a child schedule on the generated On-Call user schedule, both the On-Call Calendar and the Resource Availability timeline will work.
  • The following script is an example of a suggested after-insert-update business rule script for the cmn_schedule table; it will create the necessary child schedule association automatically.

 

check_if_RMCS_needed();

function check_if_RMCS_needed() {
// Check if a Resource Management Schedule is specified in the system property
var RMSschedname = gs.getProperty('com.snc.resource_management.default_schedule');
if (RMSschedname.nil()) {
return;
}

// Check if the specified Resource Management Schedule exists
var RMSsched = new GlideRecord('cmn_schedule');
RMSsched.addQuery('name','=',RMSschedname);
RMSsched.query();
if (!RMSsched.next()) {
return;
}

// Check for a sys_user record where this schedule is specified and the names match
var userRec = new GlideRecord('sys_user');
userRec.addQuery('schedule','=',current.sys_id.toString());
userRec.addQuery('name','=',current.name);
userRec.query();
if (!userRec.next()) {
return;
}

// Check to see if a child schedule already exists
var childRec = new GlideRecord('cmn_other_schedule');
childRec.addQuery('child_schedule','=',RMSsched.sys_id.toString());
childRec.addQuery('schedule','=',current.sys_id.toString());
childRec.addQuery('type','=','include');
childRec.query()
if (childRec.next()) {
return;
}

// Add the necessary child schedule to correct for PRB637082
createResourceMgmtChildSched(RMSsched.sys_id.toString(),current.sys_id.toString());

}

function createResourceMgmtChildSched(rms_sched,the_sched) {
var addRMSgr = new GlideRecord('cmn_other_schedule');
addRMSgr.initialize();
addRMSgr.child_schedule = rms_sched;
addRMSgr.schedule = the_sched;
addRMSgr.type = 'include';
addRMSgr.insert();
}

 


Related Problem: PRB684820

Seen In

Fuji Patch 2 Hot Fix 1
Geneva Patch 5
Geneva Patch 7

Fixed In

Kingston Patch 8
London

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2018-10-17 06:19:18
Published:2018-10-17