...
Administrators can manage ACLs using a graphical interface available through the Admin menu. Once inside Admin, click Permissions to start the manager. To access the Permissions Editor, you must be logged in as an administrator to the platform. Also, ACLs are available only if you are using the RDBMS solution repository. This feature is not available for the file-based solution repository implementation.
Existing Repositories Behavior With the New Permissions
Before changes were introduced, the Admin Permissions UI exposed a set of permissions, allowing the administrator to set these permissions for individual domain objects. Note that there were three options: Execute, Subscribe and Write. How those three options map to the actual permissions in the platform is demonstrated below:
Subscribe | ==> | Subscribe |
Execute | ==> | Execute |
Write | ==> | Create Update Delete Subscribe Execute |
Now that the share action sequence (xaction) feature has been implemented, changes have been made to the Admin Permissions UI related to what permissions are "exposed" and how they are set. The new Permissions UI has the following set of permissions:
...
Subscribe
...
==>
...
Subscribe
...
Execute
...
==>
...
Permissions
The following permissions are available to be used in access control entries:
Permission | Meaning | |
---|---|---|
Schedule | ==> | Recipient is allowed to schedule a file. |
Execute | ==> | Recipient is allowed to execute a file. This is analogous to a traditional Read permission. |
Update | ==> Update | Recipient is allowed to overwrite a file with his/her changes. |
Create | ==> Create | Recipient is allowed to create files in a directory. |
Delete | ==> Delete | Recipient is allowed to delete files or directories in a directory. |
Grant Permisions Permissions | ==> Grant Permissions | Recipient is allowed to share a file with others. More generally, user is allowed to modify the ACL of a file. |
All | ==> | Create Update Delete Subscribe Execute Grant Permissions ... All |
Any domain object / user that was previously assigned the Write permission now has the Create, Update, Delete, Subscribe, and Execute permissions assigned. This effectively is the same access level they had previously, only displayed separately rather than through the combined permission of "Write."
...
Recipient is allowed to do anything including any new permissions added in the future. |
Panel | ||||
---|---|---|---|---|
| ||||
In the sample page above, the tree on the left represents all of the solution repository objects in your solution repository. You can set permissions on any level in the solution repository object tree. Setting permissions on lower level objects in the tree overrides permission settings higher in the tree. Conversely, if you set a permission on a solution repository object that has children, and the children do not have specific permissions set, they inherit the permissions settings from their parent. So, for example, if you if you set Execute permissions for JoeUser on the analysis objectdirectory, then the query1.xaction object inherits that Execute permission; however, if you then set Create and Execute permission on the query1.xaction for JoeUser, these permissions are honored for that object, but other children of the analysis object would still only have their parent's (analysis ) Execute permission.
For greater clarity, the following permissions now replace the Write permission: Subscribe, Update, Create, Delete, Manage, and All. When a user or role is assigned an "All" permission, every permission, those existing currently, and future permissions are granted. This creates a change when setting default ACLs. Default ACLs that are assigned all permissions now receive full control, including any future permissions. The Admin and cto roles are given all permissions.
The Execute permission allows the assigned user or role to edit the solution repository object, currently enforced through the platform client tools (Report Design Wizard, Report Designer and Cube Designer). Execute permission also allows the user or role to execute the solution repository object, applicable to action sequencesdirectory) Execute permission.
Each solution repository object can have any number of permission-role or permission-user combinations set. The middle panel in the sample page above lists the access control list entries defined for the solution repository object selected in the tree. You can modify the permissions for the roles or users that are defined in the existing access control list entries:
...