Defaults and Inheritance

Overview

Defaults streamline device management and capture workflow because they:

• Allow you to define settings shared among various objects at a global level
• Pass the setting values down to the related objects, such as devices, sections, and schedules

Passing these settings down is referred to as inheritance. Because objects inherit settings from the defaults, you do not have to set them manually. This simplifies tasks such adding a new device or creating a new schedule.

Concepts and Rules

As you work with defaults, understand these concepts.

• Defaults. The settings for a particular object before you customize the settings.
• Inheritance. The setting of one object is automatically given to a related object further down the inheritance chain.
• Inheritance Chain. The inheritance levels for an object.
• Override. Changing a default setting.
• Object. An entity created and managed by EchoSystem, such as a room or section.

These rules also apply:

• Any default setting can be changed on an object's settings page.
• Changes to a setting in the parent organization apply to all existing objects, except that:
• If you override a default setting for an object, changes to that setting up the inheritance chain will not change the overridden value.

Where Do Defaults Come From?

Defaults are set in different ways, depending on the object.

• Device defaults are set on the Device Defaults page (Configuration > Device Defaults). These are inherited directly by the devices, not via a parent or child organization. See Manage Device Defaults for details on each setting. These settings can be changed (see About Devices) and the new defaults will be passed down to new devices.
• System defaults are set on the System Settings page (System > System Settings).
• Organization defaults are set on the parent organization. These settings can be changed (see Manage Organizations) and the new defaults will be passed down from the parent to the child organization.

Inheritance

If your EchoSystem Server (ESS) has a hierarchy of parent and child organizations, the inheritance chain has four levels for most objects:

• Level 1: Parent organization.
• Level 2: Child organizations. Child organizations inherit properties from the parent organization. Example: the law school inherits the Product Group settings from the parent organization.
• Level 3: Objects or sections inherit properties from the child organization. Example: A section inherits the Product Group settings from the child organization.
• Level 4: Schedules inherit properties from sections. Example: a schedule inherits the Product Group settings from the section.

If you do not implement delegated administration (and therefore do not have a parent-child hierarchy), the chain has three levels: Level 2, the child organization level, is eliminated. Objects or sections inherit settings directly from the parent organization.

This inheritance chain does not apply to devices, which inherit their settings directly from the device default settings.

For the most part, system settings are not inherited. One exception is the Academic Staff Upload Properties, which are set at a system level (System > System Settings), then inherited by individual Academic Staff.

Inheritance When You Change an Object's Organization

When you change an object's organization, the object's properties may not inherit as expected.

An object's properties will be handled in these ways:

• No customization rule. If the object's properties have not been customized, it has the default values of its parent. When you move the object to a new organization it inherits the default properties of its new parent.

  No Customization Example

  Room 667 was owned by Echo360 University. The Administrator of Echo360 University did not change the Admin User Name for the Ad Hoc Interface (capture appliance) from the default value. It is Admin. Now you move Room 667, giving ownership to the engineering school. The engineering school has also preserved the default value of this setting. After moving, the value remains Admin.

• Customization rule. If the object has a customized property, the customized property is preserved when the object is moved to a new organization.

  Customization Example

  Room 667 was owned by the law school, which customized the Admin User Name to Judge. Now you move Room 667, making it part of the engineering school. The Admin User name remains Judge. If the engineering school has a different Admin User Name (Admin, Design), you will have to change the Admin User Name for Room 667 in the ESS interface, by navigating to the room details page for Room 667.

The customization rule does not apply if you specify the value of a property on a spreadsheet and import the property using the import/export method; the value on the spreadsheet overrides any other value.