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.
Permissions granted to users on the object level have the highest priority but the narrowest scope.
Permissions granted to roles on the object level have second priority and may be overridden by user permissions.
Permissions granted to roles on the operation level (visible in the Admin > Roles page) have the lowest priority but the widest scope.
Role and User Access States
Role and user access can be in one of the following states:
1. When a specific role or user has an explicitly defined permission to execute a particular operation under the given object, it will have an enabled/disabled active toggle and a delete (trashcan) icon as shown at right.
In this example, the members of the Content Managers role are explicitly allowed to see a particular file put not allowed to manipulate it. You can delete these permissions by clicking on the trash icon, which will put inherited permissions into effect instead.
2. When a specific role or user has an explicitly defined permission to execute a parent operation under the given object, the toggles on the child operations will have the same state but no delete icon.
In this example, the members of the Content Managers role have Full Control permission which applies to all child operations as well.
3. When permission is granted to any role on the Admin > Roles page, it automatically applies to all objects of a given type and is displayed with an active enabled/disabled toggle but without a delete icon.
In this example, the members of the Content Managers role have permission to see all files and manage their tags which is reflected in the Security tabs of all the files which do not have an overriding permissions. The same applies when you grant any permission to a parent folder of a given file.
4.
An editable permission that is 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.
5. 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.
6. If permissions are not defined for a parent principal, operation, or parent entity, the toggle switch will be disabled and grey, 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.
Editing Object Permissions
You can create and edit object permissions in conjunction with Custom Roles to meet the organizational needs of a large digital signage network where pricing and offerings may vary by regions and/or stores. In this scenario, you may need to limit or allow access according to the objects (Media files, Dynamic Playlists, etc.) themselves.
Object permissions are accessed through the Security section of the Properties pane. This is on the right side of the screen in Network, Content, or Presentations tab (for player, content, or presentation properties).
Select the Security tab in the Properties window.
Assign object permissions by role or by user:
In the Assigned Roles tab, select the desired role (remember that you can only edit permissions for Custom Roles).
In the Assigned Users tab, select the desired user.
You can now choose whether to Allow or Deny certain actions for a specific object.
Permissions settings for users have higher priority than those for roles, and permissions for objects have higher priority than those for operations. For example, if the Presentation Creators are restricted from creating Live Text feeds, but full control for the role is enabled for a certain Live Text feed, then the allowance for that specific object takes precedence over the general restriction for Presentation Creators.
Object Permissions Examples
Store Managers
A company may want to let store managers decide which deals to promote so managers need to view various presentations and schedule them for the players in their store. However, if you assign them to a Custom Role based on Publishers, they would have access to the presentation schedules of all stores and might accidentally delete or modify those schedules for other stores.
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.).
This object permissions system allows store managers to schedule menus and offers only at their own store locations. You can customize this system even more: for example, if you want certain store managers to have access to certain menus or promotions depending on region or store type, you can use the object permissions for presentations to deny or allow access as you see fit.
Prototypes
The marketing department wants to upload an announcement to test how it will look on a digital display. However, only certain employees should have the ability to view, edit, or schedule the presentation since the announcement is confidential. You can limit access to this presentation either by role or by individual user; or allow access to a user who is working on this project but who doesn’t normally have access to presentations. For this scenario to work, most or all users need to be assigned to Custom Roles since the object permissions for System Roles cannot be edited.
Keep in mind that there are other factors beside object permissions that can limit access to a presentation or other object. For example, you can give a user full permissions for a Dynamic Playlist object, but that user will not be able to save content changes to that Dynamic Playlist if the role restricts the Assign Content action in the Content Permissions category.