@marinoscar/platform-web 0.0.0-stage → 0.1.0-next.4

package/dist/notifications/ui/UserNotificationsPage.d.ts

@@ -0,0 +1,101 @@
+/**
+ * Settings → Notifications (`/settings/notifications`).
+ *
+ * Issue #126, epic #109. The per-user half of the notification framework: a
+ * matrix of event x channel, driven by the server's registry
+ * (`GET /api/notifications/events`) so an event added to
+ * `apps/api/src/notifications/notification-events.ts` later appears here with
+ * NO change to this page — which is epic #109's headline promise that a
+ * notification costs one registry entry.
+ *
+ * THIN, like `UserAppearancePage`: every line of shared page chrome (the
+ * settings fetch, the loading spinner, the fetch-error alert, the
+ * success/failure snackbars) lives in `UserSettingsSection`, and the matrix
+ * itself lives in `components/settings/NotificationSettings.tsx`. What is left
+ * here is the wiring, and one decision — the exact shape of the write.
+ *
+ * =============================================================================
+ * THE WRITE: ONE CHANNEL, ONE EVENT KEY, NOTHING ELSE
+ * =============================================================================
+ *
+ * `onToggle` below is the ONLY place this feature writes preferences, and it
+ * sends a document with exactly one channel and exactly one event key in it:
+ *
+ *     \{ notifications: \{ email: \{ 'user.welcome': false \} \} \}   // store a choice
+ *     \{ notifications: \{ email: \{ 'user.welcome': null  \} \} \}   // DELETE the key
+ *
+ * The API deep-merges the channel object per event key (see
+ * `mergeNotifications` in `UserSettingsService`, and
+ * `notificationsPatchSchema`), so every preference this request does not name
+ * stays exactly as it was — including staying ABSENT, which is the state that
+ * resolves to the registry default.
+ *
+ * There is no other write path. Nothing PATCHes on mount, nothing serialises a
+ * preferences object, and there is no Save button to batch one up: a batched
+ * save needs a full local mirror to diff, and that mirror — defaulted, because
+ * it has to be defaulted to render — is precisely the materialised blob the
+ * sparse contract exists to avoid. See the header of `NotificationSettings.tsx`
+ * for the full argument.
+ *
+ * `value` arriving as `null` is the null-delete, decided by
+ * `preferenceWriteFor` at the control: the user has moved a control BACK to its
+ * registry default, so the right write is to remove their stored opinion rather
+ * than pin today's default into their document forever.
+ *
+ * =============================================================================
+ * WHY TWO LOADING STATES, NESTED
+ * =============================================================================
+ *
+ * This page needs two independent things: the user's settings document (owned
+ * by `UserSettingsSection`) and the event registry (owned by
+ * `useNotificationEvents`). They are separate endpoints and either can fail
+ * alone, so they are reported separately: the outer spinner/alert is the
+ * settings document's, the inner one below is the registry's. Collapsing them
+ * would mean a registry failure renders an empty matrix, which is
+ * indistinguishable from "this application notifies you about nothing".
+ */
+import { type ChannelState } from './NotificationSettings.js';
+import type { PageSlotsBase } from '../../core/index.js';
+/**
+ * Props of {@link UserNotificationsPage}.
+ *
+ * @stability experimental
+ */
+export interface UserNotificationsPageProps {
+    /**
+     * How an app's own channel column behaves, by channel id: disabled with a
+     * terse note and an optional banner above the matrix, as the built-in push
+     * column is (for example "link your Slack account first"). A channel with no
+     * entry is never gated. The built-in browser and push states are derived by
+     * the page; an entry for `push` replaces the built-in one.
+     */
+    channelStates?: Readonly<Record<string, ChannelState>>;
+    /** Optional extension slots (the page-slot contract); omitted, the page renders exactly as it always did. */
+    slots?: UserNotificationsPageSlots;
+}
+/**
+ * The slots of {@link UserNotificationsPage}: the page-slot contract.
+ * `BeforeContent` is where an app puts a banner (a quiet-hours notice); the
+ * channel columns and their labels come from the channel registry and
+ * `channelStates`, not from a slot.
+ *
+ * @example
+ * ```tsx
+ * <UserNotificationsPage slots={{ BeforeContent: () => <Alert severity="info">Quiet hours are 22:00 to 07:00.</Alert> }} />
+ * ```
+ *
+ * @extensionPoint slot
+ * @stability experimental
+ */
+export type UserNotificationsPageSlots = PageSlotsBase;
+/**
+ * The `/settings/notifications` page: the signed-in user's per-channel, per-event preferences and this device's permission state.
+ *
+ * @param props - see {@link UserNotificationsPageProps}.
+ * @returns the page.
+ *
+ * @extensionPoint component
+ * @stability experimental
+ */
+export default function UserNotificationsPage({ channelStates, slots }?: UserNotificationsPageProps): import("react").JSX.Element;
+//# sourceMappingURL=UserNotificationsPage.d.ts.map

package/dist/notifications/ui/UserNotificationsPage.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserNotificationsPage.d.ts","sourceRoot":"","sources":["../../../src/notifications/ui/UserNotificationsPage.tsx"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuDG;AAKH,OAAO,EAAwB,KAAK,YAAY,EAAE,MAAM,2BAA2B,CAAC;AAQpF,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AASzD;;;;GAIG;AACH,MAAM,WAAW,0BAA0B;IACzC;;;;;;OAMG;IACH,aAAa,CAAC,EAAE,QAAQ,CAAC,MAAM,CAAC,MAAM,EAAE,YAAY,CAAC,CAAC,CAAC;IACvD,6GAA6G;IAC7G,KAAK,CAAC,EAAE,0BAA0B,CAAC;CACpC;AAED;;;;;;;;;;;;;GAaG;AACH,MAAM,MAAM,0BAA0B,GAAG,aAAa,CAAC;AAEvD;;;;;;;;GAQG;AACH,MAAM,CAAC,OAAO,UAAU,qBAAqB,CAAC,EAAE,aAAa,EAAE,KAAK,EAAE,GAAE,0BAA+B,+BAwItG"}

package/dist/notifications/ui/UserNotificationsPage.js

