Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Domain support for schedules

Log in to subscribe to topics and get notified when content changes.

Domain support for schedules

Domain separation is a way to separate data into (and optionally to separate administration) by logically-defined domains. You must activate the Domain Support [com.glide.domain] plugin to enable the domain separation functionality for schedules.

The records in the Schedule [cmn_schedule], Schedule Page [cmn_schedule_page], and Timeline Page [cmn_timeline_page] tables have a defined domain. The child tables use the domain_master attribute to derive the domain from the parent table. You can find the domain_master attribute on the dictionary record for the respective table.

The following diagram illustrates the scope of domain separation in different schedule tables:
Figure 1. Domain support for schedules
domain support for schedules

Custom domain support implementations

When you migrate to the new release (madrid) with a custom implementation of domain support for schedule related tables such as Schedule Entry [cmn_schedule_span], support for domain separation is not automatically introduced. This is to avoid changing any specific configurations that you may have in place.

To implement the base system domain support for schedules, a sys.script utility is provided. To run this utility navigate to Background > Scripts – Background . The script is listed under the com.glide.schedules plugin as fix_schedule_domain_support.js.

The utility attempts to add the Domain [sys_domain] column to the Schedule [cmn_schedule], Schedule Page [cmn_schedule_page], and Timeline page [cmn_timeline_page] tables. It then attempts to add the domain_master attribute to the Schedule Entry [cmn_schedule_span], Other Schedule [cmn_other_schedule], Timeline Sub Item [cmn_timeline_sub_item], and Timeline Page Span Style [cmn_timeline_page_style] tables. If the script finds existing records between a child and parent record that have differing domain then the script does not introduce the domain_master attribute to the child table.

For example, considering the relationship of the Schedule [cmn_schedule] (parent) and Schedule Entry [cmn_schedule_span] (child) tables, if the upgrading instance has the Domain [sys_domain] column available on both tables then the utility is required to migrate to the base system implementation of domain support for schedules as it is not migrated automatically. If the script detects that there are records where the child Schedule Entry [cmn_schedule_span] domain differs to its parent Schedule [cmn_schedule] domain then it stops executing and logs a warning with the same reason. If the script does not find any differing records, it proceeds to deactivate and limit read access to the Domain [sys_domain] and Domain Path [sys_domain_path] columns on the Schedule Entry [cmn_schedule_span] table. Finally, the script adds the domain_master=schedule attribute to the dictionary file for the Schedule Entry [cmn_schedule_span] table.
Note: The domain_master attribute ensures that the domain between a child and parent record remain the same as the domain for the child is derived from the specified reference field.