"Your event cannot be scheduled during a restricted time per

Seeing the following message when scheduling an reservation: "Your event cannot be scheduled during a restricted time period"

A restriction has been setup for the room in question. The room is a "custom" room that appears in the bottom right corner for the location, if that makes a difference. The person scheduling the reservation is a building scheduler for the resource.

When I first examined the restriction, it did not have an entry under "Restricted to". So I selected our stake in the drop-down list. Oddly, I'm not able to make changes to another reservation scheduled at the same time and for the same resource as the restriction. I get the same error.

What else could be causing the conflict between the reservation and the restriction?

Have you been setup in the system as the building scheduler for that building? That would explain why you couldn't edit the restriction.

There's been a recent change in the system - building schedulers can no longer override restrictions.

That's good to know, and thanks for the help. I am the stake administrator, and added myself as a building administrator for that location for the test. As with the other building administrators for that resource, I was unable to add an "event/reservation" on top of a "restriction" (see below).

We may not be using the same terminology. I learned the lingo from the outset, as you probably did, where a "reservation" was the means to block out periods of time for a resource, and a "scheduled event" was what calendar administrators (like ward auxiliaries) would schedule for all to see. I think now they're calling a "reservation" [old] a "restriction" [new], and an "event" [old] a "reservation" [new].

In any case, we're unable to create the "event"/"reservation" on top of a "restriction". In the past, we were able to do so as long as criteria were met.

If we delete the "restriction", we're easily able to create the "event"/"reservation". Conflicts usually only arose when the event/reservation conflicted with the restriction's: 1) date and time (including setup, teardown), 2) the union of any resource between the event/reservation and restriction, 3) unit is in conflict (restriction assigned to a particular ward, another ward could not create and event/reservation) However, if you select "stake" as the unit, then any ward could utilize the resource.

tseager wrote:We may not be using the same terminology. I learned the lingo from the outset, as you probably did, where a "reservation" was the means to block out periods of time for a resource, and a "scheduled event" was what calendar administrators (like ward auxiliaries) would schedule for all to see. I think now they're calling a "reservation" [old] a "restriction" [new], and an "event" [old] a "reservation" [new].

You're correct in saying that the old term "reservation" has been replaced by the new term "restriction"; this is a definite improvement.

However, the term "event" is still the correct term. That is clearly the term used throughout the Calendar application. I was disappointed to see the term "reservation" used in the updated documentation in a few places; there's no reason to introduce that term when "event" is perfectly clear and doesn't carry the baggage of the term formerly used for restrictions.

tseager wrote:In any case, we're unable to create the "event"/"reservation" on top of a "restriction". In the past, we were able to do so as long as criteria were met.

You still can do this. But there is one additional criterion (this is the recent change that RussellHltn referred to): the event you are creating or moving on top of a restriction must be for the same unit that the restriction was created for. If the restriction is for Ward A, then only an event for Ward A can be created on top of that restriction. One specific case of this change is that no event can be created on top of a "Blocked" restriction.

tseager wrote:If we delete the "restriction", we're easily able to create the "event"/"reservation".

And that is the intention of the new way. The building scheduler has to remove the restriction before an event that is contrary to that restriction can be created.

Although this can create some extra work, it provides safety. With the older system, it was far too easy for a building scheduler to move or create events on top of restrictions without even being aware that the new event conflicted with the restriction. Now that cannot happen.

tseager wrote:Conflicts usually only arose when the event/reservation conflicted with the restriction's: 1) date and time (including setup, teardown), 2) the union of any resource between the event/reservation and restriction, 3) unit is in conflict (restriction assigned to a particular ward, another ward could not create and event/reservation) However, if you select "stake" as the unit, then any ward could utilize the resource.

That last statement is not correct. If the stake is the unit for which a restriction is created, then only the stake unit itself can create events on top of that restriction -- wards that happen to belong to that stake cannot.

tseager wrote:an "event" [old] a "reservation" [new].

