Problems with distributed scheduling software

We are having trouble with double-booking of resources under the new "distributed scheduling" paradigm. The problem is occurring NOT because members are not behaving but because the software is not behaving. I have instances where members are booking locations using their mobile devices (e.g., cell phones) and their reservations are not showing up in the "official" building calendar. Recently one ward RS scheduled our building for a work session (via the building scheduler) and another ward scheduled the same building for the same time using a mobile device (or their own PC) without the involvement of the building scheduler. The latter reservation never showed up in the official building schedule and there was a 'trainwreck' on the day of the two RS meetings.

In addition, the default calendar view that I get by unsubcribing ALL calendars except the building that I schedule DOES NOT show the same set of reservations that I get when I go to Settings/Reservations for the same building. (I might add that I continually get a scripting error whenever I click the link 'Hide all calendars'.)

It appears that there are unresolved problems in the software.

DeanDTaylor wrote:I have instances where members are booking locations using their mobile devices (e.g., cell phones) and their reservations are not showing up in the "official" building calendar.

Just to be clear, did it show up on the website at all? At this time the only way to schedule something is to go to the website. There's no way to sync a mobile calendar to the main calendar. That might be a "user error" problem.

Also, the conflict checking only works if they select the resource (and there's no duplicate resources).

I think you need to break down the issue(s) and find out just were the problem is happening. A broad description doesn't help the programers find and fix the bug.

As I said in the original post I've experienced MULTIPLE problems with overbooking. In the instance I cited I (personally) did not see the second reservation (made without the building scheduler) in any calendar. However, when I got the unpleasant report about the trainwreck I was told that BOTH parties claimed to have reserved the building. I, personally, had done the first one, but had no involvement in the second one.

In a separate instance just this week a member called and asked me to confirm that her reservation of the building for a YM/YW activity had been entered in good order (her husband had apparently done it himself via phone, PC, or whatever, but without my involvement). When I checked the calendar online the reservation did not show up, initially. Rather, what showed up was a weekly-recurring 'open' reservation for that building at that time. To reassure the member I attempted to modify and replace the recurring reservation with hers, but the software refused to allow it. I then attempted to delete the single instance of the recurring reservation and then enter the member's event, in its place. This also was refused by the software with a message stating that it conflicted with another event, though at that point the calendar displayed NO other event in the building on that day. At this point I was confused and frustrated and just started experimenting. Serendipitously, I discovered that when I changed from the default view of the calendar to the Settings/Reservations view with all available filters checked, the woman's husband's reservation magically appeared (as I noted in my initial post). So in my mind the software committed two "unpardonable sins": (1) It allowed the sister's husband to double-book (on top of the pre-existing, recurring reservation, and (2) It masked the second reservation in the default view of the calendar for the building. (Again, as I previously noted, I don't see the same reservations in the default view [with my building as the only subscribed view] as I see in the Settings/Reservations view of the same building [regardless of which filters are active].)

I appreciate the comment about the need for definitive information to isolate problems. Hopefully, the information I've provided will be helpful. I'm anxious to avoid any more unpleasantness due to double-booking.

I have had several members express some frustration while learning the new system. Many claim that the "calendar is broken" or "has too many bugs". After walking them through the process of how to work with the calendar, their attitudes change. Granted, there are a few bugs in the current calendar, but I don't believe it is as broken as you claim. It works quite well once you become comfortable with it.

As it relates to double bookings, I too have had members claim that they have reserved buildings/locations only to find out that they indeed put an event on the calendar, but didn't edit the event details and add location and rooms. They just added the event with NO location and in the description stated they wanted the gym or RS room which didn't actually reserve it. If this was the case, and you are not subscribed to the calendar where the member scheduled the event, you would never see an event with no location.

Couple other suggestions to view ALL events:

1) While the month view is handy, it doesn't show all events using buildings/rooms within a stake. If you use the week view, it will show you ALL events that utilize the locations listed. If you uncheck all your subscribed calendars and just check the location you want to look at, it will show you events that are even on other units calendars. Week view is available to all members, even if they are not calendar editors. This can be helpful in helping someone figure out what days and times buildings and rooms may be available.

2) You can also see this on the reservations calendar, as you mentioned in your post. The Settings > Reservations page isn't available to all members, but it is to administrators. You can view all scheduled activities in both month and week view by location.

Again, I don't think the issues are as dire as you are presenting them. I just believe it takes a bit of working with the new calendar to understand how to use it effectively.

DeanDTaylor wrote:...when I changed from the default view of the calendar to the Settings/Reservations view with all available filters checked, the woman's husband's reservation magically appeared (as I noted in my initial post). So in my mind the software committed two "unpardonable sins": (1) It allowed the sister's husband to double-book (on top of the pre-existing, recurring reservation, and (2) It masked the second reservation in the default view of the calendar for the building. (Again, as I previously noted, I don't see the same reservations in the default view [with my building as the only subscribed view] as I see in the Settings/Reservations view of the same building [regardless of which filters are active].)

