ON THIS PAGE:
Objects in P2 Explorer are the lowest level of granularity that can be secured.
An object is an individual, identifiable instance of a resource, such as Workspace 1 or Entity A. Object security is performed inside the module itself, rather than in the Security module of Server Management.
What Can Be Secured
Every resource has corresponding objects, however not all objects can be secured individually. Generally speaking, resources that have a View privilege also have objects that can be secured, while those without a View privilege can only be secured at the resource level.
Server
| Objects that can be secured | Objects that cannot be secured |
| Calculations | Digital States |
| Datasources | Images |
| Entities | Units |
| Hierarchies | |
| Named List Items | |
| Links | |
| Templates |
Explorer
| Objects that can be secured | Objects that cannot be secured |
| Forms | Styles |
| Workbooks | |
| Workspaces |
Sentinel
| Objects that can be secured | Objects that cannot be secured |
| Workspaces | Events |
| User Processes |
Commentary
The Commentary module can only be secured at the resource level.
Object Privileges Matrix
As with module- and resource-level privileges, object privileges are assigned to roles, rather than individual users.
Object-level privileges can only be changed by a user with Admin privileges for the relevant module (e.g. Server Admin for securing hierarchy objects, or Explorer Admin for securing workspace objects).
Assigning Object Privileges
You can assign object privileges by directly clicking the privilege against the object, from within the containing module/resource. For example, to manage privileges for a workspace, go to workspaces in P2 Explorer, and open the workspace for which you want to change the privileges. The available privileges are the same as those available for the resource.
Note that privileges cascade here too, with the highest level privilege generally on the right, and the lowest on the left. When you assign a high level privilege, such as Delete, lower level privileges are also automatically granted when that privilege is required to perform the action. This is shown by a green circle with a dot.
For object-level privileges, privileges are either granted explicitly or inherited from a resource. If a privilege is not granted via one of these methods, it is denied. Note that the Everyone role shows the actual default View privilege as being granted, whereas Edit and Delete are denied at the object level.
What the Colours Mean
As with resource-level security, the privileges matrix is colour-coded to indicate the cascading nature of privileges. The colours are:
Grey: Privilege not granted
Green tick: Privilege is explicitly granted, associated privileges will also be automatically granted.
Green dot: Privilege is granted because a higher level privilege has been granted on the resource.
Blue: Privilege is granted because it is inherited by a resource privilege.
Release History
- How Object Access Works (this release, 4.9.1):
- Named List item privileges