V2: show the configured web search and AI notices

[Paul Lizer (paullizer)]

Problem

The classic chat page renders two administrator-configured notices around the composer. V2 rendered neither, so anyone who switched interfaces silently stopped seeing them — including the notice warning that their message is about to leave the tenant.

Instead, V2 ended its composer with a hardcoded line of its own:

AI responses can be inaccurate. Verify important information.

That is not the same thing. It is not the administrator's wording, it cannot be turned off, it cannot be dismissed, and it appeared even for organisations that had deliberately configured different text.

	Legacy (V1)	V2 before	V2 after
Web search notice	✅	❌	✅
AI notice	✅	❌	✅
AI notice disabled	Nothing	Hardcoded line	Nothing

Why it needed a server-side change

Both notices reach the classic page through Jinja template context, which a SPA cannot read — and neither was derivable from what /api/v2/bootstrap already carried:

• The AI notice's hash is a SHA-256 of its message and frequency. It is what invalidates stored dismissals when an administrator edits the wording, and whether the caller's dismissal still applies depends on a stored, server-timestamped record and a date window.
• The web search notice's condition includes web_search_consent_accepted, which does not start with enable_ and so was never forwarded by _build_feature_flags. That is why it could not live in composerGating.ts.

So bootstrap gains a notices block built from the same functions_ai_notice helpers the classic page uses. route_backend_v2.py deliberately does not hash anything itself, and a test asserts that — a second implementation of the hash would let the two interfaces disagree about whether an edited notice should reappear for someone who had dismissed the previous wording.

"notices": {
  "ai": { "enabled": true, "message": "…", "frequency": "every_session", "hash": "<sha256>", "dismissed": false },
  "web_search": { "enabled": true, "text": "…" }
}

Behaviour

The web search notice sits above the input and appears only while the Web toggle is armed — a banner that is always present stops being read, and the thing it warns about only happens when web search is on. Turning web search off hides it without consuming the dismissal.

The AI notice sits below the composer. Where a dismissal is stored depends on how long it has to last:

Frequency	Stored	Why
non_dismissible	—	No dismiss control is rendered
every_session	sessionStorage	A browser-session fact; the server has nothing to add
daily, once	/api/user/settings → aiNoticeDismissal	Must outlive the tab, and the window is evaluated against a server timestamp

The notice hides only after the write lands. Hiding first would tell a user the notice is gone for the day when it may be back on the next load. A failed write raises a toast rather than looking like a dead button.

daily/once go through a dedicated dismissAiNotice() helper rather than the debounced userSettingsStore: that store rolls failures back silently into a preference cache, but the route replaces the posted value with its own timestamped record, so the cached value would never match what was stored.

Session keys are shared with the classic interface (webSearchNoticeDismissed, simplechat.aiNoticeDismissal.<hash>) rather than namespaced the way v2RailCollapsed is. A dismissal is a statement about the person, not about which interface they happened to be looking at; namespacing would make a just-dismissed notice reappear on switching interfaces in the same tab. sessionStorage throws rather than returning null in some privacy modes, so reads fail closed and writes report failure.

⚠️ Behaviour change

The hardcoded "AI responses can be inaccurate. Verify important information." line is removed. When the AI notice is disabled, V2 now shows nothing there, matching the classic interface — an organisation that turned the notice off did so on purpose. To get a line back, enable it under Admin Settings → Notices & Agreements → Chat AI Notice. Flagged in the release notes.

Two bugs caught while building this

• V1 preserves the line breaks an administrator typed (white-space: pre-line); the first pass collapsed them. Fixed, and pinned by a test that reads both sides.
• CUSTOM_AI_NOTICE.md still said the setting lives on the General tab — it moved to Notices & Agreements. Corrected.

Validation

• functional_tests/test_v2_chat_notices.py — 8/8 (new)
• test_ai_notice, test_user_settings_allowlist_keys, test_v2_api_payload_shapes, test_v2_settings_and_workspace_tags, test_v2_settings_tabs, test_v2_api_security, test_v2_ui_local_assets, test_v2_conversation_details_and_gating, test_v2_research_voice, test_docs_app_surface_coverage, test_docs_site_quality, and the admin-settings contract tests — all pass
• npm run build (tsc + vite) clean
• _build_notices verified at runtime, confirming that editing the notice text invalidates existing dismissals and that all three web-search keys are required

Two pre-existing failures are unrelated and untouched: test_chat_template_json_bootstrap_safety.py (a missing window.multiEndpointNotice literal in chats.html) and a Windows console-encoding quirk in test_user_settings_allowlist_keys.py that passes under PYTHONIOENCODING=utf-8.

Notes

• No new settings keys — both capabilities already exist in admin settings and are documented, so docs/_data/app_surface.yml is unchanged.
• No new browser assets — existing lucide-react icons and existing info/info-soft theme tokens, so CSP is untouched.
• Notice text is administrator-entered and rendered as a plain React child, so React escapes it. No dangerouslySetInnerHTML, matching V1's use of textContent/Jinja escaping.
• Version 0.261.027 → 0.261.028.

Docs

• docs/explanation/fixes/V2_CHAT_NOTICES_FIX.md (new)
• docs/explanation/features/REACT_V2_UI.md — new "Notices" section, bootstrap field, test table row
• docs/explanation/features/CUSTOM_AI_NOTICE.md — both interfaces, corrected tab name
• docs/explanation/release_notes.md