User’s access can be managed in two ways:
• Allowed Actions – Refer to the actions that can be performed on a hierarchy through a request.
• Property Access – Establishing controls as far as the properties that will be visible and editable at the node type level.
Solution Approach:
In order to meet a client’s requirement, we provisioned one user with ‘Participant Write’ permission and as a part of the configuration we allowed the ADD and DELETE action codes. A user with the permission to ADD nodes also has the permission to UPDATE nodes.
Similarly, for another user with ‘Participant Write’ permission we configured the MOVE, REMOVE, and REORDER action codes.
Expected Outcome:
MOVE, REMOVE, and REORDER action codes should be disabled for User 1 whereas ADD and DELETE options should be disabled for User 2.
Important point to note:
To Add nodes in a hierarchy, both the ADD action on the NODE TYPE and INSERT action on the hierarchy set are required. To Delete nodes from a hierarchy, both the DELETE action on the node type and REMOVE action on the hierarchy set are required.
The blog will showcase this scenario:
Refer to the below table:
Configuring the 2 Users:
1) As mentioned in the table above, ADD and DELETE action codes are provisioned for Alex Smith. Hence, the other action codes should be disabled for Alex Smith. The following snapshot is of the ‘Permissions’ tab in the node type level. Refer to Snapshot 1 below.
2) Similarly, MOVE, REMOVE and REORDER action codes are allowed for James Bird so other action codes should be disabled for him. The following snapshot is of the Permissions tab in the hierarchy set level. Refer to Snapshot 2 below.
3)I logged in as Alex Smith to ADD a new node. Refer to Snapshot 3 below.
Notice that every other action code except ADD and DELETE is disabled, which is what was expected as per the configurations that we have done.
4) Below is the snapshot to showcase the error message that we get if INSERT action code is not allowed in hierarchy level permissions when ADD is allowed in the node type level permissions. Refer to Snapshot 4 below.
5) To get rid of the error message, I added INSERT as an allowed action code in the hierarchy set level permissions for User1. The expectation now is that I will be able to ADD a new node. Refer to Snapshot 5 below.
Note: This user already has ‘Add’ and ‘Delete’ action enabled at Node Type level.
6) I created a new request- Request 3862 to ADD a new sibling to the node ‘000’. Refer to Snapshot 6 below.
7)The new node ‘001’ gets added as a sibling of 000. Refer to Snapshot 7 below.
8) Now I’ll login as James Bird who cannot ADD or DELETE nodes but can only MOVE, REMOVE or REORDER nodes. Refer to Snapshot 8 below.
Notice that as we configured, every action code except MOVE, REMOVE and REORDER is disabled.
9) Next, I’ll showcase the REMOVE action code. Note the node ‘000’ existing as a child of the parent node ‘T’. Refer to Snapshot 9 below.
10) Click on the REMOVE option from the drop-down menu. Refer to Snapshot 10 below.
11) The node ‘000’ gets removed. Refer to Snapshot 11 below.
To conclude, below is the configuration required to fulfil this requirement which is valid for all other similar scenarios:
