Appointment validation too strict
The issue
Appointments were added in !1361 (merged). Back then we had a lot of discussions about overlap validation. This was partly fueled by concepts developed within huscy.appointments. We ended up with the following validation:
- appointments belonging to the same participation must not overlap
- appointments using the same resource must not overlap
We do not support the following cases:
- appointments for the same subject but different studies must not overlap (because we did not want to leak information from other studies)
- appointments involving the same conductors must not overlap
- appointments that block a resource only for parts of their total time
- e.g. setup/teardown (see huscy)
- e.g. MRI, walk in the woods, MRI again
- appointments that block two resources at the same time
We had hoped that these limitations can be circumvented in practice. However, within a week after adding the first resource we got reports that users needed overlapping appointments.
Options
I see two options going forward:
- Add more features to cover more use cases
- Shift the responsibility to detect issue to users
Impact on Scheduler
This decision has a big impact on the scheduler. Option (1) requires that the scheduler consults castellum before confirming an appointment booking. This is both unusual (and therefore practically prevents us from using existing software solutions) and requires some way to contact castellum through a firewall (see castellum_scheduler#1 (closed)). Option (2) has none of these issues.
Impact on Resources
On a conceptual level there is not really a big impact on resources. Resources are still relevant to decide whether there are appointment conflicts. This decision is just shifted from automatic validation to users/UI. For example, error messages could be replaced by warnings.
Decision
Given the potential complexity of option (1), we believe option (2) is the way to go: It offers both less complexity and more flexibility. Our job is to provide first-rate tools to users so they get the feedback they need without being limited by it.