Polarion Software Weblog

The following statement will enable log rotation for Apache. The command is specified for installation in a Windows system. Please check paths for you own installation.
CustomLog “|C:/Polarion3.1.1/bundled/apache_2.0.59/bin/rotatelogs.exe C:/Polarion3.1.1/data/logs/apache/access.log 60″ common

Log rotation works by a pipe to the rotatelogs.exe, which itself can be configured to rotate logs by time or by size. Try rotatelogs -? to get help.

The given statement is suitable for the access log file, which receive most of the log output. Look for further log configuration in httpd.conf and adopt them appropriately to rotate all Apache log files.

Best Wishes
Matthias

If you switch on SSL, users have to type the URL beginning with https://<server name> /Polarion. If they miss the “https”, they will not reach the page. You can help your users with an automatic redirect in the Apache configuration.

httpd.conf

remove the comment on the line:
LoadModule rewrite_module modules/mod_rewrite.so

Locate the following statement:
Listen 80

Add the following statements:
Listen 8888

The port 8888 will be used for communication between Apache and Polarion, since Polarion is not able to use SSL. In ssl.conf the access to this port is limited to localhost.

ssl.conf:
Append the following section to the file:

#– rewrite the standard page to the ssl page
<IfModule mod_rewrite.c>
RewriteEngine on
#RewriteLog “path to logfile”
#RewriteLogLevel 9

####
# Only apply the rules, if the port is not SSL (443)
# or the local port (8888)
####

ReWriteCond %{SERVER_PORT} (443||8888)$

####
# Redirect only access to repo and Polarion to the
# SSL port. The other stuff is not sensitive and can
# remain on the old port.
####

RewriteRule (repo/.*) https://%{HTTP_HOST}/$1 [NC,L]
RewriteRule (polarion/.*) https://%{HTTP_HOST}/$1 [NC,L]
</IfModule>

Best Wishes
Matthias

The image folder is hidden in the Polarion installation. When you customize Polarion, you will need the images e.g. when you look up new icons for workflow states or work item types.

To make them easily accessible, you could copy the images to subversion and check out the images in the Apache configuration. By adding some statements in the Apache configuration, access to the icons becomes easy. Another advantage is you can modify the images and check them in. All changes will still be persistent if Polarion needs to be updated.

Location of the images:

<Polarion installation folder>/Polarion/plugins/ com.polarion.java2js.server_3.1.0/webapp/ria/images

Copy this folder and it content to subversion. Check out the folder in the apache configuration, for example in the subfolder “images”. You could also add a cron job (or a task in Windows) to do a nightly update on that folder.

To publish the folder in Apache, use the following section at the end of the httpd.conf:

Alias /images/ “C:/Programme/Polarion 3.1/bundled/apache_2.0.59/images/”

<Directory “C:/Polarion/bundled/apache_2.0.59/images”>
Options Indexes MultiViews
IndexOptions +FoldersFirst +IgnoreCase
AllowOverride None
Order allow,deny
Allow from all

<FilesMatch “Thumbs.db”>
Order deny,allow
Deny from All
</FilesMatch>
</Directory>

Best Wishes
Matthias

Personally I think Tortoise is the best subversion client which is currently available for windows. Additionally to its fantastic approach (just integrating into windows explorer instead of having an extra tool) TortoiseSVN also allows you to integrate with other tracking systems.
In this blog I want to show you how easily you can link commits with PolarionALM workitems. So lets get started.

First thing you should do is to check-out your project folder which you want to link with polarion. Our Example here is related to “Library” project delivered with standard setup of Polarion ALM. Lets assume you did a check out of your project into a folder called demolibrary.

After check out you have to set some TortoiseSVN specific properties on the demolibrary folder. Right click on the folder and select “properties”.

Then set following properties:

Now commit your changes back to Subversion – Done.

From now on TortoiseSVN will prompt you for a workitem id during a commit. Additionally to your commit message you should enter the number of the Polarion workitem id. Press OK.
The provided id will be listed as part of the log message and is clickable. When you click on it the Polarion workitem will be opened in a browser window for you to read. Please have a look at the images below.

Best Wishes
Tim

p.s. thanks Robert for bringing it together

Sometimes people ask me how it is possible to track status of items that have been refined by subitems. Imagine having a change request that has been broken down into several tasks. In the following blog I want to take a deeper look on how parent items can be tracked even if they have been refined into subitems.

Where Planning Information is Visible

Each workitem in Polarion contains a field that represents automatically calculated planning information. This field is called planned to. It contains the start and end date to which a workitem was scheduled by Polarion during the latest planning round (update of liveplan). The planned to field is not editable and it will only be updated if the workitem is considered as an element that must be planned (please refer to the planning.xml file for more information).

As soon as Polarion has finished a planning round you will see a start and end date inside the planned to field.

How is the planned to field calculated ?

Please have a look at the other blogs on planning and linking to get a better understanding of Polarion’s planning algorithm. Today we want to analyze the parent/child relationship in more detail. Let’s take following scenario:

Our project has received a change request (EDEMO-1: “Text should be easier to read”) which has as remaining estimate of 10 days and was scheduled to timepoint Rel-1.

After a while our change request has been refined by two subtasks (EDEMO-2: “Increase text size” and EDEMO-3: “Increase contrast and color (black and white)” ) EDEMO-2 has remaining estimate of 6 days and EDEMO-3 has a remaining estimate of 7 days

Parent Items are not Visualized in Liveplan

As a matter of fact we have created a little conflict here. The child items have in sum a different estimate compared to the parent item – 13 days for the child tasks compared to 10 days initially planned for the change request. Polarion’s liveplan will manage such conflicts in following way. Parent items will be removed from liveplan when they have child items. Only child items will be visible. The reason is that remaining time estimates on child items are considered more accurate as estimates on parent items.

How Planning Information is Delegated to Parent Items

So how can we track our change request when it is not anymore displayed in liveplan and how is the conflict resolved?

Even if parent items are not visible in liveplan the planned to field is updated correctly. After Polarion’s next planning round the liveplan will contain a range of 13 days (EDEMO-2 + EDEMO-3) instead of 10 days. Polarion sums up remaining estimates of all child items and presents the result inside the planned to field of the parent item

Where Can I See Planning Information of Parent Items

If you want to see if parent items are delayed you can switch to one of the following views:

• table view,
• tree view or
• roadmap view.

You should make sure that the timePoint, plannedStart and plannedEnd columns are displayed. If an item is delayed it will be marked in red. If you want to check why an item is delayed you can change to tree view and analyze state and estimations of the child items. In our example the 13 days for change request EDEMO-1 is too long and timepoint Rel-1 can not be reached. Additionally we see that task EDEMO-2 can not be finished in time.

Best Wishes
Tim