The new version of Polarion is available - Polarion ALM version 18.2 (Service Release 2).
Our teams finished a few ongoing projects and we are proud to present new functionality as well as enhancements to existing features, namely:
Cross-references in LiveDocs- Links to Work Items can scroll within the document.
Electronic signatures for Work Item- Aligned signatures implementation with the LiveDocs.
Rich-text synchronization with Jira- Improved the synchronization of rich-text content.
Active Load Balancing- A cluster re-balances users among the nodes.
Termination of too long transactions- Prevent the overloading of the Polarion server by terminating reports that are running too long.
Cross-references in LiveDocs
Cross-references to Work Items in LiveDocs
A new and exciting capability comes to Polarion Live Docs. You can now create cross-references inside of Live Documents. This now makes it easy to navigate to important information inside of documents.Cross-referenceslet you link to Headings or Work Items within a document. Simply copy the cross-reference of a Heading or Work Item and insert it where you would like the reference to appear. When clicked, the cross-reference will scroll to the target item.
Rendering of cross-references with outline numbers
Bydefault, cross-references will show the outline number and the title of the referenced item. This information is dynamically updated if, for instance, the document was restructured. To distinguish them from normal "Work Item links", cross-references are underlined with a dashed grey line.
Cross-references in document reuse
Cross-references are supported in branched, reused and variant documents. This means that when there is a cross-reference that scrolls within the samedocumentwhen creating a branch, variant, or reused document, the cross-reference will still scroll to its matching counterpart section in the new document. If a referenced Work Item that is targeted in a cross-reference is overwritten, the cross-reference will be updated so that it still scrolls to the same position.
Handling of cross-referenced in exports
In an exported PDF, cross-references scroll within the document just as they do in the Polarion document.
The Word round-trip of a document preserves the cross-references created in Polarion, but the cross-references will not scroll in the exported Word document and it is not possible to import cross-references created within Word.
CFR 21 Part 11 Compliant e-Signatures for Work Items
Improved electronic signatures for Work Items
To be fully compliant with the U.S Food & DrugAdministration’s (FDA) CFR 21 regulation (part 11), we implemented updates for Electronic signatures on Work Items. Electronic signatures are used for Workflow Signatures and Approval Signatures.
Our electronic signatures now conform to the legal requirements stipulated in CFR 21.
The following information is now clearly visible on all Electronic signatures:
Purpose of signature (signature verdict or workflow change).
Signatures are now a part of the Work Item form and are in a Human readable form. They can also be printed out in the Work Item form.
Electronic signatures for Work Item approval
Signatures were enhanced to cover the purpose of the signature in the comment body. The process for creating an Approval signature remains the same as it was in the previous version:
A User files their approval via the "Approvals" section of the Work Item form or the Approval sidebar in the Work Items table or LiveDoc.
Saving a change in a Work Item that saves an Approved / Disapproved verdict, opens the two-step e-signature confirmation dialog.
After signing, the Approval Comment Signature appears in the "Comments" section.
Electronic signatures for Work Item workflow
Workflow signatures are now managed in a way that is consistent with LiveDoc and Test Runs. (A signature is stored in a dedicated WorkflowSignature object and displayed in a new section of the Work Item layout.)
Workflow signatures are added when a change in a Work Item's Workflow State is triggered. (If that workflow transition requires one.)
Once a user changes the Workflow State, they must save the changes. This is when the two-step e-signature confirmation dialog appears.
Once signed, the Work Item Workflow Signature appears in the new "Workflow Signatures" section. This section is added as a widget to the Work Item form. It is not visible on the form bydefaultbut needs to be enabled in the "Form configuration" of the Work Item. It now also includes theworkflow statethat wassigned.
Handling of electronic signatures life-cycle
Like in previous Polarion releases, it is possible to bind Workflow and Approval signatures via workflow conditions and functions that can be configured for specific workflow transitions. This allows users to address various use cases that are required for managing electronic signatures during the workflow. For example:
Blocking a transition to the next workflow state until all Approvals are collected.
Marking workflow signatures as obsolete once a Work Item is switched back to the Draft state.
Resetting Approvals to the Waiting state if a Work Item is switched back to the Draft state.
Removing approval signatures once an Approval has been removed, or its verdict reset back to the Waiting state.
Rendering of electronic signatures in reports
Electronic signatures can be rendered in custom Live Reports and widgets via the Polarion Open and Rendering APIs. For this release, it is not yet possible to display signatures as a field of a Work Item, but we plan to deliver the customizable rendering of the electronic signatures field in future Polarion releases.
Jira Connector Improvements
Synchronization of rich-text with Jira
The ability to synchronize rich-text from Polarion to Jira was somewhat limited in Polarion versions prior to this release. It resulted in the removal of most of the text formatting when synchronizing changes from Polarion to Jira. This release greatly improves upon rich-text synchronization.
Synchronization of Jira epic links and issues links
The linking capabilities of the Jira Connector were extended by adding support for the bi-directional synchronization of epic links in Jira to Work item links in Polarion and unidirectional synchronization of issue and epic links to hyperlinks in Polarion.
Active Load Balancing
Active Load Balancing is an enhancement to our cluster solution. With Active Load Balancing the cluster balances traffic between all the nodes in real-time. The cluster also re-balances users if a cluster node is restarted or a new node is added to the cluster.
In order to enable this feature, twosub-featureswere implemented:
Session replication - all the user sessions are now replicated across all the nodes, so any node can take over the session handling at any time.
Time-limitedsession stickiness - this allows sessions that are not touched for some (configured) time to be re-balanced to another node.
The balancing mechanism is based on the Load Balancer configuration. The Apache Load Balancer supports 3 methods by default. (Balancing by requests, by traffic, andby busyness.) There's also an additional experimental balancing method via a custom metric called the heartbeat. The default and recommended setting is balancing 'by requests'.
To enable the Apache Tomcat session replication, the network must support MULTICAST data transfer between the nodes. Before you switch Active Load Balancing on, make sure that the network elements support it and it's allowed by company policy.
The Active Load Balancing is not enabled by default. Refer to our Enterprise Setup Guide for detailed instructions on how to enable this new functionality.
Termination of Long-running Transactions
Based on our experience from GTAC, we learned that specific user requests might occasionally clog up the server with long and resource heavy operations that are typically related to the rendering of custom, unoptimized reports.Additionally, when a user performs the operations multiple times (by refreshing the browser tab, or with multiple clicks on the same action), the clogging might end up with the depletion of server resources and crash of the server.
In order to prevent such problems UI requests that do NOT perform any write operations (typically Live Reports, or Classic Wiki Pages) will be terminated after the defined timeout. The feature is enabled by default and the timeout is set to 9 minutes and 50 seconds - just 10 seconds before the default Apache connection timeout.
The termination oflong-runningtransactions can also be limited to only Live Reports and Classic Wiki Pages, or be completely disabled.
Filtering of Plans in Planned In Work Item field
Polarion administration provides a new way to filter the list of Plans exposed in the 'Planned In' field of a Work Item. This allows for a reduction in the number of available plans via a Velocity script using the Polarion API and the Work Item attributes. The script can access the objects ofa plan, the target work item and the current user to create the filter condition. There is a new Work Item administration page called "Field Filtering" that lets you configure the filter script on the global and project levels.
This is very useful for large deployments using our Scaled Agile Framework solution where the number of plans can easily grow to the thousands. Reducing the number of plans significantly reduces the time it takes to edit a Work Item when planning it for a specific Plan.
Logging of system load in TX log
The transaction log now also captures informationabout theaverage system load during the execution of a transaction on Linux systems. This helps our technical support and development organizations assess performance problems for our customers and identify if a system was generally overloaded during a given time period.
2018-10-04 16:30:19,018 [pool-1-thread-1] INFO TXLOGGER - Core average load: 1.12625
Preventing unnecessary transformation of attachments
Polarion is implemented in a way that it always builds a complete image of all the objects being returned from the server to the client. This sometimes results in be additional datathat arenot required for the rendering of the resulting web page, e.g. a LiveDoc's attachment information that is not relevant when a Work Item within the LiveDoc is requested.
This can result in lost time and resources. A performance improvement was implemented that removes some of this unnecessary data. Depending on the data structure, it can reduce a request response time from hundreds of seconds to tens of seconds or even less! (Depending on other aspects like what data is cached.)
Notable Issue Fixes
DPP-167478 - ReqIF import ignores the default values of attributes DPP-166422 - Concurrent licenses are occasionally not freed-up upon user logout DPP-165216 - Regression with Jira Cloud: Can't sync more than 100 issues DPP-123341 - BacklinkedWorkItems query with multiple WI parameters is saved incorrectly DPP-106295 - NPE when viewing the History of a document with a deleted and then recreated attachment DPP-103120 - Error in the document panel macro if the verdict comment is deleted
Version 18.2 is an update for all Polarion ALM products.
You can download the update distribution from GTAC:
GTAC > Polarion > Full Products > 18.2 > PolarionUpdate_18.2.zip
If your maintenance subscription is current, you can update from version 2016 or 17 to version 18.2 using the License Key Code you already have. You only need to activate your updated installation, which you can do either online or offline. For details, see the bundled HOW_TO_INSTALL_THIS_UPDATE.txt in the update distribution.
If you would like to evaluate this release before updating your production installation, simply visit https://polarion.plm.automation.siemens.com/downloads, download the product of your choice, install it on any available computer and use the built-in 30-day evaluation license.
If you have any questions or comments, please don’t hesitate to contact me or yourPolarion technical support contact. On behalf of our entire team, thanks for using Polarion ALM solutions.
Best regards, Radek Krotil, Polarion ALM Product Management