Skip to main content
Reference for the checklist data model classes returned by, and passed to, the checklist service API.
Checklist contains many ChecklistItem entries; each item's result links to a CheckItemResult value

Checklist

Represents a checklist instance: an ordered collection of ChecklistItem entries, providing counting, merging, summary text, and export/reset behaviors.
Information items are excluded from all statisticsAny item with an INFORMATION result is excluded from every counting method (getCheckedCount, getMandatoryCount, isAllChecked, etc.) because they are drawn from getActiveItems(), not getItems(). This explains why an informational row does not affect the completion count shown in the checklist form extension.
Known limitation — getCheckedMandatoryCount is buggy/undocumentedgetCheckedMandatoryCount() is flagged internally as buggy and undocumented. Do not rely on it for accurate counts in custom scripting or reporting; use getMandatoryCount() and getUncheckedMandatoryCount() together (mandatory total minus unchecked-mandatory) if a checked-mandatory count is needed.

summaryMessageFormat placeholder tokens

The message-format template passed to the Checklist constructor supports these placeholder tokens:
Verify in applicationThe exact message-format syntax (e.g. positional {0}-style placeholders vs named tokens) is not shown in the gathered context — confirm the literal template syntax in the application before authoring a custom summaryMessageFormat.

mergeItemIn — template re-sync behavior

Merging happens on every parse: the checklist is seeded from the template first (each item’s label, mandatory flag, and description come from the template), and then the stored field content is merged in, carrying over only the result of each matching item (matched by id). The practical consequence is that the template stays authoritative — label, mandatory flag, and description always refresh from the current template on re-parse, while a reviewer’s recorded result is preserved.
Template changes propagate to existing itemsIf a template’s mandatory flag, label, or description changes after items already exist on an object’s checklist, those changes do reach the existing items the next time the checklist is parsed — only the item’s result is kept from the stored content. (In the source, the commented-out line //existing.mandatory = item.mandatory sits in the stored → template direction, so disabling it is what makes the template’s mandatory flag win, not the object’s.)

ChecklistItem

Represents a single item (row) in a checklist: its label, result state, mandatory flag, description/note text, and template origin.
Known limitation — setChecked(boolean) ignores its parameterSource-level evidence confirms setChecked always sets the result to CHECKED regardless of the boolean value passed. There is no “uncheck a single item” behavior via this method — passing false still checks the item. To uncheck items, use Checklist.uncheckAll() or set the result explicitly via setResult(CheckItemResult.NONE).

Note vs. description

Assigning a note to a checklist item
The Reply icon is used to add a note to an item, provided the checklist is editable:
Using the Reply icon to add a note

CheckItemResult

An enum representing the possible result states of a ChecklistItem.
UI-facing state names vs. enum constantsCheckItemResult has five constants: NONE, CHECKED, REJECTED, CONDITIONAL, INFORMATION (confirmed directly from CheckItemResult.java). Other product material describes five UI-facing result states (OK, NOK, N/A, Pending, Empty) — a plausible reading is Checked→OK, Rejected→NOK, None→N/A/Empty, Conditional→Pending, but this exact UI-label-to-enum-constant mapping is not spelled out verbatim in any single source and should be confirmed in the running application before publishing it as authoritative end-user terminology.

Underlying text storage format

Checklist state is persisted as plain text in the underlying custom field (not as structured JSON), using this line-based syntax (confirmed directly from Checklist.toText()/ChecklistService.parseLine()):
  • Each item line starts with its result character in square brackets — [X], [O], [+], [i], or [_] for CHECKED, REJECTED, CONDITIONAL, INFORMATION, or NONE respectively.
  • An optional ! immediately follows the closing bracket (before the tab) to mark the item mandatory — for example [X]!, not a trailing ! at the end of the line.
  • A tab separates the bracketed result/mandatory marker from the item label text.
  • A leading / (on its own line, indented under the item) marks a description line.
  • A leading > (on its own line, indented under the item) marks a note line.
Not structured dataBecause checklist state is plain text in a rich-text/text field, any external tool reading the field directly (rather than through IChecklistService.parse) must replicate this exact syntax, including the brackets around the result character, the mandatory marker’s position immediately after the bracket (not at the end of the line), and the tab separator.

See also

KB Articles
  • IChecklistService API Documentation
  • Checklist workflow functions and conditions
  • Assign notes to checklist items
Support TicketsSource Code
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistFormExtension.java
  • 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/CheckItemResult.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/internal/ChecklistService.java
  • proc-checklist-src/com.nextedy.polarion.checklist/src/com/nextedy/polarion/checklist/IChecklistService.java
Last modified on August 31, 2026