The Administration perspective provides access to all operations for managing Polarion user accounts and permissions. An administrator with global (i.e. repository-wide) administration rights can access all user accounts in the Polarion system. An administrator with project-scope administration rights can access user accounts for users who are assigned to the project(s) for which he/she has administrative rights.
The topic in the Topics portlet (main navigation panel) provides access to the following user management functions:
User time splitting (between projects)
LDAP interfacing (auto-create users, mapping)
When you are first beginning to use Polarion, the process of creating projects and user accounts may see a bit like the old "chicken or the egg" question ߞ which comes first?
When you create a new project, you have the possibility to specify a user as the project lead. But if you haven't created user accounts yet, you'll need to come back to the project to specify this. When you create a user account manually (i.e. not automatically with LDAP), you have the possibility to specify what Project(s) the user has access to. If you haven't yet defined any Projects, you have to return to the user account to assign project(s) after creating those in the system.
For a new Polarion system, you will probably create more user accounts than Projects initially, so the most efficient approach is probably to define Projects first and then create user accounts, assigning each user to one or more projects in the process. Just remember to go back and specify a project lead for each Project.
There are two ways to create user accounts in the Polarion system:
Create accounts directly in Polarion
Auto-create accounts from user data on a LDAP server
This section covers the first option. For information on LDAP interfacing, see Configuring LDAP Auto-create and Configuring LDAP User Mapping
This section describes the procedure for creating a new user account directly in the Polarion user interface.
You will need the following information at hand in order to create a new user account:
The new user's name (e.g. "Jean Schmidt").
The new user's e-mail address. Although not required to create a new account, if it is not specified the user will not receive any notifications.
To create a new user account:
Log in to Polarion with administrator rights (global or project scope).
Go to the Administration perspective.
If you want to create a new user for a specific project, select that project in the Projects portlet. Otherwise, select Repository.
In the Topics portlet, select : .
In the Users table, click the button. A form for entering new user account information appears.
Enter information in the required fields (marked with a red asterisk) and any other information you want to specify at this time.
Click the button to create the new user account.
The Login Name field must be a unique value in the repository, and should not contain spaces. Acceptable characters include upper and lower case letters, numbers, dash, underscore, period, and the "at" sign (@).
New users must be assigned at least one Global role in the Global Roles portlet or they will not be able to access any content in the portal.
Also note that login permission is only granted to users assigned a role of user. By default, a new user is assigned the role everyone. If you do not also assign a role of user, either at the repository level, or in at least one project, the new user account will be disabled, and the string [disabled] appears in red text in the user's account page when the new user account is saved.
This section briefly covers several common modifications an administrator may be called upon to make to user accounts.
To access an existing user account:
Log in to Polarion with administrator rights and enter the Administration perspective.
In the Topics portlet, select : to load the Users table in the Working area.
In the table, select the user account you want to modify. Remember that use user account you want may not be on the first page of the Users table of there are multiple pages. If necessary, use the Search field to search for the user's name.
After accessing the desired account, click the button in the Detail Pane of the Working Area. The following fields are modifiable:
Full Name
Password
To change a user password:
Access the user account as described in Accessing a User Account.
Open the account for editing using the button.
Enter the new password in the New Password field.
Enter the new password again in the Re-enter Password field.
Exit the Re-enter Password field to make sure your two entries match and correct the fields if they do not.
Click the button to change the user's password.
Different users fill different roles in different Projects. A use may have the same role in multiple projects, or multiple roles in the same project. The assigned role(s) control the kinds of portal content a user can access, and what level of access the user has to project artifacts and data. For example, a someone in a developer role generally works on a project and can make changes to project artifacts. A user role would typically have read-only access to most artifacts, but may be able to change some data fields, such as approval of Work Items.
User roles can be assigned for the global scope (applies to all Projects in the repository), or individual project scope (applies to a specific Project). User roles, and which users are assigned which roles, is done in the topic (Topics portlet in the Administration perspective). The level of access for each defined role is configured in Permissions.
Polarion comes pre- configured with several default user roles for different scopes:
Global and Project Group default roles:
admin
user
guest
developer
assignable
Project default roles:
project_admin
project_user
project_developer
project_assignable
For more information see the Administration Reference: Default Roles and Permissions.
Users must have a role of assignable and/or project_assignable in order to have Work Items assigned to them. If users report that they are missing in Assignee lists when they were present there in a previous Polarion version, this is probably the reason, and the Assignable role appeared only in version 3.0.0. An administrator should make sure such users are assigned the appropriate assignable role.
By default, permission to log in to the portal is granted to users having a role of user. If a user cannot log in, check the assigned roles and make sure a role of user is assigned. When a new user account is created, this role is not automatically assigned. You can tell if the user does not have this role if the user account page shows [disabled] in red text. See also: Creating User Accounts.
In any scope, you can add or delete role definitions. If you add a new Role, you will need to configure permissions for it (see Permissions ). If you assign a role to a user without defining permissions for that role, the user assigned it will not be able to access anything in the repository.
To add a new Role:
Log in with administrator rights for the scope you want for the new role, and enter the Administration perspective.
If adding a global-scope role, select Repository in the Projects Portlet Otherwise, select either the desired project group (if adding a role applicable to all Projects in it), or the Project for which you want to add a new role.
The list of currently-defined roles for your selection appears in the Working Area
Click the button.
In the edit box on the last line of the Roles column, enter the name of the role you are adding. For example, suppose you want to add a role for testers. You might specify "tester" as the role name.
If you want to add another role, click the + (plus sign) icon that appears in the Actions of the same row. A new row is added to the table with an empty edit box in the Role column.
When you have added all the roles you want, click the button.
You can now assign users the new role(s) you created. See Assigning a Role to Users
To delete a role:
Log in with administrator rights for the scope if the role you want to delete, and enter the Administration perspective.
If deleting a global-scope role, select Repository in the Projects Portlet Otherwise, select either the desired project group (if deleting a role applicable to all Projects in it), or the Project for which you want to delete a role.
The list of currently-defined roles for your selection appears in the Working Area
Click the button.
Click the - (minus sign) icon in the Actions column of the role you want to delete. The role information appears in strike-through font.
Click the button to delete the role.
Note that if any users were assigned the delete role, their account profiles are updated automatically.
If you delete a role, and there are users in the system to whom that role was assigned and the user has no other role assigned, these users will find their access limited. Polarion does not automatically set another role in this case.
You can assign one or more roles to any user. A role must already exist in order to be assigned.
To assign a role to one or more users:
Be sure you are logged in with administrative rights for the scope you want to assign, and are in the Administration perspective.
In the Projects portlet, select the scope for the assignment (repository, project group, or project).
In the Topics portlet, select : .
In the Roles table, click the Assign Users icon in the Actions column of the role you want to assign.
Select the first user you want to add from the drop-down list of user names.
To assign more users to this role, click the + (plus sign) icon in the Actions column, and select another user in the users list in the new row in the table.
When you have added all the users you want to assign the role, click the button to complete the assignment(s).
This feature may not be present in some Polarion ALM products.
In some cases, users may regularly split their working time between two or more projects (i.e. time sharing). The Live Plan project planning engine can account for this and factor such splits into the live project plan, provided the user's split time between projects is configured in his/her user account. This section explains how to configure user time splitting between projects.
To access a user's time-splitting configuration:
In the Administration perspective, select Repository, or any project in the Projects portlet.
In the Topics portlet, expand and select . The table of users for the selection appears in the top pane of the Work Zone.
Scroll or use Search to locate the user whose time is to be split between projects, and select the relevant row in the table. The user's detail appears in the lower part of the Work Zone.
In the table, the Time-split Assignments column displays the current split time assignments, if any, for the selected user.
Click the button in the user detail pane to place the user detail form in edit mode.
Scroll down, if necessary, and locate the Time-split Assignments portlet. This is where you assign the percentage of the user's time for each project.
Each row in the Time-split Assignments portlet lists a project for which the currently selected user has Work Items assigned. (You cannot split a user's work time into a project for which the user has no assigned Work Items.) You use the % of Total Time column to assign of percentage of the user's total working time to two or more projects.
The values you enter in % of Total Time must be integer values (and you do not need to enter the % sign). For example: 25 is a valid entry, while 33.3 is invalid and will result in an error message when you save changes.
It is not possible to save the configuration if the sum of all time-split assignments is more than 100.
The configuration splits the user's total working time between the different projects. That time is a combination of the Global Working Calendar configuration and the selected user's Personal Working Calendar configuration.
When a user has working time shared between two or more projects, this is reflected in the Live Plan chart. In the Repository and Project Group scope, the chart shows additional lines for a user with time splitting configured, if there are work items assigned to user in the configured projects. The lines are labeled by the user name followed by the configured percent in parenthesis. For example: Jan Almsman (20%). If the sum of configured time-split assignments is less than 100, then an extra line is shown for the remaining percentage if there are work items assigned to user in other projects for which for which no time-split assignment is specified in the configuration. The estimate of the work items for planning is multiplied by the ratio of the configured percentage. (So 20% means then the estimate is multiplied by 5.)
In the project scope, one line for the user is shown if there are items assigned to this user and there is some percent of time-split configured. If the total time splitting configured for specified projects is 100, and there are unresolved items assigned to the user in other projects, those items are not planned, nor are they displayed in Live Plan, and the warning is logged.
Planning of the work items from the different "rows" in the Live Plan which belong to the same user is independent (i.e., planning engine does not compare priorities etc.) except for items with a "depends on" link.
Permissions are an important security issue. You should plan to spend some time with this topic so that you can be sure to configure permissions appropriately.
Permissions can be configured in 3 scopes: global, project group, and project. Project settings override the same settings in the global and project group scopes. Project group in turn overrides global.
Configuration is performed by editing an XML configuration file. The global level file is installed with default settings in /.polarion/security/permissions.xml. To access this file in the Administration perspective, select the Repository node in the Projects portlet, then in the Topics portlet select : .
Permissions are configured by means of XML configuration files customized for different scopes (global, project, etc.) which can be accessed via the Polarion user interface. If you are not familiar with this concept, please see Administration Interface.
You can either download the XML configuration file to your local system, modify it, and upload back to the server, or you can edit the XML online using the text-based editor portlet provided.
As mentioned above, you can configure permissions is several scopes. Changing the global scope is the most straightforward: access the global configuration file, and modify it by one of the means described above. How to modify permissions for a more granular scope such as a project may not be immediately obvious.
Let's consider a fairly common scenario in which you have modified the default permissions configuration for the global scope, and now you want to make further modifications for a specific Project. Here, the basic process goes like this:
Select the project in the Projects portlet (you should already be in the Administration perspective).
Select the topic (expand in the Topics portlet.
In the Edit Project Configuration portlet in the Work Zone, click the button. The XML code of the current global configuration appears in the text box.
Modify the XML to create the configuration you want for the project. When finished click the button in the same portlet.
If you would rather use a preferred XML editor, you should download the global configuration file, edit it locally, and upload back to the server.
Assuming you are on the same page as described above, use the link in the Configuration portlet, located under Global configuration, to download the global configuration file to your local file system.
Modify the permissions according to what you want for the specific Project you have selected in the portal.
On the same Polarion portal screen where you downloaded the configuration file, upload the modified local file to the repository using the controls in the Upload New Project Configuration portlet.
There can be cases when the organization has sensitive projects and administrators cannot allow global read access (as allowed by the user role) and need to specify access project by project. This can be done by:
Removing the com.polarion.persistence.object.read permission from the global "user" role.
Altering the Subversion access file which specifies who can access specific resources stored in the repository, and with what permissions.
Removing any project scope roles assigned to users.
This configuration is explained in the following sections.
To modify the global user role to remove read access:
Navigate to: Administration perspective, select Repository in the Projectsportlet, and then User Management topic: item.
The XML for the global configuration appears in the Edit Global Configuration Portlet.
Locate the following code block:
<role name="user">
<!--
- Change this permissions to switch between two basic security modes:
- <grant> : all active (not disabled) users have general read access
to everything, all projects
- <deny> : general read access is NOT granted and must be assigned on
the project level or via another role
-->
<grant permission="read"/>
</role>
Change the block as follows (as hinted in the comment):
<role name="user">
<!--
- Change this permissions to switch between two basic security modes:
- <grant> : all active (not disabled) users have general read access
to everything, all projects
- <deny> : general read access is NOT granted and must be assigned
on the project level or via another role
-->
<deny permission="read"/>
</role>
Save the modified XML using the button under the online text editor.
Now assign the relevant user the project_user role in the appropriate project(s).
At this point the user will see only the specified projects upon login, but can still directly read and write information to the Subversion repository. To restrict this, proceed to the configuration in the next section.
The Subversion access file location differs according to your operating system.
Windows: C:\Polarion\data\svn\access (default path)
Linux: /var/lib/polarion/data/svn/access
Open the access file in a text editor. For every project, create the following section in the file (lines starting with # are comments and may be left-out):
[path/to/the/project/in/repository]
# By default this project is not accessible to anyone:
* =
# this is the system user which -must- have read access
polarion = r
# list all users with read-only or read/write access to this project:
# this one gets read-only access
user1 = r
# this one gets read/write access
user2 = rw
If you have restricted some user project by project and later want to remove the role form the user account you can do so provided:
The restricted user has at least one role (project_user, for example) in the project scope in some non-restricted project(s), and...
The restricted user must not have any global roles.
LDAP can be used to verify user credentials (instead of a password file in a standalone setup). The access file is used to define the user groups and access rights to individual repository locations. User accounts can be either manually created in Polarion (with user names corresponding to LDAP) or auto-created by Polarion based on existing LDAP users. All necessary software for LDAP (including Apache modules) is bundled with the Polarion installation archive. This section explains the steps for integrating LDAP/Active Directory with Polarion server.
This section describes how to configure Subversion (and thus Polarion) to authenticate against an LDAP server instead of a password file.
To perform this configuration:
Open Apache's conf/httpd.conf file in a text editor.
Search for this string: To enable authentication against LDAP.
Follow the instructions contained in comments at that point in the conf/httpd.conf file.
The configuration is mainly a matter of uncommenting certain parameters and supplying necessary data such as passwords. You will need to change at least the following parameters:
LDAP_Server
Base_DN
Bind_DN
Bind_Pass
If you want to get more information about the LDAP module configuration parameters, check the help page at http://muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap_apache2.html.
For a list of LDAP Error Codes, see http://www.directory-info.com/LDAP/LDAPErrorCodes.html.
Polarion delegates authentication of Subversion repository users (Subversion runs on Apache). This is true even when LDAP is used. If a user cannot log in to Polarion because of an invalid user name or password, the problem is actually that the user cannot log in to Subversion (repository root) with the given credentials.
If you just want to have Subversion (and Polarion) authenticate user credentials against LDAP instead of a password file, and you have performed the configuration described in Configuring Subversion to Authenticate Against LDAP, then you can skip this section and the following LDAP related sections. However, if you want to configure Polarion to auto-create users from LDAP (as described in Configuring Auto-creation of Users) or to synchronize the users defined in LDAP with Polarion users (as described in Synchronization of Polarion Users with LDAP), then you need to configure Polarion as well.
Polarion LDAP options can be configured in file ldap-config.xml accessible via Administration/User Management/LDAP Synchronization. Here you have to provide enough information for Polarion so that it can find user nodes in LDAP server, get user information, and map it to Polarion user attributes. The following settings are available:
Setting this value to true enables user synchronization. Otherwise the user synchronization action is not available, and auto-created users also will not be updated with information from the LDAP server.
URL of the LDAP server. For example: ldap://localhost:389.
Name of the LDAP node from which to search for users, often in the form cn=Users,dc=company,dc=com.
Attribute that contains the ID for a Polarion user, usually uid or sAMAccountName. For Active Directory - displayed as "Login Name" (for systems older than Windows 2000) in the Active Directory administration.
The value must be chosen in such a way that no user contains non US-ASCII characters, spaces, or any of characters that are invalid for Polarion user IDs, i.e. / : * ? \ " < > | # ' ; $ ^ ` %~
Set to false to limit the search to users directly under the base DN.
Filter that limits found users. The value can be any valid LDAP query. When doing the search it is concatenated with & USER_ID_ATTRIBUTE=*.
Name to use when searching for users; leave empty for anonymous search. Bind password can be set using Polarion property ldap.bind.password in the polarion.properties file.
Mapping of LDAP user attributes to Polarion user fields. By default, three fields are mapped from LDAP user accounts to Polarion user accounts: name, email and description. The default settings in this file should be sufficient in most cases.
You can setup mapping of LDAP attributes to name, email and description user fields. For any of these fields you can provide any number of mappings; always the first applicable one is used. Mapping is applicable if the attributes present in the mapping string are present and not empty in the LDAP user node.
Example mapping:
<mappings>
<nameMappings>
<mapping>%cn%</mapping>
</nameMappings>
<emailMappings>
<mapping>%email%</mapping>
<mapping>%emailAddress%</mapping>
<mapping>%mail%</mapping>
</emailMappings>
<descriptionMappings>
<mapping>%description%</mapping>
</descriptionMappings>
</mappings>
When LDAP authentication is set up you cannot create new users using Polarion. You should create new users in the LDAP server and then synchronize the Polarion user scheme with LDAP. However you can use the user synchronization action regardless of what Subversion authentication type is used; it is just required that the synchronization is enabled and properly configured (as described in Configuring Polarion for LDAP User Synchronization).
To invoke the synchronization process navigate to Administration > User Management > LDAP synchronization and click the button. This takes you to the Users synchronization page. Click the button to synchronize users from the configured LDAP server to the Polarion user scheme. If you click on the button, then not only new users will be inserted into the Polarion user scheme, but existing users fields will be updated as well, and existing Polarion user data will be overwritten by LDAP data. The list of user fields taken from the LDAP server is specified in the ldap-config.xml configuration file. Polarion displays the result of the synchronization: the number of new, updated and existing users.
The autocreate feature is independent of use of an LDAP server - it can be used with ordinary Subversion authentication as well. However if LDAP user synchronization is enabled (see Configuring Polarion for LDAP User Synchronization), then the newly created user is synchronized with information provided by the LDAP server.
To access the autocreate configuration file:
In the Administration Perspective select Repository node in the Projects portlet.
In the Topics portlet, select User Management : Autocreate.
Use the link in the Configuration portlet (Working Area) to download a local copy of the autocreate-config.xml file.
The autocreate-config.xml file contains the tag <autocreate-config> which has an element <enabled>. The default value in this element is false. To enable autocreate, replace this value with true. You may also want to adjust the list of roles that should be assigned to autocreated users in element <globalRoles>. Then use the controls in the Upload New Global Configuration portlet to upload the modified configuration file back to the repository.
The Auto-create users feature makes it possible to create user accounts in Polarion during login into the Polarion ALM portal. If this feature is enabled, then when a new user attempts to log in to the portal, then his/her Polarion user account is automatically created provided the password supplied valid for accessing the Subversion repository. Additionally this user is assigned several (configurable) roles which guarantee that the newly created user is at least allowed to log in.
Note that for autocreate, the user specified in the login parameter of the polarion.properties file must have write access rights for the repository folders /.polarion/user-management/users and /.polarion/security in Subversion. This is not configured in default access file. You can add it like this:
...
[/.polarion/user-management/users]
@user = rw
@admin = rw
@guest = r
polarion = rw
[/.polarion/security]
polarion = rw