Export Checklists and Surface Progress in Reports

Render a checklist on a report page

Checklist form extensions live on the object’s own page (work item, document, test run, plan), but you can also render a read-only view of a checklist inside a LiveReport — for example a shared test run report or a plan report — using a script block.

Open the report you want to customize and click Customize Report Page.
If the report is shared between an object and its template (for example a test run and its test run template), select Customize Shared Report so you only configure it once. Otherwise repeat this procedure for each object individually.
Drag a Script Block Widget onto the report where you want the checklist to appear.
Add the rendering call for the object type you’re reporting on: For a test run:
$checklistService.getChecklistView().testRun($testRun).checklist("testDone").render()
For a plan:
$checklistService.getChecklistView().plan($plan).checklist("planDone").render()
The string passed to .checklist(...) (testDone, planDone, etc.) is the ID of the custom field holding that checklist — substitute your own field ID.
Save the report.

You should now see the checklist rendered on the report page, reflecting the live result state of each checklist item.

Reuse the same field ID across templatesBecause the script block references the checklist by custom field ID, once you’ve wired a shared report template to a field ID, every test run or plan created from that template automatically shows the same checklist on its report — no per-object reconfiguration needed.

What the checklist tracks internally

Each checklist item carries a result state (Empty, OK, NOK, Pending), and the checklist as a whole exposes aggregate counts that a summary field can surface — for example the number of checked items and the number of rejected items. Items using the Information type (see Using Information-type items for static context) are excluded from these counts, so an informational row in your checklist will not affect the progress totals shown in the summary. This is distinct from the Empty result state, which is a normal, countable state for an active item that simply hasn’t been set yet.

Checklist progress data flow: the checklist aggregates active items into progress counters, which feed both a summary field on the object form and a LiveReport script block

Exporting to PDF or Word

A confirmed configuration property, nextedy.checklist._TYPEID_._FIELDID_.hideInPdf (boolean, default false), suppresses a specific checklist custom field on a specific work item/document type when the containing document or work item is exported to PDF — see Property Hierarchy and Precedence Reference for the full property definition. Set it to true for the checklist field(s) you want hidden from PDF output. Separately, the baseline-listing view (see Track and Compare Checklist Baselines) has its own, distinct hideInPdf flag. Based on the gathered code context, that widget’s render logic does not appear to branch on the flag, so the baselines list may still appear in PDF exports even when it is set. Beyond these two confirmed flags, this documentation set does not have a full list of Velocity/scripting methods for controlling checklist appearance in exported documents.

Baselines-widget hideInPdf is unconfirmed; the checklist-field property is notA support ticket reports a user who could only discover a hideInPdf()-style flag by trial and error — that experience relates to the baseline-listing widget specifically. The general nextedy.checklist._TYPEID_._FIELDID_.hideInPdf configuration property for the checklist field itself is documented in the Property Hierarchy and Precedence Reference and is not subject to that same trial-and-error caveat.

Verify in applicationBeyond the confirmed hideInPdf configuration property, this documentation set does not have a full list of Velocity/scripting methods for controlling checklist appearance in exported documents. Confirm any additional export-formatting needs directly in your project.

Surfacing checklist status outside the object

Customers evaluating Checklist frequently ask for a way to see checklist completion status — counts of OK/NOK/Pending items, or an all-checked/mandatory-checked flag — in a tabular or dashboard view, without opening each work item individually. What is confirmed:

A checklist’s aggregate state (checked count, rejected count, and whether all items or all mandatory items are checked) is computed by the checklist itself and can be reflected in a summary field on the object’s own form. Once configured, the summary field is a normal custom field, so it can be added as a column in a work item query/table and shown across many objects at once — see Summary Field Reference for the full setup.
That per-object rendering can also be placed on a LiveReport page via the script block shown above, for one object at a time (or one shared template report reused across a set of objects created from that template).

What is not confirmed:

A native LiveReport table-field integration for live, per-item checked-state (as opposed to the static _summary field text) — for example, rendering a dynamic 1/7 completed progress format directly as a table column without scripting. The confirmed approach for this is Velocity scripting against $checklistService.parse(), not a plain table column. See IChecklistService and Velocity Rendering API.
Whether the summary counter shown at the top of the checklist form extension itself (distinct from the _summary custom field) can be surfaced via reporting, columns, or export — this is not confirmed to be supported based on available evidence.

Summary field enables cross-object reporting; live per-item scripting has no table-column shortcutSupport history shows a request for checklist item counts and status to appear in a report or table across many objects at once, without opening each one. The summary field is the confirmed mechanism for this — it is a normal custom field usable as a column like any other. A separate, unresolved request asks for live per-item progress in a LiveReport table without scripting; no confirmed built-in mechanism exists for that narrower case.

Common pitfalls

Wrong field ID in the script blockThe .checklist("testDone") / .checklist("planDone") argument must exactly match the custom field ID that holds your checklist. A mismatched ID will not render the intended checklist — double-check the field ID in Administration before troubleshooting further.

Report not shared, changes don’t propagateIf you configure the script block on an individual test run or plan report instead of the shared report template, new test runs/plans created later from the same template will not automatically show the checklist. Prefer Customize Shared Report whenever the report can be shared with its template.

Verification

You should now see the rendered checklist appear on your report page with the current result state of each item, and — where you’ve built a summary field for the object — a progress summary (checked and rejected counts) reflecting the same underlying data.

​Render a checklist on a report page

​What the checklist tracks internally

​Exporting to PDF or Word

​Surfacing checklist status outside the object

​Common pitfalls

​Verification

​See also

Render a checklist on a report page

What the checklist tracks internally

Exporting to PDF or Word

Surfacing checklist status outside the object

Common pitfalls

Verification

See also