This is split into two sections:

 

Applies To: Determines the bookings that the Booking Rule applies to.

 

Does Not Apply To: Determines the bookings that the Booking Rule does not apply to.

 

In addition some rules have the option to define the bookings to be counted or ignored when applying the Rule. These are normally called Bookings To Count/Bookings To Ignore but may have slightly different names for different Rules.

 

By default a Booking Rule will apply to all bookings, so if there is nothing in both Applies To and Does Not Apply To then the Booking Rule will apply to all bookings. Therefore using Does Not Apply To only the bookings the Booking Rule does not apply to can be specified. Also combine the two types and a Booking Rule will apply to a booking as long as its accepted by the Applies To but not accepted by the Does Not Apply To. Of course Applies To can be used by itself to figure out which bookings a Booking Rule will apply to.

 

Bookings to Count/Ignore work in a similar way to Applies To/Does Not Apply To in that bookings are counted using the definition in Bookings To Count, as long as they do not also fall under the Bookings To Ignore definition.

Applies To

When running Booking Rules, Calpendo must decide which Booking Rules apply for a given booking change that a user is trying to make. To do this, Calpendo first looks to see which Booking Rules are marked as enabled. Then, it looks at whether the Booking Rule says it applies when a booking is created, when a booking is updated, or both.

 

Beyond those simple properties, every type of Booking Rule provides additional tabs in which you can identify the bookings it should apply to as follows:

 

 

 

Within each activated tab (Statuses, Bookers, Owners, Projects, Resources) if a booking passes any one of the sections set up in that tab then the booking will be accepted for that tab. So if there are items in more than one section of a individual tab (i.e. groups, types etc.) then if any of the sections within a tab is true, then the tab is true. This if a Booking Rule is applied to project type P and project group G, then the Booking Rule applies to projects of Type P or any projects in project group G. (The project doesn't have to be both of Type P and in Group G for it to pass, just one of them). If may be required that the Booking Rule may only want to apply when the project is in a particular group and also has a particular project type. In order to achieve this, specify the project group in the Projects tab, and then add a Condition in the Conditions tab to require that the project type be what is required.

 

In order for a booking to be finally accepted it must be accepted in all the activated tabs. So if Bookers and Resources are activated and there is also a Condition then the booking must be accepted in each of the three tabs in order to be finally accepted. If it is accepted by only one or two of these tabs then it will be rejected.

Does Not Apply To

Finally, as well as allowing the specification of bookings the Booking Rule does apply to, it also allows the same sort of specification for those it does not apply to. Sometimes it may be easier to say which bookings a Booking Rule shouldn't apply to, and sometimes it's easier to target the bookings required by specifying some things in the Applies To section, and some other things in the Does Not Apply To section.

 

Does Not Apply To works in exactly the same way as Applies To.

 

For example, a Booking Rule may be needed that is to be applied to most people, but a small number of people should be exempt (perhaps because they are administrators or heads of group). Implement this by creating a user group with all the people such a Booking Rule should apply to. However, user groups tend to work best when a small number of users belong to them - otherwise maintaining the groups with the right membership can become onerous. It's therefore easier to maintain a user group of the people that should be exempt, and adding them to the Does Not Apply To section.

 

If users are classified by assigning them all a user type, then create a Booking Rule which targets a particular user type in the Applies To section, but then removes some users from that selection by the use of a Does Not Apply To specification of users.

 

To see examples of what can be done with this way of choosing which bookings a Booking Rule should apply to, please see the examples shown for Simple Booking Rule.

 

One problem to be wary of is setting Admin in the Bookers of Does Not Apply To and having something in the Condition tab as well and expecting Admin too always be exempt. They will only be exempt if the Condition also applies. In this case add a Condition of Meta-property user.roles includes any Admin.

Bookings To Count/Bookings To Ignore

Some Rules allow the defining of the Bookings that will count or be ignored by the rule (there are slightly different names for the tabs depending on the Rule they are used in). These are Total Time Booked (Bookings To Include In Count) , Number Of Bookings, Interval (Preceding Bookings, Following Bookings) and Double Booking rules.

 

There are special options available within the tabs.