Module Availability Design

Module availability — design (#217)

The request, what the first slice built, and what comes next. Users: Switching modules off. Developers: Module availability — developer guide.

---

The request

#217 (Dr4inder) asked for an installation-wide way to make unused modules and features completely inactive — not just hidden from the menu or from some analysts, but gone from cross-module UI, refused by direct URLs and the APIs, honoured by background jobs and workflows — while keeping every record and relationship, and changing nothing on upgrade.

It named two kinds of thing:

• Whole modules — Calendar, Morning Checks, War Room, LMS…
• Features inside Tickets — CSAT, SLA, time tracking, the duty rota.

The decision: two slices

The two kinds are different problems. A whole module already has one gate that nearly everything asks (analystCanAccessModule()), so switching it off is mostly about finding the places that don't ask. A feature inside Tickets has no such gate, and some of them (SLA especially) raise real questions about state — what happens to a clock that was running? — that need deciding first.

So slice 1 is whole modules, done thoroughly. Slice 2 is the Tickets features, one at a time.

Built by the maintainer rather than contributed, because slice 1 is mostly a sweep of the existing codebase. The design below is written so it can be reviewed, and so slice 2 can be contributed against it.

---

Slice 1 — whole modules (built)

Decisions

Question	Decision	Why
Where	System → Modules → Availability, above the access grants	Beside the access settings it must not be confused with, with the difference stated on the page
What is stored	The modules that are off (system_settings.modules_disabled)	Upgrades, DB Verify, fresh installs and new modules all mean "on" with nothing seeded — the request's "upgrades should preserve existing behaviour" held by construction
Who it applies to	Everyone, administrators included	"Off" that an administrator can still use is "hidden", which the request explicitly isn't asking for
Always on	Tickets and System	Tickets is the hub; System holds the switch
If the setting can't be read	Everything on (fails open)	It is a tidiness control, not a security one; grants and is_admin still guard access
Data	Never touched	Records, settings and grants stay; switching back on restores everything
Queued and scheduled work	Skipped, not saved up — except queued webhook deliveries, which wait	The request: re-enabling "should not unexpectedly send a backlog"
The refusal	"Tasks is switched off for this installation.", module_disabled in JSON and the REST API	The request: "an explicit disabled-feature response rather than a misleading empty result"

The request's acceptance criteria, against slice 1

#	Criterion	Slice 1
1	Deactivate and reactivate independently	✅ one switch per module
2	Gone from cross-module UI; refused by direct URL and API	✅ pages, ~700 endpoint gates, REST API, ticket pane, other modules' screens, portal, device agents, public test links
3	Jobs and automation honour it, with a clear disabled result	✅ cron jobs skip and record why; job health doesn't call them overdue; workflow triggers don't fire; actions are skipped with the reason; Test fire is aborted with the reason
4	Dependencies explained before deactivation	⚠️ partly — the confirmation says what disappears, and the two real dependencies are handled (a checklist-required close rule can't trap tickets; Knowledge off stops the AI answers). A "what depends on this?" preview is slice 3
5	History kept, new references prevented	✅ nothing deleted; links, pickers and writes refused
6	Re-enabling, integrations and upgrade predictable	✅ documented on Switching modules off
7	Verification beyond the menu	✅ a guard test (every REST resource and trigger has a module) and a 20-check end-to-end run: page, endpoint, REST, home page, ticket pane, access checker, Test fire, off and back on

Judgement calls worth reviewing

• Projects with Tasks off keep their plans. Every plan row is a task row, and the plan, timeline, capacity, progress, RAID actions, the AI assistant and labour cost are all built on them, so hiding them would gut Projects. Decided: switching Tasks off removes the Tasks module (the board, standalone tasks, tasks on other records), not the task rows Projects uses. Only the routes into Tasks, and the RAID actions that create tasks, are removed. A toggle was considered and rejected - each Projects screen would need its own "what instead?" answer.
• Not granted vs switched off. Some screens deliberately work without the target module's grant (Problems linking a change, Assets' Software tab, an LMS author picking a KB article). Those check availability only, so who can do what is unchanged and only switched off hides them.
• Existing workflows on a switched-off module still open and save in the editor; they just don't run. Refusing to open them would hide what they were.
• A ticket's Schedule is part of Tickets, not the Calendar module, and keeps working with Calendar off.

---

Slice 2 — features inside Tickets (built)

CSAT, SLA, Time tracking and the Duty rota each have a switch under Ticket features. The decisions, all with a default that changes nothing until someone switches a feature off:

Question	Decision
An old CSAT survey link	"We're no longer collecting feedback", nothing recorded
A digit replied in chat to an old rating request	An ordinary message
Time tracking's per-company screen and API settings	The install-wide switch overrides both; the REST API says module_disabled instead of 404
SLA off for a week, then back on	Asked at the moment of switching on: send what was missed, or skip it (recorded as announced, nothing sent)
Does the off period count on the clock?	Yes — the clocks are worked out from history, so the time shown stays true
Web chat's opening hours use SLA calendars	The calendars stay editable while SLA is off
Projects capacity counts rota shifts	Not while the rota is off
The War Room bot's who is on call	Dropped from its tools while the rota is off

What was made a choice, and what wasn't. Only the SLA catch-up is a choice, and it is a one-off question when switching back on rather than a standing setting: whether a team wants a week of missed breach notices is a decision about that week. The rest have one obvious answer, or an alternative that would need state FreeITSM doesn't keep (counting the off week as paused would mean storing the switch history and changing the SLA maths). Not built because nothing needed it: no queue, so no backlog, for CSAT, time tracking or the rota.

Found on the way, not changed: SLA bell notifications only appear when an sla.* workflow is active; three SLA settings (priority change, reopen, first-response definition) and CSAT's send after X minutes are saved but never read.

Was: the plan for slice 2

Each is its own decision, reusing the switch it already has where there is one:

Feature	Existing control	Open questions
CSAT	Off mode already exists	What do outstanding survey links answer?
Time tracking	UI and API settings already separate	Hide recording everywhere; refuse POST /tickets/{id}/time-entries
Duty rota	—	Rota-based assignment while off?
SLA	—	Clocks that were running; breaches during the off period; re-enabling without a burst of breach notices

Contributions welcome — one feature per pull request, against this page.

Slice 3 — "what depends on this?"

Before switching off, list what will stop: active workflows on its triggers or actions, scheduled jobs, portal pages, linked records (counts, not contents), and any rule that requires it (for example a checklist-required close rule).

---

See also: Switching modules off · Module availability — developer guide · Module Access Control