> ## Documentation Index > Fetch the complete documentation index at: https://learn.nextedy.com/llms.txt > Use this file to discover all available pages before exploring further. # Property Hierarchy and Precedence Reference > Exhaustive reference for how Nextedy CHECKLIST resolves configuration properties across global, type-specific, field-specific, and status-specific scopes. export const LastReviewed = ({date}) => { if (!date) return null; const formatted = new Date(`${date}T00:00:00Z`).toLocaleDateString("en-US", { year: "numeric", month: "long", day: "numeric", timeZone: "UTC" }); return

Last reviewed on {formatted}

; }; ## Property key pattern All configuration properties are set in **Administration > Configuration Properties** and follow this dot-notation pattern: ```text theme={null} 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 application** The KB source states the system searches for the property "in the order mentioned above" (type+field, then field-only, then type-only, then global) for this property, but does not give the fully expanded 8-step order shown below for `adminPermission`. Treat the 4-level example above as the base pattern; see the next section for the fuller, status-aware order confirmed for `adminPermission`. 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: ```text theme={null} 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: ```text theme={null} 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 ``` **Worked configuration** ```text theme={null} # '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 actions** `adminPermission` 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 behavior** Starting 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. ## Related non-hierarchical properties The following properties are read via the same `_TYPEID_._FIELDID_` scoping mechanism but were documented individually rather than as part of 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](/checklist/reference/configuration/template-properties#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](/checklist/reference/configuration/template-properties) for the full merge/freeze mechanism. | **workItemTemplateId default confirmed via source; mergeTemplate/mergeTemplateResolved defaults confirmed via source** `mergeTemplate` and `mergeTemplateResolved` defaults above are confirmed directly from `ChecklistService.java`'s config lookups. `workItemTemplateId` has no static default value (it resolves dynamically per the fallback described above), so "See application" remains accurate for that row. ## 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 Property** Unlike 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_` segment** `checklistsIdsForTypeChanges` is **type-scoped**, not plugin-wide: the actual key confirmed in `ChecklistService.java` is `nextedy.checklist._TYPEID_.checklistsIdsForTypeChanges` (parallel to `checklistsIdsForSummary` — see [Summary Field Reference](/checklist/reference/summary-field)), not the bare `nextedy.checklist.checklistsIdsForTypeChanges` shown in earlier revisions of this page. | 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](/checklist/reference/configuration/appearance-and-feature-properties) for related display properties, and [Permission, Freeze, and Read-Only Properties](/checklist/reference/configuration/permission-and-freeze-properties) for the full `adminPermission` and freeze/merge-template behavior. ## Document-level applicability **Verify in application** A support ticket asked explicitly whether freeze and role-based `adminPermission` settings apply to document-level checklists in addition to work item checklists, and what the exact syntax is for documents. The gathered context does not confirm document-scoped syntax beyond the general `_TYPEID_._FIELDID_` pattern — confirm document-level behavior in the application before documenting it as equivalent to the work item examples above. ## See also * [Template Configuration Properties](/checklist/reference/configuration/template-properties) * [Permission, Freeze, and Read-Only Properties](/checklist/reference/configuration/permission-and-freeze-properties) * [Icon, Feature-Toggle, and Baseline Properties](/checklist/reference/configuration/appearance-and-feature-properties) * [Reference](/checklist/reference/index) **KB Articles** * Checklist configuration properties * How to control who can change the list and when ? **Support Tickets** * [#3346](https://support.nextedy.com/helpdesk/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/ChecklistSettings.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/ChecklistProduct.java` * `proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistService.java`