Calendars |
Content |
||||||||||||||||||
|
Introduction |
|
|
Calendars provide a calendar interface based on the DHTMLX Scheduler JavaScript event calendar component. For instructions regarding use and navigation of this interface, refer to the DHTMLX Scheduler documentation at https://docs.dhtmlx.com/scheduler/guides.html. In particular, see the GUI guide at https://docs.dhtmlx.com/scheduler/user_interface.html. Known differences between DHTMLX and its LabVantage implementation are noted in About the DHTMLX Scheduler.
NOTE: | This topic extensively references Department hierarchies. It is therefore recommended that you become familiar with the concepts described in Departments. |
NOTE: | In LabVantage 8.4, Calendars are used exclusively in
the WAP module, with the following
exceptions:
When upgrading to LabVantage 8.4, Schedule Plan Schedule Exclude and Stability Future Planning Calendars are automatically upgraded to the new LabVantage 8.4 Calendar. Migrated calendars are prefixed with EXC rather than CAL. |
Concepts |
|
|
Resources |
A "Resource" can be a User or an Instrument. Calendars provide the following functionality to manage Resources:
|
Appointments
Appointments can be defined for a Resource. These indicate time periods when the Resource is not available for work (such as meetings vacations for Users, maintenance for Instruments, or Department/Corporate/National holidays). Appointments can be single or recurring, and can be displayed on the Resource's Calendar. |
|
|
Core Hours Core Hours can be defined for a Resource. These indicate time periods when the Resource is available for work. Core Hours can be displayed on the Resource's Calendar. The WAP module also uses Core Hours when calculating a Resource's utilization and capacity (working versus available time). |
Core Hours and Appointments work within the Department hierarchy. For example:
• | A User can inherit both Core Hours and Appointments from the User's Default Testing Lab. Since Users are members of Testing Labs and Testing Labs are members of Sites, Core Hours defined in Site calendars are inherited by the Users in the Departmental hierarchy. Core Hours therefore need not be defined for all Users. They can be defined once for an entire Department or Shift. |
• | Core Hours and Appointments can be overridden. For example, most Users can inherit Core Hours from their Testing Lab, but exceptions can be made for individual Users. A User therefore need not attend a meeting defined for the entire Testing Lab, or can choose to work on a holiday. |
Appointments and Core Hours |
Appointments and Core Hours can be defined for the following:
|
Sites
When Appointments or Core Hours are defined for a Site, they are inherited by all Testing Labs in that Site, and from there to all "User" Resources in those Testing Labs. |
|||||
|
Testing Labs When Appointments or Core Hours are defined for a Testing Lab, they are inherited by all "User" Resources in that Testing Lab. Testing Labs can override Appointments and Core Hours inherited from their Site. |
|||||
|
Shifts When Shifts are defined for a Testing Lab, Appointments and Core Hours can be defined for each Shift. When Users are assigned to a Shift, the Users inherit their Appointments and Core Hours from the Shift (rather than the Department). Shifts can override Appointments and Core Hours inherited from their Testing Lab. |
|||||
|
Users By default, Users inherit Appointments and Core Hours from their Default Testing Lab or the Shift to which they are assigned. Users can override these inherited Appointments and Core Hours. |
|||||
|
Instruments Appointments can be defined for an Instrument,but Instruments do not inherit Appointments from their Testing Lab. Instruments may inherit Core Hours from their Testing Lab (or be overridden as shown in Example Core Hours). Defining Core Hours for Instruments can reap benefits, including visual presentation on the instrument Calendar and more accurate utilization and capacity metrics. In general:
|
|||||
|
Work Areas Work Areas do not have individual calendars or appointments. Core Hours are not directly defined for Work Areas. Work Areas can override Core Hours, but cannot set them. For utilization and capacity purposes, Core Hours for Work Areas are defined to be the longest timeframe in which Users work, and are therefore based on Users' hours. For example, if all Users in the Work Area work 0900 to 1700, those are considered the Core Hours for the Work Area. |
Private and Shared Calendars |
Calendars can be "Private" or "Shared":
|
Private Calendars Users, Sites, Testing Labs, and Instruments can have their own "Private Calendars". Private Calendars apply only to a specific SDI (the relevant User, Site, Testing Lab, or Instrument). The first time a Resource 's Calendar is viewed or edited, a Private Calendar is created for that Resource. For example, a User's Private Calendar is created when he clicks "Manage Calendar" on the User List page. |
|
|
Shared Calendars "Shared Calendars" can be shared among SDIs. In the context of Department hierarchies, this means that Shared Calendars can be used across multiple Users, Sites, Testing Labs, and Instruments. For example, a Calendar can define national holidays. If two Sites (or two Testing Labs) have the same national holidays , the same Calendar can be used for both. Only Administrators can create and edit Shared Calendars. |
Timezone Handling |
Calendars store all times and dates in the time zone of the Application Server. When viewing or saving events that do not encompass a full day and are defined by specific times, these times are converted from the Application Server's time zone to the User's time zone (and vice-versa).
Calendar Management |
|
|
Calendars can be managed at the levels of functionality described below. The mechanics of using these Calendars is described in Calendar Examples.
Shared (Global) |
Administrators can create Shared Calendars in the Calendar List page (System Admin → Scheduling & Events → Calendars). Administrators then have unrestricted access to all Calendars in the system (Private and Shared), including the ability to override any Resource's Private Calendar. An Audit View page is also provided for Administrators (Other Tasks → View Audit).
To create a Shared Calendar, simply click "Add", enter a "Description" in the prompt dialog, then click "OK".
![]() |
Department |
Departments can define Calendars using the "Manage Calendar" button in the Department List page and the "Calendars" detail in the Department Maintenance page. WorkAreas do not support calendar maintenance for the area.
In the "Calendars" detail of the Department Maintenance page, a default primary Calendar (labeled "PRIMARY") is included when a Department is created. Selecting this and clicking "Manage" creates a Private Calendar for that Department. This "primary" Calendar is always shown in the OOB configuration, but can be hidden using the "Show Primary Calendar" property on the maintcalendar Element. Shared Calendars for the Department are persisted in the SDICalendar table, thus allowing a Department to have one centralized Calendar and multiple Shared Calendars.
![]() |
"Add" and "Remove" adds/removes existing Shared Calendars to/from the Department, while "Manage" lets you edit a selected Calendar.
In the Department List page (or the WAP-specific Testing Labs List and Work Areas List), "Manage Calendar" launches the Calendar for that Department.
If the Department is a Work Area, it will only show Calendar items inherited from its parent Department.
Events created in a Department Calendar are inherited by Shifts and Users using that Calendar.
User |
Users can define Calendars using the "Manage Calendars" button on the User List page and in the "Calendars" detail of the User Maintenance page.
In the "Calendars" detail of the User Maintenance page, User Calendars operate in a manner similar to Department Calendars. A default primary Calendar is included when a User is created, the User can have multiple Shared Calendars, and the same Add/Remove/Manage functionality is provided.
A key difference between Department and User Calendars is that User Calendars are inherited from the parent Department and Shift (if used). Inherited events can then be overridden in the User's Calendar.
|
Users who have the WAP module can also manage their own Private Calendars
through the User Profile menu in the upper right of the menu bar ("View
My Calendar").
The "Hide View Calendar Profile" property in the GUI Policy allows this to be hidden, thus preventing Users from editing their own Calendar (editing would thereby require an Administrator). |
Instrument |
Unlike Department and User Calendars, Instrument Maintenance pages do not have a "Calendars" detail and cannot reference Shared Calendars.
Users who have the WAP module can create and manage Instrument Calendars from Lab Admin → Lab Instruments → Lab Instrument List. Clicking "Manage Calendar" for a selected Instrument creates a Private Calendar if one does not exist (or lets you edit an existing Calendar).
WAP |
Users who have the WAP module can also manage Calendars and Core Hours for Sites, Testing Labs, Work Areas, Users, and Instruments using the "Manage Calendar" and "Manage Core Hours" buttons on the relevant List pages in the Lab Admin → Planning tramline.
Schedule Excludes |
In LabVantage 8.4, Calendar functionality has been extended for Calendar Exclusions as noted in the Introduction.
Calendar Examples |
|
|
About the DHTMLX Scheduler |
The Calendar interface is based on the DHTMLX Scheduler JavaScript event calendar component. For instructions regarding use and navigation of this interface, refer to the DHTMLX Scheduler documentation at https://docs.dhtmlx.com/scheduler/guides.html. In particular, see the GUI guide at https://docs.dhtmlx.com/scheduler/user_interface.html.
Note these differences between DHTMLX and its LabVantage implementation:
• |
Repeat Rule In the dialog that opens when dragging to create an event, a custom "Repeat event" area has been added. This can be set to create repeating events. The LabVantage implementation offers these options:
Note that a "Yearly" rule is not offered, as the "Monthly" rule can be used to accomplish a yearly repeat (such as "every year on February 1"). |
|||||||||||
• | Full Day In the same dialog, there is a "Full day" checkbox. Checking this ignores the time set against the event and sets it to be an all day event spanning one or more days. |
|||||||||||
• |
Overriding Events If viewing a User, Instrument, or Work Area Calendar that inherits events from its parent Department (or Shift), the inherited events are shown in blue. Inherited events that have been changed (overridden) are shown in green. |
Example Appointments |
Throughout these examples, the words "Appointment" and "event" are used interchangeably ("event" being a generic term to describe any item added to the Calendar).
Appointments are color-coded:
• | Repeating Appointments that have not been inherited or overridden are shown in yellow. |
• | Appointments inherited from the parent Calendar are shown in blue. |
• | Appointments created in the current Calendar and inherited Appointments that have been changed (overridden) in the current Calendar are shown in green. |
• | "Full day" Appointments are shown in the first row (identified by the clock icon in the time column). |
The Calendar below is an example of a Shared Calendar created in the Calendar List page. This shows a repeating "Lunch" event, a single "Meeting" event, and an all day "Conference" event.
![]() |
The Calendar below is an example of a the Shared Calendar above as seen by a User who has inherited the Shared Calendar. Note the inherited events in blue. The User has added a "Dentist" appointment on Tuesday, and another "Meeting" on Thirsday. Note the green indicating the events were added to the current Calendar.
![]() |
You can override (edit) an Appointment by dragging it upward or downward. Double-clicking an Appointment opens a dialog where you can change the Description and time period:
![]() |
When you edit a repeating Appointment, a dialog asks if you want to edit the parent item or just this instance (below left). When you delete a repeating Appointment using the "Delete" button above, a similar message is shown (below right).
|
|
In both dialogs:
• | Choosing "Series" or "Delete Series" edits or deletes all occurrances of the Appointment. |
• | Choosing "Instance" or "Delete Instance" edits or deletes only the selected Appointment. |
This also works on inherited events.
These buttons are available:
• | "Return" returns to the previous page. |
• | "Undo" reverses the last action performed. Note that this is for the current session only. It resets when you leave the session and re-enter. |
• | "Change Description" (available only in Shared Calendars) lets you change the Calendar's Description. |
Example Core Hours |
In general, Core Hours are managed using the "Manage Core Hours" button in the same areas as Appointments (as decribed in Calendar Management) with the following exceptions:
• | When editing a Calendar In the Calendar List page (System Admin → Scheduling & Events → Calendars), the "Manage Core Hours" button is provided only for Private Calendars. |
• | Schedule Excludes do not define Core Hours. |
To demostrate overrides, this example uses the "Manage Core Hours" button in the Department List page to first set Core Hours for a Site, then override the inherited Core Hours in the Site's Testing Lab. Remember that Core Hours are inherited and can be overridden throughout the Department hierarchy. We are using a Site and its Testing Labs as an example.
In the absence of any other configuration, the system defaults to 9 to 5, Monday through Friday (below). You can set the Core Hours here:
![]() |
If you go to one of the Site's Testing Labs, the Site's Core Hours are grayed out to indicate they are set farther up in the hierarchy. You can then check "Override Core Hours" to change the hours.
![]() |
Times outside of the Core Hours are grayed out in the Calendar:
![]() |
Importing External Calendars |
|
|
The "Import iCAL" button on the Calendar List page lets you dynamically import Appointments from an external iCAL (iCalendar) provider (https://en.wikipedia.org/wiki/ICalendar).
Clicking "Import iCAL" prompts for the URL to the iCAL stream ("External iCAL URL") and a "Calendar Description". Clicking "OK" reads the iCAL stream on-demand and refreshes the page
Editing the imported Calendar parses out the iCAL stream and shows the Calendar events. The imported iCAL is cached for 60 minutes. You can manually refresh the iCAL stream using the "Refresh" button.
External calendars can be used as Shared Calendars for Departments, Users and Instruments. WAP availability rules consider external calendar Appointments. However, you cannot modify or override external calendar items or modify an instance in an inherited external calendar.
When viewing an iCAL feed Calendar, an "Import" button is provided to convert the iCAL to a LabVantage Calendar. This will not be updatable from the iCAL feed, but does allow local changes.