Permissible objects

Permissible objects are configuration objects to which restricted roles can be assigned. Permissible objects have both use and visibility (private or public) aspects controlled by user roles.

A role can have a server group restriction or data visibility group restriction or both. When restricted roles are assigned to IBM® Sterling Control Center Monitor building blocks, users with IDs assigned to those roles can manage the object. You can also elect to make the object visible either to all users (public), or only to restricted users in the selected roles (private). If users can view a permissible object, they can also use that object. For example, if a DVG-restricted user's role is associated with an action, the user can use that action when building a rule, regardless of whether that action (object) is private or public. If a DVG-restricted user's role is not associated with an action, the user can use that action only when building a rule if the action (object) is public. The following building blocks are permissible objects:

• Actions - rule and metadata
• Schedules - rule, SLC, metadata, and report
• Lists - email and message
• Calendars

On a Permissions window for an object, if you select restricted roles for the object, and you select:

• This <object type> is visible to all users. The object is public. A public, referenced (used by another object) permissible object can have roles in “Selected Restricted Roles” removed because removing roles does not reduce who can view or use the object. It affects only who can manage the object.
• This <object type> is visible to restricted users in these Selected Restricted Roles. The permissible object is private and can be viewed, edited, or used only by users in the restricted role or by unrestricted users. When a permissible object is private and is referenced (used by another object), none of its roles can be removed because it cannot be made more restrictive. However, a private, referenced object can be made less restrictive.

  If you mix private permissible objects when you create objects such as rules, SLCs, and automated reports, that reference permissible objects such as calendars, schedules, and actions, you may prevent other users from updating the created object. For example, the administrator creates schedule A that is private to Role A and schedule B that is private to Role B. The administrator then creates an Automated Report that includes both schedule A and schedule B, two private schedules. Only the administrator can edit the Automated Report because Role A does not have permission to see Schedule B and Role B does not have permission to see Schedule A.