Giters

neokoenig / RoomBooking

This is an open source application for booking rooms via a web based calendar, using cfWheels, Bootstrap3, jQuery, FullCalendar.js, and other bits. AKA the OxAlto RoomBooking System

Home Page:http://roombooking.readme.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Event in same room can overlap

kcits opened this issue · comments

commented

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.

commented

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.

commented

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

commented

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.

commented

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.

commented

Now in 1.2Dev