Reservation scripts can be created and tested in the Administration -> Resources -> Scripts panel.

All reservation scripts are found under the "Reservation" tabs in the scripts administration page. To create a script, click the "Create Reservation Script" button in the top right.

You will be presented with the IDE and a script of return True. To learn more about the IDE and its workings, read up on the IDE section of the documentation.

Reservation scripts are special in what global environmental context is set. In particular, you will have access to three dictionaries by default, reservation, script, and user_logged_in. These are accessible in your script by simply using their variable names.

The reservation dictionary contains all the information about the reservation that is being made. We can use this and the Exception to gate access to a resource that has this script attached.

Below is a simple script that checks the purpose field of a reservation and then displays an error to the user if the purpose contains the word "foo".

1if "foo" in reservation["purpose"]:
2  return Exception("No foos allowed in purpose.")
3return True
Copy

Try copy and pasting this into the IDE, then click the "Save" button on the bottom right to save the script. Finally, test the script by clicking the "Test Reservation or Request" button in the top right, which will bring up the testing window. There, select a resource and then try entering "foo" into the purpose input box. You should be greeted by the error "No foos allowed in purpose."

The return True at the end of the script signals that the reservation can otherwise continue and be made by the end user.

Another caveat is that multi-resource reservations are different from single-resource reservations in their structure. Multi-resource reservations have a parent reservation and then a list of single-resource child reservations in the reservation_children key. For ease of use, when you have a script that takes into account resources you will want to use the function util.reservations.all(). This returns reservations as a list, so a single-resource reservation will be [reservation] while a multi-resource reservation will be [reservation_1, reservation_2, ... ]. Please refer to the structure of the reservation object for more information.

Exceptions and return values can also be used to modify the user interface. For example, if you wanted to add a disclaimer to the reservation when it is not blocking, you can have it return the following default dictionary: { 'disclaimer_top': "## Foo is forbidden as a reservation purpose." }. Putting it all together, the script now looks like:

1if "foo" in reservation["purpose"]:
2  return Exception("No foos allowed in purpose.")
3return { 'disclaimer_top': "## Foo is forbidden as a reservation purpose." }
Copy

When you test the script and do not have "foo" in the purpose text input, you will now see a helpful disclaimer about the purpose.

Now that we have a functional script, to use it we simply add it to a resource. This can be done in either the scripts tab when editing a resource, or on the resources tables administration page with the scripts column being selected. I titled my script "No foos in purpose".

Now that the script is added to the Testy resource, I can navigate to the Testy resource calendar and use the script in my production site environment. While this script is contrived, QReserve gives you access to a rich amount of data from both the resource and the API which you can take advantage of to ensure that resource availability is custom tailored to your individual needs. Have a look at some of the other example issues and solutions that scripts can resolve.