Template Configuration Properties - Nextedy Documentation

Reference for configuration properties that control how checklist templates are resolved, applied, and enforced across work items, documents (LiveDocs), test runs, and plans. All properties in this document are set in Administration > Configuration Properties using the nextedy.checklist.* dot-notation namespace.

Property hierarchyTemplate properties follow the standard Checklist property hierarchy. See Property Hierarchy and Precedence Reference for the full 4-level precedence model. This page documents template-specific keys and their exact resolution order where it differs from the general model.

Work Item Template Properties

Name	Type	Default	Description
`nextedy.checklist._TYPEID_._FIELDID_.workItemTemplateId`	`string` (work item ID)	See application (no static default — see fallback note below)	ID of the work item whose checklist content is used as the template for the checklist stored in `_FIELDID_` on work items of type `_TYPEID_`. `_TYPEID_` and `_FIELDID_` are both optional segments.
`nextedy.checklist._TYPEID_._FIELDID_.allMandatory`	`boolean`	`false`	When `true`, treats every checklist item in the resolved checklist as mandatory, regardless of the per-item mandatory flag.

_TYPEID_ is a work item type ID (for example userstory, requirement). _FIELDID_ is the custom field ID holding the checklist (for example dod, chkApproved). Both segments are optional and can be omitted independently, which is what produces the 4-level precedence.

workItemTemplateId falls back to Polarion’s built-in item templateConfirmed from ChecklistService.java: if workItemTemplateId is not configured for a given type/field, template resolution falls back to the work item type’s own built-in Polarion template reference — the same mechanism described in Built-in Polarion Work Item Templates below. The two mechanisms aren’t fully independent alternatives: the config property takes precedence when set, and the built-in template is the fallback when it isn’t.

Precedence example — `allMandatory`

nextedy.checklist.userstory.dod.allMandatory=true   # applies just for "dod" on story level
nextedy.checklist.dod.allMandatory=true              # applies just for "dod" checklist for any work item type
nextedy.checklist.userstory.allMandatory=true        # applies to any checklist for the 'userstory' work item type
nextedy.checklist.allMandatory=true                  # applies to any checklist

The system searches for the property in the order shown above — most specific (type + field) first, least specific (global) last.

allMandatory resolution order, from most specific (type and field) to least specific (global)

Work item template ID example

# requirement is the work item type, chkApproved is the checklist custom field ID
nextedy.checklist.requirement.chkApproved.workItemTemplateId=WI-124

# work item type omitted — applies to any type using a "chkDone" checklist field
nextedy.checklist.chkDone.workItemTemplateId=WI-125

Templates are liveAll changes made to a checklist template work item are instantly promoted to every work item, document, test run, or plan that resolves its checklist through that template.

Document (LiveDoc) Template Properties

Name	Type	Default	Description
`nextedy.checklist._TYPEID_._FIELDID_.documentTemplateId`	`string` (document path)	See application (no static default — same built-in-template fallback as `workItemTemplateId`, see note below)	Path to the LiveDoc used as the checklist template for a document-scope checklist. `_TYPEID_` here refers to the document (LiveDoc) type ID; `_FIELDID_` is the checklist field/ID on the document.

# documentSpecification is the LiveDoc type, documentReadyChecklist is the checklist ID
nextedy.checklist.documentSpecification.documentReadyChecklist.documentTemplateId=Specification/Product Spec Template

Document-level checklist templates are resolved by the checklist form extension when rendering the checklist for a document. A document that is itself designated as the template automatically receives administrative permission over its own checklist structure.

documentTemplateId falls back to Polarion’s built-in document templateConfirmed from ChecklistService.java: if documentTemplateId is not configured for a given type/field, resolution falls back to the document type’s own built-in Polarion template reference, mirroring the workItemTemplateId fallback described above.

Cross-Project (Global) Templates

