Skip to content

vet portal

misc

state for vet portal

User ‘tab’ and ‘active date’ and ‘filters’ for vue components are now stored in local storage, allowing for reloading and ‘pick up where you left off’ when coming back to the app.

When ‘logout’ is clicked, ‘active date’ and ‘tab’ values are cleared, to provide someone a ‘fresh’ date/tab on the next login.

If someone leaves or closes the browser, and comes back, local state will be checked and date/tab/filters restored.

If someone logs in again, even without logging out, their view will be set to ‘dashboard’. Other state can be reset if needed in future. This is done by passing in a ‘recentLogin’ flag from to the view, which passes to vet-portal-shell vue components, and inspected on init() method.

Set/get methods are stored in VetPortalMixin.js

visible filtering

We’re going to exclude any shifts assigned to the current user from visual filtering. I may have a 12 hour “ER” shift taken on May 18, but when looking at May 18, my filters might be set for < 12 hours or only “Surgery”, or some other combination that would normally be filtered out. If the shift is assigned to the user, it will be shown, even if it doesn’t match the ‘distance’, ‘position’ or ‘duration’ filters.

timesheet data

when data is pulled down for vet portal - for employee schedule view - we will include a set of summarized clock in/out data.

Also, each shift will also need to include related clock in/out data and notes. We’ll look to bring down both the user supplied data and the ‘final’ data.

ShiftRepository::addShiftTimesRaw will add shift_time (initial) clockin/out, but also timesheetentry related in/out/notes/final values. ts_final_minutes will be included for each shift as well - number of minutes for this shift. This is coming from the timesheet entry - if for some reason someone clocked in/out of a date where there was no timesheet period defined yet, this may come back as null until the timesheet period is created (the creation will also update/recalculate related shift/times as needed). A fallback could be done to use the shift_time user_clock_in out in the addShiftTimesRaw SQL - this may be something to explore.

The javascript will need to scan each employee shift and calculate aggregate times based on the ts_final_minutes value on the shift. JS code/tests are in development for this.