Helix Core is now P4 and Helix Swarm is now P4 Code Review. Learn more >>

Documentation | 2025.2

# Users

This section describes the configurables that can be set for users.

If you make a configuration change, P4 Code Review will not use it until the configuration cache has been reloaded, this forces P4 Code Review to use the new configuration. You must be an admin or super user to reload the P4 Code Review config cache. Navigate to the User id dropdown menu, select System Information, click the Cache Info tab, and click the Reload Configuration button.

## Dashboard refresh interval

By default, when your dashboard is open, P4 Code Review checks for new content every five minutes. If P4 Code Review finds new content for a user's dashboard, the Refresh button is displayed on their dashboard. For more information about using the Refresh button, see Refresh button.

Configure the dashboard refresh interval in milliseconds with the following configuration block in the `SWARM_ROOT/data/config.php` file:

    <?php
        // this block should be a peer of 'p4'
            'users' => array(
               'dashboard_refresh_interval' => 300000, // Default 300000 milliseconds
               ),
            ),

Default value is 300000 milliseconds (300 seconds, 5 minutes)

## Display full names

For P4 Code Review 2022.1 and later, the display_fullname value defaults to true. For earlier P4 Code Review releases, the default was false. Upgrading your P4 Code Review version to 2022.1 and later will not change your display_fullname setting.

By default, P4 Code Review displays full user names. Set the display_fullname configurable to false to display userids on the:

- Project Settings page
- Group Settings page
- Activity streams
- Commits page
- Edit reviewers dialog

To display userids in P4 Code Review, set the following configuration block in the `SWARM_ROOT/data/config.php` file to false:

    <?php
        // this block should be a peer of 'p4'
            'users' => array(
               'display_fullname' => false,
               ),
            ),

Default value is true, full user names are displayed.

## Review preferences

The review preferences configure the default way that diffs are initially displayed to users when they view them in changelists and code reviews. The review preference settings are used for a user until they change their user preferences, see user profile Settings.

Configure the default user diff view settings with the following configuration block in the `SWARM_ROOT/data/config.php` file:

    <?php
        // this block should be a peer of 'p4'
            'users' => array(
               'settings' => array(
                  'review_preferences' => array(
                      'show_comments_in_files'             => true,
                      'view_diffs_side_by_side'            => true,
                      'show_space_and_new_line_characters' => false,
                      'ignore_whitespace'                  => false,
                  ),
               ),
            ),

show_comments_in_files:

- true: display comments in files and in the Comments tab. This is the default value.
- false: display comments only in the Comments tab.

view_diffs_side_by_side:

- true: display diffs in files side by side in two panes. This is the default value.
- false: display diffs in files inline in a single pane.

show_space_and_new_line_characters:

- true: display whitespace characters as dots, tabs as arrows that point to a bar, and line endings as arrows that point down.
- false: whitespace, tabs and line endings are not displayed as special characters. This is the default value.

ignore_whitespace:

- false: changes made to whitespace are highlighted in file diffs. This makes it easier to identify changes in file types where whitespace is important. This is the default value.
- true: changes made to whitespace are not highlighted in file diffs. This makes it easier to see the important changes in file types where whitespace changes are not important.

`ignore_whitespace` replaces `ignore_whitespace_default` that was used in P4 Code Review version 2017.4 and earlier. By default `ignore_whitespace` is set to false, this is the same original default value set for `ignore_whitespace_default`.

## Time preferences

The time preferences configure the default way that time is initially displayed to users. The time preference settings are used for a user until they change their user preferences, see user profile Settings.

Configure the default user time settings with the following configuration block in the `SWARM_ROOT/data/config.php` file:

    <?php
        // this block should be a peer of 'p4'
            'users' => array(
               'settings' => array(
                  'time_preferences' => array(
                      'display'  => 'Timeago', // Default to 'Timeago' but can be set to 'Timestamp'
                  ),
               ),
            ),

display:

- 'Timeago': time is displayed as how long ago the event happened. This is the default value.
- 'Timestamp': time is displayed as the date and time the event happened using the local machine browser time.

If timestamp is selected, the date format used by P4 Code Review matches the date format configuration of the local machine browser.

## How P4 Code Review handles deleted users

P4 Code Review's users are based on the users configured in the P4 Server. When a user is deleted from the P4 Server, P4 Code Review automatically removes the deleted user from the following locations:

- User profile

- Test definitions

- Workflows

- Projects

- Groups

A user who has been deleted from P4 Code Review can be identified by the suffix "deleted" at the end of their userid. This only works for My Dashboard, Reviews list, Project settings, and Review display pages that are written in React. An event is added to the activity stream whenever a deleted user is removed from workflows, projects, groups, test definition, and project followers.

For more information how P4 Code Review handles users deleted outside of the platform, see When an owner is deleted outside of P4 Code Review.

### User profile

When a user is deleted from the P4 Server, P4 Code Review automatically performs the following actions on the user profile:

- Removes the profile of the deleted user from the `SWARM_ROOT/data/config.php` file.

- Removes the profile of the deleted user from the Perforce database.

- Removes all the followers of the user that is deleted.

- Removes the deleted user from the followers list of any user or projects they might be following.

### Test definitions

When a user is deleted from the P4 Server, P4 Code Review will also remove the user from the test definition ownership. P4 Code Review handles the following two scenarios for test definitions:

- Scenario 1: If the user who was deleted is the sole owner of a test definition, on user deletion, the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file will become the owner of the test definition.

