<< Click here to display Table of Contents >> Navigation: Calpendo Configuration Guide > Workflows > Workflow Events:

Booking Rule Workflow Event

Contents

When a booking is created or updated, Calpendo checks its Rules. Each time a rule is run, it will check to see if there are any Booking Rule Workflow Events to fire. An event will be triggered once when rules are checked, and then once again for every rule. The event provides in its output the rule that it was triggered from. If that rule is null, then this is the invocation called at the beginning of checking rules. Otherwise, it's being invoked for a particular rule.

Event Properties

As well as the standard properties that can be set on all events, the following properties can be set on this type of event:

Property	Type	Description
Booking Biskit Type	Biskit of type BiskitDef that must be a subtype of Booking	The subtype of booking that this event should apply to. This defaults to the top-level Booking type, but you can restrict it to only responding to a more specific subtype of Booking.
Rule Biskit Type	Drop down of all available rule types	The subtype of rule that should trigger this event.
Create Events	Boolean	true if this event should be triggered when rules are responding to a request to create a booking, and false if we should ignore booking creation events.
Update Events	Boolean	true if this event should be triggered when rules are responding to a request to update a booking, and false if we should ignore booking update events.
Accepted Events	Boolean	true if this event should be triggered when a rule indicates an acceptance level of Accept, and false if we should ignore booking Accept events.
Rejected Events	Boolean	true if this event should be triggered when a rule indicates an acceptance level of Reject, and false if we should ignore booking Reject events.
Warned Events	Boolean	true if this event should be triggered when a rule indicates an acceptance level of Warn, and false if we should ignore booking Warn events.

Note that you must choose choose whether the rule should be triggered by a booking being created, a booking being updated, or both. Set at least one of Create Events or Update Events to true, otherwise a Booking Rule Workflow Event would never be triggered.

Once you've decided whether to be triggered by a create or update, then you must also decide whether this event should be triggered by a rule that has decided to accept, reject or warn about a booking. Again, you must set at least one of these to true, or else the event would never be triggered.

Properties Available for Child Actions To Use

The following properties are available for use in any child or descendant action:

Properties	Type	Notes
oldBooking	Biskit of type Booking	The booking as it was before the change that triggered rules.
newBooking	Biskit of type Booking	The booking as it is after the change that triggered rules, and after any changes that may have been made while checking rules.
rule	Biskit of type Rule	The rule that triggered this particular invocation of the rule event. If this is null, then this is the invocation that happens at the start of checking rules. Otherwise, it's being called for a particular rule.
realUser	Biskit of type User	The real user that has caused this event to happen. This would normally be not null, but could be null.
pretendUser	Biskit of type User	The pretend user running this rules request. It can be different from realUser when using the rule validator.
output	String	A string produced by the rule. This is not normally seen by the end users, but can be useful in the rule validator to see information about what the rule did.
update	Boolean	true when rules are called due to a booking being updated, and false when rules are called due to a booking being created.
validatorOnly	Boolean	true when rules are running from the rule validator.
rulesResult	Biskit of type RulesOutcome	A Biskit of type RulesOutcome, defined below.
repeatsAffected	JavaEnum - drop down of: •This item •This and later items •All items	Indicates which repeats are affected by the change. Only relevant for repeat bookings. For non-repeat bookings, this will be null.

This is the content of the RulesOutcome biskit:

Properties	Type	Notes
rejectionLevel	Drop down of Accept, Warn, Reject	The result of running the rule.
message	String	The message generated by the rule to be given to the user
ruleName	String	The name of the rule that generated this outcome.
tryBookingRequest	Boolean	true if the rule recommends retrying the booking as a request because it may change the result, and false if there is no recommendation to retry as a request.
tryBookingTentative	Boolean	true if the rule recommends retrying the booking as tentative because it may change the result, and false if there is no recommendation to retry as tentative.

You can modify the properties on the rulesResult. Note that you should only set something here if you want the rejection level to be at least as high as the one already set in the rulesResult. The order of the rejection levels is Accept, Warn, Reject.

If you were to set the rejection level to Accept regardless of what was already there, then you could be overwriting previous results and making it seem that a rule that had failed had actually passed.

If multiple booking Rule events could be called for the same booking then making sure only the highest level is reported is down to the programmer. (Unlike Rules which always set the highest level no matter the order they are run in)