These screens allow you to manage the application users.

Users’ List The Lock/Unlock buttons allow you to lock/unlock the user accounts. A user having a locked account cannot log in and access the application.

In modification mode, please leave the Password field blank in order to keep the user’s password unchanged. A user designated as administrator has unrestricted access to the application and to all projects. Administrator : designate the user as the administrator of the application. E-mail notifications : activate or de-activate automatic e-mail notifications for this user Locked : de-activates the user’s account

Roles organize the permissions of various members of a project. Each member of a project has a one Role in a project. A user can have different roles in different projects. On the new or edit Role screen, check off the actions authorized for the Role.

Trackers allow the sorting of Issues and can define specific workflows.

Customized fields allow you to add additional information in Projects, Issues or Users. A customized field can be of one the following types: Integer : positive or negative number String : a string of characters - one single line of input. Text : a string of characters with multiple lines of input. Differs from String Format by providing multiple lines of input instead of a single line. Date : date Boolean : true or false (check if necessary) List : value to select from a predefined list (aka: scroll list or select box) Validation elements can be defined: Required : A required field must have input in the forms For all the projects : field automatically associated to all of the projects Min - max length : minimum and maximum length for the input fields (0 means that there is no restriction) Regular Expression : regular expressions may provide validation of the input value Examples: ^\[A-Z]{4}\d+$ : 4 capital letters followed by one or several digits ^[^0-9]*$ : characters only - no digits Possible values : possible values for the fields of "List" type. Values are separated by the character |

Required : required field

For all projects : field automatically associated to all project Issues If this option is not activated, each project could choose whether or not to use the field for its Issues (please see the project configuration).

Required : required field

These screens allow you to define the different possible Issue statuses. Closed : indicates Issue is considered as closed Default : status applied by default to new Issue requests (only one status can be Default status) Color : HTML color code (6 characters) representing the displayed status

The workflow allows to define changes the various project members are allowed to make on the Issues, according to their type. Select the role and the tracker for which you want to modify the workflow, then click Edit. The screen allows you then to modify the authorized change, for the chosen role and tracker. The Current Status options indicate the initial request status. The "New Statuses allowed" columns stand for the authorized status to apply. Note: In order for a particular Role to change an Issue status, the authorization must be given to it explicitly, regardless of the workflow configuration. Example of a workflow configuration In the above example, Bug type Issue requests with a New status could be given an Assigned or Resolved status by the Developer role. Those with an Assigned status could get a Resolved status. The status of all the other Bug type requests cannot be modified by the Developer.

The value lists used by the application can be customized (for example, setting Issue priorities). This screen allows you to define the possible values for each of the following lists: Issue Priorities Document Categories

This screen allows you to select the actions that will generate an e-mail notification for project members. Note: E-mail sending must be activated in the application configuration if you want to make any notifications.

By default, redMine refers to its own database to authenticate users, by a specific password. If you already have one or several external user references (like LDAP), you can make them known in order to be used for authentication on redMine. This allows users to access redMine with their usual user names and passwords. For each known reference, you can specify if the accounts can be created on the fly on redMine. If needed, the user accounts will be created automatically during the user’s signing in (without any specific rights on the projects), according to information available in the reference. Otherwise, the administrator must have previously created the user account on redMine.

Name : reference display name Host : LDAP server host name Port : connection port to the LDAP server Account : DN of the connection account to LDAP (please leave it blank if the directory authorizes anonymous read access) Password : password of the connection account Base DN : Basic DN used for user search in the directory LDAP screen : User search screen in the directory (optional) LDAP features : Identifier : LDAP feature name used as user identifier (e.g.: uid) First name : LDAP feature name including the user’s first name (ex: givenName) Last name : LDAP feature name including the user’s last name (ex: familyName) E-mail : LDAP feature name including the user’s e-mail address (ex: mail) The features" First name ", " Last name " and " E-mail " are not used except when the accounts are created on the fly.

Displays application and environment information.

The preview presents the general project information, its main members, the latest announcements, as well as an synthesis of Issue requests open by tracker.

By default, the entire list of the project open Issues are displayed. Various screens allow you to select the Issues to be displayed. If the project has sub-projects, you have the possibility to display the sub-project's Issues as well (not displayed by default). Once applied, a screen is valid during the entire session. You can re-define it or delete it by clicking Cancel. Request list

This screen presents the number of Issues and Issue status synthesis according to various criteria (tracker, priority, category). Direct links allow for access to the detailed Issue list for each criterion.

This page presents the entire list of the resolved Issues for each version of the project. Certain types of Issues can be excluded from this display.

Allows you to inform users on project activity.

Documents are grouped by categories (see Value Lists). A document can contain several files (for example: revisions or successive versions).

This module allows you to display various folders (sources, binaires, ...) for each version of the application.

Public : if it’s a public project, it can be viewed (request consultation, documents consultation, ...) for all the users, including those who are not project members. If it’s not a public project, only the project members have access to it, according to their role. Customized fields : Select the customized fields that you want to use. Only the administrator can define new customized fields.

This screen allows you to define the project members as well as their corresponding roles. A user can have only one role in a given project. The role of a member determines the permissions they have in a project.

Versions allow you to follow the changes made during all the project. For instance, at the close of an Issue, you can indicate which version takes it into account. You can display the various versions of the application (see Files).

Issue categories allow you to organize Issues. Categories can correspond to different project modules.