Upcoming Features
Features listed here exist in the codebase in some form — a route, a service, a database table, a dashboard panel — but are intentionally disabled or unimplemented in the current release. They're kept in place, dormant, as a documented starting point rather than deleted outright, in case the underlying idea is revisited with a design that addresses why it was held back.
Proof of notice
POST /notice-shown and GET /visitors/:visitorId/notice-shownroutes both return 404, the widget never calls either, and the dashboard's Visitor detail panel no longer shows this section.The idea: record that the consent banner was actually rendered to a visitor, independent of whether they ever interacted with it — evidence that a "notice was shown" even to someone who never made a decision.
Why it's held back rather than shipped:
- It requires minting a persistent visitor identifier beforeany consent decision exists, purely to correlate a pre-decision impression ping with later records. That conflicts directly with this project's core design principle: no identifier is created or written to storage until a consent decision actually happens (see UI Configuration).
- No mainstream CMP ships this as a per-visitor tracked feature. Their compliance evidence is decision-scoped — a receipt created when a choice is made — not impression-scoped.
- It isn't required by GDPR. The actual evidentiary obligation (Art. 7(1)) is to demonstrate that consent was given, when it was given — not that notice was passively displayed to someone who never decided.
- In practice, regulators verify banner behavior by testing the live site themselves (fresh browser, inspect the network tab) rather than relying on a site's own impression logs — so the evidentiary value is low relative to the tracking surface it adds.
What's still in the codebase, dormant: the notice_shown table/collection across all storage adapters, NoticeRepo / NoticeService, both routes (guarded behind a NOTICE_SHOWN_ENABLED flag hardcoded to false), and the dashboard's visitorsApi.noticeShown() client call. See the Admin Routes reference for the disabled endpoint.
If this is revisited, the design that would actually fit the project's principles is an anonymous, aggregate impression counter (banner rendered N times for profile X on date Y) — no per-visitor identifier, no join key back to the Visitor table — rather than a per-visitor log.