Reservations of Buildings/Resources

I have noticed that the building scheduling function/reservations allows buildings and resources to be double or triple booked for the same date/time. It gives a warning of a potential conflict but still allows the event to be scheduled and does not notify the building scheduler (me) that a double booking has occurred. How can this be avoided? Am I missing something? Because of this we are telling members they still need to contact the building scheduler directly.

meporter wrote:I have noticed that the building scheduling function/reservations allows buildings and resources to be double or triple booked for the same date/time. It gives a warning of a potential conflict but still allows the event to be scheduled and does not notify the building scheduler (me) that a double booking has occurred. How can this be avoided? Am I missing something? Because of this we are telling members they still need to contact the building scheduler directly.

I haven't seen this. Are you talking about events in both cases, or are you talking about reservations and events. Because reservations and events can indeed coexist at the same time -- only an event truly books a resource (see the thread Double-booking Hazard if "Blocked" was used on "Resource for a situation where someone confused those two concepts).

But in no case would anything like triple booking be possible if the system is functioning correctly (and as I said, I haven't heard of problems in this regard). Are people who are scheduling events indeed selecting the right locations and resources?

One situation that has happened to a few people is that they somehow end up with duplicate locations. In that case, some people reserve resources on one of the locations and others reserve in the other, and to the system there is no conflict. Is that a possibility?

aebrown wrote:I haven't seen this.

Well, it appears there is a particular situation where double booking can happen with v2.0.1. See the thread Feature/bug: Building scheduler can double book resources on blocked reservation. Could that be what is happening to you?

Thank you for responding.

For example, if I go to Reservations and reserve a location and a resource and then go back to the Calendar and schedule an event for the same location, resource and time, it gives a warning, as follows, but still allows the event to be scheduled:

"You successfully created "test event 4" on 10 Jan 2012
FYI - A cursory search detected potentially conflicting event(s). Make sure to check all saved event(s) to ensure no unanticipated conflicts."

Other times it will appropriately block the event and not allow it to be scheduled. I cannot figure a rhyme or reason to it, but it is not reliable.

meporter wrote:Other times it will appropriately block the event and not allow it to be scheduled. I cannot figure a rhyme or reason to it, but it is not reliable.

From what I can see so far, this problem seems to be limited to times that have Reservations. In that case, a building scheduler is supposed to be able to schedule an Event on top of the reservation. But even a building scheduler should never be able to schedule an event on top of an event (that uses the same resource).

My guess is that the logic that allows a building scheduler to schedule on top of a reservation also (unintentionally and erroneously) allows a building scheduler to schedule an event on top of an event -- if a reservation exists for that resource at that time. I'll have to do some more research to see if that theory holds up. If so, it will be somewhat comforting if the problem is limited to building schedulers.

Reservations do not prevent building schedulers from scheduling an event.

Reservations only block calendar editors who do not belong to the unit that the resource is reserved for.

RussellHltn wrote:Reservations do not prevent building schedulers from scheduling an event.

Reservations only block calendar editors who do not belong to the unit that the resource is reserved for.

That could explain what someone might call "double booking", but not "triple booking" as mentioned in the original post (unless the apparent bug mentioned earlier is in play here).

aebrown wrote:My guess is that the logic that allows a building scheduler to schedule on top of a reservation also (unintentionally and erroneously) allows a building scheduler to schedule an event on top of an event -- if a reservation exists for that resource at that time. I'll have to do some more research to see if that theory holds up. If so, it will be somewhat comforting if the problem is limited to building schedulers.

I have confirmed this theory. It indeed only applies to building schedulers:

• The problem only happens if there is a reservation for a resource at a given time.
• If there is no reservation, an event will properly book a resource. Then no one (including a building scheduler) will be able to book that resource again at that time -- if they try to create an event using that resource, they will be told of the hard conflict and will be unable to save the event. That is exactly as it should be.
• If there is a reservation, then a building scheduler can schedule an event for that resource and time. That is also correct.
• But here's the problem. If there is a reservation reserving a resource and an event booking the resource scheduled by the building scheduler, then the building scheduler can schedule a second event for the same resource, and the event will be saved. The existing first event will be listed as a potential conflict, but not a hard conflict. This is definitely incorrect behavior.
• Interestingly, if there is a reservation and an event scheduled by someone else, the building scheduler will not be able to schedule a second event on top of it.
• Also, if the new event tries to schedule the entire location, a hard conflict will be reported (which is the correct behavior). The incorrect behavior of allowing the second event to be saved only happens when specific room(s) are selected.
• And a regular editor never sees this problem -- even if the reservation allows an editor's unit to schedule a resource, the conflict checking works properly, and a second event for the same resource is disallowed.

Thank you!

This bug is logged and will be fixed as soon as we can get to it.

So, do I understand that if I as the building scheduler reserve a specific date, time and resource as "Blocked -- Location Unavailable" that somebody else can schedule an event at the same date, time and resource? Our building is also used by the mission, people going to the temple next door, receptions, etc., so I Reserve the resources needed rather than schedule an event that requires I choose a calendar because I don't want to place those events on the Stake Calendar. Am I using the Calendar correctly or should I be scheduling those types of items as Events? I find it disturbing Reserving the resource if somebody can schedule and event over them.

greglebaron wrote:So, do I understand that if I as the building scheduler reserve a specific date, time and resource as "Blocked -- Location Unavailable" that somebody else can schedule an event at the same date, time and resource? Our building is also used by the mission, people going to the temple next door, receptions, etc., so I Reserve the resources needed rather than schedule an event that requires I choose a calendar because I don't want to place those events on the Stake Calendar. Am I using the Calendar correctly or should I be scheduling those types of items as Events? I find it disturbing Reserving the resource if somebody can schedule and event over them.

That's not what is described in this thread. If you'll read my detailed explanation, you'll see that the problem with this particular bug is that you (since you are a building scheduler) can schedule two conflicting events on top of the same reservation. That doesn't mean that anyone else can do so.

It's largely a matter of preference as to how you book events such as you describe. Personally, I like creating a "Resource Only" calendar that such events can be put on. An event is the only way to book a resource so that no one can book that resource. If you use the "Blocked" reservation, then only you (or another building scheduler, if one exists) can schedule an event on top of that reservation. But the fact remains that you can indeed do that. It's possible that a scenario could arise where you are scheduling an event months after you made a reservation, and you forget that you made that reservation, and so you inadvertently schedule an event on top of a reservation. Using a "Resource Only" calendar also lets other people book such events, even though they are not building schedulers. You may see that as a blessing or a curse, but I see it as a blessing.

For this reason (and because it makes a lot of sense to me philosophically), I like using events to book resources, and reservations only to deny others the ability to schedule events for a resource. But with discipline you can use Reservations to accomplish the same thing.

aebrown wrote:That's not what is described in this thread. If you'll read my detailed explanation, you'll see that the problem with this particular bug is that you (since you are a building scheduler) can schedule two conflicting events on top of the same reservation. That doesn't mean that anyone else can do so.

Isn't it more accurate to say anyone with Building Scheduler rights can do that? There may not always be just one in any given stake.

I'm an advocate of using a calendar called "Private Events" for such things. If desired, you can make it private since V2 does allow private events to use Resources.

Also, I don't think that reservations show up when people are looking "by location" to see what else might be happening.

RussellHltn wrote:Isn't it more accurate to say anyone with Building Scheduler rights can do that? There may not always be just one in any given stake.

True, and if you would have read the second paragraph of my post, you would have seen that I acknowledged that very point. I used the singular in my paragraph directed specifically to greglebaron because he also used the singular.

RussellHltn wrote:I'm an advocate of using a calendar called "Private Events" for such things. If desired, you can make it private since V2 does allow private events to use Resources.

That's fine. I find that I need to use that calendar for purposes other than just private events (setup/cleanup times that don't match the limited presets, for example, or a projector reservation that is for church purposes, but doesn't correspond to a scheduled event), so I use a more generic name, but you can name it whatever you want.

RussellHltn wrote:Also, I don't think that reservations show up when people are looking "by location" to see what else might be happening.

Not true. Anyone can see reservations now on V2, when they check the box for a particular location.

aebrown wrote:That's fine. I find that I need to use that calendar for purposes other than just private events (setup/cleanup times that don't match the limited presets, for example, or a projector reservation that is for church purposes, but doesn't correspond to a scheduled event), so I use a more generic name, but you can name it whatever you want.

What do you call it?

RussellHltn wrote:What do you call it?

As I mentioned in the second paragraph of my earlier post, I call it "Resource Only".

We do pretty much the same thing in our stake. We've termed it the "Stake Resource Calendar". It only has weddings, family dinners, and other stuff that doesn't need to be on the stake or ward calendars. For example, our stake does a men's basketball season which uses two buildings each week. Rather than put two entries on the stake calendar for both buildings, we put one on the stake calendar with title and description identifying both buildings, and another on the Resource Calendar with the same text for the other building.

Thank you so much for the explanation of how the calendaring program works and for the suggestions of who others are handling this. The discussion has been very helpful for me.

aebrown wrote:I have confirmed this theory. It indeed only applies to building schedulers:

This has now been fixed: see Calendar version 2.0.6 released!