Email timezones

CATS-540 outlines the need for ensuring email behaviour uses ‘wall time’ when sending emails representing time/dates. This would include the internal ‘selection’ process for determining which shifts will be included in notification emails.

areas of concern

CATS-540 linked to a confluence doc with areas of concern

Upcoming weekly schedule email

This is sent at 4pm on thursdays, and is an email to each manager about ‘filled’ (assigned/approved) shifts for their hospitals for the upcoming week.

On Thur Nov 4, the email would contain shifts with start_time values between Monday 11/8 00:00 through Sunday 11/14 23:59.

The concern is that the shift’s timezones will affect the selection process.

The email is triggered via core:email-upcoming-shifts (run on Thursdays automatically)

core:email-upcoming-shifts * Triggers SendManagersUpcomingShifts command * Dispatches EmailManagerNextWeeksShifts job * Calls EmailManagerNextWeeksShifts action

EmailManagerNextWeeksShifts::email method was modified to use the new SiteShiftRepository::getFilledShiftsForNextCalendarWeek() method.

SiteShiftRepositoryTest::testGetFilledShiftsForNextCalendarWeek demonstrates that changing the timezone of the shift does not affect the querying.
getFilledShiftsForNextCalendarWeek returns the same shift(s) regardless of what timezone the shifts are associated with and regardless of the site’s timezone itself.

Open Shifts 30 Days Out

This is triggered on Sundays as noon, and runs core:email-open-shifts, the signature of SendManagersUpcomingOpenShifts command.

This iterates over each site, and dispatches the ManagerUpcomingOpenShifts job for each site, along with a dayRange value (30 for non banfield sites, 15 for banfield sites)

The job runs EmailManagerUpcomingOpenShifts::email action.

This grabs 2 sets of shifts: * ‘open’ shifts in the coming X days (15 or 30), * ‘open’ shifts for 7 days after that period

These are then passed to mailable WeeklyOpenShiftReport for mailing to site managers.