{"id":1140,"date":"2014-06-10T18:10:06","date_gmt":"2014-06-11T01:10:06","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/Polarion-Version-2014-SR1-What-39-s-New-and-Noteworthy\/ba-p\/380874"},"modified":"2026-03-26T05:35:20","modified_gmt":"2026-03-26T09:35:20","slug":"polarion-version-2014-sr1-whats-new-and-noteworthy","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/polarion-version-2014-sr1-whats-new-and-noteworthy\/","title":{"rendered":"Polarion Version 2014 SR1: What's New and Noteworthy"},"content":{"rendered":"

Time has come to bring you the first minor update to the Polarion 2014 platform. Packaged as Polarion 2014 Service Release 1 (SR1)<\/STRONG>, this is an update for all Polarion products, free to all customers with a current maintenance subscription. You can download<\/STRONG> the update distribution at http:\/\/www.polarion.com\/downloads\/update.php<\/A><\/STRONG>.<\/p>\n

WHAT’S IN IT FOR YOU?<\/STRONG><\/p>\n

Every service release delivers bug-fixes, as well as improved usability and performance. This release is no exception, and it also includes some new features and useful enhancements that will later roll up to comprise the Polarion 2015 major release, thanks to our incremental Agile development process.<\/p>\n

In 2014 SR1 we are pleased to deliver 2 often-requested features: Document Types and Workflow, and Custom Permissions Sets.  More details on these below.<\/p>\n

So let’s have a brief overview of the new and noteworthy changes\/features in Polarion 2014 SR1. (A list of issues addressed in this release is provided in the Resolved Work Items file<\/A>.)<\/p>\n


\n

LiveDoc Documents<\/H2>
\nLiveDocs are getting richer an more robust with every release. In Polarion 2014 we added support for Document custom fields.We have now added two built-in fields to a Document artifact: Document Type<\/EM> and Document Status<\/EM>.
\n

Document Types<\/H3>
\nDocument Type field holds the definition of a Document type ;-)such as: “Requirements Specification”, “Meeting Minutes”, etc. Documents of different types can have different workflow. In upcoming releases we’ll add a support for different Document custom fields for Documents of different types.<\/p>\n

\"Document
\n

 Document Workflow<\/H3>
\nDocument Workflow can be set up to manage the Document lifecycle better. You can bind Document and Work Item workflow, so that (for example) a Document cannot be approved as long as no Work Items are approved. Or you can automate Work Item process so as all the Work Items having status Draft<\/EM> aremarked as “in review” when you send a Document to the “in review<\/EM>” status.<\/p>\n

\"Screenshot:<\/p>\n

BTW… such workflow is now pre-configured in our standard “System Engineering” project template.<\/p>\n

\"Screenshot:
\n

Custom Permission Sets<\/H2>
\nPolarion’s 2-level permissions schema based onPolarion Application Server permissions AND 3rd version control access permissions satisfies very strong enterprise security requirements. We’ve now made it more flexible to enable configuration of different permissions forcustom data sets. In other words, you can set permissions for any set of items defined by a query. As a subset of this functionality you also get different Work Item permissions for different Work Item types. For example, just set a query : type:testcase<\/EM> to configure different permissions for Test Cases.<\/p>\n

\"Screenshot:
\n

Dependent Enumerations<\/H2>
\nThe most popular type of Work Item custom field is enum<\/EM> (“enumeration”). You can set up any kind of artifact categorization using custom enumerations, such as: occurrence rate for Risk item, safety requirement ASIL level, or “operating system” and “browser” for issues. Last is a typical example where the value of one custom field e.g. “Operating System” set to “Linux” – filters the selection of options for a second field “Browser” (in which IE now does not appear).<\/p>\n

\"Screenshot:
\n

