modifying an event if a reserv was made after orig event

[damiangr]

27-Jan-2013

We have a problem when we try to modify an existing event if a reservation was made after the original event was scheduled.

I’ve been asked to notify you to see if there is any way fixing this perceived glitch.

What we have encountered is:

1) The Stake created (scheduled) all their events before the beginning of the year.

2) The Stake Center's building scheduler reserved various weekends for each ward that shares the building on an agreed upon rotating basis. This occurred 'after' the events were scheduled.

[They have done this for years, even in the 'writing in a notebook' days. Everyone knows that Ward A has the 1st Fri/Sat, Ward B the second and Ward C the fourth. Any one needing a room knows which ward to call to see if there is an opening.]

3) The Stake sees that they may have entered the wrong room or wrong time, etc... They now go in and try to edit their original event.

4) The system seems to see this as a new event and won't let the original event be modified because the reservation, made after the event was scheduled, takes precedence.


One solution would be to timestamp both the scheduling of an event and the creation of a reservation. Then you could check the timestamps to see if the original event takes precedence over the reservation and allow for modification.

Our specific example was the stake scheduled the whole building for events and wanted to go back and modify all the events to schedule just a room.

Thank You

[Gary_Miller]

The building scheduler for the building should be able to modify the event with no problem.

The problem is that once the reservation is made it over rides all the events. In this case the ward which the reservation is for would be the only one that can add or modify events.

This is why its not a good idea to make blanket reservations for the whole building for a single ward. It is much better to allow the use to be a first come first served use of the building, by allowing events to be schedule if room is available. That way you don't have an entire building reserved for a ward who may or may not use the building that weekend.

[russellhltn]

This is why its not a good idea to make blanket reservations for the whole building for a single ward. It is much better to allow the use to be a first come first served use of the building, by allowing events to be schedule if room is available. That way you don't have an entire building reserved for a ward who may or may not use the building that weekend.

I don't quite agree with that, but then we only set aside weeknights, not weekends.

[jdlessley]

This is why its not a good idea to make blanket reservations for the whole building for a single ward. It is much better to allow the use to be a first come first served use of the building, by allowing events to be schedule if room is available. That way you don't have an entire building reserved for a ward who may or may not use the building that weekend.

I also don't agree with that. The purpose of reservations is to restrict the use of the resources to one unit or the stake. If that stake feels that is the most equitable use of resources then that is their call and the system permits that methodology.

While the solution to the problem isn't the most desirable it is one reason there are building schedulers. They have the tools to make the change for the stake in this scenario. If the stake does not want to bother the building scheduler with making the changes then one of the administrators can make himself a building scheduler, if he is not already, and make the changes.

[damiangr]

The problem with this is that you have to guess how the developers were thinking. This is not unlike the Integrated Development Environment (IDE) used in SW development. In the old says we used EMACS and freeformed our code. Now we are forced into thinking like the developers of the SW package.

The reserving of whole nights and days on a week by week basis has been done with paper and pencil for years.
The problem isn't the initial scheduling, it is the way the system handles changing an event. It the event is scheduled, then a building scheduler reserves the time slot for a particular ward... everything is fine.. Until the original event is modified. Then the reservation seems to take higher priority instead of the original event.

Another solution to this is to allow the Stake Exec Sec and Stake Clerk to be members of all wards. Then they can schedule and change events without having to chase down a building scheduler.

Just remember old programmer slogan: Tim Towtdi (Tim Toady) There Is More Than One Way To Do it.