Description of 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 this illustration.
The structure and type properties you’ve defined in your Event Type Hierarchy control the cabinets, folders, and events in your event structure. See Event Type Hierarchy Overview.
Purpose of Cabinet and Folder Structure
Your event cabinet and folder structure:
- Lets 25Live know where to place new classes imported into 25Live from your SIS and new events created in 25Live
- 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
- 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.
Data and Data Inheritance
Types of Data You Can Enter for Cabinets and Folders
You can enter data of the following types for cabinets and folders:
- Event Categories
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:
|Cabinet||Can add and edit constraints||Can add and edit event categories||N/A|
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|
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
Data Inheritance Examples
- 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.
Not applicable if you use LYNX
The information in this section is not applicable if you're using the LYNX Interface which includes its own more sophisticated functions for defining date exceptions to your course schedule. If you're using LYNX, set date exceptions there rather than defining constraints in the 25Live Administration Utility.
Constraints defined in the 25Live Administration Utility define when events can’t or shouldn’t occur. They are 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
How Constraints Affect 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.
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.
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.
It is generally best practice to set wide date boundaries. For example, you might set the date boundaries of a cabinet as January 1, 2020 to December 31, 2030. Setting wide date boundaries helps ensure that the Default Routing Rule described below can most effectively route new classes and events into your event structure.
The Default Routing Rule
25Live uses a default routing rule to determine where to place new SIS classes imported into 25Live and new events created in 25Live in your event structure. You should build your cabinet/folder event structure to make maximum use of the default routing rule (see Best Practices: Cabinets, Folders, and Event Types for best practices guidelines).
The default routing rule uses these conditions to determine which folder a new class or event should be placed in:
- Event type
The folder must be an appropriate folder type for the class or event, based on the event type of the class or event.
- Date range
The date range of the class or event must be the same or within the date range of its “parent” folder.
If more than one folder meets both the above conditions, 25Live looks for a folder with the same associated organization as the class or event.
- 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 or event.
In addition, the user saving the event must have permission to see the folder (Object Security = View) as well as save events to it (Object Security/Create Events = Yes).
Preventing users from seeing the "I don't know" option when saving an event
If a new event can't be placed using the default routing rule, the user trying to save the event is presented with event heading (folder) options to choose from. If the user chooses the "I don't know" option, the event is saved in a draft state. To prevent users in certain security groups from doing this, set their Events > Event Drafts functional security so they can't create event drafts.
If you don't want certain user security groups to have to ever choose an event heading, see Preventing Choosing a Heading When Saving Events.
In this example, 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.