19. Advanced Administration


This chapter covers several administration topics of an "advanced" nature that may not always be essential for the setup and maintenance of a Polarion system, but which may be useful in achieving optimal benefits.

System and Virtual Machine Memory

Issues around server memory allocation and Java virtual machine are covered in the PDF installation guide documents bundled with Polarion distributions, and also available for download on Siemens' Doc Center:

  • Windows Installation Guide

  • Linux Installation Guide

  • Polarion Enterprise Setup Guide (for users running Polarion on multiple physical and/or virtual servers with one or more Polarion repositories in the topography.)

Administrators of Windows installations should follow the recommendations in the section Adjusting Server Memory Allocation in the Windows Installation Guide.

Administrators of Windows or Linux installations should note the section Java Virtual Machine Memory Limit in the installation guide for their respective OS.

Administrators of clustered server installations should note the recommendations in the installation guide for the operating system on their servers, well as any relevant instruction in the Polarion Enterprise Setup Guide.

The information in these documents can help avoid issues such as startup failure (where the Polarion service does not start) and Java Out of Memory (OOM) errors.

Optimizing the PostgreSQL Database

Beginning with version 2015 SR2, Polarion integrates the PostgreSQL database in all new installations. This system component is used to improve performance on complex system queries. Automated installers for Linux and Windows attempt to modify default PostgreSQL settings to optimize it for operation with Polarion. Assuming the process succeeds, PostgreSQL should perform adequately in most cases. An administrator may optionally adjust the settings described later in this section to better match the specific environment.

If PostgreSQL optimization fails during automated installation, or if Polarion is installed manually (as can be the case with Linux in particular), the administrator should modify PostgreSQL settings as described below to optimize it for Polarion.

The PosgreSQL configuration file is named postgresql.conf, located on path /opt/polarion/data/postgres-data/ on Linux, or C:\Polarion\data\postgres-data\postgresql.conf on Windows. Open the file in any text editor and set the properties as shown in the following listing:

max_connections = 80  # should be less than 10 * number of CPUs
shared_buffers = 2GB # should be 10% - 15% of total system RAM
work_mem = 10MB # should be 10MB - 100MB
maintenance_work_mem = 200MB

fsync = off
synchronous_commit = off
full_page_writes = off

wal_buffers = 256kB   # should be more than size of common transaction

checkpoint_segments = 32

effective_cache_size = 4GB       # should be approx 1/3 of RAM for PostgreSQL

max_locks_per_transaction = 100  # specific for Polarion

# Optimal planner performance setting
# For HDD, keep default setting. Otherwise, uncomment the applicable setting below:
# For SSD: 
# random_page_cost = 1.5
# For SAN:
# random_page_cost = 2.0

After saving the changes, restart PostgreSQL.


On Linux systems, check that the value of the shared_buffers parameter in postgresql.conf does not exceed the available shared memory configured by the kernel parameter SHMMAX. Adjust shared_buffers as necessary, keeping in mind the recommendation in the listing above.

Preventing Excessive Test Run Records

If you have very large manual Test Runs, the default system configuration can result in excessive numbers of Test Run records in the historical database, as it uses the default referencing of structures via foreign key. You can remedy this situation by setting the system property com.polarion.platform.sql.useNewStructTables=true in the polarion.properties file. Setting this property ensures that artificial primary keys (PK) are generated for Test Run records, resulting in far fewer records in the historical database. After setting this property it is necessary to re-index the system, which will rebuild the database.

Enumerations in the Polarion Database

By default the database table containing the enumeration options is not populated because this data rarely needs to be obtained from the database. However there can be times when the complete enumeration options definition is required in the database. (Like when the database is the primary source of this data, for example, if you are building an external report on top of the Polarion database using the The Business Intelligence and Reporting Tool (BIRT) extension.)

If this is the case, you may not only need to load the unique IDs stored with the objects, but also the names of the enumeration options.

To populate the enumeration options table in the Polarion databases, set the following property in the polarion.properties file:


Once this property is enabled, a job that populates the enumeration options table, in both the HEAD and historical database, is automatically run after each reindex.

Keep the Enumeration Table up to date

Unlike Work Items or LiveDocs, the enumeration options are not automatically updated in the database table when there's a configuration change. To ensure the consistency of the enum options table with the actual configuration, the Refresh Database button triggers a job that re-synchronizes a particular enumerations configuration to the database.

Periodically Refresh Enumerations

You can schedule the polarion.jobs.refresh.enumeration job to run regularly as a part of your system maintenance. When it is run without any additional parameters, all enumerations are refreshed. By default, the polarion.jobs.refresh.enumeration job only starts once after a reindex.

For more information on scheduled jobs, see Administrator's Guide: Configuring the Scheduler.

Object-based Enumerations

Object-based enumerations are not populated in the enum table and if required, must be collected from other tables.

For additional information, see the Administrator's Reference topic: History Indexing Job and the Administrator's Guide topic: Indexing and Reindexing: User Impact.

Speed up the Movement of Work Items to and from Documents

Enable "In-memory Object Maps" to reduce the wait time while moving Work Items to and from Documents by 95%!

Doing so will increase the amount of RAM used and the size of the object-maps folder.

(RAM usage will vary but will be about 3x the size of the object-maps folder.)

How it Works

It optimizes Object Map implementation to minimize disk access. It is based on a map kept in memory and saved to disk asynchronously.

Saves are made each time the map is asked to do so. (Provided no additional save requests have been made for 10 seconds.)

While saving, all data is flushed onto the disk and data in memory can still be modified.

Enable In-memory Object Maps

To enable "In-memory Object Maps", add the following property to the polarion.properties file:



- Any time the "True/False" value is changed a reindex must be performed.

- A reindex is also required if Polarion is shutdown incorrectly.

Reduce the size of the Object Map folder

On some production systems, depending on the configuration, the Object Map folder can get quite large (10+ gigabytes).

A Defragment object maps job can be run that greatly reduces the size of this folder.

Copy the sample script below to the Scheduler.

Set it to run during off-hours

Some resources might be temporarily locked while the defragmentation job is run. To ensure that users are not affected, run the Defragment object maps job over night on production systems.

Sample defragment object map script
<job cronExpression="0 0 6 ? * *" disabled="false" id="object.maps.defragmentation" name="Defragmentation of object maps" scope="system"/>

The sample script above will run the Defragment object maps job everyday at 6 a.m.

Database Compatibility (H2, PostgreSQL)

Polarion replaced the integrated H2 database with PostgreSQL - in new installations only from version 2015 SR2, and in existing installations from version 2016. The database is used for complex query processing, such as are often needed for reports. Users of prior versions may have some report queries formulated for H2 that do not work with PostgreSQL due to its more strictly ANSI-compliant syntax. To mitigate such problems, Polarion provides a database compatibility mode.

Compatibility mode is enabled via the system property com.polarion.platform.sql.h2CompatibilityMode. When set to true, Polarion attempts to adjust queries formulated with H2 syntax "on the fly" so that they work with PostgreSQL. Compatibility mode handles situations where a problematic query cannot be updated to be PostgreSQL compliant - reports in History and Baselines that fail due to missing or incompatible functions, for example.

