Checklist Closure Gating - edmozley/freeitsm GitHub Wiki
Stopping a ticket closing with a checklist outstanding
A checklist that nobody has to finish is a suggestion. From 2.5.0 a checklist can refuse to let a ticket close until its steps are done — and which checklists do that is decided per checklist, by the person who wrote the procedure.
Contributed by Santhosh Srinivasan, from discussion #138.
The two levels
Open a checklist template and pick one:
| Level | What happens when somebody tries to close with steps outstanding |
|---|---|
| Standard | They are warned, may go ahead, and the override is recorded — who did it, and when |
| Critical | The close is refused |
The choice sits with the template, not with the install, because the person writing the procedure is the one who knows whether skipping a step is a judgement call or a serious matter. A new-starter setup checklist and a fire-panel isolation are not the same kind of list, and an install-wide switch would force them to be.
Standard is the default, so nothing you already have starts blocking tickets when you upgrade.
A company-wide floor
Tickets → Settings → Checklists carries two choices for organisations that need more than per-template judgement:
- Follow each checklist (the default), or block every ticket with outstanding steps — an absolute floor that overrides the templates.
- What to do about a ticket with no checklist at all — because "every ticket must have its checklist finished" means nothing if a ticket can simply have none.
What being blocked looks like
A Critical checklist shows a padlock. Attempting to close tells you which steps are outstanding rather than just refusing — the point is to get the work finished, not to win an argument.
Every route to closing a ticket goes through the same gate: the reading pane, the right-click menu, bulk actions and workflows.
See also
- Checklists and SOPs — writing and using them
- Tickets
- What changed at review, and why — for contributors
- Developer guide