User status

There are different statuses associated with a Tuleap user:

‘A’ for Active

‘P’ for Pending

‘V’ for Validated

‘R’ for Restricted

‘W’ for Validated as Restricted

‘S’ for Suspended

‘D’ for Deleted

‘Validated’:(Only when administrator approval is needed) an administrator validated the account. It is not active yet: the user has to follow the link sent in the validation email to activate the account. The administrator may also activate the account in the administration interface.

‘Restricted’ users are like active users with restricted access rights:they cannot access pages from projects they are not member of. This special role is only enabled on Tuleap servers in heterogeneous environments where corporate users and external consultants share the same server.

‘Validated as Restricted’ is the same as ‘Validated’, the account was validated by an admin, but as ‘restricted’.

From the point of view of the Web interface there is not much difference between ‘S’ and ‘D’: in both cases the effect is that the user can non longer login and in both cases they are not counted in the number of active users (upper right corner of the front page). In any case a user will never disappear from the MySQL database.

To modify this field one has to go either to the User Admin page (left menu pane) but it generates a huge page with all users. So a better choice is to choose “Admin Page” and then search for the use or select the first letter of the name. Then you can change the status.

Pending users

Before a user account is made available, it has to be activated. According to your Tuleap configuration there are several ways to activate an account:

Standard case, no administration approval is needed. Once the user created his account, he will receive an e-mail, and then when clicking on the link inside he will activate his account. The admin can also activate the account (if the user e-mail is not valid…) in the pending user interface.
Administration approval is needed (sys_user_approval = 1). Once the user created his account, the administrator is notified by e-mail. He has to first validate the account in the pending user interface. Then an email is sent to the user. The account is activated once the user has followed the link sent in the email. The administrator can also directly activate the account :
- after validation, in the validated user interface
- or before validation directly in the pending user interface
Restricted user and administration approval is needed (sys_allow_register_user=1 and sys_user_approval=1) Once the user created his account, the administrator is notified by e-mail. He has to validate the account in the pending user interface. He can choose between standard user or restricted user. Then an email is sent to the user. The account is activated once the user has followed the link sent in the email. The administrator can also directly activate the account :
- after validation, in the validated user interface
- or before validation directly in the pending user interface

Here are the various possible status values for a Tuleap user:

Pending (internal: ‘P’): the account was submitted, but not validated or activated.
Validated (internal: ‘V’): (Only when administrator approval is needed): an administrator validated the account. It is not active yet: the user has to follow the link sent in the validation email to activate the account. The administrator may also activate the account in the administration interface.
Validated as Restricted (internal:W): This is the same as above: the account was validated by an admin, but as ‘restricted’.
Active (internal: A): The account is active: the user can log in and use Tuleap.
Restricted (internal: R): The account is active with a restricted status. The user can log in and use Tuleap, but only on projects he belongs to.
Suspended (internal: S): The account was suspended by an administrator: the user can no longer log in.
Deleted (internal: D): the account was deleted and the user home directory on Tuleap is removed, as well as all entries in system files.

Restricted Users

Overview

One of Tuleap main benefits is to enable code sharing and re-usability in a corporation. The goal is to provide visibility of your project and code in the whole community of users. Still, in some cases, this visibility becomes an issue:

When Tuleap is used for customer interaction, e.g. to collect customer support requests and bugs.
when some project members are from other companies (contractors), and should not have access to the whole site

In both cases, external people (customers and contractors) need an access to the server; yet, they should not be granted access to all the other projects hosted on Tuleap.

A solution to this problem has already been put in place: use two servers instead of one (one for internal use, one for ‘partners’). Yet, there is an issue with projects that are being developed internally and that have customer feedback. In this case, you need to duplicate the project, which is not convenient; customers cannot access commit pages referenced in commit emails (because they point to the internal server),etc.

Now, there is another solution by enabling restricted users on your server: these users (typically, external users), are granted access to their project pages only, and are denied access to any other page (other projects, software map, etc.). Normal users still have access to the whole server.

Configuration

local.inc

In order to setup restricted users, you need a coherent local.inc.

Edit /etc/tuleap/conf/local.inc and make sure that the following variables are properly set:

$sys_user_approval = 1;
$sys_is_project_public = 1;
$sys_allow_anon = 0;
$sys_allow_restricted_users = 1;

Some explanation:

$sys_user_approval = 1 is needed because it is during the user approval phase that the Tuleap administrator is able to set the user status to ‘Restricted’ (R) or ‘Active’ (A). If the variable is set to ‘0’, users will be created as Active by default.
$sys_is_project_public = 1 is not absolutely necessary. It just seems useless to have restricted users if all projects are private.
$sys_allow_anon = 0 is needed. Otherwise, anonymous users (i.e. users who have not logged in) would have more privilege than restricted users. So a restricted user would simply need to log out to be able to browse other projects, etc.
$sys_allow_restricted_users = 1 simply enables the ‘Restricted’ status for users.

Setting restricted users privileges

You may fine tune the privileges of restricted users on your system. Simply copy /usr/share/tuleap/site-content/en_US/include/restricted_user_permissions.txt in /etc/tuleap/site-content/en_US/include/ and edit it. This is a sample configuration file:

// comment/uncomment forbidden URLs
$forbidden_url = array(
          '/softwaremap/', // browsable software map
          '/new/',         // list of the newest releases made on the Tuleap site
          '/search/',      // search for people, projects, and artifacts in trackers!
          '/people/',      // people skills and profile
          '/stats/',       // Tuleap site statistics
          '/top/',         // projects rankings (active, downloads, etc)
          '/project/register.php',    // Register a new project
          '/export/',      // Tuleap XML feeds
          '/info.php'      // PHP info
          );

// Use true/false for those options
$allow_welcome_page=false;// Allow access to Tuleap welcome page (at e.g. http://example.com/)
$allow_news_browsing=false;     // Allow restricted users to read/comment news, including for their project
$allow_user_browsing=true;      // Allow restricted users to access other user's page (Developer Profile)
$allow_access_to_codendi_forums=true;   // Tuleap help forums are accessible through the 'Discussion Forums' link
$allow_access_to_codendi_trackers=false;// Tuleap trackers are used for support requests on Tuleap
$allow_access_to_codendi_docs=false; // Tuleap documents (Note that the User Guide is always accessible)
$allow_access_to_codendi_mail=false; // Tuleap mailing lists (Developers Channels)

Other considerations

Subversion: currently, if the sys_allow_restricted_user variable is set to ‘1’, subversion repositories have their default access policy changed: by default, only project members have read access (as well as write access). If other users need to access the SVN repository, they need to be individually added to the subversion access file (through the svn admin page).