You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to check schedules for conflicts, and there are different kinds of conflicts that may have different impacts. Once the rule system exists, users may want to change the importance of conflict rules as fits their event.
BLOCK SCHEDULING: check and forbid while scheduling. This should be very rarely used, as forbidding a scheduling move instead of just flagging it is jarring for the user.
BLOCK RELEASE: check whenever appropriate, but block a release.
WARN: check whenever appropriate, show warnings, but permit a release.
IGNORE: don't check at all.
All checks except for blocking checks should run asynchronously to avoid delaying scheduling moves.
Known conflict rules
A room may only have one talk at a time
A room must be available
All speakers must be available
All speakers may only have one talk at a time
Future conflict rules
We may want to include attendance requests, room size/interest rate, scheduled breaks, and maybe even user defined features in our conflict rule system, which is one of the reasons it needs to be generic.
As long as we only talk about named rules we know about, we may store them by name. We could have a (later on configurable) conflict ruleset as a JSON field in our event's settings:
I'm not convinced any longer that arbitrary conflict rules would be a good idea, to be honest. I can't imagine a case where the result would make up for the complexity and UX problems.
I'd be up for adding a plugin API to add warnings from plugins, and/or different severities, once/if the need arises. (If it does for you, please get in touch so we can talk about requirements and a clean API design!)