Blue Sky Thinking

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

• 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.
• 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:
  • PHP 8: the language features we can't use — a 101 on what 8.0/8.1 actually added, with before/after drawn from real FreeITSM code, and an honest list of the ones that wouldn't help us.
  • PHP enums and the RBAC capability system — the one feature the whole argument turns on, and the reason a capability is a Cap:: constant and never a string. Worth reading even if the floor never moves.

---

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