web-mojo 2.5.5 → 2.5.6

package/CHANGELOG.md

@@ -2,6 +2,33 @@
 
 ## Unreleased
 
+### Core · Detail Views can size their own row-view modal via `ViewClass.DIALOG_OPTIONS`
+
+Dense detail Views (`UserView`, `GroupView`, …) opened as a row-view dialog were stuck at `Modal.dialog()`'s default `size: 'lg'`. The only way to widen them was to repeat `viewDialogOptions: { size: 'xl' }` in every TablePage / TableView / ListView that opened the View — easy to forget, and the View itself (which actually knows how much room it needs) had no say.
+
+- **New static `DIALOG_OPTIONS` on the View class.** `ListView._onRowView()` and `TablePage.showItemDialog()` now spread `ViewClass.DIALOG_OPTIONS` onto `Modal.dialog()` whenever they open a `VIEW_CLASS` / `itemView`. A detail View declares its preferred modal presentation once — `UserView.DIALOG_OPTIONS = { size: 'fullscreen' }` — and every surface that opens it picks it up automatically. `DIALOG_OPTIONS` accepts any `Modal.dialog()` option (`size`, `centered`, `scrollable`, `noBodyPadding`, …); supported sizes are `'sm'`, `'lg'`, `'xl'`, `'xxl'`, `'fullscreen'`.
+- **Precedence (later wins):** built-in defaults (`size: 'lg'`) → `Model.FORM_DIALOG_CONFIG` → `ViewClass.DIALOG_OPTIONS` → page/instance `viewDialogOptions`. The page-level escape hatch still wins, so a page can override the View's preferred size when it genuinely needs to. Existing pages are unaffected — a View with no `DIALOG_OPTIONS` keeps the previous behavior.
+- **Adopted on the two heaviest admin inspectors.** `UserView.DIALOG_OPTIONS = { size: 'fullscreen' }` (side-nav + ~10 sections of embedded tables) and `GroupView.DIALOG_OPTIONS = { size: 'xl' }`, registered next to their `VIEW_CLASS` assignments. The `viewDialogOptions` in `UserTablePage` / `GroupTablePage` / `MemberTablePage` set no `size`, so the new sizes apply cleanly without touching those pages.
+- **Docs.** New "Sizing the dialog from the View class" subsections in `docs/web-mojo/components/TableView.md` and `docs/web-mojo/components/ListView.md`, plus a `ViewClass.DIALOG_OPTIONS` row in the TablePage "Where to register the static" table.
+
+### Admin · GroupTablePage exposes a UUID column + filter
+
+- **New `uuid` column** in `GroupTablePage` (monospace, muted, `xl`-only visibility so it doesn't crowd the table on smaller screens — matches the `created` / `last_activity` cluster). Falls back to `—` for groups without a UUID.
+- **New "Filter by UUID" text filter** wired inline on the column, so it appears in the toolbar's *Add Filter* dropdown and sends `uuid=<value>` to `/api/group`.
+
+### Admin · Webhook Subscriptions management UI (per-group section + standalone TablePage)
+
+Operators previously had no UI for the `account.WebhookSubscription` rows that landed on django-mojo last cycle — provisioning a webhook receiver meant hand-curling `POST /api/group/webhook_subscriptions`, and there was nowhere to fetch the per-group signing secret a consumer needs to verify deliveries. This adds the missing surfaces, mirroring the existing ApiKey two-surface shape. Per `planning/done/admin-webhook-subscriptions.md`.
+
+- **New `WebhookSubscription` model** in `src/core/models/WebhookSubscription.js` — endpoint `/api/group/webhook_subscriptions`, with `WebhookSubscriptionList`, `WebhookSubscriptionForms.{create,edit}`, and a `normalizePayload(formData)` helper that converts the form's comma-separated `events` string into the JSON array the server expects. Both admin surfaces share the helper so the string→array conversion lives in exactly one place. Prototype `toggleActive()` flips `is_active` and PUTs the change.
+- **Per-group Webhooks section inside `GroupView`** under the **Access** divider directly after **API Keys** (icon `bi-broadcast`, `manage_group` permission gate). The section is a `WebhookSection` composite that stacks a small `WebhookSecretPanel` above a `ListView` of `WebhookSubscriptionListItem` cards. Each subscription row shows the URL (mono, truncated), event chips, status badge, inline active toggle, and a trash button — same card pattern as the recent ApiKey reshape (no table chrome for a typical 1–10 rows per group). Create / inline-delete / inline-toggle / row-click-to-edit all wired through GroupView so we own the confirm copy, toast feedback, and refetch.
+- **Webhook signing secret panel**. Two actions: **Reveal** posts to `POST /api/group/webhook_secret` with an empty body; **Rotate** posts `{rotate: true}` after a destructive `Modal.confirm`. Both open a dismissal-protected reveal dialog (`backdrop: 'static'`, `keyboard: false`) with a monospaced `user-select-all` block themed via Bootstrap surface tokens and an inline `data-action="copy-to-clipboard"` button (handled by the inherited `View.onActionCopyToClipboard` — no custom JS). The panel does NOT auto-fetch on mount: the backend auto-mints on first POST, so a render-time call would silently create a secret the operator never asked for. Metadata (`created_at`, `last_rotated_at`) populates the panel only after a successful reveal or rotate.
+- **Standalone `WebhookSubscriptionTablePage`** at route `system/webhook-subscriptions`, registered under **System → Webhook Subscriptions** in the admin sidebar (`manage_groups` / `manage_group`). Columns: id · url (truncated mono) · events (badge formatter, `visibility: 'lg'`) · group · status · created. The Add flow calls `WebhookSubscriptionForms.normalizePayload` before `model.save(payload)` so the events transform behaves identically across both surfaces.
+- **`WebhookSubscriptionView`** detail modal — header with `bi-broadcast` icon, full URL, status, and a ContextMenu with Edit / Activate-Deactivate / Delete. `WebhookSubscription.VIEW_CLASS = WebhookSubscriptionView` registered at file load so `clickAction: 'view'` on both the per-group ListView and the standalone TablePage resolve the modal class automatically.
+- **Reuses `TagInput` (`type: 'tags'`)** for the events chip input — no new framework primitives. Helper text on the field calls out that names are free-form strings published by the emitting service, with examples (`invoice.paid`, `verification.completed`).
+- **Tests.** `test/unit/WebhookSubscription.test.js` source-text-pins the endpoint, form field shapes, and the `toggleActive` body — then extracts `normalizePayload` from the live source via brace-walking and runs it against six cases (comma split, trim/empty drop, array passthrough, missing field, no-mutate, null input). `test/unit/WebhookSubscriptionTablePage.test.js` pins the page identity, column order, the normalize-before-save call in `onActionAdd`, the admin nav registration, and the GroupView Webhooks section ordering + the no-auto-fetch-secret invariant + the static-backdrop reveal dialog + the destructive rotate confirm. GroupView Modal-pipeline integration tests aren't feasible in the current harness (called out in the planning doc).
+- **Docs.** New `## WebhookSubscription & WebhookSubscriptionList` section in `docs/web-mojo/models/BuiltinModels.md` (after the ApiKey section), and a `## Webhook Subscriptions` section in `docs/web-mojo/extensions/Admin.md` describing both surfaces, the no-auto-mint secret panel behaviour, and the events normalization contract. `WebhookSubscriptionTablePage` / `WebhookSubscriptionView` added to the `Importing Individual Pages & Views` example imports.
+
 ### Forms · `columns: { xs, sm, md, lg, xl, xxl }` now actually renders responsive Bootstrap classes
 
 - **Field-level responsive `columns` is wired up end-to-end.** `FormBuilder.buildFieldHTML` now recognises the object form documented in `forms/FieldTypes.md`, `forms/README.md`, and `pages/FormPage.md` — `columns: { xs: 12, md: 4 }` emits `class="col-12 col-md-4"` (and similarly for `sm`/`lg`/`xl`/`xxl`). Previously the object stringified to `col-[object Object]`, which Bootstrap silently ignored, so every responsive field collapsed to full-width and stacked. The integer form (`columns: 6` → `col-6`) is unchanged; an empty object falls back to `col-12`; `field.class` extras are still appended.