Configuring Ownership and Viewer Access

Learn about controlling access to various Oracle Communications Unified Assurance entities by configuring ownership and viewer access.

Configuring User and Group Ownership

You can configure ownership for dashboards, events (filter groups, filters, and displays), files, links, queries, reports, and SLM services. You can set the following ownership options on an entity's configuration interface:

Note:

Users with SUPER permission have full access to everything, regardless of ownership settings.

The following table summarizes how user ownership, group ownership, and viewers work together. In this table, Group A and Group B are example user groups.

User Ownership Group Ownership Viewers Access Granted
User N/A Any Private read and write access to the specified user. Cannot be a transient user. Any viewers assigned have read-only access.
Public to All Users Public to All Groups Any Read and write access to all users, persistent or transient, in the system. Assigning viewers is redundant; they do not gain additional access.
Public to All Users Group A None Read and write access to all users, persistent or transient, in Group A, including matching subgroups. Other users have no access.
Public to All Users Group A Group B Read and write access to all users, persistent or transient, in Group A, including matching subgroups. Read-only access from Viewers for users only in Group B, including matching subgroups. Users from groups other than Group A and Group B have no access (other than users with PUBLISHER or SUPER permission).
Public to All Users Group A Public to All Groups Read-only access for all users through Viewers. Users in Group A, including matching subgroups, can update only if they also have PUBLISHER or SUPER permission. Without PUBLISHER or SUPER permission, Group A users are read-only too.
User A N/A Public to All Groups Private read access to the specified user. Cannot be a transient user. Because Viewers is set to Public to All Groups, User A needs PUBLISHER or SUPER permission to make updates.

Viewers grant read-only access. They do not grant create, update, or delete access. To update or delete an entity, a user must have both the required role permission and read/write access from User Owner, Group Owner, or public Group Owner.

SLM Service, Service Filter, and Service Metric records support User Owner and Group Owner only. They do not support multi-tenant Viewers or PUBLISHER-based viewer publishing.

If a user has matching User Owner or Group Owner access to an SLM Service or Event Filter Group, deleting that parent is allowed even when its child or contained records have different ownership.

Configuring Viewers

The configuration interface for most entities also includes the Viewers section to provide read-only access control beyond the user and group ownership settings. When you set a user group owner, users in that group have read-write access. You can grant read-only access to additional user groups by adding them to the entity's viewers list. You can also grant read-only access to all users by adding [Public to All Groups] to the viewers list.

If the viewers list contains a user group that the current user is not allowed to see, the Viewers selected list displays that group as [Restricted]. This protects the hidden user group name while still showing that the entity has an additional viewer entry.

A user who has update access from User Owner, Group Owner, or public ownership can still update the entity. If the selected viewers list includes [Restricted], the user can remove the [Restricted] entry and save the entity. Removing [Restricted] removes the hidden viewer group from the entity.

Entities with [Public to All Groups] in the viewers list are publicly viewable. To prevent non-publisher users from changing publicly viewable content, updating a publicly viewable entity requires PUBLISHER or SUPER permission, even if a user would otherwise be granted write access to it through group or user ownership. If an update is rejected because the entity is publicly viewable, you can:

Note:

When a user with Viewer permission accesses an entity that belongs to another user or user group, the value for the User or Group Owner field is displayed as [HIDDEN].

Publisher Role for Multi-Tenant Sharing

The Publisher role is intended for delegated users who need to share application records with user groups outside their own visible user group hierarchy, without granting them SUPER administrative permission.

A typical use case is a managed service provider operator who creates dashboards, event filters, reports, files, or similar viewer-enabled records for multiple customer groups. For example, the operator might create one event filter and publish it to both Tenant A and Tenant B, even though users in those customer groups should not be able to see or select each other.

Publisher permission separates two concepts:

Users without PUBLISHER or SUPER permission can only select viewer groups that are visible to them. If an existing record includes a viewer group outside the current user's visible group hierarchy, that viewer entry is shown as [Restricted]. The user can remove the [Restricted] viewer entry if they otherwise have update access to the record, but they cannot see, add, preserve, or re-publish that hidden viewer group.

Updating a record that keeps or adds a viewer group outside the user's visible group hierarchy requires PUBLISHER or SUPER permission. This validation applies even when the user owns the record, because saving the record with that viewer assignment republishes it to another group.

PUBLISHER does not grant full administrative access. Use SUPER for unrestricted administrative access. Use PUBLISHER when a non-admin user needs to manage ownership and viewer assignments across multiple tenants.

About Owners, Viewers, and Restrictive IDs

You can also control access using restrictive IDs in user groups. In navigation trees and other restrictive-ID controlled contexts, restrictive IDs take precedence over viewer and ownership settings.

Configuration tables and navigation trees do not always use the same access rules. Configuration tables use ownership and viewer settings to determine which records are listed. Navigation trees can also require the record to be assigned under a navigation path the user can access, such as a restrictive event filter group, dashboard group, or link group. A record can be visible in a configuration table because the user owns it or can view it, but still be hidden from navigation if it is outside the user's allowed navigation tree. For example:

See User Group Properties for more information about restrictive IDs.