Membership

Membership identifies which users belong to a project and defines how they interact with reviews and project activity.

Overview

Project members and non-members behave differently:

Difference Member Non-Member Description
Notifications Receives Notification image Does Not Receive Notification image

Members receive project notifications. Non-members do not.

Avatars Receives Notification image Does Not Receive Notification image

Member avatars appear on the project home page.

States Receives Notification image Does Not Receive Notification image

Members, moderators, and authors can change review states. Non-members cannot.

Become a project member

You can become a member in one of the following ways:

  • Create a project and add yourself as a member

  • Ask an existing member to add you

If the project has owners, only a project owner can add members

Users with super privileges in P4 Server can always modify project membership.

Add a member

  1. If you are a project owner, or a member of a project without owners:

  2. Open the project.

  3. Click Settings.

  4. In the Members tab, click Manage members.

  5. Add a user, group, or project:

    • The field auto-suggests users, groups, and projects

    • Adding a group or project adds all of its members

  6. Click Add.

Groups and projects are listed before individual users and are visually grouped.

Remove a member

If you are a project owner, or a member of a project without owners:

  1. Open the project.

  2. Click Settings.

  3. In the Members list, click the X next to the user, group, or project.

  4. Click Save.

You are able to remove your own membership or ownership. Doing so could prevent you from managing the project.

Owners

A project owner is a P4 Server user who controls project configuration.

  • Only owners and users with super privileges can modify project settings

  • Owners do not need to be project members

Some settings, such as Automated tests and Automated deployment, are hidden from non-owner project members

Moderators

A moderator manages reviews for specific project branches.

When a branch has moderators:

  • Only moderators can approve or reject reviews.

  • Moderators can move reviews to any state.

  • Moderators can override automatic approval rules.

Add moderators from the branch configuration.

Moderator permissions

Role Allowed actions Restrictions

Moderators

Move reviews to any state, approve or reject reviews, prevent automatic approvals

No restrictions unless disable_self_approve is enabled in config.php. To learn more, see disable_self_approve.

Authors (not moderators)

Can set review state to:

  • Needs review

  • Needs revision

  • Archived

Can attach committed changelists.

Cannot approve or reject reviews.

Authors (also moderators)

Can set review state to:

  • Approve

  • Rejected

  • Needs review

  • Needs revision

  • Archived

Can attach committed changelists.

Cannot approve their own reviews if disable_self_approve is enabled in config.php. To learn more, see disable_self_approve.

Project members

Can set review state to:

  • Needs review

  • Needs revision

Can attach committed changelists.

Cannot approve, reject, or archive reviews.

Other users

None

Cannot change review states.

All roles

Can start a review.

Cannot change review state if it’s not in their allowed states (for example, cannot change from Rejected).

Additional behavior

  • A single moderator approval is required by default when a review spans multiple branches.

  • You can configure one moderator approval per branch.

  • If a moderator belongs to multiple branches, one approval applies to all relevant branches. To learn more, see Moderator behavior when a review spans multiple branches.

Default reviewers

Default reviewers are automatically added to reviews when they are created.

  • You can add users or groups as default reviewers.

  • Users can be optional or required reviewers.

  • Groups can be:

    • Optional

    • Required (one vote)

    • Required (all votes)

To learn how to add default reviewers to a project, see Participants tab.

Default reviewers for reviews in multiple projects or branches:

When a review spans multiple projects or branches:

  • Default reviewers from all sources are combined.

  • The most restrictive vote requirement is applied.

For example:

  • In Project-A: Reviewer X is optional.

  • In Project-B: Reviewer X is optional.

  • In the project branch, Branch-B, Reviewer X is required.

As a result, Reviewer X will be added as a required reviewer on the review.

Mentions and reviewers

If users or groups are @mentioned in a new changelist description that includes #review, they will be added to the review as reviewers.

If any of these reviewers are already specified as default reviewers they will not be added to the review again, the reviewer's most restrictive reviewer option is used for the review.

Retain default reviewers

By default, default reviewers can be removed from a review. Enable Retain default reviewers to prevent this.

Behavior

When enabled:

  • Default reviewers are automatically maintained on review updates.

  • New default reviewers are added when detected.

  • Removed default reviewers remain on the review until they are no longer retained by an applicable project or branch. Once they are no longer retained, they can be removed manually.

  • If a review is no longer associated with a project or branch, its reviewers remain but are no longer retained.

When reviews are re-evaluated

A review is checked when:

  • The review state changes.

  • A new revision is added.

  • A comment task changes.

  • A user votes or clears a vote.

  • Reviewers are edited.

  • The review author changes.

