Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 CLI Documentation | 2025.2

# p4 grant-permission (graph)

Assign the specified permission for the specified depot of type `graph` (or a repo The container of files that the Git Connector caches or mirrors from Git users. See also 'graph depot'. in that graph depot A depot of type graph that is used to store Git repos managed by P4 Server. See also Git Connector and classic depot.) to the specified user or group.

For depots of type `graph` only.

## Syntax

    p4 [g-opts] grant-permission -d graphDepot1 -g group [-r ref] -p permission
    p4 [g-opts] grant-permission -d graphDepot1 -u user [-r ref] -p permission
    p4 [g-opts] grant-permission -n //graphDepot1/reponame -g group [-r ref] -p permission
    p4 [g-opts] grant-permission -n //graphDepot1/reponame -u user [-r ref] -p permission
    p4 [g-opts] grant-permission -n //graphDepot1/reponame -g group -r ref -p restricted-ref
    p4 [g-opts] grant-permission -n //graphDepot1/reponame -u user -r ref -p restricted-ref

Syntax and naming conventions

## Description

An administrator is the owner, or a user that has been granted the `admin` permission for that specific graph depot or repo.

The user who creates a depot is the `owner` of that depot and always has full `admin` rights to the depot. An `admin` user can grant permissions, including the `admin` permission, to groups and users of the depot or a repo it contains.

This command does not verify the existence of the specified user or group. Nor does this command verify the existence of the specified reference to a branch or tag. Therefore, you can use those options before or after creating the user, group, or reference to a branch or tag.

Permissions are additive. For example, you can give a user the `create-repo` permission, and later also give that user the `delete-repo` permission. After you have granted a permission, you can remove that permission with `p4 revoke-permission`.

Certain permissions imply multiple permissions. Any such permissions are included automatically and cannot be revoked unless the permission that contains them is revoked. See Permissions.

## Options

Option | Description
--- | ---
`-d` | Applies to the depot and its repos. The P4 Server superuser can specify `-d *` to grant the permission for all repos in all graph depots.
`-n` | Applies to the repo with the specified name.
`-g` | Applies to the specified group.
`-u` | Applies to the specified user.
`-r` | Optional for the `create-ref`, `delete-ref`, and `write-ref` permissions to specify the ref, a reference that corresponds to a repository’s branch, such as refs/heads/release, or a tag, which might represent a release number, such as refs/heads/rel-2.1.14. See https://git-scm.com/book/en/v2/Git-Internals-Git-References. Required for the `restricted-ref` permission.
`-p` | Applies the specified permission.
`g-opts` | See Global options.

## Permissions

When you grant a permission to a user or group, that user or group receives:

- the specified permission
- any permissions that are implied (implicitly included) with the explicit permission

For example, `admin` implies all the other permissions, and `force-push` implies `delete-ref`.

If the Assigned Permission is ... | ... the Implied Permissions are:
--- | ---
| admin | force-push | delete-ref | create-ref | delete-repo | create-repo | write-all | write-ref | read
admin |  |  |  |  |  |  |  |  |
force-push |  |  |  |  |  |  |  |  |
delete-ref |  |  |  |  |  |  |  |  |
create-ref |  |  |  |  |  |  |  |  |
delete-repo |  |  |  |  |  |  |  |  |
create-repo |  |  |  |  |  |  |  |  |
write-all |  |  |  |  |  |  |  |  |
write-ref |  |  |  |  |  |  |  |  |
read |  |  |  |  |  |  |  |  |

The capability associated with each permission:

`admin` | Grant and revoke permissions for the repo or graph depot specified. This is different from the admin of p4 protect. A user who is super through p4 protect automatically has this admin capability. The owner of the repo or graph depot automatically has admin capability for that repo or graph depot.
`force-push` | Force an overwrite to the branch.
`delete-ref` | Delete the repository’s branch or tag specified by `-r` ref.
`create-ref` | Create and set the initial value of `-r` ref for the specified repository’s branch or tag. Does not include the write-ref permission.
`delete-repo` | Delete a repo in the specified depot of type `graph`.
`create-repo` | Allows a user to create a new repo on the graph depot through the `git push` command. For details, see Work with Git in P4 Server Administration Documentation, which explains how to create and view repos.
`write-all` | Read and update files and references of the branch or tag specified by `-r` ref. This permission allows a user to clone, pull, and push a repo that already exists in the graph depot. Does not include the `create-repo` permission. Modified files are not checked against the protection table nor for Git LFS locks.
`write-ref` | Read and update the repository’s branch or tag specified by `-r` ref. Modified files are checked against the protection table and for Git LFS locks. This is the sole permission that applies the protection setting in the protections table for a file or directory. See `p4 protect` and "Authorizing access" in the P4 Server Administration Documentation and Unable to push: not enabled by p4 protect in the Work with Git in P4 Server Administration Documentation.
`read` | Read the files in the specified depot or repo. This allows the user to clone and pull from the repo. This is different from the read permission of p4 protect.

The following permission is exclusive and has no implied permissions:

`restricted-ref` | The specified user or group can update the ref, (branch or tag) specified by the `-r` option. If set, only users with this permission can perform an update. This prevents other users with write-ref or write-all from updating the specified reference. (See the final example.)

## Usage notes

Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required
--- | --- | ---
N/A | N/A | super from p4 protect applies to all repos and graph depots a user assigned to be admin from `p4 grant-permission` for a given repo or graph depot can use `p4 grant-permission` within the scope of that repo or graph depot

## Examples

To assign the `read` permission for the specified depot of type `graph` (and its repos) to the specified user:

    p4 grant-permission -p read -d graphDepot1 -u bruno

To limit the assignment to a specific repo within a specific graph depot:

    p4 grant-permission -n //graphDepot1/repo8 -u bruno -p read

To limit a reference-related assignment (`write-ref`, `write-all`, `create-ref`, `delete-ref`, `force-push`) to a specific branch or tag:

    p4 grant-permission -n //graphDepot1/repo8 -r "refs/heads/rel-2.1.14" -u bruno -p create-ref

To make the reference-related assignment apply to more than one branch or tag, use the asterisk (*) wildcard:

    p4 grant-permission -n //graphDepot1/repo8 -r "refs/heads/rel-*" -u bruno -p delete-ref

To restrict a particular branch to a specified user or group, such as to restrict a branch to the devops team:

    p4 grant-permission -n //repo/test -g devops -p restricted-ref -r refs/heads/branchName

## Related commands

To list the permissions currently granted | `p4 show-permission`
To remove a permission | `p4 revoke-permission`

Your search for returned results