May I ask a question? It might just be terminology, but there is a difference between a "reservation" and a "scheduled event". A reservation might just prevent other units in the stake from creating an event at that time. (The classic example is that Ward A in our building has the gym on the 1st and 3rd Wednesday; Ward B has the gym on the 2nd and 4th Wednesday. I created reservations for Ward A and B on their respective nights so that no one could inadvertently schedule an event in the gym on a night that wasn't their's. However, these reservations do not actually "book" the building.) A "Scheduled event" actually books the building. So, I could make "reservations" all day long and therefore think I had reserved the building. But you could come along and schedule events over top of my reservations -- which might result in me "thinking" the software had double-booked the building.

Also, as was alluded in passing, I have synced the LDS.org calendar with my Google Calendar. If I they try to book an event on my Google Calendar, nothing is passed back to the LDS.org calendar.

To help the programmers understand what the bug might be, would it be possible for you to walk through the exact steps that result in this double-booking? If you can find a repeatable sequence, it typically greatly increases the likelihood of the bug being identified and squished.

Thanks for the info about 'week' view. I tried it and it performed as you advertised--with one exception. I got the following script error when I switched to 'week' view and every time I attempted to scroll (or click) to change the week shown:

"A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: https://ldscdn.org/scripts/jquery/1.5.1 ... .min.js:16"

Needless to say the continual stream of error messages makes an already-slow process much slower.

In regard to the scheduling conflict that I described in detail in my previous post, the location WAS specified for both events, and the building was still double-booked. In fact, our ward's Sunday block of meetings is ALSO double-booked (you can verify this if you have access to our stake information). Fortunately this has no real impact because both reservations are for our ward's own meetings. But there are two different bookings as evidenced by the fact that one reserves the entire facility and the other reserves only specified rooms.

I am disappointed (and frustrated) at the cavalier attitude about double-booking manifested in the previous post. A response to one of the other posts that I read earlier today stated that the distributed scheduling concept has been adopted to streamline the scheduling process and reduce wasted time. When two auxiliaries schedule an event at the same time and location, and find that one of them is forced to cancel or move to some other location when they discover that the building is double-booked, how much time (and emotional capital) is wasted? (Never mind how much of MY time is wasted trying to unravel these problems before/and or after the fact.)

With the holiday season fast approaching and all the associated events planned in our building I'm hoping that I don't have to explain any more "trainwrecks" to our members.

DeanDTaylor wrote:In regard to the scheduling conflict that I described in detail in my previous post, the location WAS specified for both events, and the building was still double-booked. In fact, our ward's Sunday block of meetings is ALSO double-booked (you can verify this if you have access to our stake information). Fortunately this has no real impact because both reservations are for our ward's own meetings. But there are two different bookings as evidenced by the fact that one reserves the entire facility and the other reserves only specified rooms.

It will help narrow down the issue tremendously if you will be careful about using the terminology that the calendar system uses. In the paragraph I quote above, you use the term "event" to refer to both items in the first sentence, and then in the third sentence you use the word "reservation", apparently to refer to those same items. Then in the last sentence you use the word "bookings".

There is a significant difference between a Reservation and an Event. Almost every case where I have seen someone claim that there is a double booking happens because they confuse a Reservation with an Event, or they just failed to actually include the correct rooms in the correct location.

Only an Event actually books a room. A Reservation does not. If someone created a Reservation and in so doing thought they had booked a room, then they need some gentle teaching. Fortunately, very few people have the permission to create a Reservation -- only a building scheduler, and for each location most stakes choose to have just one scheduler.

There are plenty of people on the forum willing to try to help you. Could you please revisit your example, and look at the two items that you report are in conflict? Specifically, in a view where you can see both items, click on the item, then go into the details, and determine for each event:

