search

openactive / open-booking-api

Repository for the Open Booking API specification
Other
2 stars 3 forks source link

`minimumContiguousBookingDuration` and `maximumContiguousBookingDuration` #219

Open nickevansuk opened 2 years ago

nickevansuk commented 2 years ago

Proposer

On behalf of School Space and GLL

Use Case

Currently some Open Booking API implementations make an implicit assumption that the duration of a single Slot is the same granularity as the length of the overall duration that may be booked. For example, if a Slot is 1 hour, the assumption is that bookings may be made for 1 hour, 2 hours, 3 hours, etc.

There are two use cases that this assumption does not support:

  1. In leisure operators it is sometimes the case that a single user is limited in what they can book. Hence they may only be able to book e.g. a maximum of 2 hours
  2. Scenarios where it is possible to book for durations with a higher granularity than the minimum Slot duration. E.g. 1 hour, 1.25 hours, 1.5 hours etc.

Proposal

Two additional properties on FacilityUse and IndividualFacilityUse:

Additionally to allow the duration of the booking to be extended incrementally, the specified constraint applies to all Orders with the same customer.email (or within the same Customer Account, if appropriate).

Examples

Where Slot duration is PT15M:

nathansalter commented 2 years ago

Just a quick comment

In leisure operators it is sometimes the case that a single user is limited in what they can book

This feels much more like a validation than something you could model in the FacilityUse/IndividualFacilityUse, as at the time at which you're pulling the RPDE feed you don't know the customer details yet.

Also it should probably be at least rather than more than for the minimum time, otherwise you couldn't have min & max as the same value (which although would be baffling as to why you'd want to, does make sense for completeness).

nickevansuk commented 2 years ago

Great spot, have fixed at least above.

Also agreed it could certainly be implemented as validation in terms of C1/C2 - thinking about potential user interfaces that allow a number of slots to be booked (e.g. a "+ 15min" button) it would likely be good to know up-front what the limit is?

nathansalter commented 2 years ago

it would likely be good to know up-front what the limit is?

Completely agree, but where you mention the customer.email, that implies that it could be different per customer. Is this the case? If so, we'd need to have a separate API to retrieve that information, as it doesn't fit in any of the existing APIs (of which I am aware)

nickevansuk commented 2 years ago

Ah sorry only that it's contiguous per-customer.

Scenario:

  1. minimumContiguousBookingDuration is PT1H, and each Slot has duration PT15M
  2. Jane makes a block booking for 1hr at 2pm Wednesday for 4 weeks (via C1, C2, B with an Order containing 16 OrderItems)
  3. Jane realises she actually wants to extend the block booking by 15 mins (via C1, C2, B with an Order containing 4 OrderItems).

Without existing Orders for the same customer.email included in the constraint, it is not possible for a new Order to be created just for the extra 15 min slot (as 15 mins is below the PT1H total). With this considered, she is able to create a separate Order for the additional 15 min slot without issue.

nickevansuk commented 2 years ago

Additionally, as an aside: given the likely repetition of facilityUse within the response for block-bookings in general, we might also want to allow the full facilityUse to be included the first time it is referenced, and then an @id reference used after that?

nathansalter commented 2 years ago

As mentioned on the technical call, it might be reasonable to add a beta:bookingGroup property to the OrderItem when submitting the order in this manner to make it easier for the booking system to detect which slots are supposed to be together when determining min/max duration of a group of slots. Advice would be to use a UUID