An explanation of Context

A Reservation's context consists of four parts

  1. Resource Type

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

  1. Reservation Type

The Reservation Type of the reservation. Not applicable for a resource display context.

  1. View

The View the reservation or resource is currently shown in

  1. Calendar

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 :

Resource Type

MeetingRoom

Reservation Type

Meeting

View

WeekView

Calendar

Resources

But if the user changes to the view DayView the context would change to:

Resource Type

MeetingRoom

Reservation Type

Meeting

View

DayView

Calendar

Resources

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:

  1. Matching resource type

  2. Matching reservation type

  3. Matching view

  4. matching calendar

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:

Context name

  1. Resource Type

  1. Reservation Type

  1. View

  1. Calendar

Context name

  1. Resource Type

  1. Reservation Type

  1. View

  1. Calendar

Fallback Context









Meeting Context



Meeting





Staff Meeting Context



Meeting



Staff Calendar

Staff Calendar Context







Staff Calendar

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.