The URL to use as the "official" URL for the CodeCollaborator 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.

Arbitrary text that will be displayed at the top of the CodeCollaborator 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.

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.

If 'Yes' all users will use the same tab width. If 'No' each user can configure their own preference (the global setting is the default).

Width of a tab (in spaces) for all users to use when displaying reviewed files.

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

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

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

Defect Label (singular)

User-visible label for "defect" (lower case), e.g. "Marked defect fixed". If the word 'defect' has a negative connotation in your environment, specify a different word (e.g. "item" or "finding," etc.).

User-visible label for "defects" (lower case), e.g. "Can not finish because there are open defects". If the word 'defects' has a negative connotation in your environment, specify a different word (e.g. "items" or "findings," etc.).

Text to display on the 'New Review' page prompting user to select a Group to associate with the Review.

User-visible label for "Group", e.g. "This Review is associated with that Group".

User-visible label for "Groups", e.g. "Select one of the Groups to associate with the Review".

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, everyone but with review permissions applied, only administrators, or disabled (no one).

Enabled for everyone: Everyone will see the "Reports" section; no restrictions are enforced on what information is returned.

Respect Permissions: Everyone will see the "Reports" section; users can only see report content for reviews that they can access. Note that since administrators can always access all reviews, this setting does not affect the content of their reports.

Administrators only: Only administrators will see the "Reports" section.

Disabled: No one will see the "Reports" section.

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

Mandatory: Subscribed users must be participants in a review.

Requested: Subscribed users are automatically added to a review but can be manually removed.

Disabled: Subscriptions are not used.

Should the system restrict the participants that can mark a defect fixed?

If set to Yes, only the creator of the defect and administrators will be able to mark a defect fixed. Otherwise, all roles that are allowed to mark a defect fixed will have such a privilege.

Should the system always restrict access to review content such that only certain users are allowed to view the review? In each review the review creator can elect to further restrict access. Administrators can always access all reviews.

Anyone: No global restrictions on who can access reviews

Group Based: Users must have access to the review's associated group to access reviews

Participants: Users must be participants in the review to access reviews

Participants and Group Based: Users must be participants in the review and currently have access to the review's associated group to access reviews

Should only creators 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.

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 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.

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.

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

By default, when a pre-commit review is completed, the author(s) are given an action item as a reminder to commit the changes to the underlying source control system. The author then has the option of using the Tray Notifier to commit the changes. In some workflows, this is not the correct behavior. In that case, choose "Do Not Create" to avoid this prompt.

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 have the permissions to cancel a review. Other participants are never allowed to cancel a review.

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 when creating a new review.

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

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

Allow the review creator to specify that multiple changelists should be displayed combined as if they 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.

Give users the option to view file contents in various character sets.

Usually CodeCollaborator's character set auto-detection will detect the correct character set, but when it does not, users will be able to select between these character sets for displaying the file contents. To avoid confusion, limit this list to the character sets that you expect your users to require.

Click [Supported Character Sets] to view all supported character sets.

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

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 allowable build number for the various client applications including the Command Line Client, the GUI Client, the Tray Notifier, and the Eclipse Plug-in.

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 allowable build number for the Legacy Windows GUI Client. This client has been deprecated and is no longer supported but is still in use at some customer sites.

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.

Administrators can optionally insert a message to be displayed throughout the system.

This can be useful for reminders, CodeCollaborator announcements, or general information.

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 Rich Text 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.

Image File Types

Image files are reviewed in the browser in the diff viewer using a special image diff viewer. Here you can configure which files are treated as images. By default, GIF, JPEG, and PNG images are handled as images. The content of the files must be renderable by the users' browsers for images to actually be reviewable. Images that require special software to view should be treated as Binary Files so they can be rendered by that software.

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. CodeCollaborator rotates through a number of internal facts based on aggregate review metrics.

If this is set to "Hide" and there are no extra fun facts listed, this feature is completely disabled.

Additional lines to be displayed can be entered in this field.