- Scenario 2: If there are two owners for a test definition, on user deletion, the other user automatically becomes the owner of the test definition.

### Workflows

When a user is deleted from the P4 Server, P4 Code Review will also remove the user from any workflow ownership. P4 Code Review handles the following two scenarios for workflows:

- Scenario 1: If the user who was deleted is the sole owner of a workflow, on user deletion, the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file will become the owner of the workflow.

- Scenario 2: If there are two owners for a workflow, on user deletion, the other user automatically becomes the owner of the workflow.

### Projects

When a user is deleted from the P4 Server, P4 Code Review will also remove the user from any associated projects that the user is part of. A project must have at least one member or a subgroup.

P4 Code Review handles the following scenarios for projects:

- Scenario 1: If the user who was deleted is the sole member of a project, on user deletion, the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file will become the member of the project.

- Scenario 2: If there are only two members for a project, on user deletion, the other user becomes the sole member the project.

- Scenario 3: If the user who was deleted is the sole member and owner of a project, on user deletion, the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file will become the member of the project.

- Scenario 4: If there are only two members for a project and the user who was deleted is the sole owner of the project, on user deletion, the other user becomes the sole member of the project.

- Scenario 5: If there are only two members for a project of which one user is the owner of the project and the other user is deleted, the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file will become the member of the project.

The table below outlines all the scenarios after the deletion of the Test_User from the P4 Server. This is the default behavior.

Scenario | Members | Owners | Members post deletion | Owners post deletion
--- | --- | --- | --- | ---
1 | Test_User |  | P4 Code Review |
2 | Test_User, Bruno |  | Bruno |
3 | Test_User | Test_User | P4 Code Review |
4 | Bruno | Test_User | Bruno |
5 | Test_User | Bruno | P4 Code Review | Bruno

#### Private projects

When a user is deleted from the P4 Server, P4 Code Review handles the following scenarios for private projects:

- Scenario 1: If the user who was deleted is the sole owner of the private project, on user deletion, the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file will become the owner of the project.

- Scenario 2: If a private project has more than one owner, on user deletion, P4 Code Review removes the deleted user.

### Groups

When a user is deleted from the P4 Server, P4 Code Review will also remove the user from any group that the user is part of. Groups can only be modified by group owners or super users. Therefore, if the P4 Code Review user is not the owner of the group or a super user, the group cleanup activity will not occur. In such cases, P4 Code Review logs a message indicating that it was unable to perform the clean-up due to the Swarm user permissions being limited to admin and not having owner or super user access.

P4 Code Review handles the following scenarios for groups:

- Scenario 1: If a P4 Code Review user deletes a sole group owner without having owner or super user permissions, P4 Code Review logs a message indicating that it was unable to perform the clean-up due to the limited permissions of the P4 Code Review user.

- Scenario 2: If a P4 Code Review user with owner or super user permissions deletes a sole group owner, the group owner is removed and the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file becomes the owner of the group.

- Scenario 3: If a group has two owners, 'Test_User' and 'P4 Code Review', and a P4 Code Review user deletes owner 'Test_User' without having owner or super user permissions, the 'Test_User' owner is removed and P4 Code Review becomes the sole group owner.

- Scenario 4: If a P4 Code Review user deletes the sole member of a group without having owner or super user permissions, P4 Code Review is unable to remove the member from the group due to the limited permissions of the P4 Code Review user.

- Scenario 5: If a P4 Code Review user with owner or super user permissions deletes the sole member of a group , the P4 Code Review user mentioned in the `SWARM_ROOT/data/config.php` file will become the member of the group.

- Scenario 6: If a group has only one member and one owner, and a P4 Code Review user without owner or super user permissions deletes the sole member of the group, the deleted user is removed from the group.

- Scenario 7: If a group has two members, 'Test_User' and 'Bruno', and a P4 Code Review user without owner or super user permissions deletes one member of the group, P4 Code Review is unable to remove the member from the group due to the limited permissions of the P4 Code Review user.

- Scenario 8: If a group has two users, 'Test_User' and 'Bruno', and a P4 Code Review user with owner or super user permissions deletes the 'Test_User' from the group, Swarm removes the 'Test_User' from the group and 'Bruno' becomes the sole member of the group.

- Scenario 9: If a group has two users, 'Test_User' and 'Bruno', and a sole group owner, P4 Code Review, and if a P4 Code Review user with owner or super user permissions deletes the 'Test_User' from the group, Swarm removes the 'Test_User' from the group and 'Bruno' becomes the sole member of the group. The group owner remains unchanged.

The table below outlines all the scenarios after the deletion of the Test_User from the P4 Server. This is the default behavior.

Scenario | Members | Owners | P4 Code Review user is a super user or not | Members post deletion | Owners post deletion
--- | --- | --- | --- | --- | ---
1 |  | Test_User | No |  | Test_User
2 |  | Test_User | Yes |  | P4 Code Review
3 |  | Test_User, P4 Code Review | No |  | P4 Code Review
4 | Test_User |  | No | Test_User |
5 | Test_User |  | Yes | P4 Code Review |
6 | Test_User | P4 Code Review | No |  | P4 Code Review
7 | Test_User, Bruno |  | No | Test_User, Bruno |
8 | Test_User, Bruno |  | Yes | Bruno |
9 | Test_User, Bruno | P4 Code Review | No | Bruno | P4 Code Review

Your search for returned results