Polarion Software Weblog

Polarion 3.0.3 Release is out. The new release ships with a hidden but quite interesting improvement of its wiki functionality.
The feature is called “embedding of workitems inside wiki pages”. Instead of simple references you can directly display workitems inside your wiki pages.

In this blog I want to give you some examples how this functionality can come very handy inside your projects.
Just by embedding simple workitem queries in your wiki pages you will be able to create custom specification documents, impact reports or project status reports.

Lets have a look at the different ways how work items can be embedded.

Embedding via Workitem ID

Use this if you want to embed exactly one workitem inside your wiki page.
Wiki syntax:
{wi: ProjectName/WorkItemId | List of Fields | expand=yes/no}

ProjectName(optional): name of project where work item is located. If no one is specified current project name used by default
WorkItemId: identifier of work item.
fields = List of Fields(optional): list of entries in form FieldName as Type that specifies fields to output. Type can be text, image, image-text. By default the application outputs following fields: id as text, type as image, status as image, severity as image.
expand: if this property is set to yes all specified information about work item is presented below the link

Example:
{wi: MyProject/WI-245 | description as text, status as text-image, severity as text | expand = no}

Embedding By Query

Use this if you want to add multiple items inside your wiki page.
The syntax text is similiar to Polarion Query builder syntax
{wi: query=Polarion Query | List of Fields | sortby = Field tablewidth=Width | tableheight = Height | expand=yes/no}

Example:
{wi: query= type:defect AND (priority:critical OR priority:major) | sortby=created | fields = ID, status as image, severity as image-text, description as text | tablewidth=90% | tableheight=240px}

Creation of custom specification documents

In many cases specification documents consist of some static sections and sections in which you list requirements.

In following Example I combined both approaches – embedding via workitem ID and embedding by query – to create a simple specification document

After some static section at the beginning we list the description of workitem DEMO-1.
Using list as output format( output=list) will display all selected fields below the workitem. I prefer that format because I find it easier to read.
Expand is set to yes (expand=yes) so all listed fields (here only description) are expanded already when you open the wiki page.
We could add additional fields inside the fields section seperated by comma (fields = title as text, description as text…)

In the next section I have added multiple items by query. We have two options here. We can specify a query to filter for specific requirements to be displayed..
For example we could query for all functional requirements with following query: categories.id:functional or
for all requirements in status proposed with following query: status:proposed.
The other option is to pick a set of items by id inside our query.
I have chosen the latter approach in our example.

Displaying linked testcases to a requirement in a table view

You can easily query for linked testcases to a requirement if you know the id(s) of the requirement.
Lets say our requirement has the id DEMO-22 and we want to find all testcases linked to it.
To display requirement DEMO-22 we simply embed it by ID. To display linked testcases in the next column we use following trick.
All linked testcases will have a link to DEMO-22. So if we don’t search by id (id:DEMO-22) but just for the word DEMO-22 we will find all items with the word DEMO-22 inside

.
All testcases that link to DEMO-22 will have the word inside the linked work items section.
As we want to list testcases only the complete query will look like this: “type:testcase AND DEMO-22″

Creating Backlog Reports by User

If you want to embed all open items per user for a specific timpoint you can do that simply by following query:
status:open AND timePoint.id:Iter1 AND assignee.id:ron

Manage Project reports

Create a wiki page that displays items of type project report. The project report item contains personal judgement of the project manager about his project
In that way you can aggregate reports of different projects within one wiki page

Manage risks

Some requirements should be controlled via risks that are assigned to users for periodical review.
Create a risk page which embeds the risks sorted by different aspects

I hope the different scenarios gave you some ideas how that feature could be applied within your project.
Think about: News pages, project announcements, testplan reports, release notes, glossaries
Stay tuned for upcoming blogs.

Best
Tim

In the last blogs we spent quite some time to discuss how you plan items and how you can react on changes in your plan. However we did not use links in our plan. As many items have relationships it is important to understand what impact these relationships can have on your plan.

In Polarion we can find three categories of links; dependency links, parent links, information links.

Dependency Links (depends on)

As already mentioned in our previous blog you should use this type of link if you want to express that one item can only start when the other item has been finished. Typically you will have that type of relationship between tasks. The link should always point from a task to the task it depends on.

Lets have a look at our plan before we will create a dependency relationship.

