User Group Assignment by Inheritance

Objects inherit the user group assignments of their container object. You can explicitly revoke an inherited user group assignment for a particular object if necessary.

For example, if you assign a user group to a Domain, the system assigns that user group by default to all child objects as they are created: the child Domains in the Domain (if any), all the Application Areas in the Domain and in all of its child Domains, and all the object definitions and Work Areas in the Application Areas, all the object instances in the Work Areas, and all the execution setups and outputs of all the object instances. See Figure 4-2 and Object Ownership to see these relationships displayed graphically.

Assignment revocations are also inherited. If you explicitly revoke the inherited user group assignment to a particular Application Area within the Domain, the user group is also no longer assigned to any of the object definitions or Work Areas contained in the Application Area.

Because user group assignments are inherited, in general it is best to create user groups with narrowly defined roles to assign to Domains. Assign users to roles with maximum privileges at the level where they will primarily work: for Definers, the Application Area (to allow creating object definitions through instances in the Work Area). Put Consumers in a user group assigned to the production Work Area so they can see and execute Execution Setups and outputs. See Example of Security Design.

Figure 4-2 LSH Object Ownership

Description of "Figure 4-2 LSH Object Ownership"

Note:

*Execution Setups, jobs and outputs are contained in instances of executable objects only—not in Table or Business Area instances.

Figure 4-2 shows the containers that constitute the organizational structure—Domains, Application Areas, and Work Areas—and the object definitions or instances they contain.