Problems with distributed scheduling software

[kisaac]

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....

[jdcr256]

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.

[russellhltn]

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

[DeanDTaylor]

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?

[russellhltn]

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.

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.

[DeanDTaylor]

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.

[aebrown]

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.

[DeanDTaylor]

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.

[aebrown]

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.

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.

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.

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.

[jdlessley]

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.