There are basically two main use cases related to controlling the permission to adjust the content, both are different so we will explain them one by one:
1) Who can mark the items as checked on the checklist?
i.e. perform any changes - including marking checklist items as checked, simply to modify the underlying custom field.
This is controlled by standard Polarion permissions. You can either just use Administration > Work Items > Readonly Fields or you can use field bases permissions Administration > User Management > Permissions Management to mark checklist custom field as read-only.
2) Who can define the checklist structure?
i.e. add/remove the items in the checklist.
This is a different use case, and the common goal is to link this permission with a workflow status. E.g. you can let the user change the "definition of done" checklist when the work item is in status Draft, but later, the list definition should be kept frozen.
To express that you can use Administration > Configuration Properties :
The possible values are:
- or comma-separated list of user roles (including project roles)
For example, let's suppose you have two checklists: dor (Definition of Ready) and dod (Definition of Done). You can put following properties to Administration > Configuration Properties
# 'dod' checklist can be controlled by global admin and project_developer roles
# but when 'userstory' is in status 'verified' the checklist definition cannot be changed at all
# 'dor' checklist cannot be adjusted at all, unless see bellow
# 'dor' checklist can be changed by anyone only when workitem is in status 'draft'
After that, you will be able to see that when userstory is not in status DRAFT, there is no UI control to add new items or to delete or edit the items in Definition of Ready checklist, but the users will be still able to mark items as checked ... see bellow:
Order of evaluation
The system is evaluating the adminPermission key in the following order (e.g. when evaluating type: userstory, checklist: dod, status: accepted)