Image Copy & Paste<\/B><\/H2>
\nTo insert an image from clipboard to a LiveDoc Document, Work Item Description field, or Rich Text Custom field, just type CTRL-V\/COMMAND-V. (Supported on Firefox, and Chrome.
\n

Recent Test Step \/ Test Case Results<\/B><\/H2>
\nSome regulations and\/or testing methods suggests to always provide a validation comment (actual result) for each test step. If you need to execute a test case in different conditions it helps a lot if you have an quick access to recent selected test step or test case actual results.<\/p>\n

\"Screenshot:
\n

Test Run Cleanup Job<\/B><\/H2>
\nThe Test Run artifact holds the results of each test execution. In situations where test automation is in place in a continuous integration process, you might soon get thousands of Test Runs in the system (e.g. tests running every hour). Often there’s no value in keeping all<\/EM> the Test Runs visible in the Test Runs history table, which shows all the executed Test Runs. What you really need to keep are the important milestone results. You can mark these Test Runs by using a flag “Keep in History”.<\/p>\n

\"keep_in_history\"<\/A><\/p>\n

You can then configure your project to clean up old test runs that are not flagged as “Keep in History”<\/p>\n

\"Screenshot:
\n

Lucene Update<\/B><\/H2>
\nWe have updated Lucene technology to version Lucene 4.7.0. Together with this update we make it more flexible how content is being tokenized to meet user expectations.<\/SPAN><\/p>\n

Polarion supports two different tokenization algorithms. System property <\/SPAN>search.wordBoundaries<\/TT> can be used to select from them.<\/SPAN>
\n

White Space Based Tokenization<\/STRONG><\/H3>
\nThis is the default way for Polarion. The indexed text is split around white spaces, and from the remaining character sequences all leading and trailing non-alphanumeric characters (anything that is not a letter or number) are removed.<\/p>\n

This allows to search for the substrings of structured informationbetter from the human point of view.
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
WI title<\/TH>
\n		terms for “title” field<\/TH>
\n		query<\/TH>
\n		result (standard tokenization)<\/TH>
\n<\/TR>
\n<\/THEAD>
\n
Mary had a little ‘lamb’.<\/TD>
\n		Mary, had, little, lamb<\/TD>
\n		title:mary<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title.1:mary<\/TD>
\n		not found (title.1’s term is “Mary had a little lamb”)<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title:mary*<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title.1:mary*<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
SW-backend_simulation<\/TD>
\n		SW-backend_simulation<\/TD>
\n		title\"SmileyW<\/TD>
\n		not found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title:backend<\/TD>
\n		not found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title\"SmileyW-backend<\/TD>
\n		not found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title\"SmileyW-backend*<\/TD>
\n		found<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\nNote for advanced users:<\/STRONG> This splitting is done using a regular expression and java.lang.String.split(String)<\/TT>. It is possible to configure a custom regular expression that should be used – by system property search.wordBoundaries.splitByPattern<\/TT>.<\/p>\n

However, it is important to note that this way is not<\/EM> convenient for languages that do not use white space between words.
\n

Standard Tokenization<\/H3>
\nThis method splits text into words according to <\/SPAN>Unicode standard<\/A><\/SPAN>. To use this method of tokenization use property <\/SPAN>search.wordBoundaries=standard<\/TT>.<\/SPAN>
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
WI title<\/TH>
\n		terms for “title” field<\/TH>
\n		query<\/TH>
\n		result (standard tokenization)<\/TH>
\n<\/TR>
\n<\/THEAD>
\n
Mary had a little lamb<\/TD>
\n		Mary, had, little, lamb<\/TD>
\n		title:mary<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title.1:mary<\/TD>
\n		not found (title.1’s term is “Mary had a little lamb”)<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title:mary*<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title.1:mary*<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
SW-backend_simulation<\/TD>
\n		SW-backend_simulation<\/TD>
\n		title\"SmileyW<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title:backend<\/TD>
\n		found<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title\"SmileyW-backend<\/TD>
\n		found items that have SW or backend keywords (unexpected<\/STRONG>)<\/TD>
\n<\/TR>
\n
<\/TD>
\n		<\/TD>
\n		title\"SmileyW_backend*<\/TD>
\n		found items that have SW or backend* keywords (unexpected<\/STRONG>)<\/TD>
\n<\/TR>
\n<\/TBODY>
\n<\/TABLE>
\n
<\/DIV>
\n

Prefix queries<\/H3>
\n
Until now, there was an issue when searching with prefix queries for keyword (untokenized) fields (for other fields it worked normally): prefix queries worked for keyword fields only if they contained only lowercase letters (for example title.1 – the title is converted to lower case before storing in the index field<\/STRONG> using an index function). The reason was that Lucene converts all prefix queries to lowercase (prefix terms are not analyzed \/tokenized\/, as they are incomplete words). With this release, the Lucene query parser is patched to do lowercasing only for non-keyword fields.<\/DIV>
\n

\n

 Example: you can search by Work Item ID prefix, e.g:id\"SmileyP*<\/P><\/p>\n

<\/DIV>
\n

Performance Improvements<\/B><\/H2>
\n

40% more speed on loading Work Item.<\/H3>
\nLoading of Work Items uses improved caching and evaluation of permissions, which improves the load performance by more than 40%. This improvement also positively affected use cases like loading of Documents, Work Items Tree table, or Traceability Matrix. Also, rendering of Wiki pages that work with Work Items (e.g. Reports, Plans), and export to Word or Excel are faster.
\n

Cache of historical queries<\/H3>
\n