If, after your system is updated to use PostgreSQL, you find that some queries are not working, enable database compatibility mode. Open the system configuration file polarion.properties in a text editor and make sure the following is present: com.polarion.platform.sql.h2CompatibilityMode=true. Restart the Polarion server to effect the change.

Issues handled in compatibility mode include:

  • Error: Subquery in FROM must have an alias

  • Usage of H2-specific functions that result in errors such as: function curdate() does not exist.

Even when database compatibility mode is enabled, it is still possible that some reports may need to have their queries modified manually.

Mapping H2 Functions to PostgreSQL

This section explains how to map queries that use H2-specific functions to PostgreSQL. (You can find a listing of all H2 functions at: http://www.h2database.com/html/functions.html.)

Here is an example of an error, thrown when the proper curdate function is not defined: "ERROR: function CURDATE() does not exist Hint: No function matches the given name and argument types. You might need to add explicit type casts."

To map a function from H2 to PostgreSQL:

  1. In your installation's file system, navigate to [POLARION_HOME]/polarion/plugins/com.polarion.platform.sql_x

    (Where "x" is the version number.)

  2. Copy the file h2_functions_mapping.sql, paste it to folder [POLARION_HOME]/polarion/configuration, and open it using a text or SQL editor application.

  3. If the function does not already exist in this file, add your own definition of the function from H2. For example:

    returns date AS
    $$ SELECT current_date $$ LANGUAGE SQL;

    Function definitions must always end with a semicolon (;) to be successfully deployed, and always prefix the names of mapped functions with the schema name polarion, otherwise Polarion will not always take them into consideration.

  4. Enable the property com.polarion.platform.sql.h2CompatibilityMode=true in the polarion.properties configuration file.

  5. Restart the Polarion server.


For easy debugging before deploying a function to the h2_functions_mapping.sql file, try to manually create it in the PostgreSQL database. Use the psql utility to connect to the polarion database as the polarion user: psql -p 5433 -U polarion polarion.

For information on creating PostgreSQL functions, see http://www.postgresql.org/docs/current/static/sql-createfunction.html. To check the definition of a function had in H2, see http://www.h2database.com/html/functions.html.

PostgreSQL Database Start-Stop-Restart

Polarion includes the embedded PostgreSQL database to process complex queries more efficiently than is possible with the Lucene query engine. There may be times when an administrator needs to start, stop, or restart the database.

On Windows, shortcuts are provided in the folder [POLARION_HOME]\polarion shortcuts. On Linux, the following scripts are available:

CentOS, RHEL, Debian or Ubuntu

service postgresql-polarion start
service postgresql-polarion stop
service postgresql-polarion status
service postgresql-polarion restart


rcpostgresql-polarion start
rcpostgresql-polarion stop
rcpostgresql-polarion status
rcpostgresql-polarion restart


service postgresql-polarion start
service postgresql-polarion stop
service postgresql-polarion status
service postgresql-polarion restart

Optimizing Subversion

Polarion uses a Subversion (SVN) repository as its main data storage. This section provides guidance for administrators about optimizing Subversion for best performance. Some information is specific to Windows or Linux, and some is specific for a Subversion version currently running in a Polarion installation. Before implementing any of the optimizations below, be sure to see System Maintenance: Subversion Maintenance.

Subversion 1.7 and 1.8 Cache Memory

Windows: Both Apache and svnserve use threads to serve incoming connections, so the allocated cache is shared among all connections. You should:

  • Assign at least 256 MB cache allocation via SVNInMemoryCacheSize 262144 for Apache.

  • Assign at least 256 MB cache allocation via -M 256 for svnserve.

Linux: By default, both Apache and svnserve use new processes to serve incoming connections, so the allocated cache is specific for every connection. Make sure you have enough memory for recommended cache size multiplied by the anticipated number of parallel connections to SVN. For example, given a recommend cache of at least 128 MB as svnserve cache, and if there are 10 parallel requests to SVN at the same time, at that moment the processes consume 10 * 128 MB memory, or 1280 MB. Review your cache memory to be sure the assigned cache for SVN will not consume too much memory when parallel connections are made.

  • Assign at least 128 MB cache allocation via SVNInMemoryCacheSize 131072 for Apache.

  • Assign at least 128 MB cache allocation via -M 128 for svnserve.

Because a process is spawned for each connection and there might be dozens of such connections with highly concurrent use of Polarion, the total amount of memory occupied by svnserve may be high. The following external resource may be helpful: http://svnbook.red-bean.com/en/1.8/svn.serverconfig.optimization.html

General recommendation for Subversion 1.7+ on any environment: use MaxKeepAliveRequests 10000 for Apache's mod_dav_svn.

Subversion 1.8 With 1.8 Repository Format

Utilize the revision properties packing feature with the related cache settings below:

  • Enable caching of revision properties via SVNCacheRevProps on for Apache.

  • Enable caching of revision properties via " --cache-revprops yes" for svnserve.

Subversion 1.9

  • Use dynamic cache allocation via SVNInMemoryCacheSize 0 in Apache.

  • Use dynamic cache allocation via -M 0 in svnserve.

SVN Security When Using svnserve

Make the following adjustments to enhance security of any server running svnserve:

  • Limit access to the svnserve server to only those machines that actually read the data. Use parameter --listen-host for the svnserve server.

  • Set -R for svnserve to open access for read-only

  • Configure repo_path/conf/svnserve.conf to disable anonymous access to the repository via the svn protocol and force authentication through the passwd file for read access.

Subversion Access by System User

On Polarion installations with large amounts of content, there can be significant performance benefits from setting up alternate access to the Subversion repository for the system user, especially for system indexing/reindexing.

The system property repoSystem can be used to provide an alternative repository URL to be used for read-only access by the system user. If this property is not set, the system user uses the normal access URL as specified by the repo system property.

Either of 2 protocols can be used when specifying the URL value in the repoSystem property:

  • The file:// protocol can be used when the SVN repository resides on the server computer's local drive. This is the simplest alternative, as nothing other than the repoSystem property needs to be configured. See warning below.

  • The svn:// protocol is faster, but it requires start-up of the svnserve server (part of the Subversion installation). With this protocol, if the repository resides on the server's local drive then the following can be used: svnserve -d --listen-host In this case, the repository is readable by anyone from the server computer (also true for the file:// protocol).


In a production system, you should always set up and use the svn:// protocol for system user access. See "Installing svnserve as a Service" below.

Note that Polarion does not currently support the file:// protocol with Subversion 1.9 repositories. (That version is bundled with Windows distributions, but installers create the repository using version 1.8 repository format.) If you manually update to version 1.9 before full support by Polarion is declared, use only the svn:// protocol (which is in any case the recommended protocol for a production system).



If the repository referenced via svn:// protocol is remote, then it will most likely be necessary to set up authorization for svnserve. You can find information about this in the svnserve documentation published online at: http://svnbook.red-bean.com/en/1.8/svn.serverconfig.svnserve.html.

Install and Start svnserve as a Service

The svnserve server can be installed as a service on Windows and Linux Platforms. The main steps are:

  1. Set up the svnserve service using the recommended settings for your specific version and environment (see examples below).

  2. Configure Polarion to use svn protocol for the system user to access SVN by setting the following in the pp file: repoSystem=svn://localhost/

  3. Restart the Polarion server.

Windows Example: The following is an example of how to set up the svnserve service on Windows. The following should be written as a single command-line command with a space in place of each line break in the example:

sc create PolarionSvnserve binpath= "\"C:\Polarion\bundled\svn\bin\svnserve.exe\"
--service -R -r C:\Polarion\data\svn\repo -R -M 0 --listen-host"  displayname= "PolarionSvnserve" depend= Tcpip start= auto

To start the service on Windows if it is setup using the command above:

sc START PolarionSvnserve

Linux Example: The following is an example of how to start the svnserve process on Linux using Subversion 1.9.

svnserve -d -R -r /opt/polarion/data/svn/repo -M 0 --pid-file /var/run/svnserve.pid --listen-host


The Linux command above will only start the process a single time. (Good for testing purposes.) To install svnserve so that it runs after a reboot, see the install instructions specific to your distribution.

Managing Polarion Licenses

Your Polarion server may host more than one license type: named and concurrent, for example. For named user licenses, you need to specify the user IDs of all users who will utilize each named license. For concurrent licenses, you may want to limit the number of users who can access the portal concurrently (the maximum is controlled by the license), and/or you may want to define groups of concurrent users with different limits. You may also wish to check the current usage of your license(s).

You can manage licenses and view current license usage in the Polarion portal. The configuration is only accessible in the repository scope.

Accessing License Management

To access the license management configuration:

  1. Log in with administrator permissions for the repository.

  2. If you are not in the Administration interface after you log in, click the Administration link in the tool view of Navigation.

  3. If you are in a project after you log in, click Global Administration at the top of the Navigation panel.

  4. In Navigation, click on the License topic. The License page loads.

The portal page contains embedded "Quick Help" providing more detailed information on how to use the various license management features.

Specifying License Assignments

The License page provides a plain text editor in the Assignments section which enables you to edit the underlying configuration file, which is named users in the file system. Please refer to the Quick Help documentation on the License Assignment and Usage page of Administration for specifics.

When you change any text in the online text editor, the Save button is enabled which saves changes made in the portal to the configuration file.

Users not named in the license configuration are treated as concurrent users, and will utilize the default concurrent license specified in the configuration. If the default concurrent license is not specified, then these users will use the "highest" license having an unlimited number of concurrent users. If all are limited, then these users will use the "lowest" license with the highest number of concurrent users. If all licenses have zero, then these users will not be assigned a license and will not be able to log in.

Optionally, you can configure that all users who log into Polarion are automatically assigned a concurrent add-on license together with their basic license. If no concurrent add-on license is available, none will be assigned and users can still log in with the basic license. (See the embedded Quick Help on the License page in global Administration.)


The license assignment configuration can be changed only once in 20 minutes.

Viewing License Usage

The License page provides sections that display statistics on how users are currently consuming the licenses available on your Polarion system. The numbers are current as of the moment you invoked the page. Refresh your browser to see any change.

For information about the usage details displayed on the page, see Administration Reference: License Usage Reference.

Updating and Reactivating Licenses

If your organization has purchased new, or obtained updated licenses for your Polarion installation, you can update the installation from the License page in Administration. Use the Reactivate Polarion button to begin the process. You will be taken to the first screen of the activation application, where you will find instructions for activating your license(s) online or offline.

A confirmation dialog appears on each online activation, before the activation request is actually sent. You must confirm that no running Polarion instance is activated by the License Key you are activating.

Configuring Single Sign-on (SSO)

By default Polarion uses form-based authentication and validates user credentials via Apache against a remote LDAP server or local passwd file. Additionally, Polarion supports token based authentication using Kerberos v5, Teamcenter Security Services or SAML 2.0.

SSO Configuration Settings

See the "Configuring Single Sign-on (SSO)" section in the Windows or Linux Installation guides for detailed configuration instructions.


When using Single Sign-on with Polarion, users cannot modify their password in Polarion because the password is managed by the directory service.

Fallback for Kerberos

See the Windows and Linux installation guides to configure a fallback Kerberos authentication.

E-Signatures with SSO

Electronic Signatures require that users provide their user credentials to file a signature. Therefore Polarion provides an authentication fallback in the SSO authenticated environment to enable Electronic Signatures. See the Signing Documents section for details.

Authentication via Credentials for External Web Services Clients

Some external clients may not be able to login via a token in an SSO environment. Administrators can optionally enable Web Service fallback authentication by credentials for users with external clients.

(e.g Someone accessing Polarion through a VPN who was not authenticated in the Windows domain.)

  1. Go to the LDAP Configuration page.

    ( Administration Global Administration User Management LDAP Configuration)

  2. Make sure that the “LDAP Server Connection Settings” are configured. (See the Windows and Linux installation guides for details.)

  3. Tick the “Allow for Web Services” box in the “Alternative Authentication via LDAP in a Single Sign-on Environment” section.

  4. Click Save.

Log Out with SSO

Even in LDAP or Kerberos SSO configurations, Polarion still lets users log out of Polarion while remaining signed into the greater SSO environment.

This allows organizations with concurrent Polarion licenses to make the most of them while still taking advantage of a single sign on environment.

With Kerberos

With a Kerberos Single Sign-on configuration, when users log out of Polarion, the SSO session is not invalidated.

With Teamcenter Security Services

Polarion detects whether a user is also logged into Teamcenter Security Services and if no other TSS applications are active, Polarion will also log them out of Teamcenter Security Services.

Adjust Pop-up Login Dialog Size

By default, when using SAML or Teamcenter Security Services, the internal login is done via a new browser tab.

To disable this behavior, see Polarion Setup Single Sign On in the Polarion section of SIEMENS Doc Center.

Some 3rd party authentication screens may be larger than the default pop-up dialog that Polarion provides. Administrators can change its size by adding the following properties to the polarion.properties file.

com.siemens.polarion.ui.internalLoginWidth=NNN (Where "NNN" is the number of pixels.)

The dialog "Width" in pixels.

com.siemens.polarion.ui.internalLoginHeight=NNN (Where "NNN" is the number of pixels.)

The dialog "Height" in pixels.

Repository Access Management

Polarion utilizes an integrated Subversion repository to manage all data artifacts. Access to Subversion is controlled by the Subversion access file. Polarion provides a web based client with an interface to facilitate administrators who need to control repository access directly in Subversion. This topic explains how to locate and use the client. Subversion administration and access file management is a topic beyond the scope of Help. Basic knowledge of the SVN access file is assumed. For information about Subversion repository administration, see http://svnbook.red-bean.com/nightly/en/svn.reposadmin.html.

The Access Management feature enables you to edit data in the SVN access file online, in either repository scope or single project scope. It is an administration feature, so you must have administrator permissions for the scope you want to work with.

Accessing the Client

To use the Subversion Access Management client:

  1. Log in with administrator permissions for the repository or project you want to work with, and open it (see User Guide: Accessing Projects).

  2. If you are not in Administration after logging in, click the Administration link in the tool view of Navigation.

  3. In Navigation (topics view), expand User Management and select Access Management. The Access Management page loads in your browser.

Using the Access Management Client

The Access Management page has 2 panes, top and bottom. The top pane enables you to browse through the repository structure as it is defined in the access file, and review the current Role and User assignments for folders and files. Keep in mind that this pane is a viewport into the SVN access file... what you see is what is currently in that file.

The upper pane displays a string that shows the repository path to the currently selected folder or file. Some or all of the folder names in the path are clickable depending on your permissions:

  • If you have global (Repository) administrator permissions, the all folder names in the path are clickable enabling you to navigate all the way up to the repository root.

  • If you have project administrator permissions, the full path to the project folder is displayed, but you will not be able to navigate higher than the project root folder.

The lower pane of the Access Management page provides detailed information about access rights currently defined for the folder or file selected in the top pane. In the lower pane you can:

  • Add, edit, or remove Role assignments for the selected folder or file. Click the (Edit) icon in the Roles Assignment section in the lower pane of the Access Management page.

  • Add, edit, or remove User assignments for the selected folder or file. Click the (Edit) icon in the Users Assignment section in the lower pane of the Access Management page.

    Note the assigning access by Role is generally considered better practice than by User.

  • Review Users and Roles that currently have read and write permission for folder or file currently selected in the upper pane.

  • Review Users and Roles that currently have read-only permission for the folder or file currently selected in the upper pane.

By default, files in a folder have the same access permissions as the containing folder.

Editing Role Assignments

In either scope, you can edit Role assignments. This is generally considered preferable than assigning access to individual users.

To edit Role assignments:

  1. Open the repository or project you want to manage and navigate to User Management > Access Management in the Navigation pane.

  2. In the top pane of the Access Management page, browse to the repository folder or file for which you want to edit Role assignments and select the item. The selected folder or file's SVN access details appear in the lower pane.

  3. In the Roles Assignment section, click (Edit). The table of currently assigned Roles becomes editable. Each row of the table corresponds to a Role and the permissions currently assigned to it. The last row enabled you to specify a Role and its permissions to add to the currently selected folder or file. Columns correspond to user role and permissions. Check boxes correspond to enabling (checked state) and disabling (cleared state) each permission.

    TIP: Deny All overrides the other permission settings and revokes all permissions for the selected folder or file.

Adding Role Assignments

To add Role assignments:

  1. Make sure you are editing the correct folder or file - select it in the top pane of the Access Management page. If the Role Assignments table is not editable, click the (Edit) icon on the section header.

  2. In the last row of the table, click the icon to add a new row. Select the Role you want to add to the access file from the list in the Roles column. (For information about configuring Roles, see Administrator's Guide: Managing Users and Permissions: Configuring User Roles.)

  3. Check the boxes corresponding to the permissions you wish to assign to the added Role. The options are:

    • Read - check to assign read-only permission, clear to revoke it.

    • Read & Write - check to assign read and write permission, clear to revoke it.

    • Deny all - check to deny all permissions, clear to revoke denial.

  4. If you want to add another Role and set its permissions, click the icon in the Actions column to add another row to the table. Select the Role and assign permissions as described above.

  5. Click the Save button in the lower pane's toolbar to save changes from the GUI to the SVN access file.

Removing Role Assignments

To remove existing Role assignments:

  1. Make sure you are editing the correct folder or file - select it in the top pane of the Access Management page. If the Role Assignments table is not editable, click the (Edit) icon on the section header.

  2. On the row(s) of the Role(s) you wish to remove, click the in the Actions column. The row becomes highlighted. (If you make a mistake, click the Cancel button on the lower pane toolbar and start over.)

  3. Click the Save button in the lower pane's toolbar to save changes from the GUI to the SVN access file.

Editing User Assignments

As previously mentioned, it is generally considered preferable to assign Subversion access by Role rather than by User. The most common reason to edit User assignments is in situations where some "clean-up" of the access file is desirable, removing User assignments that may have found their way into the file at some time or another. Of course, if you wish to assign access to some specific User(s), you can do so.

To edit User assignments:

  1. Open the repository or project you want to manage and navigate to User Management > Access Management in the Navigation pane.

  2. In the upper pane of the Access Management page, browse to the repository folder or file for which you want to edit User assignments and select the folder. The selected folder's SVN access details appear in the lower pane.

  3. In the Users Assignment section, click (Edit). The table of currently assigned Users becomes editable. Each row of the table corresponds to a User and the permissions currently assigned. The last row enabled you to specify a user and permissions to add to the currently selected folder or file.

Removing User Assignments

To remove existing User assignments from the Subversion access file:

  1. Make sure you are editing the correct folder or file - select it in the upper pane of the Access Management page. If the User Assignments table is not editable, click the (Edit) icon on the section header.

  2. On the row(s) of the User(s) for whom you wish to remove SVN access, click the in the Actions column. The row becomes highlighted. (If you make a mistake, click the Cancel button on the lower pane toolbar and start over.)

  3. Click the Save button in the lower pane's toolbar to save your changes to the SVN access file.

Adding User Assignments

To add User assignments:

  1. Make sure you are editing the correct folder or file - select it in the upper pane of the Access Management page. If the Users Assignments table is not editable, click (Edit) icon on the section header.

  2. In the last row of the table, select the User to which you want to assign permissions from the list of in the Users column. (For information about configuring Users, see Administrator's Guide: Managing Users and Permissions: Configuring User Users.)

  3. Check the boxes corresponding to the permissions you wish to assign to the selected User. The options are:

    • Read - check to assign read-only permission, clear to revoke it.

    • Read & Write - check to assign read and write permission, clear to revoke it.

    • Deny all - check to deny all permissions, clear to revoke denial.

  4. If you want to add another User and permissions to the table, click the icon in the Actions column to add another row to the table. Select the User and assign permissions as described above.

  5. Click the Save button in the lower pane's toolbar to save changes from the GUI to the SVN access file.

The Tilde Exclusion Marker

Subversion access management enables use of the tilde character (~) as an exclusion marker. Prefixing a user name or role with this character causes Subversion to apply the access rule to users not matching the rule. Polarion displays access rules as they are written in the access file, so prefixed items may appear in the Polarion access management user interface if they exist in the access file.

The system property com.polarion.accessmngmt.useTildaFeatureForRoles in the polarion.properties file controls whether or not Polarion's Access Management should offer tilde-prefixed roles. The property is set to true by default.

You can find more information about this marker, along with some examples, in the Advanced Access Control Features section of the web page at http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html.

Access Control for Documents

Controlling access to Documents can be an issue in some organizations. While administrators cannot specify access control on specific Documents, it is possible to control access to Document folders. Document folders are found under the modules folder, under the project folder. If, for example, you wanted to set access control on the "User Requirements Specification" Document in the eLibrary example project, you would set the desired permissions on the folder elibrary/modules/Specification/User Requirements Specification.

When access management restricts a user from accessing a Document, the Polarion user interface does not show the Document to the user in Navigation.

Note for Global Administrators

If your user account has global (i.e. repository-scope) administrator permissions, but you are editing Role access in the project scope, then the appearance of some items in the Roles list is somewhat different than for administrators having just project-scope administrator permissions. Global administrators will see Roles prefixed with a project ID: myproject-project_user, for example. A project administrator would see the same roles as a project_user.

Removing Unused Excel Import Configurations

If some Excel Import Configurations become disused or obsolete over time, they can be removed via the Repository browser. Import configuration may be save either in the global/repository scope or in the scope of some project. Deleting an Import Configuration does not require administrator permissions, but the user performing the removal must have permissions to delete content from the repository in the relevant scope.

The Repository Browser path to Excel Import Configurations is:


Configuring the Dashboard

Scope(s): repository, project

The Dashboard topic is implemented as a page in the integrated Wiki. You can customize the layout and content of this page using the macros discussed in this section. (Details on macro syntax are provided in the embedded Wiki Syntax Help in the Polarion portal).

Macros for Layout

You can organize the content of the dashboard into table and or column structures using these macros:

  • {table} - creates a table structure

  • {section} - defines a page section

  • {column} - divides a section into columns

  • {style} - enables embedding of CSS styling into the Dashboard (and other wiki pages)

Again, please refer to embedded syntax help for syntax and usage examples of these macros.

Macros for Information

There are several macros which roll up and display information from the system in the Dashboard. The most important ones are:

  • {fact}

  • {linechart}

  • {piechart}

  • {report}

Macro: {fact}

This macro renders some useful values from factbase. These values are stored for example in the workitems-data.xml file under the data folder of the Polarion installation. For example, the file for the repository level is located in: %POLARION_HOME%/data/RR/default/.reports/xml/workitems-data.xml.

This xml file contains computed values that can be rendered as numbers or graphs: UNRESOLVED-BY-ASSIGNEE, OPEN-BY-SEVERITY, STATUS and so on. Values are populated by reports (see Administrator's Guide: Configuring Reports.

Macros: {linechart}, {piechart}, {report}

The {piechart}, {piechart}, and {report} macros render information from HTML and XML files generated automatically by system calculations. The main thing you need to understand about them is that the path in their report-path is a relative path in the PR directory.

For example, if a macro is executed in project elibrary then the path is relative to the reports for that project.

Reference information about fact bases and values can be found in Administration Reference: Calculations and Facts.

Updating Dashboards

There is a calculation named all that calculates all metrics, charts etc. in a given scope. The default system configuration has a job named All Calculations that invokes this calculation. Schedule or call this job if you want to be sure that everything is freshly calculated.

Each section of the Dashboard contains an Update button which can be used to recalculate and refresh specific information displays in the Dashboard.

Depending on what you have configured to appear in the Dashboard, you may only need run some calculations, as opposed to all calculations as described above. You should configure the specific reports that run the calculations for the data you are displaying in the Dashboard. For information, see Administrator's Guide: Working with Report Configurations.

Customizing XML Export Templates

Work Items can be exported to XML (see User Guide: Exporting Work Items: Exporting to XML. Export is accomplished by means of XSL templates (XSLT). You can create your own XSL templates to transform exported Work Items to another XML document, a HTML document, a plain text file, or PDF or RTF. When creating your own XSLT, refer to the Polarion XML Export Schema in the Administration Reference.

You can access the templates via the Administration interface: Work Items > Export Templates.

You can also use the integrated Repository Browser to access export templates. Templates are located on repository path /.polarion/tracker/export_templates/. You must use this tool to access the XSL templates.

XSL Template Naming Convention

Each of the exporters has a unique set of templates. Which template is used for which exporter is determined by the name of the template:

  • Transformed XML Export: *-xml.xsl

  • HTML Export: *-html.xsl

  • Text Export: *-txt.xsl

  • RTF and PDF Export: *-fo.xsl

Where to Deploy XML Export Templates

Upload your custom XML export templates to the export templates folder in the repository: .polarion/tracker/export_templates.

Customizing Excel Export Templates

Excel export templates enable you to set up different export scenarios for users of the Excel round-trip features. Templates specify which Work Item field are exported for round-trip, and the default type for new Work Items created via Excel round trip.

Several export templates used for exporting Work Items to Microsoft Excel format are provided in the xlsx: Microsoft Excel section of the Export Templates topic of Administration (Administration >> Work Items > Export Templates > xlsx: Microsoft Excel. Repository folder is /.polarion/tracker/export_templates/excel). You will probably want to create you own Excel export templates derived from the Polarion default export templates.

The following sections discuss the characteristics of an Excel export template, and describe several commonly needed customizations:

Default Excel Export Templates

Polarion provides 3 default Excel export templates:

  • Basic.xlsx - Template with some basic column-to-field mapping. A good starting point for many customizations.

  • Empty.xslx - Contains the required tables (describe later), but nothing else. No columns are defined in the template sheet, and there is no default column-to-field mapping. If used for round-trip export, the export dialog fields selection is pre-filled with all columns that are shown in the Table view of Work Items.

    This template is best used as the basis for new templates developed "from scratch".

  • TimeReport.xlsx - this template defines a work time report. It serves as a good example of how to define calculated columns in your custom Excel export templates.

Start by downloading the Excel export templates and checking to see how much is already implemented that you can use. The Empty.xlsx template is the most basic template with minimal data. The Basic.xlsx template has some typically used fields and columns pre-defined. The Time Report.xlsx template has some examples of calculated columns. Create a copy of one of these export templates to use for your customizations.

Export Template Structure

Work Items are exported to an Excel table (a named region of the worksheet) named WorkItems. Your template must contain this table, which should contain only a header and one normal row - the "template" row (see figure below). In Polarion's pre-defined export templates, this table is found in Sheet 1. Any column in this template sheet that has the a column label corresponding to a Polarion Work Item field ID is automatically mapped to the corresponding field. This includes custom fields. You can add columns as needed. If you need to have column names that do not correspond to field IDs, use the mapping table on the Polarion sheet.

The pre-defined Excel export templates from Polarion also contain a hidden sheet named Polarion. This sheet specifies some settings for the exporter and enables column to field mapping when template column names do not correspond to Polarion Work Item field names. Your custom template should contain this sheet with the 2 tables from Polarion's default templates. You will need to manually "un-hide" this sheet in the workbook if you need to make changes to it, and then change it back to hidden before distributing your custom template.

The first table in the Polarion sheet is a table of property-value pairs that enable you to set default values for two properties:

  • New Work Item Type - specify the type for any new Work Items that may be specified by end users in exported round-trip workbooks based on the template, and created in Polarion during re-import.

  • New Comments Column - a regular expression value that matches headers of columns that should be imported as new Work Item comments.

The second table on the Polarion sheet is a column-to-field mapping table. Use this table to map any columns in the template table of Sheet 1 whose column names do not correspond to Polarion field names. Each row corresponds to a column in Sheet 1 that doesn't have a column name matching a field ID. (If there are rows in this table that duplicate the mapping on Sheet 1 you don't need to remove them. The mapping will not be duplicated.)

When adding a new column and field row to the mapping table, be sure to use the Insert context menu on a row in the mapping table. Do not add rows outside the table. Rows inside the table will be shaded.

If you should happen to specify a field that doesn't exist, it will not appear to uses in the Export Work Items dialog when they select the Excel export option.

The end result of your customized template, when uploaded to the portal, should be that all fields you have mapped in the template appear to users as the default fields in the Selected Columns list of the Export Work Items dialog. It's recommended that you save your templates with different filenames from the default templates. You can upload your finished templates on the Export Templates page (described earlier) of Administration, then test them by invoking Export in the Work Items table and selecting xlsx: Microsoft Excel in the Format field. If you need to modify your template to correct errors (or for any reason), you can do so and re-upload it using the Replace existing export template with this upload option.

Figure 19.1. Customizing Excel Export Template

Customizing Excel Export Template

Sheet column to Polarion Work Item field mapping in an Excel export template

Making a Column Read-only

To make an export template column read only:

  1. Open the sheet of the export template containing the WorkItems region (normally on Sheet1).

  2. In the first row after the header row (the "template" row referred to earlier), select the cell you want as read only.

  3. On the cell's context menu, choose Format Cells.

  4. Select the Protection page of the dialog and check Locked.

Adding a Column

To add another column to the Excel export template:

  • Open the sheet of the export template containing the WorkItems region (normally on Sheet1).

  • On first row after the header row (the "template" row referred to earlier), drag the lower right corner of the right-most cell until you see the outline for a new column. (Or use the content menu of the right-most cell to insert a column to the right).

  • Set the value of the new column's header to the name of a Polarion field to which you want the column mapped.

    Alternatively, set the header value to any unique value, and then on the Polarion sheet add a row to the mapping table.

Adding a Calculated Column


Download and open the Time Report.xlsx export template to see an example of calculated columns.

To create a new calculated column in an Excel export template:

  1. Create a new column as described in the previous section, but do not map it to any field. Rather, specify a unique value in the column header.

  2. Enter the desired formula in the template row cell of the new calculated column.

    Note that you cannot use relative cell references. Rather you should use table column references. For example:

    =[Time Spent]+[Remaining Est.]-[Initial Est.]

    Again, the calculated columns in the pre-defined Time Report.xlsx export template can provide a useful example of such references.

Specifying Column for Test Step Iteration Numbers

Excel export for offline Test Case execution supports export of Test Cases with multiple Iterations of Test Steps. By default, the export template is configured to append a label for each Iteration to the Title column in the exported workbook. It is possible to configure which field displays the Iteration number in the property Append Iteration Label to Field in the hidden Polarion sheet. The default is the "title" field.

Configuring OLE Object Support

It is possible to import Microsoft Word documents that contain OLE objects. Polarion can display OLE Object thumbnails during Word document import. However, some additional third-party image converter software must be installed and configured before you can import such Word documents. OLE Objects in documents must contain their thumbnails in .emf or .wmf file formats, and the image converter used must support their conversion into JPEG. OLE Objects themselves are not imported, only their thumbnails.

Installation of third-party image converter, and configuration of Polarion to support OLE objects are covered in the Polarion installation guide documents for Windows and Linux, bundled with the respective distributions and available on product download pages on the Polarion Software web site (www.polarion.com).

Customizing the Login Screen

You can customize the Polarion portal login screen to display a custom logo or other image in place of the Polarion logo. The image must be hosted online in a location accessible to your Polarion server via http. Images may be GIF, PNG, or JPEG format. Recommended width is 100 pixels. (Height is scaled automatically.)

In a clustered environment where Polarion is served over multiple servers (physical and/or virtual), if a custom image is specified on the server that is the entry point for the system, the image will be used as the icon for each server's entry point. In an environment utilizing a single server, the custom image appears beside the Polarion logo.

To add a custom logo or image to the login screen:

  1. Using a text editor, open the system properties file polarion.properties (follow link for location).

  2. Add the following line to the file:


    ...where [IMAGE_URL] is the URL of the logo or other image you want to display in the login screen.

  3. Save the file.

The Polarion server must be restarted before the image will appear in the login page.

Repository Browser mime Types

The Repository Browser uses the following information to detect if a file is binary or text: the svn:mime-type property, the container (Tomcat) mime-type settings, and configuration parameters BinaryMimeTypes and BinaryMimeTypes set in the web.xml (located in the web client plugin folder of the Polarion installation: polarion/plugins/org.polarion.svnwebclient_n.n.n/webapp/WEB-INF/ - where "n.n.n" are numbers specifying a Polarion release number: 3.5.0, for example).

If mime type is detected in SVN properties or container settings, it is then looked up in the BinaryMimeTypes and BinaryMimeTypes lists. If the mime type isn't set or isn't present in those lists, then an automatic algorithm, which analyzes the first 1000 bytes of the file and returns the best guess at the file type, is used.

This approach still cannot guarantee 100% accuracy of file type reporting and file handing in the Repository Browser. For example, one organization might want to have a file type .xyz treated as binary, while another wants the same file type interpreted as text. If you find that some file types are not reported and handled correctly in the Repository Browser, or if you have some file types that you want to make sure are always interpreted correctly, you can edit the above-mentioned web.xml, setting mime-type mappings and interpretations in the BinaryMimeTypes and BinaryMimeTypes lists.

Taking a Thread Dump

A thread dump captures the state of all Java threads in the system and provides crucial information for the troubleshooting of performance problems. Polarion administrators can manually take a thread dump directly from the "Maintenance" administration UI. The thread dump is then written to the Polarion log that can be sent to Polarion technical support.

Advanced System Tuning

There are some system properties that can be useful for experienced Polarion administrators. These are set in the file system properties file polarion.properties.

Property: attachments.indexingOfAttachmentContent.enabled

When not present in polarion.properties, or if added to the properties file and set to true, indexing of the content of attachments is enabled. When enabled, attachments to Documents, Wiki pages, Work Items and Test Runs are indexed. Attachment indexing is performed by a background job when the server is started. Users may not be able to search attachments for some time until the indexing job is completed.

Regardless of the setting, other attachment fields (author, title, fileName, updated and length) are not affected by this property and are always indexed (and therefore searchable by users).

Example: attachments.indexingOfAttachmentContent.enabled=true

The attachments index can be explicitly refreshed via the Maintenance page in Administration.

For a list of supported attachment file types, see the User Reference topic Attachment File Types.

Property: attachments.maxSizeOfIndexedAttachmentInMB

If property attachments.indexingOfAttachmentContent.enabled is enabled, this property sets the maximum file size, in megabytes, that will be indexed for content, and therefore searchable for content by users. If an attachment is larger than the value specified in this property, only the attachment fields (author, title, fileName, updated and length) are indexed and searchable.

The value can be either an integer value (file sizes of 1 MB or more), or a float value. If no value is provided, or the property is left out of the properties file, a default value of 50 MB will be used if attachments.indexingOfAttachmentContent.enabled is enabled. The default limit of 50 MB has been found generally suitable for Polarion installations meeting the recommended system requirements

The setting applies to all attachments to any content that supports them: Wiki pages, Documents, Work Items, Test Runs, etc. The limit also applies to imported documents. If users encounter "Out of Memory" errors when uploading attachments or importing documents, check the limit in this configuration setting and either adjust the setting, or add more system memory and storage, as needed to meet the needs of your users. Examples:

  • attachments.maxSizeOfIndexedAttachmentInMB=2

  • attachments.maxSizeOfIndexedAttachmentInMB=0.5 (i.e. 512 KB)

  • attachments.maxSizeOfIndexedAttachmentInMB=5.5 (i.e. 5.5 MB)

Property: maxAttachmentSize

Controls the size of any attachment in Polarion. If the attached file is bigger than the configurable limit, the upload is stopped.

It applies to Work Item, Wiki Document, Live Document and imported document attachments.

The default setting is 200 megabytes written in bytes (200000000).

Property: com.polarion.tracker.defaultNumberOfHeadings

Administrators can configure the maximum number of heading levels available by adding this property plus a value (=x) to the polarion.properties file. There is no upper limit to the number of heading levels.

Property: com.polarion.durationHoursPerDay

Specifies the number of hours per work day. Requires an integer value (default value is "8"). Other type values are silently ignored and the default substituted. The setting applies globally and cannot be overridden in the project or project group scopes. The specified value appears read-only in the Work Items: Planning page of Administration.

Property: com.polarion.enumerations.objectEnumerationsLimit

Sets a hard limit on the number of items that are loaded into enumerated lists of system objects such as Documents, Pages, Test Runs, users, etc. Excess items cannot be selected in the UI. Default value is 10 000. You can set a whole number (for example, 200 ), or -1 for unlimited.

Take for example a custom field in which users select a Document from a drop-down list of Documents (provided by an object enumeration). If the system contains hundreds or thousands of Documents, populating the select list can take too long. Setting a lower limit in this property can significantly improve performance.

See also: com.polarion.ui.maxRenderedItemsInCombo.

Property: polarion.reindex.from.revision

  • Which revision is taken as the first one to process when Polarion is started for the first time, or if its runtime data were cleared (e.g. due to reindex).

  • Possible values are FIRST and HEAD.

  • Default value: FIRST.

  • setting this to HEAD will speed up fresh start significantly, but the history of Work Items will not be available (only changes done after the start).

Property: polarion.startup.disable.artifacts.auto.recognition

  • Controls whether or not build artifacts auto-recognition during startup should be disabled (affects only projects where there are no configured build artifacts and auto-recognition is not disabled on the project level).

  • The auto-recognition can be initiated manually from Administration.

  • Default value: false.

  • Setting the value to true will result in significant speed-up of first start or reindex.

Property: polarion.startup.disable.artifacts.change.detection

  • Controls whether or not detection of build artifacts-related changes should be disabled during startup (does not affect first startup or reindex or projects created while the server was not running).

  • Default value: false.

  • Setting the value to true will result in significant speed-up of restart.

Property: com.polarion.ui.maxRenderedItemsInCombo

Universally controls the number of items loaded into combo box lists. Default value is 100. Decreasing the value can improve loading of lists, if performance is noticed to be slower than optimal, which may occur if there are many projects with many concurrent users. Users can filter for excess items by typing a string of characters in the combo box. For example, assuming an item "Zebra Stripe Pattern", user can filter by typing zebra.

See also: system property com.polarion.enumerations.objectEnumerationsLimit.

Property: useDecimalHoursDurationFormat

  • Controls whether or not the value for hours in time reporting fields (Initial Estimate, Time Spent, etc.) must be entered as a decimal value rather than the default fractional.

  • Default value: false.

  • When set to true, hour durations in all time reporting fields are displayed and entered as decimal hours only - 22.33 for example. The examples displayed by clicking on the "?" next to time input fields are changed when this feature is enabled, and the export option Convert Durations to decimal hours is not displayed in the export dialog.

    Storage in XML persistence and pre-2011 LiveDocs is still in the fractional format, only hours are not converted to days. So the value in the example above is actually stored as 22 1/3h. It is stored that way rather than 22 33/100h because of smart parsing of user-entered values to the fractional format, which recognizes the decimal representation of fractions (y/3, y/6 and y/12). So for example entering 0.08 or 0.083 is parsed as 1/12h. The smart parsing can be disabled by setting the system property dontUseSmartDecimalHoursDurationFormatParsing to true.

Property: wordImport.ignore.[CLASS]

Where [CLASS] the short name of an object class from the docx4j library

  • Default value: false

  • Controls whether or not unsupported content, of the type represented by the specified class, is reported with the Unsupported Content message (see screenshot) in the result Document after importing a document from Microsoft Word.

By default, unsupported content contained in the import source is not imported, and is replaced by the graphical message shown below in the result Document after the import process finishes. If you would rather that such content be silently ignored, you can add this property for each type of unsupported content you do not want reported in the import result Document.

Figure 19.2. Unsupported Object

Unsupported Object

Graphical message when an object in a source document cannot be imported to Polarion. Set this property to suppress it.

Example: wordImport.ignore.R.DayLong=true where R.DayLong is the short name of the class of the object from docx4j library.

In this case, content objects of the R.DayLong class will be ignored during import and no message will appear in the import result. To find the class name, look at the tool-tip on the Unsupported Content message in an import result where some unsupported content was present in the source document.

Note that OLE thumbnails are supported for imported Word documents when third-party image converter software is installed and configured. See the User Guide topic Documents with OLE Objects for more information.

Property: com.polarion.logoURL

Optionally specifies the URL of a remotely hosted logo or icon image to display in the Navigation panel in lieu of the default logo. The hosted location must be accessible to the Polarion server. If this property is not specified, the default logo is displayed.

If specified, the remote image should ideally be 60 W x 64 H (pixels) in GIF, PNG, or JPG format. Larger images should ideally have the same aspect ratio,and will automatically be resized and cropped if necessary to fit the display space allocated by Polarion in the Navigation panel.

This can especially useful for organizations running multiple Polarion servers. A different logo image can be configured for each server, enabling end users to tell at a glance which one they are connected to.



Property: com.polarion.ui.lock.timeout

Optionally specifies a lock timeout in minutes for the Diagram Editor. When a user begins editing a diagram, a lock is set and no other user can edit it until the diagram changes are saved, the user closes the Diagram Editor, or the lock timeout set in this property occurs.

If this property is not specified, the lock timeout defaults to 8 hours. The user who obtained the lock must save the diagram or close the Diagram Editor in order to remove the lock.

Example: com.polarion.ui.lock.timeout=30 (Sets lock timeout to 30 minutes.)

Property: com.siemens.polarion.repository.git.timeout

Administrators can set a Repository Polling timeout value for when changes are pulled from an external Git repository.

If this property is not specified, the default timeout for Repository Polling job is set to 30000ms (30s)

Example: com.siemens.polarion.repository.git.timeout=3000 (Sets Repository Polling job timeout to 3 seconds.)

Property: com.polarion.ui.login.resetPasswordLinkURL

Holds the URL of a page on your system that you have provided for users to reset their password. You must also set the resetPasswordLinkLabel property (below).



See also: Enabling Users to Reset Password.

Property: com.polarion.ui.login.resetPasswordLinkLabel

Link text to display on the Polarion portal login page, leading to your password reset page. You must also set the resetPasswordLinkURL property (above).


com.polarion.ui.login.resetPasswordLinkLabel=Reset Password

See also: Enabling Users to Reset Password.

Configure Tomcat to use an HTTP connector:

By default the Tomcat application server is connected via an AJP connector to a local Apache which gets the clients' traffic from load balancer. With 3.18.2 it's possible to configure HTTP protocol instead, bypass the local Apache instance for the browser clients' traffic and connect directly the load balancer with the Tomcat application server. This is useful mainly when a different Load balancer is used. See Apache Tomcat 9 for details.

The AJP connector is deployed automatically, but you can specify the ajp-port in the polarion.properties file by adding the following line:


Configuration steps:

  1. Find the following property in the polarion.properties file.


  2. Replace it with:



This will deploy Polarion directly on the HTTP protocol on port 80.

Properties for Activity Stream

Administrators can configure history limits (number of days and maximum number of items) for each Activity source, plus a default registered activity source, via the system properties listed in this section.

All Source Types:

  • com.polarion.activity.maxActivitiesAge - Default is 90 (days)

  • com.polarion.activity.maxActivitiesLimit - Default is 5000 (activities)

Specific Source:

  • com.polarion.activity.[sourceID].maxActivitiesAge - Specify an integer value. Value represents days.

  • com.polarion.activity.[sourceID].maxActivitiesLimit -Specify an integer value. Value represents number of activities.

Specific Source Type:

  • com.polarion.activity.[sourceID].[type].maxActivitiesAge - Specify an integer value. Value represents days.

  • com.polarion.activity.[sourceID].[type].maxActivitiesLimit - Specify an integer value. Value represents number of activities.

Work Items Tree Rendering

In the Tree view of Work Items, some user queries can return a tree so large that the performance of the entire system is adversely affected. Before constructing a tree of Work Items, Polarion checks two system properties with default values designed to prevent this. However, administrators can review and optionally adjust these depending on their system's resources.

The system property com.polarion.ui.treeTable.softLimit sets a first check limit on the number of items returned by a query run by a user in the Tree view. The default value is 1000. If you want to change that limit, you need to add this line to the system properties file: com.polarion.ui.treeTable.softLimit =500. (Replace "500" with an integer specifying the limit... it can be smaller or larger than the default 1000 items, depending on your system's resources.)

The check is performed on the number of items returned by the query. If the count exceeds the limit, the user is presented a dialog informing that the tree is large and can take a long time to load, and asking permission to display only the top N nodes (where "N" is the limit set in the above property). These top items can be on any level of the tree. This is neither the final number of nodes, nor the final number of roots. Rather, it is the initial number of roots. When the tree is created some of these items might be removed and others might be added.

If the user rejects loading of the top N items, a second condition is checked in the system property com.polarion.ui.treeTable.hardLimit (default value 10000). If the total number of nodes returned does not exceed this limit, the tree is constructed from the full query result. Otherwise, the user is shown a message that the tree is too large to show and has been limited to N nodes, where "N" is the value set in this property. Again, the administrator can set a higher or lower limit by adding com.polarion.ui.treeTable.hardLimit to the polarion.properties file.

Matrix Rendering

There are two properties in the polarion.properties file that define the maximum number of cells in a Traceability matrix or a Variants comparison matrix.

com.siemens.polarion.ui.matrix.hardLimit = 50 000

(The maximum allowed number of cells.)

com.siemens.polarion.ui.matrix.softLimit = 10 000

(Triggers a warning before displaying the matrix if the number of cells exceed this number.)

Fonts and Font Substitution

The fonts available in LiveDoc Documents and rich text edit fields, and font-substitution for import and round-trip operations is configurable in the system property com.polarion.ui.richText.fonts.

Font substitution works for:

  • Import from Microsoft Word and Microsoft Excel.

  • Round-trip for the above.

  • Text copied from sources outside Polarion AML (e.g. from a Word document) and pasted into a LiveDoc or rich text field.

Font substitution replaces certain fonts with fonts defined in Polarion. Any font not available in Polarion and for which there is no substitution set is replaced by Polarion's default font.

Available fonts are separated by semicolon, and font substitution is separated by a comma. Consider the following example:

com.polarion.ui.richText.fonts=Arial, Helvetica; "Courier New", Courier, monospace, HanWangKanTan; Georgia, Garamond; "Times New Roman", Times

  • Arial, Courier New, Georgia and Times New Roman are set as available fonts.

  • Helvetica is substituted by Arial

  • Courier, monospace, and HanWangKanTan are substituted by Courier New, etc.

The defined fonts must be installed on client computers. Any missing fonts will be substituted by the default font, Arial This is hard-coded into Polarion and cannot be changed by administrators.

Lucene Word Splitting

In Version 2014-SR1, Polarion updated the embedded Apache Lucene query engines. The way indexed text is split into words changed from the previous Lucene version. Polarion now provides a system properties to enable administrators to control how words are split during query operations.

Property: search.wordBoundaries

Defines how word boundaries are defined for the index. Two values are supported:

  • splitByPattern - the input is split to words using a regex pattern. This is the default.

  • standard - the word boundaries are defined according to Unicode standard. This value should always be used for Asian languages

Property: search.wordBoundaries.splitByPattern

Defines the pattern to be used when using "search.wordBoundaries=splitByPattern". It is used with: java.lang.String.split(String).

Default value: \A[^\d\p{IsAlphabetic}]*|[^\d\p{IsAlphabetic}]*[\s]+[^\d\p{IsAlphabetic}]*|[^\d\p{IsAlphabetic}]*\Z

The default value ensures that the text is split by white-space, and the leading and trailing sequences of non-alphanumeric characters are removed from the remaining character sequences. The rest are "words" for the index. For example: Hello! WI-1234 _help_. is split to words Hello, WI-1234, and help.

JVM Properties for Maven Calculation

When updating to a new Polarion version, your current settings in JVM properties for Maven calculations may result in an Out of Memory (OOM) error PermgenSpace. In this case, you will need to adjust JVM memory values in the system file calculation.properties (repository path: .polarion/reports/calculation.properties.

Splitting DAO Cache by Prototype

Polarion provides the option to customize the DAO cache configuration via the file $POLARION HOME$/polarion/configuration/ehcache.xml. The default configuration should be optimal for 8 GB Xmx settings on the server and should work well for larger installations as well. However, administrators have the option to adjust the cache size to store more objects in the in-memory cache.

The size of some objects may vary considerably. For example, you may have small manual Test Runs that are significantly smaller than the expected 2 MB object size. It might be useful to resize the cache for such objects.

To do that, copy the ehcache.xml file from:

$POLARION_HOME$/polarion/plugins/com.polarion.platform_x.y.z/platform.jar/META-INF/ehcache.xml (where "x.y.z" denotes your current Polarion version), to

$POLARION_HOME$/polarion/configuration/ehcache.xml and adjust particular settings in the copy.

(On Windows, replace forward slash characters in these paths with backslashes.)