1. Is it a Reservation or an Event?
2. Does it include a location -- the same location?
3. Does it include rooms -- at least one of the rooms being the same?
4. Is it on the same date and time?

DeanDTaylor wrote: I am disappointed (and frustrated) at the cavalier attitude about double-booking manifested in the previous post. A response to one of the other posts that I read earlier today stated that the distributed scheduling concept has been adopted to streamline the scheduling process and reduce wasted time. When two auxiliaries schedule an event at the same time and location, and find that one of them is forced to cancel or move to some other location when they discover that the building is double-booked, how much time (and emotional capital) is wasted? (Never mind how much of MY time is wasted trying to unravel these problems before/and or after the fact.)

I hope you were not referring to my post back to you as being cavalier...that was not the intent. I am not a church employee, just a fellow member who has been using the new calander for the good part of a year. My stake and member units have not experienced the double bookings issues you have. Perhaps someone else would be of more assistance is getting to the bottom of the issues you are having.

dshepher wrote:2) You can also see this on the reservations calendar, as you mentioned in your post. The Settings > Reservations page isn't available to all members, but it is to administrators.

Just so we don't confuse anyone, the Settings > Reservations page isn't available to administrators either. Only building schedulers have this page/capability.

jdlessley wrote:Just so we don't confuse anyone, the Settings > Reservations page isn't available to administrators either. Only building schedulers have this page/capability.

Thanks for the correction!

It's a learning curve, to be sure! We've had monumental "train-wrecks" with the old system of building schedulers as well. Those problems that caused most of them are still possible with the new system-- One had scheduled the building, and the second THOUGHT they had...

What may seem "cavalier" to you is a necessary step to resolving what you say is happening. It's all about getting to the exact details, as there are many possible problems that we must eliminate one by one....

Yes, unfortunately, no system is foolproof.

My family held a wedding reception in our stake center. Our stake just used building schedulers with a paper calendar and lots of phone calls. When we showed up to decorate, there was another family just starting their wedding reception. Luckily we were there a night early for the decorating.

