Skip to main content
There are two distinct permission questions to answer:
  1. Who can mark items as checked (or set any other result state)?
  2. Who can define the checklist structure — add, remove, or edit items?

​
Control who can check items

Marking items as checked is just modifying the underlying custom field, so it is controlled by standard Polarion permissions rather than a Checklist-specific property:
  • Administration > Work Items > Readonly Fields — mark the checklist custom field as read-only for everyone (or for specific conditions supported by that screen).
  • Administration > User Management > Permissions Management — use field-based permissions to control who can write to the checklist custom field.
Use this level when you need a hard, all-or-nothing lock on the field — nobody who doesn’t have write access to the field can check items either.

​
Control who can define the checklist structure

Adding, removing, or editing items is a separate concern from checking them, and is typically tied to a workflow status — for example, allowing structure edits only while a work item is in draft, then locking the definition once it moves further along. Configure this with the adminPermission configuration property:
Accepted values:

​
Example: DoR / DoD checklists with different rules

Configuration Properties screen showing adminPermission entries
With the example above, once a userstory leaves status draft, there is no UI control to add, delete, or edit items in the dor checklist — but users can still mark existing items as checked (that’s governed separately, see above).
Checklist with structure editing controls hidden outside of draft status
Version 25.7.0 also locks the Clear actionStarting with version 25.7.0, regular users without admin permission on the applicable condition can no longer clear the checklist structure either — the Clear button is no longer available under the gear menu icon for them.
Gear menu with Clear option unavailable to non-admin users

​
How the system picks which property applies

adminPermission supports type, field, and status specificity at once. When resolving the effective value for a given type, checklist ID, and status, the system evaluates keys from most specific to least specific and uses the first one that is set:
Diagram of adminPermission resolution order, from most specific (type, checklist, status) to least specific (checklist only)
Full evaluation order, for example when resolving type userstory, checklist dod, status accepted:
  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
Set the property at the right level or it silently falls throughBecause the system walks this precedence list and stops at the first match, a narrowly-scoped property you expect to apply can be silently skipped if a broader property higher in this list is also set and happens to be evaluated first for your combination of type/checklist/status. Always check which properties already exist under Administration > Configuration Properties before adding a new one, to avoid two rules unexpectedly conflicting.

​
Freeze structure changes as part of a workflow gate

Combining adminPermission with a specific _STATUS segment is the standard way to freeze a checklist’s definition once a work item passes a review gate — for example, Configure Gate Enforcement (DoD / DoR) and Freeze on Status shows how to pair this with mergeTemplate/mergeTemplateResolved so the checklist both stops re-syncing to its template and stops accepting manual structure edits at the same time.

​
Known limitation: no per-item audit trail

No built-in per-item user/timestamp attributionThe checklist does not currently show, next to each item, which user set its result or added a note, along with a date/time — there is no built-in per-item audit trail.A documented workaround for audit/compliance scenarios: split a single checklist into team-specific checklists (separate custom fields), and use the adminPermission property above to restrict who can change the structure of each one. This at least attributes structural changes to a team/role via the permission configuration, even without built-in per-item timestamps.

​
Verification

You should now see:
  • Users without the configured role (or when adminPermission=@none applies) unable to add, remove, or reorder checklist items, while still able to check existing items (unless the field itself is also read-only).
  • The Clear action absent from the gear menu for non-admin users on version 25.7.0 and later.

​
See also