Compatibility - Nextedy Documentation

For the Polarion versions Checklist supports, see Polarion Version Support.

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.

Supported Object Types

Checklist supports four Polarion object types. Each object type has specific integration points and capabilities.

Feature Matrix by Object Type

Feature	Work Items	Documents (LiveDocs)	Test Runs	Plans
Checklist rendering	✅	✅	✅	✅
Form extension	✅	➖	➖	➖
Document/View builder	✅	✅	✅	✅
Template merging	✅	✅	✅	✅
Workflow conditions	✅	✅	✅	➖
Workflow functions	✅	✅	✅	➖
Baseline tracking	✅	✅	➖	➖
Summary field	✅	✅	➖	➖
`parse()` API	✅	✅	✅	✅
`store()` API	✅	✅	➖	➖
`reset()` API	✅	✅	➖	➖
`applyTemplate()` API	✅	✅	➖	➖
`getChecklistConf()` API	✅	✅	➖	➖
PDF export	✅	✅	✅	✅
Hide in PDF option	✅	✅	✅	✅

For setup instructions specific to each object type, see the Getting Started tutorials:

Custom Field Requirements

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.

Workflow Function and Condition Compatibility

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.

Workflow Conditions

Condition	Work Items	Documents	Test Runs	Parameter
All items checked	✅	✅	✅	`checklist` (required, comma-separated field IDs)
Mandatory items checked	✅	✅	✅	`checklist` (required, comma-separated field IDs)

Workflow Functions

Function	Work Items	Documents	Test Runs	Parameters
Apply template	✅	✅	✅	`checklist` (required, comma-separated field IDs)
Reset to template	✅	✅	✅	`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.

For complete workflow configuration details, see Workflow Functions and Conditions.

API Access Methods

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.

For complete API reference, see IChecklistService API.

Configuration Property Hierarchy

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.

Template Configuration Properties

Template sources are configured through the hierarchical property system. The following properties control template resolution.

Property	Applies To	Description
`nextedy.checklist._TYPEID._FIELDID.workItemTemplateId`	Work items	Static template source work item ID. Supports cross-project references with `projectId:workItemId` format
`nextedy.checklist._TYPEID._FIELDID.workItemTemplateHolder`	Work items	Custom field that holds the template work item ID dynamically. Overrides static `workItemTemplateId`
`nextedy.checklist._TYPEID._FIELDID.documentTemplateId`	Documents	Static template source document location
`nextedy.checklist._TYPEID._FIELDID.documentTemplateHolder`	Documents	Custom field that holds the template document location dynamically
`nextedy.checklist._TYPEID._FIELDID._STATUS.mergeTemplate`	Work items, documents	Controls whether template items are merged based on object status
`nextedy.checklist._TYPEID._FIELDID.mergeTemplateResolved`	Work items	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.

Rendering Modes

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.

Licensing

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.

Installation for setup instructions and post-installation steps
Configuration Properties for the complete property reference
Workflow Functions and Conditions for workflow integration details
IChecklistService API for programmatic access

​Supported Object Types

​Feature Matrix by Object Type

​Custom Field Requirements

​Workflow Function and Condition Compatibility

​Workflow Conditions

​Workflow Functions

​API Access Methods

​Configuration Property Hierarchy

​Template Configuration Properties

​Rendering Modes

​Licensing

​Related Pages

Supported Object Types

Feature Matrix by Object Type

Custom Field Requirements

Workflow Function and Condition Compatibility

Workflow Conditions

Workflow Functions

API Access Methods

Configuration Property Hierarchy

Template Configuration Properties

Rendering Modes

Licensing

Related Pages