p4 user

Create, edit, or delete Helix Core Server user specifications and preferences.

Syntax

p4 [g-opts] user [-f] [username]
p4 [g-opts] user -d [-f | -F] username
p4 [g-opts] user -D [-f | -y] username
p4 [g-opts] user -o [username]
p4 [g-opts] user -i [-f]

Syntax conventions

Description

Use the p4 user command to edit user specifications and preferences, or to create new user records.

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. We recommend that a Helix Core Server superuser prevent this with the dm.user.noautocreate configurable. See Recommended settings to configurables for security in the Helix Core Server Administrator Guide.

Although users and groups can exist without an entry in the protection table, they cannot run commands until the protections table has an entry that applies to them. Permissions that control access to files, directories, and commands are assigned to a user or a group of users with p4 protect permission levels, such as list, read, write, admin, and super.

Note

For graph depots A depot of type graph that is used to store Git repos managed by Helix Core Server. See also Git Connector and classic depot., access control is assigned to users or groups with a different command, p4 grant-permission (graph).

When called without a username, p4 user can be used to edit the specification of the current user, such as edits to the Reviews field.

When called with a username, the user specification is displayed, but cannot be changed. The form appears in the editor defined by the P4EDITOR environment variable.

Helix Core Server superusers can create new users or edit existing users' specifications with the -f (force) option: p4 user -f username. Both the -f and -F options can be used to delete users, but the -F option has additional effects on protections and groups. See Options below.

The user who gives a Helix Core Server command is not necessarily the user under whose name the command runs. The user for any particular command is determined by the following:

If the user running the command is a Helix Core Server superuser, and uses the syntax p4 user -f username, user username is edited.
If the -u username option is used on the command line (for instance, p4 -u joe submit), the command runs as that user named "joe" (a password might be required).
If the above has not been done, but the file pointed to by the P4CONFIG environment variable contains a setting for P4USER, the command runs as that user.
If neither of the above has been done, but the P4USER environment variable has been set, the command runs as that user.
If none of the above apply, the username is taken from the OS level USER or USERNAME environment variable.

Removing users

Important

Before you delete users based on their last access time, check the access time directly on the edge and replica servers, in addition to checking the access time on the master or commit server.

The -D option can be convenient for the administrator if a user leaves the organization. This option not only deletes the specified user, it also deletes all the client workspaces that belong to the absent user. See Options and Examples.

Types of users

Important

Once you set the user type, you cannot change it.

standard user

the default, which applies to:
- end users
- users with the admin access level
- users with the super access level, also known as Helix Core "superusers"
each standard user consumes one Helix Core Server license

By default, Helix Core Server creates a new user record in its database whenever a command is issued by a user who does not exist. Helix Core Server superusers can also use the -f (force) flag to create a new user as follows:

p4 user -f username

Fill in the form fields with the information for the user you want to create.

The p4 user command also has an option (-i) to take its input from the standard input instead of the forms editor. To quickly create a large number of users, write a script that reads user data, generates output in the format used by the p4 user form, and then pipes each generated form to p4 user -i -f.

Permissions for standard users

Although users and groups can exist without an entry in the protection table, they cannot run commands until the protections table has an entry that applies to them. See p4 protect.

operator user

for system administrators responsible for the maintenance, including automated maintenance, of the Helix Core service
does not consume a license
restricted to the following set of commands:
- p4 admin with the following options: checkpoint, journal, stop, restart
- p4 configure, p4 counter (including -f), p4 counters
- p4 dbstat, p4 dbverify, p4 depots, p4 diskspace
- p4 heartbeat
- p4 jobs, p4 journalcopy -l, p4 journals
- p4 lockstat, p4 login, p4 logout, p4 logparse, p4 logrotate, p4 logschema, p4 logstat, p4 logtail
- p4 monitor
- p4 passwd, p4 ping, p4 pull -lj, p4 pull -ls
- p4 servers and p4 servers -J
- p4 topology
- p4 user
- p4 verify
Permissions for operator users
Users having the operator type do not need an entry in the protections table to run the set of operator commands. However, an operator does need the super access level to run an option that requires the super access level. For example, p4 logout -a user and p4 admin updatespecdepot.

service user

for inter-server communication in replicated and multi-server environments, which can:
- simplify the task of interpreting your server logs
- improve security by requiring that any remote Helix Core services with which your Helix Core service is configured to communicate have valid login tickets for your installation.
does not consume a license
restricted to the following commands:

p4 dbschema	p4 export	p4 login
p4 logout	p4 passwd	p4 info
`p4 user`

Note

