Full Video Transcript
Hi, my name is Ryan Maffesoli, and I'm a solutions engineer here at Perforce. In this series, we're going to go over some more of the day to day and basic admin functions you can use to administer your Helix Core server using the P4 admin tool.
In this video, we're going to go over the user creation and user group creation that you can later use with the permissions table to assign permissions and grant access as you need per project.
So let's switch over to our P4 admin view. We're going to go over to the user and groups tab in this view on the left we have a list of all of our users on the server and then on the right, we have all existing groups. Down at the bottom we have a details pane that you can expand out if you want to view details on a specific user or specific group. And if you wanted to create a new user, we can either go up to the menu bar and go file new user or file new group. Or in both of these panels, we can also right click and say, new user or new group as we need.
I'm going to go ahead and create a new user, and it's going to pull up a form for us to fill out. Now, beyond the initial user name, some other things we're going to want are the user's email and a full name. And that full name is used to help communicate back and forth within the system of who has files checked out and things of that nature. Particularly if you are standard email or username structure is perhaps like first initial, last name, it might not be verbose enough so you know exactly who's working on whatever. I'll go ahead and make a test user and we will assign an email here as well as a full name.
We also have the options to edit our authentication method that this user is going to use. If it's set to Perforce by default, what it's going to be doing is using Helix Core's internal authentication of username and password to authenticate with the server. If instead you've installed the Helix authentication service, then you would switch this over to LDAP and that would tie into your LDAP authentication and all that. When creating a new user you can either as an admin set a default password and send that to them. Or if you leave this blank, it will then prompt the user to create a password on first login. So for this user, I'm just going to go ahead and leave that blank.
Underneath here, we've got the type of user we're creating. Now, for any artist or developer or any human that's going to be interacting with our server and making workspaces, checking files out, making edits, and submitting them back, you're going to want to stay with a standard user.
That standard user will pull a license but it's the most unrestricted style of user. And by that I mean that it can still be assigned as a super user, an admin or read only user, things of that nature. However, the other 2 types of operator and service user are far more limited. So an operator license does not pull a Helix Core license and so can be used for folks that need to only admin the server so it might be along the lines of running P4 verify or checkpoint or things of that nature. So where the operator needs to come in, administer the server machine itself, make sure your tables are even backed up and all of that, but won't be pulling down work or creating workspaces and things of that nature. That doesn't require a user license and you would want an operator license at that point.
Similarly, we have a service user, which is typically used by automated services you may set up. So this may be transactions between one server to another or scripts you're looking to run. This service user will again be limited to a certain set number of commands. It's allowed to actually operate and it is limited there, but it will again, not pull a user license. And so it can be used in those sort of automated fashions.
I'm going to go ahead and make a standard user. Underneath here. We do have the option to add our user to groups, so I can go ahead and browse, which will pull up a dialogue here, and I can select any number of groups to add them. I can also assign that user as an owner of this group, and as well define job views if you're using our job system. Or certain paths that this user is responsible for reviews upon. And that would be with Helix Swarm and all that. So if I were to define that, I can either define it through text here, or I can step over into this Reviews tab and let's say this user is going to be reviewing everything in this Demo Project Depot, I can say include tree, and if I step back to my form, you'll see that that text has now been filled out in that same manner. So I can go ahead and create this test user, and it's now available here on the server.
Now, user groups are also quite valuable because they can allow you to assign permissions to an entire group of users perhaps on a project basis, perhaps because you've got a certain set of super users or admins you would like to define one set of permissions for and then disperse amongst many users. And the creation process is very similar.
We'll just come into a new group. We'll go ahead and name this one super users for later use. We can add a description. And we can also then from this menu browse and add our users. So I'll add both here. I'll add myself as the owner. If we had many groups, we could also add subgroups to this. And that would also propagate this group membership down into those other subgroups for later use with the permissions table. There are other values, values you can set for these groups between. We've got a maximum number of results and maximum lock time for database tables and things of that nature.
If you need to control things on that sort of granular spec you can. A lot of times I'm not setting these personally. You can also change how long before each session times out. So here, by default, we've got a 12 hour session before that ticket needs to be refreshed as well as how long before a password expires.
So again, it's unset here, but I could define 30 days or things of that nature. All depends on your security protocols and all that. But you do have the ability to define that here and have that all set up. So once I click apply we do have our super user group here with both of our users in place in that group.
Now that we have these groups existing, we can use these later on our permissions and protections table to assign depot access between super user, write, read, all of that to this entire group level, which will then be then disperse down to all its members. So it can be very useful for permission management and grouping users into that sort of thing.
So I hope this helps, and I'll see you next time.