Batch approve shift change requests

A request came in to provide scheduling managers the ability to batch approve shift change requests. This would simplify their workflow while giving them time back which is otherwise spent reviewing each individual request. However, when working through this workflow, there were a couple of gotchas that led to the current implementation.

When the user selects records in UI and his the batch approve button, they send a payload of ShiftChange ids to an api endpoint /api/iv/admin/batch-approve-shift-change-requests. This engages the ShiftChangeController batchUpdate function which processes the work in 3 primary stages:

Fetch and update shift

The first piece to the puzzle includes an iteration over the shift change requests and grabbing the related shift for each record. An “old” copy of the shift is created before any changes are made. The original incentives are also grabbed before any updates are performed. The shift is then updated along with their its respective incentives. If successful, the old and updated shift is returned and the shift change request is added to the processed key in the final response. If failed, null is returned and the shift change request is added to the failed in the final response.

Further information:

When a shift is updated the following event is called:

event(new ShiftDetailsChanged($shift, $oldShift, $user, $deltaChanges, true));

Shy of seeing updates to timesheets, I am not entirely certain what is happening here. More documentation around this should be written up.

Notify managers of changes

If the update is successful, we move on to notifying the managers. This sends an email with the old information along with the updated values. If the email fails to send, the function for the notification logic returns false and an error is added to the error key in the final response. If the function returns true, or in other words, everything was sent properly, no further action is taken.

Notify employee of changes

If the update is successful, we move on to notifying the employees. This sends an email with the old information along with the updated values. If the email fails to send, the function for the notification logic returns false and an error is added to the error key in the final response. If the function returns true, or in other words, everything was sent properly, no further action is taken.

Final Response

Once each shift request is processed, the following is sent in a json response:

$results = [
    'shiftChanges' => $shiftChanges,
    'processed' => $processed,
    'failed' => $failed,
    'notification_errors' => $notification_errors,
];

The shift changes are the remaining shift change requests that have not been processed. These will be passed back to the UI for further review.

Work to be done

In the future, we should really have a better way of handling email errors. While this works for now, it is possible that something will get missed for the scheduling managers.