Every team has a definition of done. Without a Redmine checklist plugin enforcing those steps, developers close issues when they believe the work is finished not when every required step is complete. A bug fix may ship before its test case is updated. A feature may close before QA sign-off arrives.
In practice, project managers discover missed steps during review cycles, release preparation, or client handoffs. By then, the cost of correction is higher than it would have been at the point of closure.
The Redmineflux Checklist Plugin adds enforced completion steps directly to Redmine issues. Before an issue can close, every checklist item must be ticked. Teams configure steps per issue type, per project, or per individual issue. Nothing ships without the right checks completed.
The short answer: Redmine has no built-in checklist feature. Issues can have subtasks and custom fields, but there is no per-issue step list with enforced completion. The Redmineflux Checklist Plugin adds configurable checklists to any Redmine issue type mandatory steps that must all be ticked before the issue status can move to closed. Teams use it to enforce definition of done, QA sign-off, and deployment verification.
Some teams approximate checklists using subtasks or custom fields in Redmine. Subtasks require creating separate issues per step, which clutters the issue list. Custom fields can represent a boolean “done” state but cannot enforce sequence or require all fields to be completed before closure. Neither approach scales to team-wide standard processes.
The Redmineflux Checklist Plugin adds native checklist functionality to Redmine issues. Checklists are lightweight, configurable, and enforceable.
Any Redmine issue can have a checklist. The developer or project manager adds checklist items directly to the issue as a simple list of steps to complete before the issue is done. Items are ticked as work progresses. The issue cannot be closed until all items are checked.
In practice, this pattern works for one-off requirements that do not fit a standard template edge-case deployments, ad-hoc client requests, or non-standard bug fixes that need specific verification steps.
The plugin supports checklist templates assigned to issue types. Every bug issue in a project automatically gets the standard bug fix checklist. Every feature issue gets the feature delivery checklist. Templates are defined once at the project level and applied automatically when a new issue of that type is created.
Example template for a bug fix issue:
As a result, every developer closing a bug issue works through the same checklist. Steps are not optional they are visible, trackable, and enforced.
When all checklist items are ticked, the issue can be closed normally. When one or more items remain unchecked and a developer attempts to set the status to Closed, Redmine blocks the transition and shows which checklist items are incomplete.
Specifically, this enforcement happens at the issue level it does not require a separate workflow tool, a separate QA system, or a manual code review gate. The checklist is inside the issue, and the enforcement is inside Redmine.
Checklist completion status is visible on Agile Board cards. A card with an incomplete checklist shows a progress indicator how many items are ticked out of the total. Project managers reviewing the sprint board can see at a glance which issues have outstanding completion steps without opening each issue individually.
The plugin records every checklist tick in the issue history with a timestamp and the user who confirmed it. For issues requiring sign-off from a specific role QA approval, tech lead review, security sign-off the audit trail shows who confirmed each step and when.
This is particularly useful for compliance-sensitive teams where delivery sign-off needs to be traceable.
In practice, Scrum teams running sprints with the Agile Board Plugin use the Checklist Plugin to enforce the definition of done at the issue level. The sprint board shows checklist completion per card. The sprint cannot be closed cleanly until every issue’s checklist is complete.
As a result, this removes the subjective judgement call from sprint closure “done” means the checklist is complete, not “done” means the developer felt finished.
Similarly, QA teams use checklists to enforce testing steps before an issue moves to Resolved. The QA checklist template for a feature issue includes: test case executed, test result recorded, regression suite updated, UAT completed, and sign-off note added. The issue cannot move to Resolved until the QA engineer has confirmed each step.
Combined with the Testcase Management Plugin, this creates a complete QA gate: test cases are managed in the test management system, and the checklist enforces that all testing steps were completed before the issue is closed.
Additionally, operations teams use checklists on deployment issues to enforce pre- and post-deployment verification. A deployment issue checklist might include: backup confirmed, staging deployment validated, stakeholder approval received, production deployment executed, smoke test passed, monitoring alert configured. The deployment issue cannot be closed until every step is confirmed.
No. Redmine has no built-in checklist for issues. The Redmineflux Checklist Plugin adds configurable per-issue checklists and template checklists by issue type. Checklist completion is enforced issues cannot be closed until all items are ticked.
Yes. The Checklist Plugin supports templates assigned to issue types at the project level. Every new issue of that type is created with the standard checklist pre-populated. Templates are defined once and applied automatically.
Yes. The Checklist Plugin enforces completion when one or more checklist items remain unchecked and a developer attempts to close the issue, Redmine blocks the status transition and shows which items are incomplete.
Yes. The Checklist Plugin integrates with the Agile Board Plugin. Cards on the sprint board show a checklist progress indicator the count of completed items out of total items without needing to open each issue.
The Redmineflux Checklist Plugin supports Redmine 5.0.x, 5.1.x, and 6.0.x. Teams running Redmine 4.x should contact support before purchasing to confirm compatibility.
In short, a team’s definition of done is only as strong as its enforcement. When checklist steps are documented but not enforced, the documentation becomes a reminder that gets skipped under deadline pressure. Consequently, the Checklist Plugin moves completion standards from documentation into the issue itself where they cannot be skipped, and where every skip is visible.
