Content
View differences
Updated by Rosanna Sibora about 16 hours ago
**Goals**
* Make custom field type "checklist" a structured and reusable part of the work package model.
* Support both simple usage (ad hoc task lists) and complex usage (gating, templates, governance).
* Provide checklist items with richer semantics than simple checked / unchecked state, including item-level metadata and progress indicators. Enable item-level semantics: checked / unchecked, status, assignee, priority, due date, and description per checklist item.
* Enable workflow-level enforcement where checklist completion can block status transitions.
* Enable checklist templates.
**1\. Core Checklist Model (Custom Field: Checklist)**
Introduce a new custom field type "Checklist" that can be added to work package types. Each checklist instance is composed of ordered checklist items. Each item supports:
* Title / short label
* Extended description / notes
* Status (at minimum: Open, In Progress, Done, Blocked, Skipped - not just binary checked/unchecked)
* Open question: should it be possible for global admins to define the workflow?
* Assignee (single user)
* Priority (e.g., Low, Normal, High, Critical)
* Due date
* To be verified: Mandatory flag (item must be completed before certain transitions are allowed)
The checklist as a whole displays a progress indicator (e.g., "5 / 12 items done") visible from the work package detail view and optionally from wp table / board / backlog views.
**2\. Structured Editing and Management**
* Add, edit, delete, and reorder checklist items inline within the work package
* Drag-and-drop reordering
* Group items into named sections or categories within a single checklist
* Bulk status update across multiple items
* Bulk assignment or due date assignment
* Collapse/expand sections or the full checklist
**3\. Checklist Templates**
* Define reusable checklist templates
* Open question: at the project or global (instance) level?
* Idea to be verified: Administrators can manage templates centrally; project managers can define project-level templates
* A template contains a predefined set of items with optional default values (status, priority, assignee role, description)
* Templates can be applied to a work package at creation time or manually at any point
* Applying a template appends or replaces the current checklist (with user confirmation)
* Open question: or adding the items additionally? Tendency: allow users to decide.
* Templates are editable; changes to a template do not retroactively affect already-applied checklists (unless explicitly propagated)
* Open question: expected behavior to be verified.
**4\. Workflow Enforcement / Gating**
* Work package status transitions can be configured to require that all mandatory checklist items are completed before the transition is permitted
* This applies to configured transitions in the workflow settings (e.g., cannot move to "In Development" unless all DoR items are checked)
* A clear visual indicator informs the user which mandatory items are blocking the transition
* Enforcement is optional and configured per work package type and per transition
**5\. Conversion of Checklist Items to Work Packages**
* Any checklist item can be promoted / converted into a standalone work package or child work package
* Upon conversion, the item's title, description, assignee, due date, and priority are pre-populated in the new work package
* A reference link is maintained between the original checklist item and the resulting work package
* Converted items display their linked work package status inline in the checklist
**6\. Visibility and Progress Reporting**
* Checklist progress (items done / total items) is visible in the work package detail view header area
* Progress is optionally surfaced in work package list views as a column, e.g. as a bar chart
* Open question / idea: show in the column also percentage delivered or number of times checked / unchecked
* Filtering and grouping by checklist completion state is supported (e.g., "show all work packages with incomplete mandatory checklist items")
* Activity log records checklist changes (item added, status changed, assignee changed, etc.)
**7\. Multiple checklists per work package**
* Multiple named checklists can coexist on a single work package (e.g., one for DoR, one for DoD)
* Each named checklist can independently have its own template source and gating rules
**8\. Prerequisite and Dependency Tracking via Checklists**
* Checklist items can reference other work packages as prerequisites
* A checklist item can be linked to another work package (as a soft dependency or required input)
* Status of linked work packages is optionally reflected in the checklist item status
**Acceptance Criteria**
* A "Checklist" custom field type exists and can be added to any work package type
* Checklist items support at minimum: title, status (multi-value), assignee, due date, priority, mandatory flag
* At least one checklist template can be defined globally and applied to a work package
* A configured workflow transition can be blocked until all mandatory items in a designated checklist are marked done
* Any checklist item can be converted into a linked work package
* Checklist progress is visible in work package detail view, in list view and in the backlog view
* Multiple named checklists (e.g., DoR + DoD) can coexist on a single work package
* Make custom field type "checklist" a structured and reusable part of the work package model.
* Support both simple usage (ad hoc task lists) and complex usage (gating, templates, governance).
* Provide checklist items with richer semantics than simple checked / unchecked state, including item-level metadata and progress indicators. Enable item-level semantics: checked / unchecked, status, assignee, priority, due date, and description per checklist item.
* Enable workflow-level enforcement where checklist completion can block status transitions.
* Enable checklist templates.
**1\. Core Checklist Model (Custom Field: Checklist)**
Introduce a new custom field type "Checklist" that can be added to work package types. Each checklist instance is composed of ordered checklist items. Each item supports:
* Title / short label
* Extended description / notes
* Status (at minimum: Open, In Progress, Done, Blocked, Skipped - not just binary checked/unchecked)
* Open question: should it be possible for global admins to define the workflow?
* Assignee (single user)
* Priority (e.g., Low, Normal, High, Critical)
* Due date
* To be verified: Mandatory flag (item must be completed before certain transitions are allowed)
The checklist as a whole displays a progress indicator (e.g., "5 / 12 items done") visible from the work package detail view and optionally from wp table / board / backlog views.
**2\. Structured Editing and Management**
* Add, edit, delete, and reorder checklist items inline within the work package
* Drag-and-drop reordering
* Group items into named sections or categories within a single checklist
* Bulk status update across multiple items
* Bulk assignment or due date assignment
* Collapse/expand sections or the full checklist
**3\. Checklist Templates**
* Define reusable checklist templates
* Open question: at the project or global (instance) level?
* Idea to be verified: Administrators can manage templates centrally; project managers can define project-level templates
* A template contains a predefined set of items with optional default values (status, priority, assignee role, description)
* Templates can be applied to a work package at creation time or manually at any point
* Applying a template appends or replaces the current checklist (with user confirmation)
* Open question: or adding the items additionally? Tendency: allow users to decide.
* Templates are editable; changes to a template do not retroactively affect already-applied checklists (unless explicitly propagated)
* Open question: expected behavior to be verified.
**4\. Workflow Enforcement / Gating**
* Work package status transitions can be configured to require that all mandatory checklist items are completed before the transition is permitted
* This applies to configured transitions in the workflow settings (e.g., cannot move to "In Development" unless all DoR items are checked)
* A clear visual indicator informs the user which mandatory items are blocking the transition
* Enforcement is optional and configured per work package type and per transition
**5\. Conversion of Checklist Items to Work Packages**
* Any checklist item can be promoted / converted into a standalone work package or child work package
* Upon conversion, the item's title, description, assignee, due date, and priority are pre-populated in the new work package
* A reference link is maintained between the original checklist item and the resulting work package
* Converted items display their linked work package status inline in the checklist
**6\. Visibility and Progress Reporting**
* Checklist progress (items done / total items) is visible in the work package detail view header area
* Progress is optionally surfaced in work package list views as a column, e.g. as a bar chart
* Open question / idea: show in the column also percentage delivered or number of times checked / unchecked
* Filtering and grouping by checklist completion state is supported (e.g., "show all work packages with incomplete mandatory checklist items")
* Activity log records checklist changes (item added, status changed, assignee changed, etc.)
**7\. Multiple checklists per work package**
* Multiple named checklists can coexist on a single work package (e.g., one for DoR, one for DoD)
* Each named checklist can independently have its own template source and gating rules
**8\. Prerequisite and Dependency Tracking via Checklists**
* Checklist items can reference other work packages as prerequisites
* A checklist item can be linked to another work package (as a soft dependency or required input)
* Status of linked work packages is optionally reflected in the checklist item status
**Acceptance Criteria**
* A "Checklist" custom field type exists and can be added to any work package type
* Checklist items support at minimum: title, status (multi-value), assignee, due date, priority, mandatory flag
* At least one checklist template can be defined globally and applied to a work package
* A configured workflow transition can be blocked until all mandatory items in a designated checklist are marked done
* Any checklist item can be converted into a linked work package
* Checklist progress is visible in work package detail view, in list view and in the backlog view
* Multiple named checklists (e.g., DoR + DoD) can coexist on a single work package