Sercurity and Permissions - Polarion 2015 Early Access

Fine Grained Permissions

Welcome to the 5th chapter in our Polarion 2015 Early Access Program, where we provide you with a preview of what’s delivered in the release. Here, we’ll look at the enhancements to user permissions that many of our customers have requested.

We speak about “permissions” any time you want to control who can access or modify information:

2-Level Permissions

Polarion secures data access with 2 independent layers.

All access to the data is performed on behalf of the logged-in user, and an authorized connection is created to the SVN repository storage. This ensures that every single modification is tracked with the actual user account, and also that SVN access permissions are checked.

Although these file-based permissions are enough for some users, others require much more granular, fine-grained access control. For the 2015 release, we have significantly enriched the Polarion permissions schema.

Custom Set Permissions

Consider the following scenarios:

  1. Security-related Issues should not be visible to any external developers
  2. Requirements Specification type Documents should be read-only when the they are being pushed for review, or have been approved.

For each scenario, you would want to assign specific permissions to a subset of all Issue artifacts, or all Document artifacts. This is exactly what we have implemented with Custom Sets.

Administrators can now assign different permissions to artifacts with specific attributes, defined by a query. In the above scenarios, these could be Issues with category Security - category:(security)- or Documents of type Requirements Specification with any of several status values… document.type:requirements_specification AND status:(inreview,reviewed,approved).

Simply define the collection of items using a filter / query statement, and specify specify the actual permissions for the matching items.


Per-field Work Item Permissions

It is often not enough to control the core artifact lifecycle (create, read, modify, delete). Sometimes it’s necessary to limit access to individual Work Item attributes. For example:

  1. You want customers to access requirements, tasks, test cases online in Polarion, but you want to be sure they do not see how much time it was spent on the individual tasks, and/or what was the estimated effort.
  2. You want to ensure that after Business Value is set for change requests, it cannot be modified except by the product owners.

There are literally tons of such scenarios, and that’s why we now make it highly flexible and enable you to grant or deny permissions for any Work Item attribute (i.e. field, including Custom Fields):


With all these options, it is important to understand how are the permissions checked:


The basic rules of permission dependency to understand and remember are:

Document Permissions

If we would drill down more to the one of the scenarios mentioned above...

“Requirements Specifications should be read-only when the document is being pushed for review or approved.

...we would find out that it is actually not the full Document that should be read-only, because once it is reviewed you still want to be able to change the status to reviewed. But the Document’s content must be read-only.

To meet this kind of need, we have introduced several more Document permissions:


The MODIFY CONTENT permission controls whether users can modify a Document’s content, specifically:

  1. edit the free-form text content
  2. add / remove new Work Items to the Document
  3. modify the Document structure
  4. modify the content of the Work Items (see below)

So in the scenario above, you could explicitly deny the MODIFY CONTENT permission once the Document is pushed for review or approved.



This permission controls whether users can modify a Document’s built-in fields (e.g. status) and custom fields. (Not to be confused with Work Item fields!)


The MANAGE permission controls whether users can move a Document, change the Work Item types that can be stored in a Document, change the outline number prefix, etc.

Container-derived Permissions

So we said that if user is not allowed to modify content of a Document, he/she should not be allowed to modify the content of any contained Work Item.

In our scenario, one option would be to configure Polarion that when a Document is pushed to review, all the contained Work Items would be pushed to review as well, and to configure the permissions so that Requirement artifacts in the review state have their Title and Description marked as read-only.

This is definitely possible, but to make it simpler for administrators so that they do not need to worry about keeping the permission of a Document and it’s contained Work Items synchronized all the time, we have bound the Work Item permissions with the Document permissions.

For Work Items stored in a Document, we introduced following “built-in” permission:


In other words, if user cannot edit the Document content, he/she cannot change the Title, Description and attachments of any Work Item, via the Document Editor, the Work Item Editor, or the API.

Got feedback? We want it!

Post a Comment for the Community

comments powered by Disqus