Restrictions

  • Retained default reviewers cannot be removed from a review while they are retained by an applicable project or branch.

  • Their voting requirement cannot be reduced.

  • Their voting requirement can be made stricter.

Automatic removal when branch file matches change

When a new revision changes the files in a review, P4 Code Review re-evaluates which project branches apply to that review.

If the revision removes the last file that matches a branch's depot paths, that branch no longer applies to the review and its default reviewers are removed automatically.

This automatic removal applies to all default reviewers contributed by that branch, including retained and non-retained default reviewers.

  • If a default reviewer came only from the branch that no longer matches any files in the review, P4 Code Review removes that reviewer automatically.

  • If a retained default reviewer is removed in this way, P4 Code Review also clears the retention lock.

  • If the same reviewer is still contributed by another project branch that continues to match files in the review, that reviewer remains on the review.

  • Reviewers added manually are not affected.

If a later revision adds a file that matches the branch's depot paths again, P4 Code Review automatically re-applies the branch and adds its default reviewers back to the review.

This behavior differs from the Refresh Projects workflow.
  • File changes in a review can automatically remove or re-add default reviewers.

  • Project or branch configuration changes require Refresh Projects.

  • Refresh Projects can make retained reviewers removable, but it does not remove them automatically.

When retained reviewers can be removed from existing reviews

This workflow applies when project or branch configuration changes. It differs from the automatic reviewer updates that occur when a revision changes the files included in a review.

If a project branch adds a reviewer through default reviewers and Retain default reviewers is enabled, that reviewer is locked to the review while the branch remains in scope for the review.

If an administrator later removes that branch from the project, existing open reviews are not updated automatically. This is intentional. P4 Code Review does not run a background update of open reviews when project branch settings change.

To update an existing review, run Refresh Projects on the review. During the refresh, P4 Code Review recalculates which project branches still apply to the review.

  • If the removed branch no longer applies, P4 Code Review clears the retained reviewer lock for any reviewer added by that branch.

  • The reviewer then becomes available for manual removal from the review.

  • P4 Code Review does not remove the reviewer automatically.

  • If the same reviewer is still retained by another branch that applies to the review, the reviewer remains locked.

A retained reviewer might still appear on an existing review after project settings change

This does not mean the refresh failed. Refresh Projects unlocks the reviewer for manual removal, it does not remove the reviewer automatically.

Example

A project has two branches.

  1. One branch assigns User 1 as a default reviewer with Retain default reviewers enabled.

  2. A review is created that matches both branches, so User 1 is added as a retained reviewer.

  3. An administrator removes the branch that retained User 1 from the project.

  4. The review continues to show User 1 as a reviewer until someone runs Refresh Projects.

  5. After the refresh, User 1 is no longer locked by the removed branch and can be removed manually, unless another matching branch still retains User 1.

Reviews spanning multiple projects and branches

Related projects and branches

When a review spans related projects and branches, and a user or group is a retained default reviewer in one location but not another, the branch voting option is used.

Example

Review context

  • Review 5678 spans Project A and Branch A-1

Configuration

  • Project A

    • User-X: Required reviewer

      • Retain default reviewers: Enabled

  • Branch A-1 (child of Project A)

    • User-X: Optional reviewer

    • Retain default reviewers: Disabled

Result

  • User-X is an Optional reviewer.

  • User-X is not a retained default reviewer.

  • The branch setting overrides the project setting.

  • The reviewer’s voting requirement can be changed.

  • The reviewer can be removed from the review.

Unrelated projects and branches

When a review spans unrelated projects and branches, and a reviewer is retained in some but not others, the strictest voting requirement is used.

The strictest retained reviewer requirement becomes the minimum allowed voting requirement for that reviewer.

Example

Review context

  • Review 1234 spans Project A, Project C, and Branch F-1

Configuration

  • Project A

    • Group-D: Optional reviewer

    • Retain default reviewers: Enabled

  • Project C

    • Group-D: Required reviewer (all votes)

    • Retain default reviewers: Disabled

  • Branch F-1 (unrelated)

    • Group-D: Required reviewer (one vote)

    • Retain default reviewers: Enabled

Result

  • Group-D is a Required reviewer (all votes).

  • Group-D is a retained default reviewer.

  • The strictest voting requirement is applied.

  • The voting requirement can be changed, but not below the strictest retained level.

  • Minimum allowed: Required reviewer (one vote).

  • The reviewer cannot be removed from the review.