In this example we will assume that work on “feature 4” can’t start before “feature 1” has been finished. Currently our plan does not reflect that constraint. To achieve this behaviour we have to create a dependency link from “feature 4” to “feature 1”. We edit “feature 4” and add in the field linked workitems “feature 1”. As relationship we select “depends on”. As long as the change is not submitted you will see the workitem id in the title section. After submittion the title will be displayed in the linked workitems section.

We will manually update the plan to see what has changed. As expected “feature 4” has moved now a bit to the right as it has to wait for “feature 2” to be finished. Unfortunately “feature 4” is now also in delay due to the shift by the created dependency

As you can see dependencies are a valuable instrument to adjust and refine your plans. Knowing this people tend to make extensive use of dependency links even if no real “depends on” relationship exist between the items. They use the link more to influence the order in which the items are planned. Don’t do this – use priorities instead

Parent Links (parent, implements)

Imagine estimated a feature with an effort of 10 days. To get a better understanding of the feature the assignee breaks id down to two subfeatures: “feature 4a” and “feature 4b”. After refining the feature and describing it in more detail you add new estimates to “feature 4a” and “feaeture 4b”. No imagine that you estimate for “feature 4a” an estimate of 6 days and to “feature 4b” an estimate of 8 days. We have created a conflict in our plan. The high level feature has been estimated with a different value than its refinement.

Whenever you use parent links polarion will plan the child items and not the parent item. That means that in our liveplan we will from that point on only see the child items.

As you can see the liveplan always displays the highest refinement level. Probably you ask yourself now what happens with the estimates of the parent workitem and where can you control the status of the parent element? Whenever we want to have a view on the high level items we can consult the roadmap view which contains all items from a timepoint that you select. Personally I prefer an adjusted treeview in which I can also see why an item is in delay and what child item coused the delay.

In our example “feature 4a” is in delay and therefore “feature 4” is in delay. If the entry in the timePoint column is in red color it is in delay. “Feature 4” can only be finished at 24^th of April which is exactly 4 days later than initially planned.

Information Links (relates to, duplicates, reveals)

Information links are the easiest links related to planning as they have no impact at all. You can create as many information links as you like, they will have not change your plan. Inks are anyhow helpful to describe that some items have relationships to each other that should be taken in account. Examples are: A bug is related to a feature, a testcase reveals a bug, a change request duplicates a change request that exists already in the system.

Best Wishes
Tim

Automated migration of user permissions from version 2.6.5 (acls.xml) to version 3.0.0 (permissions.xml) can result in some users having more privileges than they had before the migration.

After the migration, an administrator should log in to the Administration perspective, go to the User Management : Permissions topic for the repository scope, and review and adjust user permissions. This should also be done for any projects which override the default configuration.

The main problematic part is if you changed something in the “GLOBAL SECURITY SETTINGS” section of acls.xml – due to the different logic behind permissions.xml the influence of this section is reduced when migrated to Polarion 3.0 as “GENERAL PERSISTENCE SECURITY SETTINGS” which only impacts entities like Work Items and not things like Administration.

Product Version: 3.0.0
Reported OS: Windows
Description:
A customer support ticket indicated Polarion ALM server was taking a very long time to start (over 3,800 seconds), and ran very slow afterwards. The cause was discovered to be the ZoneAlarm firewall. When the firewall was disabled by the customer, the problem persisted. However, When Polarion was installed on a computer with similar configuration but without ZoneAlarm firewall installed, startup and performance was normal.

Recommendations:
For the time being we recommend that you not attempt to run Polarion server on Windows computers having ZoneAlarm installed. We have not seen any problems with Polarion server running on Windows with the Windows firewall installed and activated, so we can suggest that as a firewall alternative.

This post cites and corrects several errors in the Polarion for Subversion 2.6.5 documentation. There are additional errata which we will cover in subsequent posts.

Print action applies to current query

Documentation states that the Print action is limited to selected work item and multiple work items in Bulk Edit. The print action can be used to print (and in fact display in a printable page) the work items matching current query.

No project scope Working Calendar

Documentation incorrectly states that Working Calendars may be defined for a project, as well as globally and for a user. Working Calendar can only be defined in global default and user specific configurations.

Recording status changes on custom fields

This feature of Polarion 2.6.5 was not documented. You can define a custom workflow that sets up a record of status changes to a custom field. Comments and code int in the linked workflow.xml file (dowload zip archive show an example of how to set this up for a custom field which shows the date when a Work Item was accepted , using the following example custom field definition:

<field id="acceptedOn" type="date-time" name="Accepted On" description="Date when the Work Item was accepted."/>