@@ -0,0 +1,197 @@
+import { jsx as _jsx } from "react/jsx-runtime";
+/**
+ * Settings → Notifications (`/settings/notifications`).
+ *
+ * Issue #126, epic #109. The per-user half of the notification framework: a
+ * matrix of event x channel, driven by the server's registry
+ * (`GET /api/notifications/events`) so an event added to
+ * `apps/api/src/notifications/notification-events.ts` later appears here with
+ * NO change to this page — which is epic #109's headline promise that a
+ * notification costs one registry entry.
+ *
+ * THIN, like `UserAppearancePage`: every line of shared page chrome (the
+ * settings fetch, the loading spinner, the fetch-error alert, the
+ * success/failure snackbars) lives in `UserSettingsSection`, and the matrix
+ * itself lives in `components/settings/NotificationSettings.tsx`. What is left
+ * here is the wiring, and one decision — the exact shape of the write.
+ *
+ * =============================================================================
+ * THE WRITE: ONE CHANNEL, ONE EVENT KEY, NOTHING ELSE
+ * =============================================================================
+ *
+ * `onToggle` below is the ONLY place this feature writes preferences, and it
+ * sends a document with exactly one channel and exactly one event key in it:
+ *
+ *     \{ notifications: \{ email: \{ 'user.welcome': false \} \} \}   // store a choice
+ *     \{ notifications: \{ email: \{ 'user.welcome': null  \} \} \}   // DELETE the key
+ *
+ * The API deep-merges the channel object per event key (see
+ * `mergeNotifications` in `UserSettingsService`, and
+ * `notificationsPatchSchema`), so every preference this request does not name
+ * stays exactly as it was — including staying ABSENT, which is the state that
+ * resolves to the registry default.
+ *
+ * There is no other write path. Nothing PATCHes on mount, nothing serialises a
+ * preferences object, and there is no Save button to batch one up: a batched
+ * save needs a full local mirror to diff, and that mirror — defaulted, because
+ * it has to be defaulted to render — is precisely the materialised blob the
+ * sparse contract exists to avoid. See the header of `NotificationSettings.tsx`
+ * for the full argument.
+ *
+ * `value` arriving as `null` is the null-delete, decided by
+ * `preferenceWriteFor` at the control: the user has moved a control BACK to its
+ * registry default, so the right write is to remove their stored opinion rather
+ * than pin today's default into their document forever.
+ *
+ * =============================================================================
+ * WHY TWO LOADING STATES, NESTED
+ * =============================================================================
+ *
+ * This page needs two independent things: the user's settings document (owned
+ * by `UserSettingsSection`) and the event registry (owned by
+ * `useNotificationEvents`). They are separate endpoints and either can fail
+ * alone, so they are reported separately: the outer spinner/alert is the
+ * settings document's, the inner one below is the registry's. Collapsing them
+ * would mean a registry failure renders an empty matrix, which is
+ * indistinguishable from "this application notifies you about nothing".
+ */
+import { useCallback, useState } from 'react';
+import { Alert } from '@mui/material';
+import { LoadingSpinner } from './LoadingSpinner.js';
+import { NotificationSettings } from './NotificationSettings.js';
+import { useIsMounted } from '../headless/useIsMounted.js';
+import { useNotificationCapability } from '../headless/useNotificationCapability.js';
+import { useNotificationConfig } from '../headless/useNotificationConfig.js';
+import { useNotificationChannels } from '../headless/useNotificationChannels.js';
+import { useNotificationEvents } from '../headless/useNotificationEvents.js';
+import { requestPermissionAndSyncPush } from '../headless/pushSubscription.js';
+import { UserSettingsSection } from './UserSettingsSection.js';
+/** Mirrors the `Notifications` card in `config/userSettingsSections.tsx`, so the
+ *  hub card, the compact AppBar title (#95) and this page's `h1` all agree. */
+const PAGE_TITLE = 'Notifications';
+const PAGE_DESCRIPTION = 'Choose which events notify you, and whether they arrive by email or in your browser.';
+/**
+ * The `/settings/notifications` page: the signed-in user's per-channel, per-event preferences and this device's permission state.
+ *
+ * @param props - see {@link UserNotificationsPageProps}.
+ * @returns the page.
+ *
+ * @extensionPoint component
+ * @stability experimental
+ */
+export default function UserNotificationsPage({ channelStates, slots } = {}) {
+    // Both hooks at the top level of the component, NOT inside the render prop
+    // below — a hook called from a callback is a hook called conditionally, and
+    // the render prop is only invoked once the settings document has loaded.
+    const { events, isLoading: eventsLoading, error } = useNotificationEvents();
+    // The channel labels (PP-14.10). A failed read is not fatal: the matrix then
+    // labels each channel with its raw id, which is legible if plain.
+    const { channels, isLoading: channelsLoading } = useNotificationChannels();
+    const isLoading = eventsLoading || channelsLoading;
+    // OBSERVED here; this page requests only from the click handler below (the
+    // shell's `usePushSubscriptionSync` owns the once-per-load auto-prompt).
+    //
+    // #221 moved this from `useBrowserNotificationPermission` to the CAPABILITY
+    // hook layered over it. Same observation, wider answer: the four permission
+    // states could not distinguish an iOS Safari tab (fix: Add to Home Screen)
+    // from an ancient browser (no fix), or a plain-HTTP origin (fix: HTTPS) from
+    // either — so the page could only ever offer one remedy for four problems.
+    // The raw permission is still available on this hook's result; nothing on
+    // this page needs it, because every decision here is about what the user can
+    // DO, which is exactly what `capability` names.
+    //
+    // #227: `adminDisabled` is now wired from `GET /api/notifications/config`,
+    // via `useNotificationConfig` below. `config` is `null` until that first read
+    // resolves, and `config?.browserEnabled === false` — rather than
+    // `!config?.browserEnabled` — is what keeps that window from reading as
+    // "disabled": see `useNotificationConfig`'s own header for why the two reads
+    // disagree during loading and why only one of them is correct.
+    const { config: notificationConfig } = useNotificationConfig();
+    const { capability, refresh: refreshPermission } = useNotificationCapability({
+        adminDisabled: notificationConfig?.browserEnabled === false,
+    });
+    const isMounted = useIsMounted();
+    const [isRequestingPermission, setIsRequestingPermission] = useState(false);
+    /**
+     * The "Allow notifications" button's handler (#127).
+     *
+     * Nothing on THIS page calls it automatically — the once-per-load auto-prompt
+     * lives in the shell (`usePushSubscriptionSync`, #365). The button remains
+     * because Firefox and Safari ignore a gestureless request. Like the shell,
+     * it goes through `requestPermissionAndSyncPush`, so a grant here subscribes
+     * this device to push straight away when the deployment offers it.
+     *
+     * THE REFRESH IS IN A `finally`, and that matters more than it looks.
+     * `requestBrowserNotificationPermission` resolves `null` on an unsupported or
+     * throwing browser and can resolve with the permission unchanged when the
+     * user dismisses the prompt without choosing. Refreshing unconditionally
+     * re-reads `Notification.permission` — the single source of truth for what
+     * this page renders — instead of trusting one call's return value, so the
+     * banner lands on the honest state in every one of those cases, including
+     * "nothing happened, the button stays".
+     */
+    const handleRequestPermission = useCallback(async () => {
+        setIsRequestingPermission(true);
+        try {
+            await requestPermissionAndSyncPush(notificationConfig);
+        }
+        finally {
+            // Guarded: the prompt is modal and the user can navigate away from this
+            // page while it is open, so both of these can land after unmount.
+            if (isMounted()) {
+                setIsRequestingPermission(false);
+                refreshPermission();
+            }
+        }
+    }, [isMounted, notificationConfig, refreshPermission]);
+    return (_jsx(UserSettingsSection, { title: PAGE_TITLE, description: PAGE_DESCRIPTION, slots: slots, children: ({ settings, isSaving, save }) => {
+            if (isLoading)
+                return _jsx(LoadingSpinner, {});
+            if (error) {
+                // Inline and permanent, like the section's own fetch error: without
+                // the registry there is no matrix to render, and a snackbar that
+                // auto-hides would leave a blank page behind with no explanation.
+                return _jsx(Alert, { severity: "error", children: error });
+            }
+            // `null` only in the window between "not loading" and "not errored",
+            // which the two branches above have already covered; rendering nothing
+            // is still the correct fallback rather than an assertion.
+            if (!events)
+                return null;
+            return (_jsx(NotificationSettings, { events: events, channels: channels ?? undefined, channelStates: channelStates, 
+                // THE RAW STORED NAMESPACE, passed straight through — `undefined`
+                // when the user has never saved a preference, which is the normal
+                // case. Deliberately NOT `?? {}`-ed into a defaulted object here:
+                // every control derives its own state from this plus the registry,
+                // and the one thing that must never exist is a filled-in local copy.
+                preferences: settings.notifications, isSaving: isSaving, browserCapability: capability, 
+                // The promise is dropped deliberately: `handleRequestPermission`
+                // handles its own failure (there is nothing to report — the banner
+                // already says what the state is) and the button's own spinner is
+                // driven by `isRequestingPermission`.
+                onRequestPermission: () => void handleRequestPermission(), isRequestingPermission: isRequestingPermission, 
+                // #365: the real value. `false` while the config is still loading,
+                // matching the component's own default.
+                pushEnabled: notificationConfig?.pushEnabled ?? false, onToggle: (channel, event, value) => {
+                    // The single-key patch. Built with a computed key so the channel
+                    // comes from the control that was clicked rather than from a
+                    // literal that could disagree with it, and typed explicitly so a
+                    // channel the union does not know about fails to compile here
+                    // rather than 400ing at the API's channel enum.
+                    const notifications = {
+                        [channel]: { [event.key]: value },
+                    };
+                    // The promise is intentionally dropped: `save` reports its own
+                    // failures through the section's snackbar rather than rejecting,
+                    // exactly as `UserAppearancePage` does. On success the section
+                    // re-renders from the SERVER's response, so what the switch shows
+                    // afterwards is what was actually stored — no optimistic overlay,
+                    // and therefore no second source of truth to drift.
+                    void save({ notifications }, {
+                        success: 'Notification preferences updated',
+                        failure: 'Failed to update notification preferences',
+                    });
+                } }));
+        } }));
+}
+//# sourceMappingURL=UserNotificationsPage.js.map