Although a service user cannot run p4 pull or p4 journalcopy directly on the command line, the service user on a replica automatically runs this command to retrieve metadata and archive content (versioned files) from the master.

To create a service user, run the command:

p4 user -f service1

The standard user form is displayed. Enter a new line to set the new user’s Type: to be service:

User:      service1
Email:     services@example.com
FullName:  Service User for remote depots
Type:      service

By default, the output of p4 users omits service users. To include service users, run p4 users -a.

Tip

We recommend you include your service users in a group. See the p4 group topic.

Permissions for service users

On your server, use p4 protect to grant the service user super permission. Service users are tightly restricted in the commands they can run, so granting them super permission is safe. If you are only using the service user for remote depots and code drops, you can further reduce this user’s permissions as described in Restricting access to remote depots in the Helix Core Server Administrator Guide.

Note

For more information about the environments where you might want a service user, see Deployment architecture and Remote depots and multi-server development in the Helix Core Server Administrator Guide

Tip

For a table that shows the minimum access level required to run each command, see Access levels required by Helix Server commands in the Helix Core Server Administrator Guide.

Form Fields

Field Name	Type	Description
`User:`	Read-only	The Helix Core Server username under which `p4 user` was invoked. By default, this is the user’s system username. Be aware of the Limitations on characters in filenames and entities.
`Type:`	Read-only	Type of user: `standard`, `operator`, or `service`. Important The type cannot be changed after the user is created.
`AuthMethod:`	Writable	One of the following: `perforce` or `ldap`. This field can only be changed when the `-f` option is specified for the `p4 user` command. Specifying `perforce` enables authentication using Helix Core Server’s internal `db.user` table or by way of an authentication trigger. This is the default unless it is overridden with the `auth.default.method` configurable. Specifying `ldap` enables authentication against AD/LDAP servers specified by the currently active LDAP configurations.
`Email:`	Writable	The user’s email address. By default, this is `user@client`.
`Update:`	Read-only	The date and time this specification was last updated.
`Access:`	Read-only	The date and time this user last ran a Helix Core Server command. Warning If you are deleting users based on their last access time, check the access timestamp directly on the edge and replica servers in addition to the access time on the master or commit server. Do not expect the master or commit server to have the timestamps of when users accessed edge and replica servers.
`FullName:`	Writable	The user’s full name.
`JobView:`	Writable	A description of the jobs to appear automatically on all new changelists (see Usage notes).
`Password:`	Writable	The user’s password (see Usage notes ).
`PasswordChange:`	Read-only	The date and time of the user’s last password change. If the user has no password, this field is blank.
`Reviews:`	Writable List	A list of files the user would like to review (see Usage notes). This field can include exclusionary mappings.

Tip

If there is a line under a field, indent that line. For example,

Reviews:
    //depot/path/to/directory1/...     
    //depot/path/to/directory2/readme.txt

Options

`-d username`	Deletes the specified user and can be used by: a Helix Core Server superuser if combined with the `-f` option any user where `username` is that user's own `username` If you have set `P4AUTH`, no warning will be given if you delete a user who has an open file or client.
`-D username`	Only a Helix Core Server superuser can use this option, which: deletes the specified user removes the specified user from the protections table and all groups deletes all the client workspaces that belong to that user, thereby reverting files that the deleted user had open However, this option: does not work on an edge server - see "Commit-edge" in the Helix Core Server Administrator Guide does not delete any Helix Swarm client workspaces that are associated with the deleted user, so that Swarm's history remains intact Note Does NOT delete workspace clients that have files opened by OTHER users. To force the deletion of workspace clients that have files opened by OTHER users, combine the -D option with the -f option in preview mode. To perform the operation, add the -y option. See Examples.
`-y`	Used with -D to actually perform the delete operation. Without -y, p4 user -D, p4 user -D -f, and p4 user -D -F merely report what the command would do IF -y were included. Note p4 user -D -y, p4 user -D -f -y, and p4 user -D -F -y cannot be undone.
`-f`	Superuser force option that allows the superuser to create, modify, or delete the specified user, or to change the last modified date. (preview mode unless the -y option is added)
`-F`	Superuser option that is used with the `-d` or -D option. With the -D option, -F forces the deletion of the specified user and also removes the user from the protections table and from all groups. The command fails if removing the user from a group causes the group to be deleted. In such a case, delete the group before deleting the user. (preview mode unless the -y option is added)
`-i`	Read the user specification from standard input. The input must conform to the `p4 user` form’s format.
`-o`	Write the user specification to standard output.
`g-opts`	See Global options.

Usage notes

