Users

There are three types of Helix Core Server users: standard users, operator users, and service users. For details about these user types, including how to create users of these types, see Types of users in the p4 user command of Helix Core Command-Line (P4) Reference.

For information about authenticating users and granting them access, see Secure the server.

Warning

By default, Helix Core Server creates a new user whenever a previously unknown user invokes any command that can update the repository or its metadata. When executed by a nonexistent user, most Helix Core Server commands cause a user to be created. You can control this behavior by setting the dm.user.noautocreate configurable with the p4 configure command. For greatest security, we recommend that only the Helix Core Server superuser be allowed to create new users:

$ p4 configure set dm.user.noautocreate=2

Renaming users

You can use the p4 renameuser command to rename users. The command renames the user and modifies associated artifacts to reflect the change: the user record, groups that include the user, properties that apply to the user, and so on. See the description of the p4 renameuser command in the Helix Core Command-Line (P4) Reference. In general, the user name is not changed in descriptive text fields such as change descriptions. It is only changed where the name appears as the owner or user field of the database record.

For best results, follow these guidelines:

  • Before you use this command, check to see that the new user name does not already exist. Using an existing name might result in the merging of data for the existing and the renamed user despite the best efforts of the system to prevent such merges.
  • The user issuing this command should not be the user being renamed.
  • The user being renamed should not be using the server when this command executes. After the command completes, the user should log out and then log back in.

  • The p4 renameuser command does not process unloaded workspaces: all the user’s workspaces should be reloaded (or deleted) first.

    A distributed installation might contain local workspaces or local labels owned by the user. These workspaces and labels, which are bound to Edge Servers, should be deleted or moved to the Commit Server first.

  • Files of type +k which contain the $Author$ tag that were submitted by the user will have incorrect digests following this command. Use p4 verify -v to recompute the digest value after the rename.

Deleting obsolete users

Each standard user on the system consumes one Helix Core Server license. A Helix Core Server administrator can free up licenses by deleting users with the following command:

$ p4 user -d -f username

Before you delete a user, you must first revert (or submit) any files a user has open in a changelist. If you attempt to delete a user with open files, Helix Core Server displays an error message to that effect.

Deleting a user frees a Helix Core Server license but does not automatically update the group and protections tables. Use p4 group and p4 protect to delete the user from these tables.

Reverting files left open by obsolete users

If files have been left open by a nonexistent or obsolete user (for instance, a departing employee), a Helix Core Server administrator can revert the files by deleting the client workspace specification in which the files were opened.

As an example, if the output of p4 opened includes:

//depot/main/code/file.c#8 - edit default change (txt) by jim@stlouis

you can delete the stlouis client workspace specification with:

$ p4 client -d -f stlouis

Deleting a client workspace specification automatically reverts all files opened in that workspace, deletes pending changelists associated with the workspace, and any pending fix records associated with the workspace. Deleting a client workspace specification does not affect any files in the workspace actually used by the workspace’s owner; the files can still be accessed by other employees.