package/dist/notifications/ui/UserNotificationsPage.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserNotificationsPage.js","sourceRoot":"","sources":["../../../src/notifications/ui/UserNotificationsPage.tsx"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuDG;AAEH,OAAO,EAAE,WAAW,EAAE,QAAQ,EAAE,MAAM,OAAO,CAAC;AAC9C,OAAO,EAAE,KAAK,EAAE,MAAM,eAAe,CAAC;AACtC,OAAO,EAAE,cAAc,EAAE,MAAM,qBAAqB,CAAC;AACrD,OAAO,EAAE,oBAAoB,EAAqB,MAAM,2BAA2B,CAAC;AACpF,OAAO,EAAE,YAAY,EAAE,MAAM,6BAA6B,CAAC;AAC3D,OAAO,EAAE,yBAAyB,EAAE,MAAM,0CAA0C,CAAC;AACrF,OAAO,EAAE,qBAAqB,EAAE,MAAM,sCAAsC,CAAC;AAC7E,OAAO,EAAE,uBAAuB,EAAE,MAAM,wCAAwC,CAAC;AACjF,OAAO,EAAE,qBAAqB,EAAE,MAAM,sCAAsC,CAAC;AAC7E,OAAO,EAAE,4BAA4B,EAAE,MAAM,iCAAiC,CAAC;AAG/E,OAAO,EAAE,mBAAmB,EAAE,MAAM,0BAA0B,CAAC;AAE/D;+EAC+E;AAC/E,MAAM,UAAU,GAAG,eAAe,CAAC;AACnC,MAAM,gBAAgB,GACpB,sFAAsF,CAAC;AAoCzF;;;;;;;;GAQG;AACH,MAAM,CAAC,OAAO,UAAU,qBAAqB,CAAC,EAAE,aAAa,EAAE,KAAK,KAAiC,EAAE;IACrG,2EAA2E;IAC3E,4EAA4E;IAC5E,yEAAyE;IACzE,MAAM,EAAE,MAAM,EAAE,SAAS,EAAE,aAAa,EAAE,KAAK,EAAE,GAAG,qBAAqB,EAAE,CAAC;IAC5E,6EAA6E;IAC7E,kEAAkE;IAClE,MAAM,EAAE,QAAQ,EAAE,SAAS,EAAE,eAAe,EAAE,GAAG,uBAAuB,EAAE,CAAC;IAC3E,MAAM,SAAS,GAAG,aAAa,IAAI,eAAe,CAAC;IAEnD,2EAA2E;IAC3E,yEAAyE;IACzE,EAAE;IACF,4EAA4E;IAC5E,4EAA4E;IAC5E,2EAA2E;IAC3E,6EAA6E;IAC7E,2EAA2E;IAC3E,0EAA0E;IAC1E,6EAA6E;IAC7E,gDAAgD;IAChD,EAAE;IACF,2EAA2E;IAC3E,8EAA8E;IAC9E,iEAAiE;IACjE,wEAAwE;IACxE,6EAA6E;IAC7E,+DAA+D;IAC/D,MAAM,EAAE,MAAM,EAAE,kBAAkB,EAAE,GAAG,qBAAqB,EAAE,CAAC;IAC/D,MAAM,EAAE,UAAU,EAAE,OAAO,EAAE,iBAAiB,EAAE,GAAG,yBAAyB,CAAC;QAC3E,aAAa,EAAE,kBAAkB,EAAE,cAAc,KAAK,KAAK;KAC5D,CAAC,CAAC;IAEH,MAAM,SAAS,GAAG,YAAY,EAAE,CAAC;IACjC,MAAM,CAAC,sBAAsB,EAAE,yBAAyB,CAAC,GAAG,QAAQ,CAAC,KAAK,CAAC,CAAC;IAE5E;;;;;;;;;;;;;;;;;OAiBG;IACH,MAAM,uBAAuB,GAAG,WAAW,CAAC,KAAK,IAAI,EAAE;QACrD,yBAAyB,CAAC,IAAI,CAAC,CAAC;QAChC,IAAI,CAAC;YACH,MAAM,4BAA4B,CAAC,kBAAkB,CAAC,CAAC;QACzD,CAAC;gBAAS,CAAC;YACT,wEAAwE;YACxE,kEAAkE;YAClE,IAAI,SAAS,EAAE,EAAE,CAAC;gBAChB,yBAAyB,CAAC,KAAK,CAAC,CAAC;gBACjC,iBAAiB,EAAE,CAAC;YACtB,CAAC;QACH,CAAC;IACH,CAAC,EAAE,CAAC,SAAS,EAAE,kBAAkB,EAAE,iBAAiB,CAAC,CAAC,CAAC;IAEvD,OAAO,CACL,KAAC,mBAAmB,IAAC,KAAK,EAAE,UAAU,EAAE,WAAW,EAAE,gBAAgB,EAAE,KAAK,EAAE,KAAK,YAChF,CAAC,EAAE,QAAQ,EAAE,QAAQ,EAAE,IAAI,EAAE,EAAE,EAAE;YAChC,IAAI,SAAS;gBAAE,OAAO,KAAC,cAAc,KAAG,CAAC;YAEzC,IAAI,KAAK,EAAE,CAAC;gBACV,oEAAoE;gBACpE,iEAAiE;gBACjE,kEAAkE;gBAClE,OAAO,KAAC,KAAK,IAAC,QAAQ,EAAC,OAAO,YAAE,KAAK,GAAS,CAAC;YACjD,CAAC;YAED,qEAAqE;YACrE,uEAAuE;YACvE,0DAA0D;YAC1D,IAAI,CAAC,MAAM;gBAAE,OAAO,IAAI,CAAC;YAEzB,OAAO,CACL,KAAC,oBAAoB,IACnB,MAAM,EAAE,MAAM,EACd,QAAQ,EAAE,QAAQ,IAAI,SAAS,EAC/B,aAAa,EAAE,aAAa;gBAC5B,kEAAkE;gBAClE,kEAAkE;gBAClE,kEAAkE;gBAClE,mEAAmE;gBACnE,qEAAqE;gBACrE,WAAW,EAAE,QAAQ,CAAC,aAAa,EACnC,QAAQ,EAAE,QAAQ,EAClB,iBAAiB,EAAE,UAAU;gBAC7B,iEAAiE;gBACjE,mEAAmE;gBACnE,kEAAkE;gBAClE,sCAAsC;gBACtC,mBAAmB,EAAE,GAAG,EAAE,CAAC,KAAK,uBAAuB,EAAE,EACzD,sBAAsB,EAAE,sBAAsB;gBAC9C,mEAAmE;gBACnE,wCAAwC;gBACxC,WAAW,EAAE,kBAAkB,EAAE,WAAW,IAAI,KAAK,EACrD,QAAQ,EAAE,CAAC,OAAO,EAAE,KAAK,EAAE,KAAK,EAAE,EAAE;oBAClC,iEAAiE;oBACjE,6DAA6D;oBAC7D,iEAAiE;oBACjE,8DAA8D;oBAC9D,gDAAgD;oBAChD,MAAM,aAAa,GAAiC;wBAClD,CAAC,OAAO,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,GAAG,CAAC,EAAE,KAAK,EAAE;qBAClC,CAAC;oBAEF,+DAA+D;oBAC/D,iEAAiE;oBACjE,+DAA+D;oBAC/D,kEAAkE;oBAClE,kEAAkE;oBAClE,oDAAoD;oBACpD,KAAK,IAAI,CACP,EAAE,aAAa,EAAE,EACjB;wBACE,OAAO,EAAE,kCAAkC;wBAC3C,OAAO,EAAE,2CAA2C;qBACrD,CACF,CAAC;gBACJ,CAAC,GACD,CACH,CAAC;QACJ,CAAC,GACmB,CACvB,CAAC;AACJ,CAAC"}

