Users

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

Dashboard refresh interval

By default, when your dashboard is open, Swarm checks for new content every five minutes. If Swarm 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

By default, Swarm 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 Swarm, 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.
Note

ignore_whitespace replaces ignore_whitespace_default that was used in Swarm 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.
Tip

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

How Swarm handles deleted users

Swarm's users are based on the users configured in the Helix Core Server. When a user is deleted from the Helix Core Server, Swarm automatically removes the deleted user from the following locations:

• User profile

• Test definitions

• Workflows

• Projects

• Groups

A user who has been deleted from Swarm 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.

User profile

When a user is deleted from the Helix Core Server, Swarm 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 Helix Core Server, Swarm will also remove the user from the test definition ownership. Swarm 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 Swarm 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 Helix Core Server, Swarm will also remove the user from any workflow ownership. Swarm 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 Swarm 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 Helix Core Server, Swarm 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.

Swarm 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 Swarm 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 Swarm 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 Swarm 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 Helix Core Server. This is the default behavior.

Scenario	Members	Owners	Members post deletion	Owners post deletion
1	Test_User		Swarm
2	Test_User, Bruno		Bruno
3	Test_User	Test_User	Swarm
4	Bruno	Test_User	Bruno
5	Test_User	Bruno	Swarm	Bruno

Private projects

When a user is deleted from the Helix Core Server, Swarm 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 Swarm 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, Swarm removes the deleted user.

Groups

When a user is deleted from the Helix Core Server, Swarm 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 Swarm user is not the owner of the group or a super user, the group cleanup activity will not occur. In such cases, Swarm 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.

Swarm handles the following scenarios for groups:

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

• Scenario 2: If a Swarm user with owner or super user permissions deletes a sole group owner, the group owner is removed and the Swarm 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 'Swarm', and a Swarm user deletes owner 'Test_User' without having owner or super user permissions, the 'Test_User' owner is removed and Swarm becomes the sole group owner.

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

• Scenario 5: If a Swarm user with owner or super user permissions deletes the sole member of a group , the Swarm 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 Swarm 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 Swarm user without owner or super user permissions deletes one member of the group, Swarm is unable to remove the member from the group due to the limited permissions of the Swarm user.

• Scenario 8: If a group has two users, 'Test_User' and 'Bruno', and a Swarm 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, Swarm, and if a Swarm 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 Helix Core Server. This is the default behavior.

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