An administrator can control the permission level of folders and documents in the Directory, granting access to specific users, groups of users or users who are assigned to a specific user role, while restricting access to others.
If you do not have administrator access, you cannot edit permission levels, but you can view your level of access to a selected folder or object in the Details panel. See Directory user interface for more details.
This topic is designed to help you understand permission levels. To go straight to the steps for setting or changing permission levels, see:
Understanding permission levels
The basic permission levels are described in the following table:
| Permission level | Folders | Documents |
|---|---|---|
| No Access | The user or group cannot view or edit the contents or metadata of the folder. | The user or group cannot open, view or edit the document. |
| Read Only | The user or group can view the folder metadata and folder contents in read only mode. | The user or group can open and view the document in read only mode. |
| Read and Execute | The user or group can view and run data flows and schedules within the folder. | The user or group can view and run the document. |
| Write and Execute | The user or group can edit and run data flows and schedules within the folder. | The user or group can edit and run the document. |
| Full Access |
The user or group can open and edit items in the folder, and edit the permission level of the folder and documents in the folder. |
The user or group can open and edit the document, and edit the permission level of the document. |
To understand the effect of permissions, it is important to be familiar with the concept of permission inheritance and how permissions work with user groups and user roles.
Permission inheritance
You can set permissions in the Directory at the folder level, or on a specific document. By default, permissions are inherited from parent folders. For example, if a folder has the permission level of Full Access, all data flows and nodes that are stored within that folder will inherit the Full Access permission level. If you choose to assign a specific permission level to a document, that document will no longer inherit the permission level of the folder in which it is stored. However, if the document is then moved to a different folder, the document would inherit the default permissions of the target folder and any previously set document-level permissions are not maintained.
Similarly, if you use the Save As option to save a document with a new name, any permissions set at the document level are not maintained. The document will inherit the default permissions of the folder in which it is saved.
When importing documents, if there are any import conflicts and you choose to overwrite the original document with a document with the same ID, the imported document will inherit any permissions previously set on the original document.
User groups and user roles
Permission levels can be assigned to a user, a group of users or to all users who have been assigned a particular user role. You may have multiple permissions set on a single folder or data flow to grant access to certain user groups, while restricting access to others. For example, folder A contains a set of data flows that you want to share with a wide group of users, but only a small percentage of those users should be able to edit the data flows. In this case, you may grant Read Only access to all Explorer users on that folder, and give Write and Execute access to all Designer users.
In general, a user will have at least one user role, and they may also be a member of a user group. When a user selects a folder or document in the Directory, their level of access is determined by considering any permissions set on that object that apply directly to them, and to their user role and group memberships.
For more information on the available user roles, see User roles.
Example
A user "Joe" is given Read Only access to a data flow:
When Joe signs in and opens the data flow, he sees the data flow in Read Only mode. This means that he can view the data flow, but does not have access to the toolbar buttons or the Nodes panel.
At a later date, an administrator grants Write and Execute access to the selected data flow to all Designer users:
Joe is assigned to the Designer user role. User role permissions override permissions that are set at a user level, so Joe would now have Write and Execute access to the data flow. This means that when he opens the data flow, he would now have access to the Nodes panel and would see all toolbar buttons.
Executing nodes and data flows
| Object | Required permission level to execute |
|---|---|
| Data flow |
To run a data flow or schedule, the user must have read and execute access to the data flow. |
| Node |
To run any node within a data flow, the user must have execute access to the first library node in the node's parent chain. This could be the library node of a containing composite. Let's take the example of the Pivot - Data to Names node. This node is a pre-built composite node, which contains a Java node. If you double-click the Pivot - Data to Names node and drill into the contained composite, you'll see the Java node:
In this example, the Pivot - Data to Names node has been assigned execute permission, but the Java node does not have execute permission. Given that the Pivot - Data to Names node has execute permission, it is possible to run the node, including the Java node contained within the Pivot - Data to Names node. It would not be possible to run other Java nodes if they were dropped separately onto the canvas, but as this Java node is contained within the Pivot node which does have execute permission, it can be executed. Note: If you want to restrict access to a node, it is recommended that you do not give users read or execute permission on the node. Although read permission would not automatically give a user access to execute the node, they would be able to recreate the node or use it within a composite node.
|