Calendar Is Double Booking Events

I've been the building scheduler for our Stake for 7 years, and this is the first time I've seen this. Two different people were able to book our Stake pavilion at the same time. They had everything done perfectly to schedule it. The system shouldn't have allowed this to happen, but it did. Is this a glitch?

ASpaugh wrote:Is this a glitch?

Probably. Double-booking should never happen, but due to some misunderstandings of how things work, it can happen.

The first thing to check: Did both actually select the same location/"room"? (Perhaps one only listed the location and didn't actually select it.) Is it possible there is a duplicate location/room such that each booked a different location on the system that refers to the same physical location?

Is one "event" actually a restriction and the other an event? Many are surprised at how restrictions work: It's only possible to restrict it to a unit. If a building scheduler used a restriction to book the cultural hall for the RS, the YM of the same unit can still schedule a basketball game there. In that case the fault lies with the building scheduler not understanding how restrictions work.

Thanks for the reply.

I double-checked everything and it was done correctly by both people. They were both for events, not restrictions. There aren't double calendars for the same location. I did a few test events and I can schedule anything I want no matter what is already scheduled at the Pavilion. I tried this with other locations in the Stake as well and the Pavilion is the only one that has this issue. I don't know what else to try.

ASpaugh wrote:There aren't double calendars for the same location. .... I did a few test events and I can schedule anything I want no matter what is already scheduled at the Pavilion. I tried this with other locations in the Stake as well and the Pavilion is the only one that has this issue.

Is the Pavilion a calendar or a location? The system prevents double-booking of locations. I don't think there's anything to prevent multiple events on the same calendar.

Is there anything that you can see different about how the Pavilion is set up from the other locations?

Can you attach some screen shots (cutting out any sensitive information as needed)?

The Pavilion is a location, not a calendar. It's one single location outside, no rooms, so you have to book the entire thing.

Also...

ASpaugh wrote:The Pavilion is a location, not a calendar. It's one single location outside, no rooms, so you have to book the entire thing.

I wonder if there is a bug involving locations which have no rooms. I could see that case being missed in testing and not showing up in production use much.

eblood66 wrote:I wonder if there is a bug involving locations which have no rooms. I could see that case being missed in testing and now showing up in production use much.

I think that's it, because I can duplicate it.

Edit: "Entire Facility" works as expected, so this doesn't seem to carry over to any usage case for multi-room facilities.

Well hopefully they will fix it soon, because this is very frustrating. I added a room and tested it, and now it won't book conflicting events.

ASpaugh wrote:Well hopefully they will fix it soon,

I can't say how soon, but that kind of bug gets prompt attention. Bugs that are just annoying and can be worked around usually wait for a update.

The developers have been notified.

Thank you for your help and for reporting it.

I read the threads from the conversation and the pavilion I oversee is doing the same thing.
Two groups created separate events on the same day at the same time. I was able to create a fake event on the same day and time of the other events. I can create numerous events over and over, but I cannot do this at meetinghouses.
Seems like pavilions have an issue.
Good luck with finding the glitch.

I created a room in the pavilion and now it won't double book.

We have this on our list to fix, hopefully in the next release.

CrockettDR wrote:We have this on our list to fix, hopefully in the next release.

It appears that some changes were pushed out. Was this fixed?

We are having this problem as well. (Not sure if something was done yet to adress the issue.) Currently the Calendar is allowing other wards to book the same rooms at the same time as blocked off events. As far as we can tell when someone from our own ward tries to "double" book an event it won't let them. Thanks!

I believe the issue was addressed.

tracyforyan wrote:Currently the Calendar is allowing other wards to book the same rooms at the same time as blocked off events. As far as we can tell when someone from our own ward tries to "double" book an event it won't let them.

How exactly was the location "blocked off"?

Normally the system blocks duplicates, but we just encountered a duplicate entry as well. A custom-entered classroom for the same location. the only thing that is suspicious is that the building scheduler booked both events -- would the system allow that type of override by the location building scheduler ?

Attached are example screenshots of the overlap.

There was at one time a override for restrictions, but there should never be an override for events. Something messed up here.

rootbeericecream wrote:Normally the system blocks duplicates, but we just encountered a duplicate entry as well. A custom-entered classroom for the same location. the only thing that is suspicious is that the building scheduler booked both events -- would the system allow that type of override by the location building scheduler ?

Any other details you can supply - like when these events were placed, or when/what kind of modifications wee made?

The first step to fixing is to duplicate that.

Our scheduler reported that he scheduled the "rose jpg" event on August 11. The YW event was scheduled several months ago.

I just tried that now, I can't duplicate it. I assume the conflicting room is a "custom" room. Is the building a "regular" one or was it added? (Does the "Remove" button appear when you go to edit the location?)

Were there any edits along the way - perhaps a change that turned a non-conflict into a conflict (such as a change in starting date. Or a change in locations?)

While I don't see how it could do it, any chance the first event was saved during PST as it appears the second event was saved in PDT?

The conflict room is a 'custom' room. It is a regular building. Possible that there were edits along the way. The old one was a recurring appointment ( 3 wks/month) potential exception edits along the way, but unsure of that). for this there wouldn't have been a change in locations - but possibly the most recent added one was added without locations, and then location added later.
Yes, based upon the recurrance, the older recurring event was scheduled prior to PST/PDT change last spring.

I agree, this is a puzzle.

We've struggled to duplicate this one. If anyone has some good steps, that would be helpful.

Can you please explain how restrictions are different? I have a restriction for the entire building classified as "blocked - location unavailable - entire facility" and NOT assigned to a ward. But yet the ward was able to book the Cultural Hall for the same time period. I can understand the ward booking the space if I had classified it to the ward, but I have it as blocked. Please explain.
(I tried to include a screenshot but I'm not able to paste.)

pamvan wrote:Can you please explain how restrictions are different?

You can lay a "blocked" restriction overtop of an existing event. So using "blocked" to insure exclusive use is not a good idea.

But as a building scheduler, you also have the ability to schedule an "event" on the building calendar. That will behave just like an event and not allow co-existence with another event. In that same situation, you would receive a warning and would not be able to schedule your "block" event. The only difference is that the event will not sync externally like a ward or stake event could.

I don't know. Have you tried contacting LDS.org about it? They could help you. But, I've never heard of this before.