Blue Sky Thinking - edmozley/freeitsm GitHub Wiki

Blue sky thinking

A holding area for ideas that have been explored and written up, but are not committed to being built.

Everything here has had real thought put into it — enough to understand the shape, the upside, and the catch. What lands a page in this section rather than on a roadmap is that the honest answer to "should we build this?" is currently "not yet, maybe never" — usually for one of:

  • Risk management — the feature opens a security or data‑integrity hole serious enough that it only ships if mitigated to a very high standard (and might reasonably never clear that bar).
  • Complexity vs reward — the payoff is real but modest, and the cost/maintenance/edge‑cases outweigh it for now.
  • Uncertain demand — a neat idea looking for enough of a need to justify it.

Being here is not a rejection. These pages exist so the thinking isn't lost: if an idea is revived later, the analysis (and the reasons for caution) are already on record rather than re‑derived from scratch. Equally, an idea staying parked indefinitely is a perfectly acceptable outcome.

Parked ideas

  • CalDAV and CardDAV — syncing calendars and, more interestingly, contacts with an open standard rather than one vendor's API. Raised in #133. Two requests of very different sizes: CalDAV is partly served already, since the iCalendar subscription feed is the read-only half of it and FreeITSM already has a two-way route in the Graph push — so its real argument is vendor independence, not capability. CardDAV is the stronger idea, because underneath the protocol it is a complaint that the people in FreeITSM are an island that has to be typed in twice and then drifts. The page's most useful finding is that most of the machinery already exists: users already records where a person came from and whether the record is managed elsewhere, and directory sync already enforces three expensive rules (nobody is ever deleted, a run that looks wrong changes nothing, missing once is noise) that any source would need identically. The catch, stated so nobody under-prices it: CardDAV is not "a third flavour" — every extension point in directory sync assumes LDAP is the transport, so it needs a new fetch-and-map layer and its own test fixture. Parked on uncertain demand (one site, already running a DAV server) and on the two-way half being a permanent maintenance commitment whose failure mode — silently overwriting a corrected phone number — is worse than not having it. 🔑 The page also isolates a prerequisite nobody had noticed: the self-service portal lets a requester change their password, theme and preferred name and nothing else, so the GDPR Article 16 self-correction the whole request rests on does not exist yet locally. That piece is small, useful on its own, and is what should be built first if any of this ever is.
  • CRM and a real service catalogue — the customer side of the data model is a stub: FreeITSM records a supplier contact's switchboard number and a customer contact's theme preference, and tenants has six columns against suppliers' nineteen. There are also already three unrelated ideas of "a service" (CMDB objects, the status page's list, portal forms), so a catalogue's first job is reconciling those rather than becoming a fourth. The two genuinely valuable pieces — cost-to-serve from time already logged, and renewal warning from contracts pointed the other way — need no CRM at all. Parked because the unanswered question (is an account a tenant, or something below it?) changes the schema rather than the UI, and a half-built CRM is not a partly-useful CRM — it is a second place to look that is always slightly out of date.
  • Full-text search across tickets and attachments — searching inside ticket bodies, notes and attached documents rather than only their subjects and references. Raised in #53. The governing insight: extraction is the hard half and indexing is not — MySQL already does full‑text natively, while turning a PDF into text is the genuinely difficult part, so the useful integration is a document parser, not a search engine. The page covers what phase 1 would be, the security rule that the query must carry the permission controls rather than the results being filtered afterwards (post‑filtering starves results and fails worst for portal users, who can see least), the settings path for very large installs, and — the part most worth keeping — the ideas ruled out and why: vectors as the foundation, an external search engine as the starting point, and any hard PDF dependency. Parked because the shape is settled but the scope isn't: whether history gets backfilled, and whether portal users get content search at all, both change what gets built.
  • Consolidating groups of people — FreeITSM has three reusable groups of people (teams, LMS learning groups, people groups) and no two features agree on which they accept: you cannot assign a course to a team, and you cannot give a knowledge folder to a learning group, while everything else in the product routes through teams. The page's main job is to argue against the obvious fix. A team is not a group with extra fields — it carries module access, RBAC roles, department visibility and tenant reach, so merging it into a generic groups table either lets every group hold capabilities or reintroduces the same distinction as an unvalidated column. And folding learning groups into people groups is a privilege expansion wearing a schema change's clothes: every existing learning group would appear in the Knowledge permission picker overnight, with nothing announcing it. What is proposed instead is to converge the consumers, not the tables — one small, additive, schema-free change to let the LMS accept a team — and deliberately not the mirror-image change, because widening learning groups entrenches the one grouping that should be allowed to wither. Honest catches on the page: convergence makes the vocabulary wider, a shared principal resolver pays less than it looks (Knowledge only asks the forward question; the LMS asks both), withering has no end date, and nobody has asked for any of it. Includes a separate, near-free suggestion: three unrelated things are called department, and the labels could stop pretending otherwise.
  • Portal managers: ideas not yet built - eight smaller ideas noticed while building portal managers: an audit history of management lines; requester notifications so everyone gets the portal bell; telling a sender their ticket went in confidential; read receipts; locking a directory-owned name and email; a hand-set company reverted by sync; announcing web chat, WhatsApp and catalogue tickets like every other; and a Directory Sync page that still describes a screen that was never built. Each with its catch - several are small, none is committed to.
  • Remote Image Archiving — download remote (https://) email images into FreeITSM at import, for archival integrity, anti‑tracking privacy and offline rendering. Genuinely useful, but the naive form is a Server‑Side Request Forgery risk (the server fetching attacker‑supplied URLs from inside the firewall). Ships only with a fully hardened safe‑fetch helper — may never.
  • Content Security Policy hardening — making FreeITSM run under a strict CSP (no inline script). A legitimate defence‑in‑depth goal, but the app (like most server‑rendered PHP) relies on ~1,300 inline handlers and 159 inline script blocks, so full strict‑CSP is a large, phased, per‑module refactor — not a bug fix. A working 'unsafe-inline' policy is documented for today. Raised in #43.
  • Raising the PHP floor to 8.1 — dropping PHP 7.4/8.0 support to unlock enums, which are precisely the right shape for the RBAC capability system (~70 capabilities and a couple of hundred guard calls once the roll‑out lands). Parked because the argument turned out to have a hole in it: class constants close the dangerous failure mode without leaving 7.4, so what's left is elegance, not safety — and that doesn't justify breaking every 7.4 user's upgrade path. We build on constants, shaped so the enum swap is later a find‑and‑replace. Revisit triggers are on the page. Two companion pages:

New parked ideas get their own page and a line here. Keep each page honest about the catch, not just the upside.