package/dist/notifications/ui/UserSettingsSection.d.ts

@@ -0,0 +1,99 @@
+/**
+ * Shared chrome for every `/settings/*` page that edits the user settings
+ * document.
+ *
+ * Issue #96, epic #90. The exact counterpart of
+ * `pages/Admin/SystemSettingsSection.tsx` (#92), for the same reason and with
+ * the same shape. `UserSettingsPage` used to be one component stacking three
+ * cards, and with it ONE copy of the wiring those cards shared: the
+ * `useUserSettings` hook, the loading spinner, the fetch-error alert, and the
+ * success/failure snackbars. Splitting the stack into routed pages without
+ * extracting that wiring would have produced a copy of it per page — and the
+ * whole point of epic #90 is that near-identical copies drift within a release.
+ * There is still exactly one copy; it just lives here now.
+ *
+ * ONE HOOK CALL PER PAGE, NOT ONE FOR THE SURFACE. Each routed page mounts its
+ * own `UserSettingsSection`, so each owns its own `useUserSettings()` and its
+ * own snackbar state. That is the behavioural change #96 asks for: on the old
+ * stacked page a successful theme save raised a toast that sat visually
+ * alongside the Profile card, because there was one snackbar for three
+ * sections. Two pages that are never mounted together cannot do that. The cost
+ * is one `GET /user-settings` per settings page visit, which is the same cost
+ * the admin split already accepted and is dwarfed by the page's own chunk.
+ *
+ * A RENDER PROP rather than an outlet or a HOC — same argument as the admin
+ * wrapper. `ThemeSettings` and `ProfileSettings` take `settings` fields as
+ * VALUES and are deliberately left untouched by this issue, so the state has to
+ * arrive as arguments. It also lets `settings` be NON-NULLABLE in the callback:
+ * the null case is handled once, here, so neither page repeats a
+ * `settings && …` guard that TypeScript would otherwise demand of both.
+ *
+ * NO `RequirePermission`, NO `hasPermission` CHECK, unlike the admin wrapper —
+ * and that is a deliberate difference, not an omission. These are the user's
+ * own settings; the API grants `user_settings:read` / `user_settings:write` to
+ * all three roles, and `config/userSettingsSections.tsx` declares no
+ * `permission` on any card for the same reason. A gate here would be inventing
+ * an authorization rule the API does not enforce, and would lock users out of
+ * their own profile.
+ *
+ * NO `<Paper>` AROUND THE CHILDREN, unlike the admin wrapper. The admin editors
+ * are bare form controls that need section chrome; `ThemeSettings`,
+ * `ProfileSettings` and `PersonalAccessTokens` each render their own `<Card>`
+ * already, and nesting those in a Paper stacks two elevated surfaces with a
+ * hairline of background between them.
+ */
+import type { ReactNode } from 'react';
+import type { PageSlotsBase } from '../../core/index.js';
+import type { UserSettingsUpdateBase } from '../../settings/index.js';
+import type { NotificationsUserSettingsDocument as UserSettings, NotificationsUserSettingsUpdate } from '../headless/types.js';
+/** The PATCH body: the notifications branch, on the hook's base shape. */
+type UserSettingsUpdate = NotificationsUserSettingsUpdate & UserSettingsUpdateBase;
+/** The strings a save raises, per call site. See `save` below. */
+export interface UserSettingsSaveMessages {
+    /** Shown in the success snackbar, e.g. `'Theme updated'`. */
+    success: string;
+    /**
+     * Success-path fallback for the ERROR snackbar when the rejection is not an
+     * `Error` and therefore carries no `.message`, e.g.
+     * `'Failed to update theme'`. Carried per call site rather than hardcoded to one generic string
+     * so the two pages keep the exact copy the stacked page used.
+     */
+    failure: string;
+}
+/** What a settings page gets handed once the document has loaded. */
+export interface UserSettingsSectionState {
+    settings: UserSettings;
+    /** True while a PATCH is in flight. Pages pass it straight to `disabled`. */
+    isSaving: boolean;
+    /**
+     * PATCH a partial settings document and raise the success snackbar.
+     *
+     * SWALLOWS the rejection into the error snackbar rather than rethrowing —
+     * this is `UserSettingsPage`'s `handleThemeChange` / `handleProfileSave`
+     * unchanged, and both callers depend on it. `ProfileSettings.handleSave`
+     * awaits `onSave` and then calls `refreshUser()` outside any try/catch: if
+     * this rethrew, a failed save would skip that refresh and leave the form's
+     * `isSaving` cleared only by its `finally`, with the rejection escaping as an
+     * unhandled promise. `ThemeSettings.onThemeChange` is typed `void` and does
+     * not even receive the promise.
+     */
+    save: (updates: UserSettingsUpdate, messages: UserSettingsSaveMessages) => Promise<void>;
+    /**
+     * Adopt a settings document an endpoint other than `PATCH /user-settings`
+     * already returned (the profile-image upload/delete responses), so the
+     * stored `version` stays current, and optionally raise the success snackbar.
+     */
+    replaceSettings: (settings: UserSettings, successMessage?: string) => void;
+}
+interface UserSettingsSectionProps {
+    /** `h1` for the page. Mirrors the card title in `userSettingsSections.tsx`. */
+    title: string;
+    /** Secondary line under the title. Mirrors the card description. */
+    description: string;
+    children: (state: UserSettingsSectionState) => ReactNode;
+    /** The page-slot contract's slots; omitted, the chrome is exactly what it always was. The spinner is not slotted. */
+    slots?: PageSlotsBase;
+}
+export declare function UserSettingsSection({ title, description, children, slots, }: UserSettingsSectionProps): import("react").JSX.Element;
+export default UserSettingsSection;
+//# sourceMappingURL=UserSettingsSection.d.ts.map

