This page documents Nextedy CHECKLIST compatibility with Polarion versions, supported object types, API availability, and feature requirements across different deployment configurations.
For the complete and current list of supported Polarion versions, check the release notes included with your Checklist distribution or contact Nextedy support. The table above reflects versions confirmed through support interactions and testing.
After installing or upgrading Checklist on any Polarion version, you must delete the workspace configuration cache at [POLARION_INSTALL]/data/workspace/.config and restart Polarion. This step is frequently missed and is a common source of post-installation issues. See the Installation tutorial for the complete procedure.
All checklist data is stored in Polarion custom fields. The following requirements apply across all object types and versions.
Requirement
Value
Notes
Field type
Text (multi-line plain text)
Mandatory. Other field types cause a validation error at render time
Field scope
Per object type
Custom fields must be defined on the appropriate object type (work item, document, test run, plan)
Field naming
Any valid custom field ID
Use descriptive IDs like dod, dor, review for clarity
Multiple checklists
Supported
You can define multiple checklist fields on a single object type
If you configure a checklist field with the wrong type, you receive an error message at render time explaining the type mismatch. The field must be type Text (multi-line plain text). This is the most common configuration mistake.
All seven workflow functions and conditions support work items, documents, and test runs. The checklist parameter accepts comma-separated field IDs for multi-checklist validation.
checklist (required), skipForUsers (optional, comma-separated user IDs)
Uncheck all
✅
✅
✅
checklist (required, comma-separated field IDs)
When you specify multiple checklists in a workflow condition (comma-separated), all checklists must satisfy the condition for it to pass. This is AND logic, not OR logic. For example, if you specify checklist=dod,dor, both the dod and dor checklists must have all items checked for the “all items checked” condition to return true.
The Checklist service API is accessible from multiple integration contexts within Polarion.
Access Method
Context
Service Variable / Pattern
Velocity templates
Wiki pages, live reports
$checklistService
Java code
Workflow functions, conditions, extensions
Platform service lookup
JavaScript (Nashorn)
Scripted conditions, save hooks
Platform registry access
JavaScript (Nashorn) access to the Checklist service is supported. The standard platform registry pattern provides access to the service in scripted workflow conditions and save hooks.
Configuration properties follow a 4-level precedence hierarchy that is consistent across all supported Polarion versions.
Level
Pattern
Scope
1 (Global)
nextedy.checklist.*
All object types, all fields
2 (Type-specific)
nextedy.checklist._TYPEID.*
Specific work item type, all fields
3 (Field-specific)
nextedy.checklist._FIELDID.*
All object types, specific field
4 (Type+Field)
nextedy.checklist._TYPEID._FIELDID.*
Specific type and specific field
Properties at a more specific level override those at a more general level. For example, a type+field-specific property overrides the global default for that combination.For the complete property reference, see Configuration Properties.
Controls template merging after a work item has a resolution set
Use workItemTemplateHolder or documentTemplateHolder when different objects of the same type need different templates (for example, when a custom field on the work item determines which template to use). Use the static workItemTemplateId or documentTemplateId when all objects of a given type share the same template.
Checklist rendering adapts to the output context automatically.
Mode
Context
Behavior
Interactive (Edit)
Polarion UI
Full checklist widget with item editing, notes, and state changes via iframe
PDF export
PDF generation
Static HTML table representation of checklist items and their states
Hidden
PDF with hideInPdf()
Checklist is omitted from PDF output entirely
The rendering mode is detected automatically based on the Polarion rendering context. You can force the checklist to be hidden in PDF output using the hideInPdf() builder method or the corresponding configuration property.
Checklist validates the license on each render. The license status affects the UI display.
License Status
Behavior
Valid
Normal operation, no warnings
Trial
Checklist functions normally with a trial notice
Expired
Warning message displayed to users
Invalid
Warning message displayed with links to documentation and support
License warnings are displayed in the checklist widget UI. The specific messages and their visibility depend on the license status returned by the Nextedy license service.
