Property Hierarchy and Precedence Reference

Property key pattern

All configuration properties are set in Administration > Configuration Properties and follow this dot-notation pattern:

nextedy.checklist._TYPEID_._FIELDID_.propertyName

Segment	Type	Default	Description
`_TYPEID_`	`string` (optional)	See application	The work item type ID (or document type ID) the property applies to, e.g. `userstory`. Omit to apply to all types.
`_FIELDID_`	`string` (optional)	See application	The checklist custom field ID the property applies to, e.g. `dod`. Omit to apply to all checklists.
`propertyName`	`string`	N/A	The specific property being set, e.g. `allMandatory`, `adminPermission`.

Both segments are optional, independently_TYPEID_ and _FIELDID_ can each be present or omitted, which is what produces the 4-level precedence below. They are not positionally fixed beyond “type before field” in the key.

4-level precedence (type + field specificity)

Documented for the allMandatory property, which configures whether all checklist items are treated as mandatory:

Level	Property Key Example	Scope
4 (most specific)	`nextedy.checklist.userstory.dod.allMandatory=true`	Applies only to the `dod` checklist on the `userstory` work item type
3	`nextedy.checklist.dod.allMandatory=true`	Applies to the `dod` checklist for any work item type
2	`nextedy.checklist.userstory.allMandatory=true`	Applies to any checklist on the `userstory` work item type
1 (least specific / global)	`nextedy.checklist.allMandatory=true`	Applies to any checklist, any type

Verify in applicationThe system searches for allMandatory in the order shown above — type+field, then field-only, then type-only, then global. The fully expanded 8-step order in the next section is documented for adminPermission only; whether other properties follow that same status-aware expansion is not documented. Treat the 4-level example above as the base pattern, and verify anything beyond it in your Polarion instance before relying on it.

For type=userstory, field=dod, property=allMandatory, the lookup walks from level 4 down to level 1 in the table above, stopping at the first property key that is actually set, and falling back to the global default only if none of the more specific keys are configured.

Status-aware precedence (adminPermission)

The adminPermission property additionally supports a _STATUS segment, extending the pattern to:

nextedy.checklist._TYPEID_._FIELDID_._STATUS_.adminPermission

Property	Type	Default	Description
`nextedy.checklist._TYPEID_._FIELDID_._STATUS_.adminPermission`	`string`	See application	Controls who may define/edit the checklist structure (add/remove items), optionally scoped to a specific workflow status.

Accepted values:

Value	Meaning
`@none`	No one may change the checklist structure at this scope.
`@all`	Anyone may change the checklist structure at this scope.
Comma-separated list of user roles	Only users holding one of the listed roles (including project roles) may change the checklist structure.

For a userstory type, dod/dor checklists, and an accepted status, the system evaluates adminPermission in this exact order:

nextedy.checklist.userstory.dod.accepted.adminPermission
nextedy.checklist.dod.accepted.adminPermission
nextedy.checklist.userstory.dod.adminPermission
nextedy.checklist.dod.adminPermission
nextedy.checklist.userstory.accepted.adminPermission
nextedy.checklist.accepted.adminPermission
nextedy.checklist.userstory.adminPermission
nextedy.checklist.adminPermission

Worked configuration

# 'dod' checklist can be controlled by global admin and project_developer roles
nextedy.checklist.dod.adminPermission=admin,project_developer

# but when 'userstory' is in status 'verified' the checklist definition cannot be changed at all
nextedy.checklist.dod.verified.adminPermission=@none

# 'dor' checklist cannot be adjusted at all for userstory, unless overridden below
nextedy.checklist.userstory.dor.adminPermission=@none

# 'dor' checklist can be changed by anyone only when the work item is in status 'draft'
nextedy.checklist.userstory.dor.draft.adminPermission=@all

adminPermission controls structure, not check/uncheck actionsadminPermission governs who can add, remove, or redefine checklist items. Whether a user can mark existing items as checked is a separate concern controlled by standard Polarion permissions — Administration > Work Items > Readonly Fields or Administration > User Management > Permissions Management on the underlying custom field. Configuring adminPermission alone does not lock down check/uncheck actions.

Version-gated UI behaviorStarting with version 25.7.0, regular users without admin permissions on a given adminPermission condition also lose access to the Clear action — it’s no longer available under the checklist’s Gear menu icon. Earlier versions may not hide this control the same way.

The following properties are read via the same _TYPEID_._FIELDID_ scoping mechanism, but are listed individually here rather than through a precedence worked example:

Property	Type	Default	Description
`nextedy.checklist._TYPEID_._FIELDID_.workItemTemplateId`	`string`	See application	Configures the work item ID used as the checklist template for the given type/field scope. If unset, falls back to the work item type’s own built-in Polarion template reference — see Built-in Polarion Work Item Templates.
`nextedy.checklist._TYPEID_._FIELDID_._STATUS_.mergeTemplate`	`boolean`	`true`	Controls whether the checklist template is merged into the current checklist when the object is in the given status. Set to `false` to freeze the checklist at that status.
`nextedy.checklist._TYPEID_._FIELDID_.mergeTemplateResolved`	`boolean`	`false`	Companion property to `mergeTemplate`: when the object has a resolution set, `mergeTemplate` is forced to `false` unless `mergeTemplateResolved=true`. See Template Configuration Properties for the full merge/freeze mechanism.

