Beyond the standard settings for selecting which bookings it applies to, a Simple Booking Rule only specifies three things:

 

 

 

Please note that there is no intelligence here to decide whether or not to reject booking or give the user a warning - all the logic supported by a Simple Booking Rule is in the selection of the bookings the Booking Rule applies to. While it may seem that this would make a Simple Booking Rule somewhat limited in scope, you can achieve quite a lot with it, as shown by the following examples.

Example: Disallowing Bookings More Than 6 Weeks In Advance

Suppose that the resources are very busy, and people are responding by booking well into the future, just in case they will have a need. So its decided to stop this behaviour by disallowing bookings more than 6 weeks away.

 

This result can be achieved with Permissions, although that wouldn't allow a nice error message to the user - they would just receive the standard Permission Denied message.

 

This can also be done with a Time Template as well as a Booking Rule, and it's probably better to do it with a Time Template so that the user would get feedback before they try to make such a booking. However this example may be helpful.

 

To do it, create a Simple Booking Rule with Change Type of Create and Update and add this as the Condition:

 

 

This adds 6 weeks to the current time (the time when the user tries to make a booking), and then tests whether the booking starts (dateRange.start) after that time, when both times are rounded to the nearest minute. If the booking starts after the 6 week time, then the condition is true, and so the Booking Rule applies.

 

Please note that if repeats are allowed the Global Preference->Bookings->Number of Days of Bookings to check for repeat bookings must be larger than the number of days you are checking for by 1-2 weeks to stop repeat bookings going after that time, depending on what type of repeat is being used. A better option would be:

 

Example: Physicist Projects Can Book 4 Weeks In Advance, Biologists 6 Weeks

This expands on the previous example, but this time we want to have a different time limit depending on the project used to make the booking. Again, this could be done with Time Templates, but we'll show how to do it with Booking Rules.

 

Create two Simple Booking Rules this time with Change Type of Create and Update, one to prevent physicists from booking too far ahead, and one to prevent biologists from booking too far ahead. The physicists' Booking Rule would look like this:

 

 

and the biologists' Booking Rule would look like this:

 

 

This assumes that project types are used to classify the projects. An alternative would be to name the projects individually in the Booking Rule, or else create project groups and use those instead.

Example: Special Projects Can Book Any Time In Advance

Now suppose that there is a project group that lists Special Projects that should be allowed to book as far into the future as it wants to. A good example of this is if your resource needs regular maintenance and so you set up a Maintenance project. Most probably associate a small number of users with this project, to restrict who can create such bookings.

 

Modify the physicist and biologist Booking Rules from the last example so that each of them adds to the Does Not Apply To section:

 

 

The effect of this is that whenever a booking is made for a project in the Special Projects project group, the Booking Rules we created above no longer apply, and so it removes the restriction about how far into the future such bookings can be for.

Example: Special Projects And Admins Can Book Any Time In Advance

Now suppose that as well as allowing Special Projects to be allowed to book as far into the future as they want to, administrators need to be able to make bookings for any project well into the future. The users to be excluded from the time limit could be specified by listing them individually, by their user role or by creating a user group for it. Any of these would be sensible, with the choice depending on how Calpendo should be set up to meet your general requirements.

 

Let's suppose we want to allow users with the Admin user role to book well into the future for any project. Then the physicist and biologist Booking Rules could be changed from the previous example so that their Does Not Apply To sections contain this:

 

 

However, this is probably not what is required. With this prescription, any booking whose Booker property is set to Admin and whose project is in the Special Projects group will be allowed to book well into the future. For a Booking Rule such as this, it may be required to exclude a booking from the Booking Rule if the project is "special" or if the booking were made by an administrator. To achieve this, replace the Bookers entry with a condition, like this:

 

 

Note that we also put the condition on the Applies To section. Had we used a condition in the Does Not Apply To section, then we would still have required all of the Does Not Apply To to be applicable for the exclusion to work.

 

There's also another caveat to this example: if the Permissions do not stop non-administrators from making a booking with the booker property set Admin, then a non-administrator could work around this Booking Rule by setting the booker to somebody else when they create the booking. This practice can be stopped with Permissions, but can also be stopped by making the condition in the Booking Rule checked the user that performed the change, rather than the booker property of the booking. This is shown in the next example.

Example: Prevent Cancellations With Less Than 24 Hours To Go

Depending on the policies employed at the facility, last-minute cancellations may need to be prevented apart from those made by an administrator. This will require a Booking Rule that targets changes to bookings that result in the booking status changing to Cancelled from something else, that was made within 24 hours of the booking time, and that the change was not made by an administrator.

 

This can be done with a Simple Booking Rule with Change Type of Update that has the following added to the Applies To section:

 

 

There are some important things to note about these conditions:

 

•By checking the meta property called user, person that makes the change is being checked, regardless of who is set to be the booker or owner of the booking.

•We could have moved the user.roles check to the Does Not Apply To section by negating the sense of the condition. That is, by adding a condition to the Does Not Apply To section that said Meta property user.roles includes Admin. This would have been functionally identical, as long as there were no other entries in the Does Not Apply To section.

 

In the Rule Tab, enter a message to be displayed to people who try to cancel within 24 hours of the booking.