package/dist/notifications/ui/UserSettingsSection.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserSettingsSection.d.ts","sourceRoot":"","sources":["../../../src/notifications/ui/UserSettingsSection.tsx"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2CG;AAGH,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,OAAO,CAAC;AAGvC,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAGzD,OAAO,KAAK,EAAE,sBAAsB,EAAE,MAAM,yBAAyB,CAAC;AACtE,OAAO,KAAK,EACV,iCAAiC,IAAI,YAAY,EACjD,+BAA+B,EAChC,MAAM,sBAAsB,CAAC;AAE9B,0EAA0E;AAC1E,KAAK,kBAAkB,GAAG,+BAA+B,GAAG,sBAAsB,CAAC;AAEnF,kEAAkE;AAClE,MAAM,WAAW,wBAAwB;IACvC,6DAA6D;IAC7D,OAAO,EAAE,MAAM,CAAC;IAChB;;;;;OAKG;IACH,OAAO,EAAE,MAAM,CAAC;CACjB;AAED,qEAAqE;AACrE,MAAM,WAAW,wBAAwB;IACvC,QAAQ,EAAE,YAAY,CAAC;IACvB,6EAA6E;IAC7E,QAAQ,EAAE,OAAO,CAAC;IAClB;;;;;;;;;;;OAWG;IACH,IAAI,EAAE,CAAC,OAAO,EAAE,kBAAkB,EAAE,QAAQ,EAAE,wBAAwB,KAAK,OAAO,CAAC,IAAI,CAAC,CAAC;IACzF;;;;OAIG;IACH,eAAe,EAAE,CAAC,QAAQ,EAAE,YAAY,EAAE,cAAc,CAAC,EAAE,MAAM,KAAK,IAAI,CAAC;CAC5E;AAED,UAAU,wBAAwB;IAChC,+EAA+E;IAC/E,KAAK,EAAE,MAAM,CAAC;IACd,oEAAoE;IACpE,WAAW,EAAE,MAAM,CAAC;IACpB,QAAQ,EAAE,CAAC,KAAK,EAAE,wBAAwB,KAAK,SAAS,CAAC;IACzD,qHAAqH;IACrH,KAAK,CAAC,EAAE,aAAa,CAAC;CACvB;AAED,wBAAgB,mBAAmB,CAAC,EAClC,KAAK,EACL,WAAW,EACX,QAAQ,EACR,KAAK,GACN,EAAE,wBAAwB,+BA0F1B;AAED,eAAe,mBAAmB,CAAC"}

package/dist/notifications/ui/UserSettingsSection.js

@@ -0,0 +1,78 @@
+import { jsx as _jsx, Fragment as _Fragment, jsxs as _jsxs } from "react/jsx-runtime";
+/**
+ * Shared chrome for every `/settings/*` page that edits the user settings
+ * document.
+ *
+ * Issue #96, epic #90. The exact counterpart of
+ * `pages/Admin/SystemSettingsSection.tsx` (#92), for the same reason and with
+ * the same shape. `UserSettingsPage` used to be one component stacking three
+ * cards, and with it ONE copy of the wiring those cards shared: the
+ * `useUserSettings` hook, the loading spinner, the fetch-error alert, and the
+ * success/failure snackbars. Splitting the stack into routed pages without
+ * extracting that wiring would have produced a copy of it per page — and the
+ * whole point of epic #90 is that near-identical copies drift within a release.
+ * There is still exactly one copy; it just lives here now.
+ *
+ * ONE HOOK CALL PER PAGE, NOT ONE FOR THE SURFACE. Each routed page mounts its
+ * own `UserSettingsSection`, so each owns its own `useUserSettings()` and its
+ * own snackbar state. That is the behavioural change #96 asks for: on the old
+ * stacked page a successful theme save raised a toast that sat visually
+ * alongside the Profile card, because there was one snackbar for three
+ * sections. Two pages that are never mounted together cannot do that. The cost
+ * is one `GET /user-settings` per settings page visit, which is the same cost
+ * the admin split already accepted and is dwarfed by the page's own chunk.
+ *
+ * A RENDER PROP rather than an outlet or a HOC — same argument as the admin
+ * wrapper. `ThemeSettings` and `ProfileSettings` take `settings` fields as
+ * VALUES and are deliberately left untouched by this issue, so the state has to
+ * arrive as arguments. It also lets `settings` be NON-NULLABLE in the callback:
+ * the null case is handled once, here, so neither page repeats a
+ * `settings && …` guard that TypeScript would otherwise demand of both.
+ *
+ * NO `RequirePermission`, NO `hasPermission` CHECK, unlike the admin wrapper —
+ * and that is a deliberate difference, not an omission. These are the user's
+ * own settings; the API grants `user_settings:read` / `user_settings:write` to
+ * all three roles, and `config/userSettingsSections.tsx` declares no
+ * `permission` on any card for the same reason. A gate here would be inventing
+ * an authorization rule the API does not enforce, and would lock users out of
+ * their own profile.
+ *
+ * NO `<Paper>` AROUND THE CHILDREN, unlike the admin wrapper. The admin editors
+ * are bare form controls that need section chrome; `ThemeSettings`,
+ * `ProfileSettings` and `PersonalAccessTokens` each render their own `<Card>`
+ * already, and nesting those in a Paper stacks two elevated surfaces with a
+ * hairline of background between them.
+ */
+import { useState } from 'react';
+import { Alert, Box, Container, Snackbar, Typography } from '@mui/material';
+import { PageSlotsFrame } from '../../core/index.js';
+import { useUserSettings } from '../../settings/index.js';
+import { LoadingSpinner } from './LoadingSpinner.js';
+export function UserSettingsSection({ title, description, children, slots, }) {
+    const { settings, isLoading, error, isSaving, updateSettings, replaceSettings: adoptSettings, } = useUserSettings({ syncTheme: false });
+    const [successMessage, setSuccessMessage] = useState(null);
+    const [localError, setLocalError] = useState(null);
+    const replaceSettings = (next, message) => {
+        adoptSettings(next);
+        if (message)
+            setSuccessMessage(message);
+    };
+    const save = async (updates, messages) => {
+        try {
+            await updateSettings(updates);
+            setSuccessMessage(messages.success);
+        }
+        catch (err) {
+            setLocalError(err instanceof Error ? err.message : messages.failure);
+        }
+    };
+    // Before the `Container`, exactly as the stacked page did: a spinner under a
+    // heading that is about to be replaced by the same heading flickers, and the
+    // AppBar (#95) is already naming the page from the registry while this loads.
+    if (isLoading) {
+        return _jsx(LoadingSpinner, {});
+    }
+    return (_jsx(Container, { maxWidth: "md", children: _jsxs(Box, { sx: { py: 4 }, children: [_jsxs(PageSlotsFrame, { slots: slots, headerProps: { title, description, actions: null }, header: _jsxs(_Fragment, { children: [_jsx(Typography, { variant: "h4", component: "h1", gutterBottom: true, children: title }), _jsx(Typography, { color: "text.secondary", sx: { mb: 2 }, children: description })] }), children: [error && (_jsx(Alert, { severity: "error", sx: { mb: 3 }, children: error })), settings && (_jsx(Box, { sx: { display: 'flex', flexDirection: 'column', gap: 3 }, children: children({ settings, isSaving, save, replaceSettings }) }))] }), _jsx(Snackbar, { open: !!successMessage, autoHideDuration: 3000, onClose: () => setSuccessMessage(null), message: successMessage }), _jsx(Snackbar, { open: !!localError, autoHideDuration: 5000, onClose: () => setLocalError(null), children: _jsx(Alert, { severity: "error", onClose: () => setLocalError(null), children: localError }) })] }) }));
+}
+export default UserSettingsSection;
+//# sourceMappingURL=UserSettingsSection.js.map

package/dist/notifications/ui/UserSettingsSection.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"UserSettingsSection.js","sourceRoot":"","sources":["../../../src/notifications/ui/UserSettingsSection.tsx"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2CG;AAEH,OAAO,EAAE,QAAQ,EAAE,MAAM,OAAO,CAAC;AAEjC,OAAO,EAAE,KAAK,EAAE,GAAG,EAAE,SAAS,EAAE,QAAQ,EAAE,UAAU,EAAE,MAAM,eAAe,CAAC;AAC5E,OAAO,EAAE,cAAc,EAAE,MAAM,qBAAqB,CAAC;AAErD,OAAO,EAAE,eAAe,EAAE,MAAM,yBAAyB,CAAC;AAC1D,OAAO,EAAE,cAAc,EAAE,MAAM,qBAAqB,CAAC;AA2DrD,MAAM,UAAU,mBAAmB,CAAC,EAClC,KAAK,EACL,WAAW,EACX,QAAQ,EACR,KAAK,GACoB;IACzB,MAAM,EACJ,QAAQ,EACR,SAAS,EACT,KAAK,EACL,QAAQ,EACR,cAAc,EACd,eAAe,EAAE,aAAa,GAC/B,GAAG,eAAe,CAAmC,EAAE,SAAS,EAAE,KAAK,EAAE,CAAC,CAAC;IAE5E,MAAM,CAAC,cAAc,EAAE,iBAAiB,CAAC,GAAG,QAAQ,CAAgB,IAAI,CAAC,CAAC;IAC1E,MAAM,CAAC,UAAU,EAAE,aAAa,CAAC,GAAG,QAAQ,CAAgB,IAAI,CAAC,CAAC;IAElE,MAAM,eAAe,GAAG,CAAC,IAAkB,EAAE,OAAgB,EAAE,EAAE;QAC/D,aAAa,CAAC,IAAI,CAAC,CAAC;QACpB,IAAI,OAAO;YAAE,iBAAiB,CAAC,OAAO,CAAC,CAAC;IAC1C,CAAC,CAAC;IAEF,MAAM,IAAI,GAAG,KAAK,EAAE,OAA2B,EAAE,QAAkC,EAAE,EAAE;QACrF,IAAI,CAAC;YACH,MAAM,cAAc,CAAC,OAAO,CAAC,CAAC;YAC9B,iBAAiB,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;QACtC,CAAC;QAAC,OAAO,GAAG,EAAE,CAAC;YACb,aAAa,CAAC,GAAG,YAAY,KAAK,CAAC,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC;QACvE,CAAC;IACH,CAAC,CAAC;IAEF,6EAA6E;IAC7E,6EAA6E;IAC7E,8EAA8E;IAC9E,IAAI,SAAS,EAAE,CAAC;QACd,OAAO,KAAC,cAAc,KAAG,CAAC;IAC5B,CAAC;IAED,OAAO,CACL,KAAC,SAAS,IAAC,QAAQ,EAAC,IAAI,YACtB,MAAC,GAAG,IAAC,EAAE,EAAE,EAAE,EAAE,EAAE,CAAC,EAAE,aAChB,MAAC,cAAc,IACb,KAAK,EAAE,KAAK,EACZ,WAAW,EAAE,EAAE,KAAK,EAAE,WAAW,EAAE,OAAO,EAAE,IAAI,EAAE,EAClD,MAAM,EACJ,8BACE,KAAC,UAAU,IAAC,OAAO,EAAC,IAAI,EAAC,SAAS,EAAC,IAAI,EAAC,YAAY,kBACjD,KAAK,GACK,EACb,KAAC,UAAU,IAAC,KAAK,EAAC,gBAAgB,EAAC,EAAE,EAAE,EAAE,EAAE,EAAE,CAAC,EAAE,YAC7C,WAAW,GACD,IACZ,aAQN,KAAK,IAAI,CACR,KAAC,KAAK,IAAC,QAAQ,EAAC,OAAO,EAAC,EAAE,EAAE,EAAE,EAAE,EAAE,CAAC,EAAE,YAClC,KAAK,GACA,CACT,EAEA,QAAQ,IAAI,CACX,KAAC,GAAG,IAAC,EAAE,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,aAAa,EAAE,QAAQ,EAAE,GAAG,EAAE,CAAC,EAAE,YAC1D,QAAQ,CAAC,EAAE,QAAQ,EAAE,QAAQ,EAAE,IAAI,EAAE,eAAe,EAAE,CAAC,GACpD,CACP,IAEgB,EAGjB,KAAC,QAAQ,IACP,IAAI,EAAE,CAAC,CAAC,cAAc,EACtB,gBAAgB,EAAE,IAAI,EACtB,OAAO,EAAE,GAAG,EAAE,CAAC,iBAAiB,CAAC,IAAI,CAAC,EACtC,OAAO,EAAE,cAAc,GACvB,EAEF,KAAC,QAAQ,IACP,IAAI,EAAE,CAAC,CAAC,UAAU,EAClB,gBAAgB,EAAE,IAAI,EACtB,OAAO,EAAE,GAAG,EAAE,CAAC,aAAa,CAAC,IAAI,CAAC,YAElC,KAAC,KAAK,IAAC,QAAQ,EAAC,OAAO,EAAC,OAAO,EAAE,GAAG,EAAE,CAAC,aAAa,CAAC,IAAI,CAAC,YACvD,UAAU,GACL,GACC,IACP,GACI,CACb,CAAC;AACJ,CAAC;AAED,eAAe,mBAAmB,CAAC"}

package/dist/notifications/ui/broadcastsTable.d.ts

@@ -0,0 +1,117 @@
+/**
+ * Admin → Operations → Broadcasts: the DataTable column contract (issue #325,
+ * epic #319).
+ *
+ * A sibling module rather than columns inlined in `BroadcastsPage.tsx`, for the
+ * reason every table in this repo follows (`jobsTable.tsx` and
+ * `buildUserColumns` of `@marinoscar/platform-web/identity/ui` are the models): the column list is
+ * the table's PUBLIC shape — what a test, a CSV export and both renderers read
+ * — while the page is the state that feeds it. Keeping them apart lets a test
+ * assert the contract without mounting a page and mocking its fetch layer.
+ *
+ * =============================================================================
+ * WHAT `GET /api/admin/broadcasts` ACTUALLY HONOURS
+ * =============================================================================
+ *
+ * Read off `apps/api/src/notifications/broadcasts/dto/broadcast-list-query.dto.ts`
+ * and `broadcasts.service.ts`'s `list`:
+ *
+ *   | query param       | accepts                                  | column here    |
+ *   | ----------------- | ---------------------------------------- | -------------- |
+ *   | `status`          | draft/scheduled/sending/sent/canceled/failed | `status`, `is` |
+ *   | `page`/`pageSize` | 1-based, pageSize max 100                | pagination     |
+ *
+ * That is the whole query surface. NO COLUMN IS `sortable`: the service orders
+ * by `createdAt DESC` and offers no `sortBy`, so a sortable header would either
+ * silently do nothing or 400 — the same reasoning `jobsTable.tsx` gives at
+ * length. There is no quick search either, for the same reason: no free-text
+ * parameter exists, and a search box that filters only the current page is a
+ * control that lies about its scope.
+ *
+ * =============================================================================
+ * `draft` IS OFFERED AS A FILTER EVEN THOUGH THE API NEVER WRITES ONE
+ * =============================================================================
+ *
+ * `create` stamps `scheduled` unconditionally; nothing in this epic produces a
+ * `draft` row. It is still in the enum because the STATUS COLUMN can render one
+ * — the database column allows it, and a future compose-and-save-for-later
+ * would populate it — and a filter that omits a status the table can display is
+ * a filter that silently cannot reach some of its own rows.
+ *
+ * =============================================================================
+ * IMPORTANCE IS DERIVED FROM `eventKey`, BECAUSE THERE IS NO `critical` COLUMN
+ * =============================================================================
+ *
+ * The API takes `critical: boolean` on create and DERIVES the event key from
+ * it (`admin.broadcast` vs `admin.broadcast_critical`), then stores only the
+ * key. So "can recipients mute this?" is answered by reading the key back, and
+ * `isCriticalBroadcast` below is the single place that reading happens — the
+ * page, the detail dialog and this table all call it rather than each writing
+ * their own `=== 'admin.broadcast_critical'`.
+ */
+import type { DataTableColumn, DataTableFilterModel } from './datatable.js';
+import type { Broadcast, BroadcastStatusName } from '../headless/broadcasts.js';
+/**
+ * Persistence key for `user_settings.dataTables`. A constant, never derived
+ * from the route or the heading: it is a storage key and must survive a rename.
+ */
+export declare const TABLE_ID = "broadcasts";
+/** Column ids the page reads filters out of. Named so a typo cannot drift. */
+export declare const TITLE_COLUMN_ID = "title";
+export declare const STATUS_COLUMN_ID = "status";
+/**
+ * The event key the API derives for a broadcast recipients may not mute.
+ * `admin.broadcast_critical` in `notifications/broadcasts/broadcasts.service.ts`.
+ */
+export declare const CRITICAL_EVENT_KEY = "admin.broadcast_critical";
+/** Whether recipients can mute this broadcast. See the module header. */
+export declare function isCriticalBroadcast(broadcast: Pick<Broadcast, 'eventKey'>): boolean;
+/**
+ * MUI `Chip` colours per status.
+ *
+ * `default` for `draft` and `canceled` — neither is a state to alarm anyone,
+ * and a canceled announcement is a decision that was taken deliberately rather
+ * than a fault. `warning` for `sending` because it is the one status during
+ * which an operator's options are shrinking by the second.
+ */
+export declare const STATUS_CHIP_COLOR: Record<BroadcastStatusName, 'default' | 'info' | 'warning' | 'success' | 'error'>;
+/**
+ * `browser` is labelled "In-app", everywhere.
+ *
+ * The API's channel is named for the mechanism; the administrator's question is
+ * about the destination. In this application the `browser` channel is what
+ * writes the durable `notifications` row the bell renders — the OS toast is a
+ * secondary effect of the same channel. Turning browser notifications off
+ * deployment-wide mutes the toast for a critical (mandatory) broadcast while
+ * its row is still written; for a non-critical broadcast it drops the in-app
+ * delivery too (#521). The label names what the admin is choosing — a place in
+ * the app — not the OS mechanism.
+ */
+export declare function channelLabel(channel: string, labels?: ReadonlyMap<string, string>): string;
+/** A timestamp in the viewer's locale, or an em dash when the API sent `null`. */
+export declare function formatDateTime(value: string | null | undefined): string;
+/** The first 8 characters of a UUID — enough to tell two rows apart by eye. */
+export declare function shortId(id: string): string;
+/**
+ * `dispatched / targeted`, as a scalar.
+ *
+ * The denominator is `—` until the fan-out freezes the audience and counts it,
+ * because until then there genuinely is no target: `recipientsTargeted` is
+ * `null` on every `scheduled` row. Printing `0 / 0` would state a measurement
+ * that was never taken, and — worse here than on the jobs page — would read as
+ * "this broadcast reaches nobody".
+ */
+export declare function formatProgress(broadcast: Pick<Broadcast, 'recipientsDispatched' | 'recipientsTargeted'>): string;
+/**
+ * Read a single-operand `is` filter out of the model as a plain STRING.
+ *
+ * Returning a scalar (not the filter object) is what lets a refetch effect
+ * depend on it directly — an effect keyed on the filter array would refetch
+ * forever, since the array is rebuilt on every change. Lifted from
+ * `jobsTable.tsx`, which explains the same trap.
+ */
+export declare function readIsFilter(filters: DataTableFilterModel, columnId: string): string | undefined;
+/** Narrow a stored/URL-supplied filter value to a status the endpoint accepts. */
+export declare function asBroadcastStatus(value: string | undefined): BroadcastStatusName | undefined;
+export declare function buildBroadcastColumns(labels?: ReadonlyMap<string, string>): DataTableColumn<Broadcast>[];
+//# sourceMappingURL=broadcastsTable.d.ts.map

package/dist/notifications/ui/broadcastsTable.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"broadcastsTable.d.ts","sourceRoot":"","sources":["../../../src/notifications/ui/broadcastsTable.tsx"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkDG;AAGH,OAAO,KAAK,EAAE,eAAe,EAAE,oBAAoB,EAAE,MAAM,gBAAgB,CAAC;AAE5E,OAAO,KAAK,EAAE,SAAS,EAAE,mBAAmB,EAAE,MAAM,2BAA2B,CAAC;AAEhF;;;GAGG;AACH,eAAO,MAAM,QAAQ,eAAe,CAAC;AAErC,8EAA8E;AAC9E,eAAO,MAAM,eAAe,UAAU,CAAC;AACvC,eAAO,MAAM,gBAAgB,WAAW,CAAC;AAEzC;;;GAGG;AACH,eAAO,MAAM,kBAAkB,6BAA6B,CAAC;AAE7D,yEAAyE;AACzE,wBAAgB,mBAAmB,CAAC,SAAS,EAAE,IAAI,CAAC,SAAS,EAAE,UAAU,CAAC,GAAG,OAAO,CAEnF;AAWD;;;;;;;GAOG;AACH,eAAO,MAAM,iBAAiB,EAAE,MAAM,CACpC,mBAAmB,EACnB,SAAS,GAAG,MAAM,GAAG,SAAS,GAAG,SAAS,GAAG,OAAO,CAQrD,CAAC;AAcF;;;;;;;;;;;GAWG;AACH,wBAAgB,YAAY,CAAC,OAAO,EAAE,MAAM,EAAE,MAAM,CAAC,EAAE,WAAW,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,MAAM,CAE1F;AAED,kFAAkF;AAClF,wBAAgB,cAAc,CAAC,KAAK,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,GAAG,MAAM,CAEvE;AAED,+EAA+E;AAC/E,wBAAgB,OAAO,CAAC,EAAE,EAAE,MAAM,GAAG,MAAM,CAE1C;AAED;;;;;;;;GAQG;AACH,wBAAgB,cAAc,CAAC,SAAS,EAAE,IAAI,CAAC,SAAS,EAAE,sBAAsB,GAAG,oBAAoB,CAAC,GAAG,MAAM,CAGhH;AAED;;;;;;;GAOG;AACH,wBAAgB,YAAY,CAC1B,OAAO,EAAE,oBAAoB,EAC7B,QAAQ,EAAE,MAAM,GACf,MAAM,GAAG,SAAS,CAKpB;AAED,kFAAkF;AAClF,wBAAgB,iBAAiB,CAAC,KAAK,EAAE,MAAM,GAAG,SAAS,GAAG,mBAAmB,GAAG,SAAS,CAE5F;AAMD,wBAAgB,qBAAqB,CAAC,MAAM,CAAC,EAAE,WAAW,CAAC,MAAM,EAAE,MAAM,CAAC,GAAG,eAAe,CAAC,SAAS,CAAC,EAAE,CAgMxG"}