Helix Core — version control from Perforce — tracks, manages, and secures changes to all your digital assets, including large binary files. Scale your infrastructure, support your remote teams, and move faster.
Full Video Transcript
Helix provides a permissions scheme to prevent unauthorized or inadvertent access to the depot. You can view the permissions for a particular user or group by selecting the relevant tabs here.
Looking at John, we can see he has write access to all the current projects in the depot, but no access to the other areas. Conversely, you can select the depot tab and see what level access a particular user or group has to those files.
The Access Level sliders enable us to narrow down the data that is displayed. If we wanted to see where John had write permissions or higher, we would set the filter to show only those permissions.
Below is the protections table. Each line represents a permission that is defined by the fields listed above. Access level specifies the actions that the user can perform. Roughly defined… someone with super access can do anything. An admin can run commands that affect the metadata and files, but not commands that affect the actual server operation. Write enables a user to open and edit files, and submit them to the server. Write is the most common level of access. Open permits a file to be edited in the users local workspace but not to be submitted back into the depot. Read enables the user to read the file but not to change it, similar to a read-only capability in any file system. No access is self explanatory and review is a special read permission for review daemons. The rest of this list consists of exclusionary versions of the same commands, with the addition of restrictions on the ability to branch.
The next few columns enable you to control access for a particular user or group by entering the name of the user or group, and the hosts they can use to access the depot.
In this column, you enter the area of the depot to which you are controlling access, and here you can add some notes to remind yourself why the changes were made.
Although the P4Admin tool enables you to set permissions all the way down the level of individual users and files, it’s best to take a higher-level approach by creating groups first, defining permissions for that group (usually write permission), and then assigning users to the group. You can make exceptions for lower-level permissions if needed.
For example, let’s say the Web Designers need full write access to the 1.5 branch of Talkhouse because that version will include a new web front end. We could include them in the developers group as a subgroup, but that approach gives them write access to lots of other code that they don’t need to modify. In this case, we will add a line in the permissions table to enable write access to the area they need. To insert a new permission, select the insert line icon.
Next, choose write in the drop down, leave group selected, enter WebDesigners as name, and leave host as any. Now enter the name of the depot location. In this case, //depot/Talkhouse/rel1.5/… Watch out for misspellings and don’t forget the ellipses to include access to everything in the rel1.5 directory. If you have to enter a directory name that contains spaces, enclose it in quotes.
Superusers icons are highlighted with an outline like Joe Coder. To ensure that your superusers always have full access, even in the protect table that contains exclusionary lines, create a line for a superuser group and make it the last line. The table is read from the bottom up so this ensures your superusers will always have the access they need. It’s a good idea to do the same with the Admins.
After you have completed your entries, be sure to click “Save Edits.” If you are having any pangs of worry about completing the changes at this point, you can select “Revert Edits” to delete any of the current changes you have made to the protections.
It’s best practice to not enable too much access initially. Divide your users into groups, and define permissions for those groups to work in specific sections of the depot as needed. Also, minimize the use of exclusionary permissions because managing several one-off exceptions can get confusing. If you must use exclusions, keep in mind that the table is read from the bottom up and lower exclusionary lines override lines above them, but not lines below them, so the order is significant. You can rearrange the lines here.
This concludes our overview of permissions in P4 Admin. If you have any specific technical questions, please contact [email protected].
Thanks for watching.