February 4, 2009

Preview Permissions in P4V's Administration Tool

Flexible Workflows
Traceability

New for the 8.2 release is the ability to view the permissions of an unsaved protect table in the permission viewer of the Administration Tool. This means in addition to viewing the permissions that are actually active in the depot, you can make changes to the protect table in the viewer and see what the new permissions would be with the new table before actually activating them in the server.

(The permission viewer is in P4V's Administration Tool, on the 'Permissions' Tab)

The activation of this feature is seamless: you simply start editing the table (note the caption for the permission changes to indicate they are the unsaved permissions.)

unsaved permissions label

This feature allows you to do 'what if' changes to the protect table and check permissions before submitting.

How it works

The permission viewer uses index lists that are fetched using the p4 protects (2006.2+) command to determine permissions.  For example in this table:

>p4 protects -o
write user * * -//...
super user james * //...
list user sally * //...
write user sally * //depot/...

The user sally is referred to by three lines in the table (1, 3, and 4). The permission viewer receives the indexes of these three entries from running the p4 protects -u sally command.

>p4 protects -u sally
write user * * -//...
list user sally * //...
read user sally * //depot/...

Implementing preview permissions turned out to be very easy. Instead of generating the list of indexes by running p4 protects, we will generate the index lists ourselves. They then feed right into the permission viewer to determine the permission to a file or folder.

That sounds easy enough- we just need to sweep through the unsaved table and pick out all the lines that mention user sally. But wait- if sally is a member of a group that has permissions, then we need to add those lines in as well.

The solution is to use the p4 groups -i command, which returns the list of groups that a user or group belongs to directly or indirectly.

Suppose we edit the protect table by adding a line that includes the group sallygroup that contains sally as a member:

write user * * -//...
super user james * //...
list user sally * //...
read user sally * //depot/...
write group sallygroup * //depot/...

then using p4 groups -i:

>p4 groups -i sally
sallygroup

Now we can sweep the protect table, and assemble the indexes of lines that match any of the direct or inherited matches (1, 3, 4, and 5). This index list is exactly the same as the one we receive from p4 protects- except it represents the unsaved table! It then feeds into the permission viewer with no changes to the internal code.

Far too much work to do manually, so the permission viewer does it for you to present the preview permissions in the GUI.

Tip: Use the filter table icon on the tool bar of the protect table editor to view the table filtered by the current user. This means the lines shown are the only lines used to calculate permissions for that user.

filter icon