External URL

The URL to use as the "official" URL for the Code Collaborator server.  This URL will be reported to clients, used in notification emails, and so forth.  It should be something that is accessible from as many other computers as possible.  It needs to include the port number if it's not 80.

Company / Unit

Arbitrary text that will be displayed at the top of the Code Collaborator web page.  This distinguishes the server from other servers.  This personalizes the server and also makes it easy for users to distinguish between different installations you might have.

The text to display on the front page when the user logs in.  This text is displayed just below the "Username" field.

The default text suggests using the same login as the version control system, however you might want to change this to be more specific, or in the case of LDAP authentication, you could instruct the user to use that login.

Global
"Create User"

If you're not using LDAP authentication, every user in the system must be explicitly created.  The system administrator can create users at any time, but an easier technique is to allow users to create their own accounts from the "Login" screen.
 
When this option is enabled, this create-account form is displayed, otherwise it's hidden.
 
This option doesn't make sense if you're using LDAP authentication because in that case user accounts are created automatically when a user first successfully authenticates on the Login screen.

Tab Width

Width of a tab, in space-characters, to use when displaying source code.

The minimum time (in seconds) to wait before auto-updating chat conversations in the diff viewer.

As you increase the refresh time, new chat display will become less responsive, but server load will diminish.  Also, because most modern browsers limit the number of simultaneous server connections to 2, this also reduces contention for connections on the browser side.

The minimum number of letters to use when abbreviating user names during a review.

Allow Regular Users to Perform System Dump

Should regular users be allowed to perform system dump?

Selecting "Yes" will give users, as well as administrators, access to the system debugging information.

Who should be allowed to view the "Reports" section of the user interface?  You can choose everyone, only administrators, or no one/disabled.

Subscriptions Access

Selecting "Users" will allow users, as well as administrators, access to edit subscriptions.  Choose "Administrators" to give access to only administrators.

Subscriptions Mode

This will give you the choice to set subscriptions as mandatory, suggested, or disabled.

Allow System Administrator to Perform Reviews

Should the main system administrator be allowed to participate in reviews?
 
If you're using internal authentication the setting is typically "no" because the main "admin" account is special and should be used only for system configuration and not to actually do code reviews.
 
If you're using LDAP authentication the setting is typically "yes" because the main administrator is usually an actual human being who will also want to participate in reviews.
 
This setting affects whether the system account is allowed to create a new review and whether it appears in e.g. drop-down lists for review participants.

Allow "Mark All Read"

Should users be given the option to "mark all conversations read" in one click in the conversation area of the diff viewer?
 
This is a convenient operation, so most administrators leave this enabled.  However this makes it easy for someone to not actually read a lot of comments because they are not forced to visit each conversation individually.

Once a review has completed, should participants be allowed to re-open the review just by making an additional comment?

If not allowed, an administrator is still able to re-open a review by clicking a link.

Allow Editing Completed Reviews

Once a review has completed, should participants be allowed to edit the review title and custom fields?

Allow Deleting/Cancelling Reviews

Should the review creator or author be able to cancel the review at any time?

If "Don't allow" is selected, only an administrator will be able to cancel a review.  Other participants are never allowed to cancel a review.

Restrict Access to Review Content

Should the system always restrict access to review content such that only participants of the review and other system administrators are allowed to view the review?
 
If set to "no," in each review the review creator can elect to restrict access to review content on a case-by-case basis.  If set to "yes," all reviews are so restricted and the review creator has no choice in the matter.

Should all participants of a review be allowed to upload files to a review?

If set to "yes," only review creators and administrators will be allowed to upload files to the review.  However, the option will be available on the Create Review screen to override at the review creator's discretion.  If set to "no," all participants will be allowed to upload files.

If set to non-zero, this is the default number of days until reviews are due. If zero, users will not be prompted for a review deadline in the "Basic Information" section of the Review Creation Wizard page.

Show Metrics

Should users be able to see that metrics are collected including time spent in review, number of defects, and so on?

If disabled, metrics are still collected and can be retrieved from the database, however the information is not displayed to the user during review or in the reports section.

Allow Combined Review View

Allow the review creator to specify that multiple review changelists should be displayed combined as if it were one large changelist.
 
We do not recommend using this setting unless you're sure your users will understand what they are seeing.  This mode can confuse changes that are actually part of the review with changes that happened between files in the changelist.

Bug URL Format

The URL to your bug tracking system that displays a bug of a given ID.  Use the special text BUGID to represent the actual ID.  This setting is used when automatically linking bugs to your external issue tracking system.

For example, with FogBugz the URL might look like this:

http://bugserver/default.php?BUGID

In Bugzilla the URL would look something like this:

http://bugserver/show_bug.cgi?id=BUGID

Create Bug URL

The URL to your bug tracking system that creates a new bug.  Optionally use the special text BUGSUBJECT as the starting subject line for the bug.  This setting is used when the  user is prompted to create a bug in your external issue tracking system.

For example, with FogBugz the URL might look like this:

http://bugserver/default.php?command=new&pg=pgEditBug

In Bugzilla the URL would look something like this:

http://bugserver/enter_bug.cgi

Bug ID Comment Regular Expression

A Java-style regular expression that identifies a reference to an external bug in other text.  This is used to pick out bug references in review titles, custom fields, comments, and defects.  The regular expression is case-insensitive.

You must include exactly one grouping expression that identifies the bug ID in the string.  This is used to link to the actual bug.

For example: case\s*(\d+)

This would match a string like Case 1423 but not 500 cases.  This is the standard way to refer to a bug in FogBugz.

Client Installer Link

URL to the version of the client installers that you want presented to users of the system.

This is typically redirected to an Intranet page maintained by the administrator.

Minimum Command-Line Build

Minimum allowable build number for the various client applications including the command-line client (ccollab), the Eclipse plug-in, and the Perforce integration system (p4collab).

Use this to ensure your clients are reasonably up to date.  This is especially important if there is a feature or bug-fix you know is necessary for your system.

The help text in the GUI will identify the oldest stable, compatible build number and will list the most recent known build number for your reference.

Minimum Windows GUI Client Build

Minimum allowable build number for the Windows GUI Client.

Use this to ensure your clients are reasonably up to date.  This is especially important if there is a feature or bug-fix you know is necessary for your system.

The help text in the GUI will identify the oldest stable, compatible build number and will list the most recent known build number for your reference.

Binary files attached to reviews are not displayed in the Diff Viewer, and instead must be opened by external applications.  Here you can configure which files are to be treated as binary.  By default, Microsoft Word, Microsoft Excel and Adobe PDF files are considered binary.

Filename matching is done using the '*' and '?' wildcards characters. '*' matches 0 or more contiguous characters, and '?' matches exactly one character.  The character matching is case-insensitive on Windows platforms and case-sensitive on all other platforms.

Fun facts are lines of information displayed on the home page.  Code Collaborator rotates through a number of internal facts based on review metrics.  Additional lines to be displayed can be entered in this form, or can be disabled.  Disable fun facts by setting the "Show System Fun Facts" field to hide.