Cabinets and folders

25Live uses the concept of cabinets and folders to house and organize events in your Series25 database in a particular hierarchical structure, as shown in the illustration in “The Event Type Hierarchy”

The structure and type properties you’ve defined in your Event Type Hierarchy control the cabinets, folders, and events in your event structure. See “The Event Type Hierarchy” for detailed information on the Event Type Hierarchy and how to create it using the 25Live Administration Utility.

Your event cabinet and folder structure:

• Allows you to enter certain data at the cabinet and/or folder level that is automatically inherited down to all folders within the cabinet and events within each folder to save data entry time and ensure data consistency (see “Cabinet and folder data and data inheritance”)

• Allows you to simplify the scheduling environment for different users by allowing them to access only the cabinet(s) and/or folder(s) in which they’re permitted to save events. For example, Scheduler A can save events in the “Main Campus” folder, but can’t see or save events in the “Law School” folder. The ability to see, edit, and create events in particular cabinets and folders is controlled by the object security on those cabinets and folders for each security group.

• Allows you to control via object security who can create and update which cabinets and folders; for example, allowing some users to update particular cabinets and their folders, and allowing others view-only access to the same cabinets and folders.

See the 25Live Security Administration Guide, accessible by clicking Help, for information on setting object security on cabinets and folders.

You can enter data of the following types for cabinets and folders:

You can enter data of the following type for folders:

Some data entered for particular cabinets and folders in your event structure is inherited by folders and events within the cabinet or folder, as shown here:

	Constraints	Event Categories	Organizations
Cabinet	Can add and edit constraints	Can add and edit event categories	N/A
Folder	Inherits constraints from cabinet Can add and edit constraints	Inherits event categories from cabinet Can add and edit event categories	Can add and edit organizations
Event	Inherits constraints from folder Can add and edit constraints	Inherits event categories from folder Can add and edit event categories	Doesn’t inherit organizations from folder Can add and edit organizations

• Dates for the Thanksgiving holiday set for a cabinet are inherited by all the cabinet’s folders and by each folder’s events.

• A folder that contains imported class sections has an event category that identifies the term. All events within the folder inherit that term category.

Constraints define when events can’t or shouldn’t occur. They are very useful in:

• Preventing users from scheduling events for periods when no events should occur, such as during holidays and breaks when the campus is closed.

• Warning users of special campus periods, such as commencement or homecoming, when they might not want to schedule competing events.

The constraints inherited by an event from its folder or cabinet and/or defined for the event itself work together with the dates/times defined for the event to determine the event’s actual dates/times.

For example, the BIO301 class meets every Monday, Wednesday, and Friday at 9 a.m. from August 26, 2019 through December 13, 2019. The event has inherited several date/time constraints from its cabinet that prevent classes from being scheduled on the following US holidays: Labor Day, Columbus Day, and Thanksgiving (Thursday - Friday). When the date/time definition is created for the class, the occurrences that would fall on the constraint dates are automatically removed, as are their location and resource assignments. For example, there won’t be an occurrence or a location or resource assignment for the Friday following Thanksgiving day.

Date/time constraints aren’t calculated into space utilization

Because they’re event-specific, date/time constraints aren’t calculated into space utilization. If you want to be sure constrained time on locations is accounted for in 25Live space utilization reports, set blackout dates on locations for campus holidays and other defined constraint dates/times.

For information on defining location blackouts, see “Adding a location”.

When you create a constraint, you can choose one of two constraint types:

An Exclude constraint identifies dates/times when events can’t occur. For example, you could define constraints that exclude events on Labor Day, Columbus Day, and the Thanksgiving holiday. These constraints would cause these days to be automatically excluded from the defined dates/times of events.

A Warning constraint allows schedulers to determine whether or not to schedule events during date/time constraint periods. When a location is assigned to an event with a warning constraint attached, a message informs the scheduler that the event violates a constraint. The scheduler is free to decide whether to change the dates/times of the event or ignore the warning.

For example, a warning constraint might be appropriate in a special events cabinet where you want to define a constraint for the Christmas holidays but also permit schedulers to use their discretion about scheduling an event for that time period. A concert might be appropriate, while an extension class might not. Another warning constraint might require that activities in the Continuing Education folder start only after 4 p.m. When a Spanish for Travelers class is saved to the folder with a Thursday meeting time from 3:00 p.m. to 6:30 p.m., a warning would be displayed.

Warning constraints are most useful for non-academic events where you want to leave it up to the scheduler to determine whether excluded dates/times should apply to a particular event.

When you create a cabinet, you must define its date boundaries. Date boundaries are the earliest (start date) and latest (end date) any event within the cabinet can occur. The date boundaries of a cabinet are automatically inherited by the folders within the cabinet. You have the option of changing the date boundaries of folders as needed, but they must be the same as or within the date boundaries of their cabinet.

You can set end dates fairly far into the future. For example, the date boundaries of the “Cabinet/folder example” are January 1, 2015 to December 31, 2025, as are the date boundaries of each of its folders.

25Live uses a default routing rule to determine where to place new SIS classes imported into 25Live in your event structure. You should build your cabinet/folder event structure to use the default routing rule.

The default routing rule uses these conditions to determine which folder an imported class should be placed in:

• Organization
If more than one folder meets both the above conditions, 25Live looks for a folder with the same associated organization as class.

• Event category
If more than one folder meets all the above conditions, 25Live looks for a folder in the same event category as the class.

How object security affects routing

Object security also plays a major role in routing. The LYNX Interface user must be able to save the class to the folder identified by the default routing rule based on the user’s object security rights to that folder. We recommend, therefore, that you make the LYNX user a member of the System Administrators (-1) security group, or another security group that has global rights to save events, to minimize routing issues.

The example event structure below is based on the Event Type Hierarchy described in the “A little more complexity” example. In it, we’ve create two cabinets: Classes and Events. In the Classes cabinet, we’ve created two folders: Class Section and Class Sections Law. In the Events cabinet, we’ve created a single Special Events folder. The folders in each cabinet automatically inherit the date range of their cabinet.

The Class Section and Class Sections Law folders will contain all class sections imported from the SIS that fall within the date range of those folders (both folders have the same date range inherited from the Classes cabinet). Both folders have a “Section Group” folder type. What distinguishes Law sections from all other sections is the subject code organization we’ve associated with the folder—LAW. Based on the system's default routing rule, imported law school sections (those with LAW as their associated organization) will be routed into the Class Sections Law folder because that folder has the LAW organization associated with it.

All other sections will be routed into the Class Section folder, because we’ve associated all subject code organizations other than Law with that folder.

Events with a Conference Event, Meeting/Gathering, or Student Activity event type that fall within the date range of the Special Events folder will be placed in that folder. We selected the “University Activity” category for that folder, so all events in it will automatically inherit that category for event searching and reporting purposes.