Name	Type	Default	Description
`nextedy.checklist._TYPEID_._FIELDID_.workItemTemplateId` (cross-project form)	`string` (`PROJECTID:WORKITEMID`)	See application	Same property as above, but the value is prefixed with a project ID to reference a template work item stored in a different Polarion project.
`nextedy.checklist._FIELDID_.documentTemplateId` (cross-project form)	`string` (`PROJECTID:Space/DocumentName`)	See application	Same property as the document template property above, but referencing a document template stored in a different project.

# Work item template stored in "myOtherProject"
nextedy.checklist.requirement.chkApproved.workItemTemplateId=myOtherProject:WI-124

# Document template stored in "myOtherProject"
nextedy.checklist.checklist.documentTemplateId=myOtherProject:Specification/SpecificationTemplate

FormatThe cross-project reference format is PROJECTID:WORKITEMID for work item templates, or PROJECTID:Space/DocumentName for document templates. Omitting the PROJECTID: prefix resolves the template within the current project.

Built-in Polarion Work Item Templates

Checklist also supports Polarion’s own built-in work item template mechanism. As noted above, this is the fallback template source used when workItemTemplateId is not configured for the given type/field — not merely an unrelated alternative:

Create a new work item (for example, titled “TEMPLATE”).
Mark it resolved so it disappears from default views.
Reference this item from the work item type enumeration as the type’s built-in template.

Known limitation — duplicated checklist items with Polarion item templatesWhen using Polarion’s built-in work item template mechanism (rather than workItemTemplateId), a bug in current versions of Polarion — not in Checklist — changes the checklist field’s format from Text to Richtext when data is copied from the template to the new item. This can result in duplicated checklist items.Workaround:

Open the workflow configuration for the affected work item type.
Select the init action.
Add the workflow function ChecklistResetToTemplate (see Workflow Functions and Conditions).
Add a checklist parameter with the value set to the name of the checklist custom field.

This resets the checklist immediately after item creation, which also corrects the field type. Nextedy has raised this issue with Siemens; the workaround will not be necessary once it is fixed upstream.

Template Merge Behavior

Behavior	Description
Merge on parse	When a checklist field is parsed, items from the linked template are merged with the existing stored items.
Result carried over on merge	If an item with the same ID already exists in the stored checklist, only its result is carried over/preserved — other fields (label, mandatory, description) are refreshed from the template.
Reset destroys local progress	Applying `ChecklistResetToTemplate` (or the underlying reset operation) discards existing checklist progress and reloads the template content in full.

Reset is destructiveResetting a checklist to its template overwrites current checklist progress, including all local additions and previously recorded result states. This action cannot be undone from within the checklist form extension.

Object-Type Template Resolution Summary

Verify in applicationThe exact API surface for test run and plan template resolution (their template reference mechanism) is confirmed at the service level in code, but the corresponding admin-facing configuration property names for test runs and plans specifically were not present in the gathered context. Confirm the exact property names in the running application before publishing type-specific guidance beyond what is shown here.

Property Hierarchy and Precedence Reference — general 4-level precedence model shared across all Checklist configuration properties.
Permission, Freeze, and Read-Only Properties — controlling who can edit a checklist’s structure once a template is applied.
Icon, Feature-Toggle, and Baseline Properties — appearance and baseline-related properties.
Workflow Functions and Conditions — ChecklistApplyTemplate and ChecklistResetToTemplate workflow functions that act on templates during workflow transitions.

Sources

KB Articles

Checklist configuration properties

Support Tickets

#3346

Source Code

proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistConf.java
proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistAdminServlet.java
proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistSetupService.java
proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistSettings.java
proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistProduct.java
proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistService.java

​Work Item Template Properties

​Precedence example — allMandatory

​Work item template ID example

​Document (LiveDoc) Template Properties

​Cross-Project (Global) Templates

​Built-in Polarion Work Item Templates

​Template Merge Behavior

​Object-Type Template Resolution Summary

​Related Configuration

Work Item Template Properties

Precedence example — `allMandatory`

Work item template ID example

Document (LiveDoc) Template Properties

Cross-Project (Global) Templates

Built-in Polarion Work Item Templates

Template Merge Behavior

Object-Type Template Resolution Summary

Related Configuration