Hours of Operation Refactor

[Kyle Huckins]

While working on lp1396764, I encountered some unexpected challenges relating to the design of the Org Unit Hours of Operation object. At the moment, its fields are structured like this:

<fields oils_persist:primary="id">
    <field name="dow_0_close" />
    <field name="dow_0_open" />
    <field name="dow_1_close" />
    <field name="dow_1_open" />
    <field name="dow_2_close" />
    <field name="dow_2_open" />
    <field name="dow_3_close" />
    <field name="dow_3_open" />
    <field name="dow_4_close" />
    <field name="dow_4_open" />
    <field name="dow_5_close" />
    <field name="dow_5_open" />
    <field name="dow_6_close" />
    <field name="dow_6_open" />
    <field name="id" reporter:datatype="id" />
    <field name="org_unit" oils_persist:virtual="true" reporter:datatype="org_unit"/>
</fields>

This ends up with a lot of bloat, especially in cases where we want to add fields to the Hours of Operation. The OPAC UI displaying hours of operation has to go through each day of the week manually, and the Angular UI to edit them is also fairly clunky in how it iterates through each day of the week.

I'd propose changing it over to something a bit more simple and workable:
<fields oil persist:primary="id">
    <field name="open">
    <field name="close">
    <field name="day_of_week">
    <field name="id">
    <field name="org_unit">
</fields>

When referencing an Org Unit's Hours of Operation, we would grab all 'auhoo' objects referencing the chosen Org Unit, listed out by day of the week in an order based on the "open" time. This also eases the ability to add additional fields to the object, such as notes (mentioned as desired in lp1396764), without causing further bloat to the object.

The challenge to this refactor would be that every part of the codebase that references the Org Unit Hours of Operation would need to be changed significantly to move over to this version of the object. Beyond the UI portions, there are references in the Perl, and significant sql edits would need to be made as well.

[Josh Stompro (u-launchpad-stompro-org)]

Would this design allow for there to be multiple entries for each day? Making the split hours function much easier? And support 3+ open chunks in a day?

Would this make it easier to mesh with the closed dates feature also?

I've often wished for there to be a set of DB functions to make the open/closed status of an org easier to access in custom scripts. I think this design change would make that easier to do.

Things like this, that would take into account open days and set closed holidays from the closed days editor.
OrgOpenNow(102); --bool is org open right now
OrgOpenToday(102); --bool is org open today at any time.
OrgOpenOn(102,'2022-02-11'::timestamp); --bool, is org open on specified date or timesamp.
OrgNextOpen(102); --Next open timestamp for org
OrgNextClosed(102); --When does the org close next, useful for same day/in library use hourly checkouts being due at next closing time.
OrgNextOpenDays(102, 7); --Return date equal to 7 open days from now for org unit. For hold shelf time for instance. Or for due dates for items.

It would be great to have any easy way to only run a cron job if a location is open. Or to be able to add open date and time logic to action_trigger processing.

Anyway, +1 for me

[Kyle Huckins (khuckins)]

Noting that, if merged, the workaround fix in bug 1396764 adding Note fields would translate to a single Note field here

[Michele Morgan (mmorgan)]

The workaround Bug 1396764 has been merged.

Some comments from 1396764 to consider when addressing this bug:

- New Note fields need to translate
- Make display of Note field optional
- Support mid-day closing period
- Support schedules that differ from week to week
- Support summer vs. winter schedules
- Support curbside hours