Skip to main content

​
The problem the hierarchy solves

Imagine you administer a project with a dozen work item types, each with its own Definition of Done (DoD) and Definition of Ready (DoR) checklist. Some rules genuinely apply everywhere (nobody outside the QA role should ever be able to restructure a checklist). Other rules are far more specific (only while a userstory is in status draft can the DoR checklist be edited at all). If every property had to be written out in full for every type, every field, and every status combination, your configuration would be enormous and contradiction-prone. The configuration property hierarchy solves this by letting a single property key omit the segments it doesn’t need to be specific about. A property with fewer segments is a broader default; a property with more segments is a narrower override. The system searches from most specific to least specific and applies the first match it finds.

​
The general shape of a property key

Properties follow the pattern:
Both _TYPEID_ (the work item type) and _FIELDID_ (the checklist’s custom field ID) are optional. This is confirmed directly for the allMandatory property, which controls whether every item in a checklist is treated as mandatory:
The KB content is explicit that the system searches for the properties in the order listed above — meaning the most specific form (type + field) is checked first, and the search falls back toward the fully generic form only if nothing more specific is set.
diagram
Mental model: think ‘CSS specificity,’ not ‘first property wins’The most useful analogy is CSS specificity: a highly specific selector (an ID selector) beats a general one (a type selector), regardless of the order the rules are written in the stylesheet. Configuration properties behave the same way — it doesn’t matter what order you typed the properties into Configuration Properties; what matters is how many segments each key specifies. The narrowest applicable key always wins.

​
A four-segment example: adminPermission

The clearest illustration of the full hierarchy in the gathered context is adminPermission, which controls who is allowed to change a checklist’s structure (add or remove items) as opposed to merely checking items off. Its full key shape adds a workflow status segment:
The documented evaluation order — checked from most specific to least specific — is:
  1. nextedy.checklist.userstory.dod.accepted.adminPermission
  2. nextedy.checklist.dod.accepted.adminPermission
  3. nextedy.checklist.userstory.dod.adminPermission
  4. nextedy.checklist.dod.adminPermission
  5. nextedy.checklist.userstory.accepted.adminPermission
  6. nextedy.checklist.accepted.adminPermission
  7. nextedy.checklist.userstory.adminPermission
  8. nextedy.checklist.adminPermission
Notice the pattern: type+field+status beats type+status, which beats field+status, which beats type+field, and so on, down to the fully generic key with no segments at all. The accepted values for adminPermission are @none (nobody, including admins, may restructure the checklist), @all (any user may), or a comma-separated list of user roles (including project-specific roles).
This is exactly the kind of “freeze the definition once review starts, but let it evolve early” process rule that regulated teams need, expressed as ordinary property configuration rather than custom workflow logic.
adminPermission governs structure, not checking itemsThis distinction matters enough to repeat: adminPermission controls who may add, remove, or redefine checklist items. It says nothing about who may mark existing items as checked or unchecked — that’s controlled by ordinary Polarion field permissions (Readonly Fields or field-based Permissions Management), which is a completely separate mechanism layered on top of the checklist-specific hierarchy.

​
Other properties that follow the same pattern

The hierarchy isn’t unique to allMandatory and adminPermission — it’s the general resolution mechanism for checklist-scoped settings. workItemTemplateId and documentTemplateId (covered in Templates) resolve exactly the same way: a property scoped to _TYPEID_._FIELDID_ is more specific than one scoped to _FIELDID_ alone, which in turn is more specific than an unscoped global default. Some properties, however, are not part of this type/field hierarchy at all — they’re plugin-wide settings with a single fixed key, not a family of increasingly specific overrides. From the gathered context: nextedy.checklist.debug (troubleshooting logging, default false), nextedy.checklist.conditional_enabled (master toggle for the Conditional result state — surfaced in the UI as Pending, see Checklist Items, Result States, and Text Syntax — default false, disabled until an administrator sets it; full reference at Icon, Feature-Toggle, and Baseline Properties), nextedy.checklist.searchAttempts (default 30), and the icon overrides nextedy.checklist.checked_sign, nextedy.checklist.unchecked_sign, nextedy.checklist.no_sign, and nextedy.checklist.conditional_sign. Don’t assume every nextedy.checklist.* key participates in type/field narrowing — check the specific property’s documentation.
Verify in applicationThe baseline-related properties nextedy.checklist.baselines.itemType (default btask) and nextedy.checklist.baselines.baselineField (default baseline) are read per-document rather than following the full type/field/status hierarchy described above. Confirm in the live application whether these support any narrower scoping before assuming they behave identically to allMandatory or adminPermission.

​
Common misconceptions

A missing narrow property does not mean ‘no rule applies’A frequent point of confusion is assuming that if you haven’t explicitly set a type-specific or field-specific property, the checklist has no governing rule. In fact, the system always falls through to the global default (nextedy.checklist.propertyName) if one exists, or to the property’s built-in default value if no property at all is set anywhere in the hierarchy. “Unconfigured” at the narrow level is not the same as “unconfigured” overall.
Document-level checklists may not share every property’s exact syntaxThe gathered ticket insights record a real question from a Polarion consultant: whether freeze/permission behavior (like adminPermission) available for work item checklists is also available, with the same syntax, for document-level checklists. The KB content confirms a document-scoped equivalent exists for controlField (nextedy.checklist.document._TYPEID_._FIELDID_.controlField), but the full hierarchy and exact key shape for document-level adminPermission is not confirmed in the gathered context.

​
Why this design matters for compliance

In a regulated setting, the ability to say “this rule is the organization-wide default, but this specific type in this specific status has a documented, deliberate exception” is not a convenience feature — it’s what lets a single configuration file serve as an auditable record of process policy. Because every property key encodes its own scope directly in the key name, an auditor (or a future administrator) can read the full list of configuration properties and reconstruct the entire rule set without needing separate documentation of “which override wins in which case” — the specificity of the key itself answers that question.
KB Articles
  • Checklist configuration properties
  • Checklist workflow functions and conditions
  • How to control who can change the list and when ?
Support TicketsSource Code
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/Checklist.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistItem.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/ChecklistConf.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/ChecklistAdminServlet.java
Last modified on August 31, 2026