shift update ¶

There are two entry points for saving updates to a shift, and this has been somewhat of a transitioning process in the code, so this is a point-in-time document as of Jan 5, 2021.

entry points ¶

schedule/vue ¶

The ‘schedule’ view editing of a shift is vue-based - example URL

https://schedule.indevets.com/schedule/#/schedule/edit/3f891a81-72bb-47d8-890c-8c38e5979e98

This will POST to https://schedule.indevets.com/schedule/#/schedule/update

Which goes to App\Http\Controllers\Ajax\ScheduleController::update()

Key point is

    $shift = (new AdminShiftRepository())->updateAndAssignShift($user, $shiftInfo);
    ...
    // this calls to AdminShiftRepository::update which is...

    public function update(User $user, array $info): Shift
    {
        // permission checks would be here, although
        // we're in 'admin' repo, so generally shouldn't
        // need much - 'admin' is god mode...
        // from 'info' - grab the shift
        $shift = Shift::find($info['id']);
        $shiftService = new ShiftService();

        $shift = $shiftService->updateWithoutRequest($shift, $info, $user);
        $shift->save();

        return $shift;
    }

shift/blade ¶

From ‘assigned’ or ‘open’ link we get to https://schedule.indevets.com/indevets/assigned/shifts/cd927637-9af0-4e84-98db-ffaefa2808e6/edit#/

The ‘update code’ button PATCHes to https://schedule.indevets.com/indevets/shifts/cd927637-9af0-4e84-98db-ffaefa2808e6/edit#/

which points to \App\Http\Controllers\Indevets\ShiftController@update

            $user = $request->user();
            $service = new ShiftService();
            $service->update($request, $shift, $user);

ShiftService update() was modified to take data from ‘request’ and then pass to updateWithRequest, which the schedule/vue entry point eventually gets to..

tldr - both paths lead to updateWithoutRequest

The ‘withoutRequest’ indicated we’re not relying on an HTTP Request object to be passed in.

processing in updateWithoutRequest ¶

We have a $data array of incoming data to change - start date/time - end date/time - position id - notes

IF employee id or site_id exist, exception thrown - these are generally prevented in UI - changing a site should be handled by canceling and recreating. changing an employee should be an explicit ‘unassign’ then ‘reassign’.

These may be accommodated in this update() call in a later code change.

We start a DB transaction.

we generate $deltaChange by passing in the existing $shift and the new set of proposed changes (in $object, based on incoming $data)

$deltaChanges is an array with keys

employee
site
start_time
end_time
position
notes

Any of these keys will be set with ‘previous’ and ‘new’ values if the value was changed.

We then call ‘fill’ on the shift with new data, then save the updated shift.

We then sync ‘incentive’ changes as well.

NOTE - currently, changes to incentives will not be explicitly noted, although they’ll show up as ‘notes’ changes for now.

The $original array has the original data intact.

We process the $deltaChanges in to a text version and store in $note variable, then store this as a ‘shiftActivity’ (along with other data about what changed) and a general ‘activity’ in activity log (shiftActivity will go away at some point and be normalized in activity log)

We then commit the DB transaction.

THEN… update info in WIW if there’s a need to.

Assignment and unassignement calls will throw ShiftAssigned and ShiftUnassigned events.

NOTE - THIS MAY NOT BE WHAT IS WANTED!!!

The ShiftAssigned event listener will send email notification to the vet, whether assigned by admin or self-assigned.

The ShiftUnassigned event listener will send email notification to the vet, whether assigned by admin or self-assigned.

At the END of the updateWithoutRequest() process, a ShiftDetailsChanged() event is thrown, which is caught and currently will trigger a recalculation of timesheet values for the affected shift.s

The ShiftDetailsChanged() event listener is being extended to also send ‘shift details changed’ emails to both the hospital managers and the updated shift doctor of record.

OPEN QUESTIONS

a) when a shift is ‘assigned’ (self assigned or admin assigned), the dr gets an email saying “you have a new shift assignment”. This is ALSO happening when the shift is ‘approved’.
Perhaps this should only be sent to hospitals when ‘approved’?
Or drs should only get this email when the shift is ‘approved’? But then anyone taking a shift in vetportal may potentially not get an email, as they can clock in when it’s ‘assigned’.

b) whenever any ‘change’ happens, the ‘assign’ and ‘unassign’ setting logic happens, which may trigger those emails, and then a ‘details changed’ email is sent separately. i’m already anticipating people complaining about this, but do not have a plan in place yet to track all the various paths as to when someone should or should not get emails. trying to determine if/when to combine various bits of these is complex. if we were to prohibit the ‘edit’ form from ever allowing an ‘employee’ change (like we prevent hospital changes), that would mean that changing/assigning/unassigning the dr would be a separate step from changing other shift details. This might result in hospitals getting ‘duplicate’ emails… ?

Unassign dr (dr and hospital get notified)
Change details (hospital gets notified)
Assign new dr (hospital gets notified and new dr is notified of assignment, but not ‘changes’).

thoughts???