Can File Arguments Use Revision Specifier?	Can File Arguments Use Revision Range?	Minimal Access Level Required
N/A	N/A	`list` for edits to oneself `super` to delete another user this command is available to an operator and a service user (see Types of users in p4 user)

The -d option can be used by non-superusers only to delete the user specification that invoked the p4 user command. Helix Core Server superusers can delete any Helix Core Server user.
User deletion fails if the specified user has any open files. Submit or revert these files before deleting users.
By default, user records are created without passwords, and any Helix Core Server user can impersonate another by setting P4USER or by using the globally available-u option. To prevent another user from impersonating you, set a password with the p4 passwd command.

Passwords can be created, edited, or changed in the p4 user form or by using the p4 passwd command. Setting your password in the p4 user form is only supported at security levels 0 or 1. You can p4 passwd to set passwords at any server security level, and you must use p4 passwd to set passwords at higher security levels. For more about how the various security levels work, see Helix Core Server Administrator Guide.

Tip
If you edit the Password: field in the p4 user form, do not use the comment character # within the password. Helix Core Server interprets everything following that character on the same line as a comment, and does not store it as part of the password.

If the dm.user.resetpassword configurable has been set, all users created with passwords are required to reset their passwords before they can issue commands.
Passwords are displayed as six asterisks in the p4 user form regardless of their length.
If you are using ticket-based authentication (see p4 login for details), changing your password automatically invalidates all of your outstanding tickets.
The collected values of the Email fields can be listed for each user with the p4 users command, and can used for any purpose.
The p4 reviews command, which is used by the Helix Core Server change review daemon, uses the values in the Reviews field. When activated, the change review daemon sends email to users whenever files they’ve subscribed to in the Reviews field have changed. Files listed in this field must be specified in depot syntax.
For example, if user joe has a Reviews field value of
```
//depot/main/...
//depot/.../README
```
the change review daemon sends joe an email whenever any README file has been submitted, and whenever any file under //depot/main has been submitted.

Another example for the Reviews field is:

//depot/*/relnotes.txt

to send notification for changes to the relnotes.txt file on all the branches in the depot.
There is a special setting for job review when used with the Helix Core Server change review daemon. If you include the value:
```
//depot/jobs
```
in your Reviews field, you will receive email when jobs are changed.
If you set the Jobview field to any valid jobview, jobs matching the jobview appear on any changelists created by this user. Jobs that are fixed by the changelist should be left in the changelist when it’s submitted with p4 submit; other jobs should be deleted from the form before submission.

For example, suppose the jobs at your site have a field called Owned-By:. If you set the Jobview field on your p4 user form to Owned-By=yourname&status=open, all open jobs owned by you appear on all changelists you create. See p4 jobs for a full description of jobview usage and syntax.

Examples

`p4 user joe`	View the user specification of Helix Core Server user `joe`.
`p4 user`	Edit the user specification for the current Helix Core Server user.
`p4 user -d sammy`	Delete the user specification for the Helix Core Server user `sammy`, but has no effect on `sammy`'s workspace clients.
`p4 user -D sammy`	Previews the deletion of: user `sammy` all of `sammy`'s workspace clients, except those where a user other than `sammy` has files opened
`p4 user -D -y sammy`	Performs the deletion of: user sammy all of `sammy`'s workspace clients, except those where a user other than `sammy` has files opened Note Cannot be undone.
`p4 user -D -f sammy`	Previews the deletion of: user sammy all of `sammy`'s workspace clients, including those where a user other than `sammy` has files opened
`p4 user -D -f -y sammy`	Performs the deletion of: user sammy all of `sammy`'s workspace clients, including those where a user other than `sammy` has files opened Note Cannot be undone.
`p4 user -D -F -y sammy`	Performs the deletion of: user sammy all of `sammy`'s workspace clients, including those where a user other than `sammy` has files opened sammy from the protections table and groups Note Cannot be undone.
`p4 -u joe -P hey submit`	Run `p4 submit` as user `joe`, whose password is `hey`. This command does not work at higher security levels.
`p4 user -f joe2`	Create a new Helix Core Server user named `joe2` if the caller is a Helix Core Server superuser, and `joe2` does not already exist as a Helix Core Server user. If user `joe2` already exists, allow a Helix Core Server superuser to modify the user’s settings.

Related commands

To view a list of all Helix Core Server users	`p4 users`
To change a user’s password	`p4 passwd`
To view a list of users who have subscribed to review particular files	`p4 reviews`
To control how new users are created by changing the `dm.user.noautocreate` configurable	`p4 configure`

p4 user

Syntax

Description

Removing users

Types of users

Permissions for standard users

Permissions for operator users

Permissions for service users

Form Fields

Options

Usage notes

Examples

Related commands