- This line was added.
- This line was removed.
- Formatting was changed.
A Reservation's context consists of four parts
The Resource Type of the resource the reservation is shown in, or the Resource Type of the resource. Only applicable on the Resource Calendar and only part of the context for backward compatibility with the old Reservation_Display__r.ResourceType__c field
The Reservation Type of the reservation. Not applicable for a resource display context.
The View the reservation or resource is currently shown in
The Calendar the reservation or resource is currently shown in
So for example a reservation of type: Meeting, with B25__Resource__c = MeetingRoom 1 (of type MeetingRoom), being viewed on the Calendar called Resources on the View WeekView, would have the context of :
But if the user changes to the view DayView the context would change to:
Determining what context will be used to determine what hover and what titles will be shown.
When determining what context to use, Booker25 compares the reservation context or the resource context to all contexts that have been defined.
First, all contexts with conflicting values are discarded. This means that if the Reservation for example has Reservation Type: Meeting room, all Contexts that have Reservation Type filled in with a different value will be discarded. If a Context has no value in the Reservation Type field, it will not be discarded.
Second, the remaining contexts are ranked in the following way:
Matching resource type
Matching reservation type
Empty values do not count as a match.
If two contexts both have a matching value at the same level, they are then ordered based on lower level matches. The context with the highest ranking will be used to determine what titles and hover to use.
Now follow a few examples of what context would match in certain situation using the following contexts:
Staff Meeting Context
Staff Calendar Context
A Reservation with Reservation Type: Meeting on the Resource Calendar will use the Meeting Context. The Staff Meeting Context is discarded because the Calendar has a conflicting value and the Fallback Context has no matches to add to it's rank.
A Reservation with Reservation Type: Meeting on the Staff Calendar will use the Staff Meeting Context. Both Meeting Context and Staff Meeting Context match on the Reservation Type. They are further ranked based on lower level matches, in this case Calendar. It will not use Staff Calendar Context because Reservation Type is a higher ranking match.
A Reservation with Reservation Type: Holiday on the Resource Calendar will use the Fallback Context. Both Meeting Context and Staff Meeting Context have a conflicting value for Reservation Type and Staff Calendar Context has a conflicting value for Calendar.
A Reservation with Reservation Type: Holiday on the Staff Calendar will use the Staff Calendar Context. First, Meeting Context and Staff Meeting Context are discarded, based on the conflicting value in Reservation Type. Then, Staff Calendar Context has a higher match with the Calendar, over no matches for the Fallback Context.
Sharing and contexts
Be careful when using Sharing on Contexts. When a user can see two or more Reservation Display Context records with the exact same context, Booker25 does not know which Context to prefer and picks one at random.
When Sharing is set to Private for Reservation Display Contexts, you can show different titles and hovers for different users, based on what context is shared with them. Booker25 normally prevent duplicate contexts to be inserted, to prevent ambiguity as to what context to show. When checking for such duplicate Contexts, Booker25 takes in to account the Sharing Identifier field. Use this field to identify with what Public Group of users this record is shared, and Booker25 will allow you to insert duplicate contexts if the value of this field is different.
On this page