As far as I know it's still an "event". At least that's what I see when I go to create one. Where is "event" now a "reservation"?

tseager wrote:In any case, we're unable to create the "event"/"reservation" on top of a "restriction".

As long as the unit matches the restriction, there should be no problem. You can have multiple restrictions at the same time on the same resource. In that case any unit that matches one of the restrictions can schedule. For example if there's a restriction to ward A, and another for ward b, both co-exist. Either ward A or ward B can schedule, but ward C cannot. (This is also new. Before the end result was that no one could schedule. That was a bug.)

tseager wrote:In the past, we were able to do so as long as criteria were met.

In the past - as a building scheduler - restrictions didn't affect you. They only affected non-building schedulers.

tseager wrote:However, if you select "stake" as the unit, then any ward could utilize the resource.

Hmmmm. I've always assumed that "stake" meant stake-level calendars only, not any unit in the stake. The help file doesn't seem to address this, so I'll have to ask.

russellhltn wrote:

tseager wrote:However, if you select "stake" as the unit, then any ward could utilize the resource.

Hmmmm. I've always assumed that "stake" meant stake-level calendars only, not any unit in the stake. The help file doesn't seem to address this, so I'll have to ask.

You don't have to ask. I guarantee that a restriction for the "stake" means that only the stake unit can schedule an event on top of the restriction. Wards cannot schedule on top of the restriction. I've verified this in the past, and double-checked it today.

aebrown wrote:However, the term "event" is still the correct term. That is clearly the term used throughout the Calendar application. I was disappointed to see the term "reservation" used in the updated documentation in a few places; there's no reason to introduce that term when "event" is perfectly clear and doesn't carry the baggage of the term formerly used for restrictions.

I'm happy to report that the places in the documentation that incorrectly used the term "reservation" to refer to events have been fixed. I reported them a few days ago using the RKATS comment feature, and they have been promptly addressed.

There are still two articles (Managing Locations and Subscribed Calendars and Locations) that have not been updated and use the old term "reservation" to refer to "restrictions", but I've reported those as well and hope that they will be updated soon.

aebrown wrote:

aebrown wrote: There are still two articles (Managing Locations and Subscribed Calendars and Locations) that have not been updated and use the old term "reservation" to refer to "restrictions", but I've reported those as well and hope that they will be updated soon.

I must have happened upon the documentation during those few days. Glad to see it is called an event, and as you say, without the baggage.

aebrown wrote:

russellhltn wrote:

tseager wrote:However, if you select "stake" as the unit, then any ward could utilize the resource.

Hmmmm. I've always assumed that "stake" meant stake-level calendars only, not any unit in the stake. The help file doesn't seem to address this, so I'll have to ask.

You don't have to ask. I guarantee that a restriction for the "stake" means that only the stake unit can schedule an event on top of the restriction. Wards cannot schedule on top of the restriction. I've verified this in the past, and double-checked it today.

Good to know. Didn't realize this was the case, and thought we had used restrictions and calendars by assigning "stake" and allowing any ward to create events.

russellhltn wrote: As long as the unit matches the restriction, there should be no problem. You can have multiple restrictions at the same time on the same resource. In that case any unit that matches one of the restrictions can schedule. For example if there's a restriction to ward A, and another for ward b, both co-exist. Either ward A or ward B can schedule, but ward C cannot. (This is also new. Before the end result was that no one could schedule. That was a bug.)

Very interesting. Would not have thought to use it this way. This will allow our stake to use the calendar in new ways.

Thank you both for your helpful posts. It helped me narrow down the issue. I discovered that we were able to create events on top of reservations for all but this one reservation. I also noticed that I was *unable* to save the "restricted to" value on this one particular restriction. Pointed to corruption. I deleted and recreated the restriction with the same values and . . . . it worked!

Thank you very much for helping me narrow it down, and help us learn about the changes and other features of the calendar.

tseager wrote:and . . . . it worked!

Glad to hear that it worked.