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

Event in same room can overlap #27

Closed
kcits opened this issue Jan 5, 2015 · 5 comments
Closed

Event in same room can overlap #27

kcits opened this issue Jan 5, 2015 · 5 comments
Assignees
Milestone

Comments

@kcits
Copy link
Contributor

kcits commented Jan 5, 2015

I just realized rooms can be over-booked. Is there a setting to change this? Resources can not be over-booked if Unique is checked but rooms can.

@neokoenig
Copy link
Owner

there's no specific setting at the moment - it should be do-able, but it does mean you'd need to do not only an availability check for the room between DateA - DateB, but also recheck the (unique) bookable resources, as they're also dependent on that DateTime span.

@kcits
Copy link
Contributor Author

kcits commented Jan 6, 2015

Would you recommend doing a check at the date/time picking or upon attempted save of the event?

@neokoenig
Copy link
Owner

I guess it depends how strict we want to be. You could enforce checks:

  1. when any date, or concurrent resource is changed (i.e via ajax)
  2. Just when the resource or room is initially selected via JS
  3. Serverside on save

I've (almost) deliberately made it so that there are ways around some of the checks - this was never really designed as something where concurrency would actually be a massive issue: the JS stuff is just there for convenience - for instance, you can technically disable the JS and there's no serverside checks for concurrency at the moment.

I've had some people use it as using the 'all day' events as markers, i.e So and so festival 1st Oct - 15th Oct, then having individual events which fall within that festival event as the actual main bookings. So in their circumstance, concurrency wouldn't work (assuming you were checking "all day" events).

So really, not only is there potentially a few different ways to 'enforce' concurrency, but (perfectly valid) reasons for concurrency...

So in sum, what might be the best thing to do is to do a 'warning' notice via JS when the date range is selected, saying, 'oh, by the way, this is apparently going on at the same time' rather than actually enforcing it: that would probably be the most useful.

@kcits
Copy link
Contributor Author

kcits commented Jan 7, 2015

Thinking through your process I prefer the 'warning' notice of 'oh, by the way, this is apparently going on at the same time' approach.

With regards to all day events, I can understand both sides, but lean towards all day events being used like a marker and not causing the hard rule of unable to schedule multiple events for that all day event. Using the 'warning' would be acceptable in the 'all day' instance.

@neokoenig neokoenig self-assigned this Jan 22, 2015
@neokoenig neokoenig added this to the 1.2 milestone Jan 22, 2015
@neokoenig
Copy link
Owner

Now in 1.2Dev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants