Grid view hides double-scheduling

[andypiper]

Currently, it is possible to to schedule more than one talk into a single session slot, in the same room.

The list / table view will show both talks, but in grid view, only the first scheduled talk is shown.

This can make it difficult for organisers to notice accidental double-bookings (we had that issue for one session at OggCamp this weekend)

[iansltx]

Would it be useful to enforce "no more than one talk starting at the same time in the same track" as a constraint when editing/creating a talk at the API level as a way to solve this? I can check our database to see how many talks would violate this constraint; I'm betting the ones that do (when tracks are specified) are mistakes, similar to what you're mentioning here.

And yes, I have a feeling that dealing with that would be easier than HTML table-wrangling :)

[e3betht]

Do we really need to enforce this in the code? Does this break our display? I feel like we should not be enforcing things that aren’t absolutely necessary. If someone has two talks in the same track at the same time, that seems like their preference and we should leave that alone. Perhaps they are using subject matter tracks rather than room location tracks and they have two talks in the mental health track at the same time. I don’t see why we shouldn’t allow that flexibility. If they enter something wrong, they will see it when they view the schedule.

[iansltx]

@e3betht The current grid view, when displaying a multi-track conference, flat-out doesn't show more than one talk per track per time slot. If you don't assign a track at all that's not a problem, but that's not the scenario you (or @andypiper) are presenting.

As for tracks-as-themes, that seems to be more the province of tags/categories than the thing we call a track, which is centered around giving attendees visibility on where to find the talk physically. Again, we need to look through the database to confirm how folks are using the system exactly, but the topic-based use case sounds like we'd want a M:M tagging system expressly for that purpose. Tracks are technically implemented as M:M, but literally no one uses the M:M capability (probably partially because it isn't in the UI)...I say literally because that's what I found when querying the production database yesterday :)

In any event, I'll run the numbers on same-slot same-conference same-track talks to see if/how that data looks.