wtclaude
24a3cd85b3
ENGAGEMENT.md Phase 7. `user_notifications`, the in-app DeliveryChannel, the
four inbox routes, and the web surface — plus the two pieces earlier phases
assigned here that Phase 7's own acceptance line omits.
Four decisions settled by the org lead before any code:
1. `inapp` defaults to `instant` — the only channel that does. Push wakes a
device somebody is holding and email leaves the building, so both are asked
for; an inbox item is a row on a page the user chose to open. Left `off` the
channel ships dead.
2. The phase takes push's `deliver` (§2603) and the web per-channel preferences
screen (Phase 3's as-built), neither of which its own bullets mention.
3. The inbox takes `/auth/me/notifications` and `/account/notifications`; the
preferences screen moves to `…/settings`. The plain word belongs to the
content, which is what the bell opens.
4. `ctx.inbox.push` honours the user's in-app preference when `triggerId` names
a registered trigger, and writes when it does not.
Server
- `user_notifications` + `model/userNotifications/`. The dedupe UNIQUE is scoped
to the USER, narrower than the outbox's `(rule, user, channel)`: an inbox has
no channel dimension, so two rows for one event would be one item shown twice.
- `engagement/inappChannel.js` — renders by block ROLE (first heading → title,
first button → url, the rest → body) and inserts. `pushChannel.js` — a
content-free `{stream, ref}` tickle whose ref deep-links the inbox row.
- `engine.liveChannels` orders `inapp` first (`CHANNEL_ORDER`) so that ref
resolves on the first sweep. An ordering, not a dependency.
- `templates.renderInappByKey` + `resolveTemplate` extracted from `renderByKey`,
so both channels take the same fallback chain.
- `inapp.event` seed → seedVersion 2: it named `body`/`url`, which nothing
supplies. Renamed to the structural vocabulary the projection fills in.
- `utils/userNotificationsPrune.js` — nightly, READ items only, horizon in
`settings.user_notifications_retain_days` (default 90).
- `GET /auth/me/notifications`, `…/unread-count`, `POST …/:id/read`,
`POST …/read-all`. Swagger + route manifest + four component schemas.
Web
- `NotificationBell` in all three headers, polling its badge once a minute and
pausing while the tab is hidden. `PlayerInbox` at `/account/notifications`.
- The preferences screen becomes a channel matrix over
`/auth/me/notifications/channels` — a strict superset of the push-only stream
list it replaces. The two legacy endpoints are untouched, so the shipped
Android app keeps its wire shape.
- Staff get the same two screens at `/admin/notifications…`: `RequirePlayer`
keeps them out of `/account`, so without this the inbox was unreachable for
every non-player account. `lib/notificationPaths.js` is the one mapping.
Verified: 28 new server tests (5 of them against a real MariaDB, for the three
index/statement properties that are a server contract rather than a reading of
this code) + 3 client. Server suite green, client 327 green. A live rig walked
the whole path: two rules on one event produced three outbox rows and exactly
one inbox item, the tickle carried `ref: notification:2`, and the retention
sweep dropped an aged read row while keeping an equally aged unread one.
Docs: RunicGateway/docs#TBD, RunicGateway/runicgateway.com#TBD
Co-Authored-By: Claude <noreply@anthropic.com>
70 lines
3.1 KiB
JavaScript
70 lines
3.1 KiB
JavaScript
import { useEffect, useRef, useState } from 'react'
|
|
import { Link, useParams } from 'react-router-dom'
|
|
import PublicLayout from '../../components/PublicLayout.jsx'
|
|
import PageHeader from '../../components/PageHeader.jsx'
|
|
import { api } from '../../api/client.js'
|
|
|
|
// The landing page for the unsubscribe link in a Team notification email
|
|
// (TEAMS.md §6.4).
|
|
//
|
|
// **Public, and it must be**: the person reading it is in their mail client, not
|
|
// signed in, and an unsubscribe that first demands a login is one most people do
|
|
// not complete. The token in the path is what stands in for the session.
|
|
//
|
|
// **The page POSTs; the link the user clicked was a GET.** A GET must not mutate —
|
|
// mail clients and security scanners follow links in messages, and one that did
|
|
// would silently mute Teams nobody asked to leave. So the link lands here, this
|
|
// runs one POST, and the API route that shares the path answers GET with a
|
|
// redirect to exactly this page.
|
|
//
|
|
// **It says the same thing whatever the token was.** A page that distinguished a
|
|
// valid token from a forged one would be an oracle for which (user, Team) pairs
|
|
// exist, on a surface with no session behind it. The server always answers 200 and
|
|
// this always says the same sentence.
|
|
|
|
export default function Unsubscribe() {
|
|
const { token } = useParams()
|
|
const [state, setState] = useState('working')
|
|
// React 18 StrictMode mounts an effect twice in development. The POST is
|
|
// idempotent (it sets a boolean), so a second call is harmless — but it is
|
|
// still a second request for no reason, and the guard keeps the network panel
|
|
// honest for anyone debugging this page.
|
|
const fired = useRef(false)
|
|
|
|
useEffect(() => {
|
|
if (fired.current) return
|
|
fired.current = true
|
|
api.unsubscribeTeam(token)
|
|
.then(() => setState('done'))
|
|
// A network failure is the ONE case worth distinguishing, because it is the
|
|
// one where trying again helps. A rejected token is not: the server does not
|
|
// tell us, deliberately.
|
|
.catch(() => setState('failed'))
|
|
}, [token])
|
|
|
|
return (
|
|
<PublicLayout section="website" shell="narrow">
|
|
<PageHeader eyebrow="Notifications" title="Unsubscribe" />
|
|
{state === 'working' && <p className="sans dim">One moment…</p>}
|
|
{state === 'done' && (
|
|
<>
|
|
<p className="sans" style={{ color: 'var(--ink)' }}>
|
|
You will not receive further notification emails about this team.
|
|
</p>
|
|
<p className="sans dim" style={{ fontSize: '0.9rem' }}>
|
|
This muted the team rather than switching off your account’s email, so your other
|
|
teams are unaffected. You can turn it back on any time under{' '}
|
|
<Link to="/account/notifications/settings">notification settings</Link>.
|
|
</p>
|
|
</>
|
|
)}
|
|
{state === 'failed' && (
|
|
<p className="sans" style={{ color: 'var(--ink)' }}>
|
|
We could not reach the site to record that. Please try the link again, or change the
|
|
setting yourself under <Link to="/account/notifications/settings">notification settings</Link>.
|
|
</p>
|
|
)}
|
|
</PublicLayout>
|
|
)
|
|
}
|