Object permissions can be granted to users and roles to allow or deny execution of certain business operations and the specific instances of a given entity type. They are typically used for overriding operation permissions which describe a general security policy. You can manage object permissions for the entities of Content, Dynamic and Tagged Playlist, Live Text and Media Feed, Presentation, Group and Player types.
...
An editable permission for a specific principal, entity, or operation has will have an enabled/disabled active toggle and a delete (trashcan) icon as shown in Image 1.
For example, a custom Content Managers role with only Content - View Content permissions under a selected Media FileAn editable permission for a specific principal, entity, or parent operation has will have an enabled/disabled active toggle but no delete icon.
For example, a custom Content Managers role with Content (Full Control) permissions under a selected Media File. In this case, permission to execute Content - View Content is inherited fromĀ Content (Full Control).
An editable permission that is defined for a specific principal, parent entity. These permissions are displayed withentity, or parent will havean activeenabled/disabled activetoggle. The toggle switch is will be grey and does will not have a delete icon.
For example, a custom Content Managers role has permission to execute any operation under any new content folder. These permissions are inherited from the parent content folder.
An editable permission that is defined for a parent principal. It is displayed with enabled/disabled active. The toggle switch is grey and does inherited will have a grey toggle switch, will be set to the inherited setting (enabled or disabled), and will not have a delete icon.
For example, a custom Content Managers role has permission to execute any operation under any new content folder or media file. If you assign a new user to this role, permissions to execute all operations under all content folders (except their personal folder) and media files are inherited from their role.
If permissions are defined for a parent principal, operation, or parent entity and are not editable, they will be displayed with enabled/disabled but inactive and a grey toggle switch without the delete icon.
These are permissions defined for System Roles, Personal Folders, Special Groups, etc.
A non-editable permission that is inherited (for example, System Roles, Person Folder, Special Groups, etc.) will have a grey toggle, will be set to the inherited setting (enabled or disabled), and will not have a delete icon.
If permissions are not defined for a parent principal, operation, or parent entity, the toggle switch is will be disabled and grey. There is , and there will be no delete icon.
For example, a role with incompletely defined permissions and a user who doesn't extend and override them.
...
Create a Custom Role based on Publishers.
Assign all of the store managers to this role.
Change the role so that the actions View Groups and Update Schedule in the Group category are denied.
Make sure that each group of players reflects a different store location ???
Change the object permissions of each group on the network so that each user assigned to the custom Publishers role can only view and modify the group corresponding to his or her store ???
You can also assign object permissions based on individual players. This is helpful if you already organize groups in some other way (by region, by store type, etc.).
...