Challenges with the `schedule` table for organizations in the USA

Technical
15

Hey folks,

Skyler and I have produced a formal proposal which we plan to put to the committee at the next meeting.

The full technical details of the proposal are contained in that document. In summary, the proposal does the following:

  • Adds two new fields to the service object: service.events and service.opening_hours. These both consist of lists/arrays of schedules, but have specific semantics. As a result of this, the service.schedules field will be deprecated (i.e. data using it is still valid, but we recommend you use one of the other fields instead).
  • Adds some fields to the schedule object which make it a bit friendlier to use.
    • schedule.group acts as a label to group different schedule objects together so that you know they belong together (e.g. to differentiate Week and Weekend schedules across “normal” hours and “holiday” hours whereas before you could accidentally pair a Normal Weekday schedule with a Holiday Weekend schedule).
    • schedule.shortcode will be able to contain a value from a codelist/enumerated list representing some common values for schedules e.g. 9-to-5.

This doesn’t replace the need to rethink how schedules work for future MAJOR versions. The thinking that Skyler has done here is invaluable and we’ll be capturing it for future iterating.

1 Like
Standing Technical Meetups