Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add conflict rules for scheduling #214

Closed
rixx opened this issue Nov 3, 2017 · 2 comments
Closed

Add conflict rules for scheduling #214

rixx opened this issue Nov 3, 2017 · 2 comments
Labels
size: big or difficult Will take a long time and/or a lot of skill stage: up for grabs type: feature

Comments

@rixx
Copy link
Member

rixx commented Nov 3, 2017

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.

Features

Impact levels

  • 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.

Checking styles

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.

Implementation

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:

{
   rules: [
        room_conflict: {
            severity: block_release,
            check_async: true
        }
    ]
}
@fflorent
Copy link

fflorent commented Mar 2, 2019

For what it is worth, I made a view in a separate DB that reveals speakers conflicts (a workaround until we have a proper conflict manager tool):

USE pretalx_custom_views;

CREATE VIEW conf_with_speaker_and_timeslots 
AS 
SELECT st.start, st.end, pu.id as user_id, pu.name as username, ss.id as conf_id, ss.title as conf_title 
FROM pretalx.schedule_talkslot st JOIN pretalx.submission_submission_speakers ssp ON st.submission_id=ssp.submission_id 
  JOIN pretalx.person_user pu ON ssp.user_id=pu.id
  JOIN pretalx.submission_submission ss ON ss.id=st.submission_id
WHERE st.schedule_id=(select distinct MAX(schedule_id) FROM pretalx.schedule_talkslot);

CREATE VIEW speakers_conflicts 
AS
SELECT l.username, l.start as left_start, l.end as left_end, l.conf_title as left_conf_title, r.start as right_start, r.end as right_end, r.conf_title as right_conf_title 
FROM pretalx_custom_views.conf_with_speaker_and_timeslots l JOIN pretalx_custom_views.conf_with_speaker_and_timeslots r ON r.user_id=l.user_id 
WHERE r.conf_id<>l.conf_id AND ((r.start > l.start AND r.start < l.end) OR (r.end > l.start AND r.end < l.end));

In order to view conflicts in MySQL:

select * from pretalx_custom_views.speakers_conflicts;

Hope it can help. Reviews welcome.

Cheers,
Florent

@rixx
Copy link
Member Author

rixx commented Nov 9, 2019

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!)

@rixx rixx closed this as completed Nov 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size: big or difficult Will take a long time and/or a lot of skill stage: up for grabs type: feature
Projects
None yet
Development

No branches or pull requests

2 participants