The mother of the other party was furious that we had even shown up (even though we explained that we'd simply help them clean up after and then set up our stuff). She told us who she had called to schedule the building, and my dad explained that the person she had called was the building scheduler for the other building in the stake. She cussed him out and asked him who he was to tell her who was who. He quietly responded, "Sister *****, I'm the stake president."

She hadn't recognized him in the dark parking lot. She was much nicer after that.

And the bottom line at this point is that distributed scheduling is not going away.

aebrown wrote:It will help narrow down the issue tremendously if you will be careful about using the terminology that the calendar system uses. In the paragraph I quote above, you use the term "event" to refer to both items in the first sentence, and then in the third sentence you use the word "reservation", apparently to refer to those same items. Then in the last sentence you use the word "bookings".

There is a significant difference between a Reservation and an Event. Almost every case where I have seen someone claim that there is a double booking happens because they confuse a Reservation with an Event, or they just failed to actually include the correct rooms in the correct location.

Only an Event actually books a room. A Reservation does not. If someone created a Reservation and in so doing thought they had booked a room, then they need some gentle teaching. Fortunately, very few people have the permission to create a Reservation -- only a building scheduler, and for each location most stakes choose to have just one scheduler.

There are plenty of people on the forum willing to try to help you. Could you please revisit your example, and look at the two items that you report are in conflict? Specifically, in a view where you can see both items, click on the item, then go into the details, and determine for each event:

1. Is it a Reservation or an Event?
2. Does it include a location -- the same location?
3. Does it include rooms -- at least one of the rooms being the same?
4. Is it on the same date and time?

Thanks for pointing out the distinction between an 'event' and a 'reservation'. Now, please help me dissect the conflict in our calendar that I mentioned in yesterday's post. When I go to the Settings>Reservations view for the 'Sunnyside Bldg' location for Sunday, Nov 20 I see three items on the building calendar. When I click on them and get the 'short' description, they ALL have a link titled "Edit Reservation Details". However, when I click this link and get the details screen, two of them say "Event Details" and only one says "Reservation Details". Now, focus on the listed details for two of these three items listed below:

Item #1 (Reservation): Unit: Ward A; Rooms: Entire facility; Location: Sunnyside Bldg; Time block: 9:30 AM - 12:30 AM; Description: Ward A Meeting Block

Item #2 (Event): Unit: None; Rooms: Chapel; Location: Sunnyside Bldg; Time block: 11:30 AM - 2:30 PM; Event: Ward B Meeting Block

Note that BOTH items specifically state (in the details page) the SAME Location (namely, the Sunnyside Bldg), so presumably both items are bona fide 'bookings' in the specified location. Note also the double-booking of the Chapel in the 11:30 AM - 12:30 PM time slot. According to the posts on this forum yesterday and according to the documentation I've been provided, Item #2 should have been rejected by the software because Item #1 is a 'reservation' of the entire building for Ward A functions in the entire time block from 9:30 AM - 12:30 PM. But the software allowed the overbooking by the other ward unit. I'm guessing that the reason has to do with the fact that the 'Unit' in Item #2 was specified as 'None' (probably as the default choice in the dropdown menu). Was this the intent of the developers--to allow double-booking by the artifice of not specifying a unit when scheduling an event?

DeanDTaylor wrote:so presumably both items are bona fide 'bookings' in the specified location.

Close, but no. Only the event "books" the building. The reservation only reserves it. You, or anyone else who is a building scheduler can override any reservation. It's also possible the reservation was put in place after the event.

DeanDTaylor wrote:I'm guessing that the reason has to do with the fact that the 'Unit' in Item #2 was specified as 'None'

That's odd. And it might explain why it got past the reservation.

Edit: I'm seeing ALL of my events as unit "None". Clearly, that field isn't working for some reason.

RussellHltn wrote:Close, but no. Only the event "books" the building. The reservation only reserves it. You, or anyone else who is a building scheduler can override any reservation. It's also possible the reservation was put in place after the event.



That's odd. And it might explain why it got past the reservation.

Edit: I'm seeing ALL of my events as unit "None". Clearly, that field isn't working for some reason.

Was there going to be a follow-up on the last comment? I, too, wondered why there is no facility to specify a unit when an 'event' is scheduled, and, as you noted, all 'events' apparently come across with "Unit: None" specified.

DeanDTaylor wrote:Was there going to be a follow-up on the last comment? I, too, wondered why there is no facility to specify a unit when an 'event' is scheduled, and, as you noted, all 'events' apparently come across with "Unit: None" specified.

There is no need to specify a unit when an event is scheduled. An event is always placed on a calendar, and a calendar always belongs to a specific unit (ward or stake). So it makes perfect sense that "there is no facility to specify a unit when an event is scheduled."

The only odd thing about this is that the display for an Event lists "Unit: None". It could be useful as a displayed piece of information, but the unit that owns the calendar of the event should be displayed, or the "Unit: None" text should be omitted entirely to avoid confusion.

aebrown wrote:There is no need to specify a unit when an event is scheduled. An event is always placed on a calendar, and a calendar always belongs to a specific unit (ward or stake). So it makes perfect sense that "there is no facility to specify a unit when an event is scheduled."

The only odd thing about this is that the display for an Event lists "Unit: None". It could be useful as a displayed piece of information, but the unit that owns the calendar of the event should be displayed, or the "Unit: None" text should be omitted entirely to avoid confusion.

I had guessed that the 'Unit' parameter might be supplied implicitly (from the context) as you indicate. However, I ruled it out because that creates another problem--what about when I (the scheduler) am creating an event for another person (this is very frequent in our stake and will, no doubt, continue to be so, at least during the transition to the new 'distributed scheduling' paradigm)? The only calendar that I have to choose from when I create an event is my own building calendar (which the software apparently translates to "Unit: None"). So when I (unknowingly) attempt to violate any preexisting 'reservation' (e.g., from a different unit from the one for whom I'm creating the 'event') the software happily allows me to do so (I've verified that this is, in fact, the case).

If your response is to the effect that "well, unfortunately, that comes with the territory for a scheduler, given his/her role and rights", then PLEASE tell me how to get rid of the scripting error ["A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. [font=&quot]Script: https://ldscdn.org/scripts/jquery/1.5.1 ... .min.js:16[/font]"] that I get with every click when I'm trying to navigate to the correct 'week' view so that I can see ALL the 'reservations' and 'events') that are currently on my building calendar. The recurring error message, though not fatal, makes the process incredibly slow.

DeanDTaylor wrote:I had guessed that the 'Unit' parameter might be supplied implicitly (from the context) as you indicate. However, I ruled it out because that creates another problem

Regardless of your other issues, there is no question that the unit for an event is specified by the unit that owns the calendar for the event. So we can set that issue aside.

DeanDTaylor wrote:what about when I (the scheduler) am creating an event for another person (this is very frequent in our stake and will, no doubt, continue to be so, at least during the transition to the new 'distributed scheduling' paradigm)? The only calendar that I have to choose from when I create an event is my own building calendar (which the software apparently translates to "Unit: None").

Even if your stake is slow in adopting truly distributed scheduling, it still should be extremely rare that a building scheduler would want to create an event. Remember that an event is more than just a resource reservation -- it is an event on a calendar, with details that are helpful for those who are invited to attend the event. It's an event that will be synced to other calendars such as those on mobile devices.

How are those invitees going to see the event? Only if it is on a calendar that they are subscribed to. The most likely way for that to happen is for the event to be on an appropriate ward calendar (for a ward event) or stake calendar (for a stake event). It should be a ward responsibility to schedule ward events, and there should be at least one ward member who will take responsibility for scheduling ward events, even if that ward is not ready to distribute scheduling any more broadly than that yet.

DeanDTaylor wrote:So when I (unknowingly) attempt to violate any preexisting 'reservation' (e.g., from a different unit from the one for whom I'm creating the 'event') the software happily allows me to do so (I've verified that this is, in fact, the case).

Building schedulers do indeed have the power to override reservations by creating events. But given that only building schedulers can create reservations, I think the software designers assumed that the schedulers would know about the reservations. But I think it would be a helpful improvement if the software warned building schedulers that they are about to override a reservation -- are they sure they want to do this?

I also think that given this great power that building schedulers have, this is another argument for schedulers avoiding creating events as much as possible. No one else can override a reservation, knowingly or unknowingly. This problem simply does not exist for anyone besides a building scheduler.

DeanDTaylor wrote:If your response is to the effect that "well, unfortunately, that comes with the territory for a scheduler, given his/her role and rights", then PLEASE tell me how to get rid of the scripting error ["A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. [font=&quot]Script: https://ldscdn.org/scripts/jquery/1.5.1 ... .min.js:16[/font]"] that I get with every click when I'm trying to navigate to the correct 'week' view so that I can see ALL the 'reservations' and 'events') that are currently on my building calendar. The recurring error message, though not fatal, makes the process incredibly slow.

I don't know what to tell you about the scripting error. That is clearly not a widespread problem, or we would have heard about it more on this forum. But I can certainly understand that it would be very frustrating for you. And since I'm not on the calendar development team, I'm not sure what to tell you about tracking down or eliminating such a problem.

DeanDTaylor wrote:I had guessed that the 'Unit' parameter might be supplied implicitly (from the context) as you indicate. However, I ruled it out because that creates another problem--what about when I (the scheduler) am creating an event for another person (this is very frequent in our stake and will, no doubt, continue to be so, at least during the transition to the new 'distributed scheduling' paradigm)? The only calendar that I have to choose from when I create an event is my own building calendar (which the software apparently translates to "Unit: None"). So when I (unknowingly) attempt to violate any preexisting 'reservation' (e.g., from a different unit from the one for whom I'm creating the 'event') the software happily allows me to do so (I've verified that this is, in fact, the case).

Currently building schedulers can create events for calendars in their own unit only. This works for single unit locations. For multi-unit locations this requires more than one building scheduler, if the building scheduler is the only one creating events. Having more than one building scheduler for a location can create situations that would need to be dealt with.

I think that I helped Bro. Taylor understand what was going on in our Stake with the New LDS Calendars. Because version 1.0 didn't let anyone see the reservations made by the Building Schedulers, and to have the building schedulers continue in the same role as they had with the classic website per the resources calendars, we made a Stake Calender for each of our building schedulers to use to schedule the events that where going on in the building that they worked with. We had asked all of the units to continue to make all reservations for buildings and rooms via the building schedulers (even though if a person was a editor they could do it for themselves), while we waited for the new version to come out.

So we had Bro. Taylor as both a Building Scheduler so he had access to the Reservations Calendar to block time etc. for specific Wards for the building and rooms, and also as an Administrator (editor) of a Stake Calendar for him to use to enter scheduled events and schedule the building and rooms too.

Now that version 2.0 shows the info from the reservations calendar and with the insight from the forum from others, we are going to move forward and train our stake and wards on how to use the new calendars as designed with acting Ward Administrators, Building Schedulers and etc. acting in the roles as outlined in "help".