About the defaults in the table abovemergeTemplate defaults to true and mergeTemplateResolved to false. workItemTemplateId has no static default value — it resolves dynamically through the fallback described above, which is why its Default column reads “See application”.

Global (non-hierarchical) properties

These properties are configured without _TYPEID_/_FIELDID_ scoping — they apply plugin-wide:

Property	Type	Default	Description
`nextedy.checklist.debug`	`boolean`	`false`	Enables debug mode/logging for the checklist plugin. Intended for admin/support troubleshooting.
`nextedy.checklist.conditional_enabled`	`boolean`	`false`	Master toggle controlling whether the `Conditional` result state is available to users.
`nextedy.checklist.searchAttempts`	`integer`	`30`	Number of attempts the plugin makes when searching for a related object (retry tuning for search operations).
`nextedy.checklist.checked_sign`	`string`	`far fa-check-square`	Icon class rendered for the `OK`/checked result state.
`nextedy.checklist.unchecked_sign`	`string`	`far fa-minus-square`	Icon class rendered for the unchecked result state.
`nextedy.checklist.no_sign`	`string`	`far fa-square`	Icon class rendered for the `Empty` (None) result state.
`nextedy.checklist.conditional_sign`	`string`	`far fa-plus-square`	Icon class rendered for the conditional result state; only meaningful when `conditional_enabled` is `true`.
`nextedy.checklist.baselines.itemType`	`string`	`btask`	Work item type that represents a baseline record for checklist history.
`nextedy.checklist.baselines.baselineField`	`string`	`baseline`	Custom field on the baseline item type that stores the baseline/revision identifier.
`nextedy.checklist.disable.hook`	`boolean` (JVM system property)	`false`	Globally disables the checklist save hook (summary refresh, reset-on-type-change). Not a Polarion configuration property — must be set as a JVM system property and requires a server restart.

disable.hook is not a Configuration PropertyUnlike every other property on this page, nextedy.checklist.disable.hook cannot be set via Administration > Configuration Properties. It is a JVM system property set at the application server level and requires a restart to take effect.

Type-scoped property — `checklistsIdsForTypeChanges`

Not actually global — takes a _TYPEID_ segmentchecklistsIdsForTypeChanges is type-scoped, not plugin-wide: the key takes a _TYPEID_ segment — nextedy.checklist._TYPEID_.checklistsIdsForTypeChanges, parallel to checklistsIdsForSummary (see Summary Field Reference) — and not the bare nextedy.checklist.checklistsIdsForTypeChanges.

Property	Type	Default	Description
`nextedy.checklist._TYPEID_.checklistsIdsForTypeChanges`	`string` (comma-separated list)	`""` (empty — no checklists monitored)	Comma-separated checklist field IDs monitored for work item type changes on the given type; a listed checklist that has content resets to the new type’s template on type change. Available from Checklist version 25.1.0.

Per-field PDF visibility property

Property	Type	Default	Description
`nextedy.checklist._TYPEID_._FIELDID_.hideInPdf`	`boolean`	`false`	Sets the default PDF-export visibility for a specific checklist custom field on a specific work item/document type. If `true`, the checklist is suppressed when the containing document or work item is exported to PDF.

See Icon, Feature-Toggle, and Baseline Properties for related display properties, and Permission, Freeze, and Read-Only Properties for the full adminPermission and freeze/merge-template behavior.

Document-level applicability

Verify in applicationWhether freeze and role-based adminPermission settings apply to document-level checklists in the same way as to work item checklists is not documented, and no document-specific syntax beyond the general _TYPEID_._FIELDID_ pattern is confirmed. Verify document-level behavior in your Polarion instance before relying on it being equivalent to the work item examples above.

FAQ

Property Hierarchy and Precedence Reference

Property key pattern

4-level precedence (type + field specificity)

Status-aware precedence (adminPermission)

Global (non-hierarchical) properties

Type-scoped property — `checklistsIdsForTypeChanges`

Per-field PDF visibility property

Document-level applicability

See also

​Property key pattern

​4-level precedence (type + field specificity)

​Status-aware precedence (adminPermission)

​Related non-hierarchical properties

​Global (non-hierarchical) properties

​Type-scoped property — checklistsIdsForTypeChanges

​Per-field PDF visibility property

​Document-level applicability

​See also

Property key pattern

4-level precedence (type + field specificity)

Status-aware precedence (adminPermission)

Related non-hierarchical properties

Global (non-hierarchical) properties

Type-scoped property — `checklistsIdsForTypeChanges`

Per-field PDF visibility property

Document-level applicability

See also