npm - @visns-studio/visns-components - Versions diffs - 6.32.3 → 6.34.3 - Mend

@visns-studio/visns-components 6.32.3 → 6.34.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (53) hide show

package/README.md +483 -0
package/package.json +1 -1
package/src/components/DataGrid.jsx +44 -2
package/src/components/Field.jsx +32 -0
package/src/components/Form.jsx +39 -2
package/src/components/Navigation.jsx +274 -15
package/src/components/Notification.jsx +13 -2
package/src/components/TableFilter.jsx +14 -2
package/src/components/auth/Login.jsx +11 -4
package/src/components/auth/PasskeyEnrolPrompt.jsx +269 -0
package/src/components/auth/Profile.jsx +422 -26
package/src/components/auth/Reset.jsx +1 -1
package/src/components/auth/TwoFactorAuth.jsx +1 -1
package/src/components/auth/Verify.jsx +2 -2
package/src/components/auth/authEndpoints.js +43 -0
package/src/components/auth/passkeyClient.js +102 -0
package/src/components/auth/passkeyPrompt.js +408 -0
package/src/components/auth/profileLayout.js +45 -0
package/src/components/controls/DataGridSearch.jsx +16 -2
package/src/components/controls/DataGridSortSheet.jsx +2 -0
package/src/components/emailCampaigns/BlockEditor.jsx +486 -0
package/src/components/emailCampaigns/CampaignEditor.jsx +614 -0
package/src/components/emailCampaigns/CampaignReport.jsx +98 -0
package/src/components/emailCampaigns/EmailCampaigns.jsx +422 -0
package/src/components/emailCampaigns/EmailLists.jsx +505 -0
package/src/components/emailCampaigns/emailCampaignApi.js +135 -0
package/src/components/generic/ActionButtons.jsx +1 -1
package/src/components/generic/GenericAuth.jsx +197 -21
package/src/components/generic/GenericDetail.jsx +95 -3
package/src/components/generic/GenericMain.jsx +7 -0
package/src/components/generic/StandardModal.jsx +71 -158
package/src/components/sms/SmsCampaigns.jsx +2517 -0
package/src/components/sms/SmsInbox.jsx +20 -5
package/src/components/sms/SmsLineSettings.jsx +2 -5
package/src/components/sms/SmsThreadPanel.jsx +20 -0
package/src/components/sms/smsEndpoints.js +23 -0
package/src/components/styles/DataGrid.module.scss +22 -0
package/src/components/styles/EmailCampaigns.module.scss +922 -0
package/src/components/styles/Form.module.scss +100 -2
package/src/components/styles/Navigation.module.scss +322 -5
package/src/components/styles/Notification.module.scss +140 -8
package/src/components/styles/PasskeyEnrolPrompt.module.scss +105 -0
package/src/components/styles/Profile.module.scss +157 -0
package/src/components/styles/Sms.module.scss +484 -4
package/src/components/styles/StandardModal.module.scss +273 -0
package/src/components/styles/Vault.module.scss +5 -3
package/src/components/styles/global.css +38 -7
package/src/components/utils/navCollapsed.js +201 -0
package/src/components/utils/rowActionSettings.js +76 -0
package/src/components/utils/usePasskeysEnabled.js +84 -0
package/src/components/utils/useShellLayout.js +131 -0
package/src/index.js +107 -1
package/src/utils/rememberTab.js +70 -0

package/README.md CHANGED Viewed

@@ -9,6 +9,335 @@ A comprehensive React component library used by the VISNS Studio team for CRM an
 VISNS Components is a React-based UI component library that provides a set of reusable, consistent, and customizable components for building web applications. It includes components for authentication, data grids, forms, navigation, and more, designed to work seamlessly together.
+## Recent Updates (v6.34.3)
+### The auth fields' values no longer sit on top of their labels
+The sign-in, reset, verify and 2FA screens draw a floating label inside the
+input, and `_authShell.scss` sizes those inputs for it — a 3.35rem box with a
+top-heavy padding so the value clears the label. That rule is `.field input`,
+(0,1,1), and `global.css` sizes every text input through a twenty-clause
+`input[type]:not(...)` chain that outranks it. So the chain won: the box shrank
+to `--field-height`, the padding went horizontal-only, and the value was drawn
+straight through the label. The six auth inputs now carry `visns-auth-input`,
+and both global chains (sizing and focus) exclude it, the same opt-out
+`searchInput` and `filterInput` already have. Apps that keep a global input
+rule of their own can exclude the same class.
+### The shell layout is on `<html>`, where anything can read it
+`GenericAuth`'s `layout` prop — `full` for the header bar, `cms` or `simple`
+for the sidebar rail — decided the shape of the whole page and then stopped at
+`Navigation`. Everything the route table mounts is several components away from
+ever being told, and the answer changes how a screen wants to lay itself out: a
+horizontal tab strip is right on a page that already has a rail down its left,
+and a vertical rail beside a vertical rail is not.
+So the shell now mirrors itself onto `<html>` as `data-layout="full|cms|simple"`,
+exactly the way `density` mirrors itself as `data-density` — one attribute,
+written once by whoever owns the page (and removed on unmount), readable by CSS
+and by JS without a prop being threaded through six components that do not care.
+`getShellLayout()` reads it once, `useShellLayout()` subscribes to it, and
+`isSidebarShell(layout)` answers the question callers actually have; all three
+are exported from the package, and all three answer `'full'` where there is no
+document, which is both the SSR answer and what every app that never passed the
+prop renders. Nothing in the library styles off the attribute, so an existing
+app gains one attribute on `<html>` and changes in no other way.
+### The notification panel opens beside the rail, not off the bottom of it
+With `navigation.actionsPlacement: "sidebar"`, Notifications is a row pinned to
+the FOOT of the rail. The panel is `position: absolute; top: 100%; right: 0` of
+its trigger — which is a panel hanging off the bottom-right corner of a header
+chip, and from a row at the bottom-left of the viewport that is a panel dropping
+off the screen and lying half on the rail, half on the page.
+Inside `[data-nav-actions="sidebar"]` it now anchors to the row's right edge and
+its bottom (`left: calc(100% + var(--nav-action-panel-gap, 10px)); bottom: 0`),
+clearing the rail's own `z-index: 996`, so it floats over the content the way a
+rail's flyout is expected to. The box is a column capped at `min(70vh, 640px)`
+with the notification list as the only part that scrolls, so the header, the
+Desktop alerts row and the footer button stay put however long the list is, and
+it wears the radius and shadow the rail's rows wear. "View all notifications"
+was mid-grey on a grey band — the colour of a disabled control, for the one
+action in the panel — and is now the primary button on the project's own
+`--primary-color`. Below 1024px, where the rail is a drawer and there is nothing
+to its right, the panel opens upward from the row at the drawer's full width.
+Every rule is scoped under the sidebar selector: a `layout="full"` app renders
+the same panel it rendered before, byte for byte.
+### The rail's icons were never drawn
+`renderNav` has always resolved an icon for a sidebar row from `NAV_ICONS` by
+the item's `icon` or, failing that, its `id` — so `dashboard`, `clients`,
+`reports` and `settings` get one with nothing in the config saying so. None of
+them ever appeared, in either state, and once the rail could collapse that left
+a column of blank squares.
+The cause was one rule written for the top bar: `.app-nav .nav-item { svg {
+display: none; visibility: hidden } }`. `.app-nav` is the list class BOTH
+layouts use, so the bar's decision — a row of words, an icon per word would be
+noise — was silently taken for the rail as well. It was not a fight the rail
+could lose on specificity either: the rail's own svg rule is five classes deep
+and outranks it comfortably, but it only ever set `position`, `right`, `opacity`
+and `color`. It never mentioned `display`, so there was nothing for the higher
+specificity to override.
+The two hiding declarations now sit under `.hwrap`, the header layout's own
+root, which the sidebar layouts never match. The rail's rule states
+`display: block; visibility: visible; flex: 0 0 auto` rather than assuming them,
+the row carries `gap: 0.6rem` between icon and label, and the old `right: 8px`
+nudge — which made sense while the icon was hidden and now just pulled the glyph
+into the row's padding — is gone. Collapsed, the row centres what is left.
+### Row actions can be disabled, not just hidden
+A row action could only be taken away per row, with `condition: (row) =>
+boolean`. That is right when the action does not apply to the row, and wrong
+when it applies but is not permitted: an icon present on nine rows and missing
+on the tenth reads as a rendering bug, and it answers none of the question the
+user has, which is "why not this one".
+`disabled: (row) => boolean | string` keeps the icon in the cell and makes it
+inert. A string both disables the action and becomes its tooltip, replacing the
+action's ordinary title — the cell is one 18px glyph and there is nowhere else
+for a reason to go:
+```js
+{
+  id: 'update',
+  disabled: (row) =>
+    row.name === 'Administrator'
+      ? 'The Administrator role cannot be changed.'
+      : false,
+}
+```
+It applies to every action id at once, resolved where the icon component is
+produced rather than in each of the two dozen `case` branches. The icon is drawn
+at 38% opacity with `cursor: not-allowed` (`.vs-action--disabled`), carries
+`aria-disabled="true"` and `tabIndex={-1}`, and swallows its click — dropping
+the handler entirely would let the event reach the row underneath, which on most
+grids opens the record, so "greyed out" would still navigate. Pointer events are
+deliberately left on, or the tooltip explaining the whole thing could never be
+hovered.
+`condition` still hides, both may be set, and a hidden action is never asked
+whether it is disabled. **A throwing predicate is NOT disabled** — the opposite
+of `condition`, which hides on a throw: failing closed there costs a verb the
+user might not have had anyway, while failing closed here would disable a
+legitimate action on every row of the grid on one bad field access. A literal
+(`disabled: true`, or a string) is accepted as well as a predicate.
+### Dialogs on a phone
+`StandardModal` decided its own geometry in JavaScript, per render, from
+`window.innerWidth` and a user-agent sniff. Four things were wrong with that at
+phone size, and the first three are why a long form was hard to finish there.
+**Save was off the bottom of the screen.** The panel scrolled *and*
+`.modal__content` inside it scrolled, both capped at `85vh`. The form's button
+bar is `position: sticky; bottom: 0`, so it stuck to the bottom of the *inner*
+box — which starts below the header and therefore ends below the bottom of the
+outer one. Reaching the end of the form did not reach Save; you had to scroll
+the outer region as well. A dialog is one scroll region now: `.modal__content`
+gives up its cap and its overflow, the panel is the scroller, the header is
+sticky to the top of it and the button bar to the bottom, and both stay on
+screen at every height.
+**`100vh` is not the screen on iOS.** A side sheet was `height: 100vh`, which
+Safari measures as though the address bar were hidden — so the last ~60px of
+the panel, the part with the buttons in it, sat underneath the browser chrome.
+Every height is stated twice now, `vh` then `dvh`, which an inline style object
+cannot do and a stylesheet can.
+**A phone-shaped window was often not "mobile".** The sniff required
+`isMobileUA || (width <= 768 && hasTouch)`, so a 390px viewport that does not
+advertise touch — responsive mode, a narrow window, some webviews — took the
+desktop branch and its `min-width: 600px`, inside 390px of glass, with the page
+scrolling sideways. Width is the only question now, and it is asked in a media
+query: at ≤640px every variant is full-width with the minimums off, the centred
+dialog lands as a **bottom sheet** (rounded at the top, pinned to the bottom
+edge, `92dvh`, clear of `env(safe-area-inset-bottom)`), and the side sheet fills
+the screen with no slide-in, because it has no edge to arrive from. The band
+between 641 and 1024px is fixed too: `large` asked for 800px plus the overlay's
+own padding, so it overflowed every window narrower than 840px.
+**The dialog was underneath the app.** The overlay was `z-index: 1000` and the
+sidebar rail is 1050, so on a `cms` layout the rail painted over the dialog's
+left edge. The order is now written down in one place
+(`StandardModal.module.scss`) and it runs: content header 995, rail actions 996,
+rail 1050, **overlay 1200** (`--modal-z`), **date pickers 1300**
+(`--datepicker-z`), portalled react-select menus 9999. The two upper entries
+matter as much as the lower ones — a date picker and a select menu opened from
+inside a form render into `<body>`, outside the overlay's stacking context, so
+each needs a number above it or it opens *behind* the form. The pickers were
+1060, a number chosen years ago to clear "Bootstrap modals (1050)", and
+`.datepicker-portal-container` had no rule at all.
+Also: page scroll is locked to the value it found rather than to `unset` (which
+used to release the navigation drawer's own lock), `overscroll-behavior` stops a
+scroll that reaches the end of the panel continuing into the page behind it,
+form controls inside a dialog are 16px at `(max-width: 640px) and (pointer:
+coarse)` so iOS does not zoom into them on focus, and the close button is a
+44px target there. `size: "half"` fields already collapsed to one column — the
+form grid is a container query, and a full-width phone panel is always narrow
+enough. `closeOnDocumentClick`, Escape, the focus trap and focus return are
+unchanged, and `customStyles` is still inline and still wins over all of it.
+### The rail collapses, and the tooltips become the labels
+The sidebar rail costs `--sidebar-width` of every page, permanently, to show a
+handful of words. Next to a datagrid that is a column of the table. There is now
+a collapse toggle on the rail's logo plate — a `PanelLeftClose` / `PanelLeftOpen`
+chevron, absolutely positioned against the plate so an expanded rail is laid out
+exactly as it was — and the rail folds down to an icon strip, which is the state
+the tooltips above were written for: rows draw their icon alone, the label is
+clipped to a pixel rather than removed (so it stays the accessible name), and an
+item with no icon shows the first letter of its label in a small circle instead
+of collapsing to an empty square. An expanded nav row is byte-identical to
+6.32.3, wrapper included — the label is only put in an element once the rail is
+collapsed, because this rail's stylesheet styles `span` as a descendant of
+`.nav-item` (a rule that belongs to the group heading) and would otherwise draw
+every row as a `--primary-color` block.
+- **Prop**: `collapsedLogo` on `GenericAuth` (threaded to `GenericMain` and
+  `Navigation`) — the square brand mark for the strip. Optional: with none, the
+  plate holds the toggle alone, which reads better than a wordmark cropped to
+  two letters.
+- **Storage**: `localStorage['visns.nav.collapsed']`, read inside a `try` (a
+  private window that throws on access is simply expanded) and read
+  **synchronously in a lazy `useState` initialiser**, so a remembered collapse
+  is in place for the first paint instead of snapping narrow after it.
+- **Attribute**: `<html data-nav-collapsed="true">`, written by `Navigation` in
+  a `useInsertionEffect`, the same mechanism as `data-layout` and `data-density`.
+  Absent means expanded, so an app whose toggle has never been clicked matches
+  none of the new rules.
+- **CSS variables**: collapsed, the root redefines
+  `--sidebar-width: var(--sidebar-collapsed-width, 64px)`. That one lever moves
+  the rail's width, the content's `margin-left` and everything else already
+  sized against the variable; an app that retuned `--sidebar-width` keeps its own
+  expanded figure. The width animates over `var(--speed, .18s)`.
+- **Helpers**: `useNavCollapsed()`, `getNavCollapsed()` and `setNavCollapsed()`
+  are exported, for an app that wants its own shortcut or a focus-mode button.
+Groups with children expand the rail rather than trying to open a two-level menu
+inside a 64px strip — the simplest behaviour that cannot be mispositioned. Below
+1024px the rail is the mobile drawer, where there is no width to reclaim: the
+toggle is not rendered there, the attribute is not applied, and every collapsed
+rule sits inside `min-width: 1025px`, so drawer behaviour is exactly as it was.
+`layout="full"` has no rail and is untouched.
+### Every row in the rail has a tooltip, not just the bell
+The bell carried one because it is a mounted component that brought its own; the
+navigation rows and the other account rows — Profile, Logout — had nothing. They
+all now carry the same `data-tooltip-id="system-tooltip"` / `data-tooltip-content`
+pair every header chip has always had, read by the single `<Tooltip>` GenericAuth
+mounts, with the label taken from the item's own `label` and falling back to the
+humanised id. They are drawn **only while the rail is collapsed** (see below) —
+an icon strip is unreadable without them, and a tooltip repeating a label printed
+six pixels to its right is noise; the attributes are omitted rather than the
+tooltip disabled. `place="right"`, not the header's `"bottom"`: a tooltip under a
+row in a vertical list covers the next row, which is the one you were about to
+read.
+No `title` attribute goes anywhere near them — the native tooltip and this one
+both fire, half a second apart, and you get the label twice in two boxes.
+`Notification` takes a `tooltipPlace` prop for the same reason, defaulting to
+the `"bottom"` it has always used. Header-layout chips are untouched.
+### Profile tabs follow the shell
+The account screen drew a "My Profile" header card and then a second card
+holding a two-item rail beside the content — on a `cms` app, a vertical
+navigation column immediately beside the app's own vertical navigation column,
+spending a fifth of the content width to show two words, with "Overview" printed
+twice half a centimetre apart.
+`Profile` takes a `tabLayout` prop now, `'rail' | 'underline'`, the same two
+names and the same `<TableFilter variant="underline">` strip that `GenericIndex`
+and `GenericDetail` use. **The default is resolved from the shell layout above**:
+`underline` when the app is `cms` or `simple`, `rail` when it is `full`. So a
+sidebar app gets the strip with no host edit, a top-bar app keeps the rail it has
+always had, and a page that knows better names the prop and overrides both. In
+strip mode the title is the page's own title row rather than a card, the tabs sit
+directly on one content card, and the panel header — which only ever repeated the
+selected tab's name — is not drawn. Rail mode renders the markup and the styles
+it always did.
+### Passkeys: asked once, on the device that can use them
+The login screen has had a "Sign in with a passkey" button since 6.32 — for the
+people who had already set one up somewhere else. Nobody had, because nothing
+ever offered. `GenericAuth` now makes the offer itself, once, immediately after
+a sign-in, and gives the account screen a tab for managing what was enrolled.
+`passkeys` grows from a boolean to `boolean | object`:
+```jsx
+<GenericAuth
+    passkeys={{
+        enabled: true,        // default true — an object IS the opt-in
+        promptOnLogin: true,  // default true; false = offer, never interrupt
+        snoozeDays: 30,       // how long "Not now" holds for
+        copy: { title: 'Sign in faster next time' },
+    }}
+/>
+```
+`true` keeps everything it meant (the login button) and adds the prompt and the
+tab. **`false` or absent renders nothing at all** — no button, no tab, no
+prompt, no request — so an app that never passed the prop is unchanged.
+The dialog is offered only when every one of these holds, and the decision is
+one pure function (`shouldPromptForPasskey` in `auth/passkeyPrompt.js`) with a
+test per gate:
+- the host enabled passkeys and left `promptOnLogin` on;
+- `isPasskeySupported()` — the browser can actually do WebAuthn;
+- **somebody signed in during this page's life**, rather than refreshing a page
+  whose session already existed. `GenericAuth` hands the auth screens a
+  `markAuthenticated` wrapper instead of its raw `setIsAuthenticated`, so a
+  sign-in from `Login`/`TwoFactorAuth` is distinguishable from the profile check
+  that finds an existing session. Nothing is written to storage for this: a flag
+  in `sessionStorage` outlives the page that wrote it, and this value cannot;
+- they did not sign in **with** a passkey — `Login` reports
+  `setSystemAuth(true, { method: 'passkey' })`, and that person is never asked;
+- they hold no passkeys yet, known from a GET of the index endpoint. A 404, a
+  failure or an unreadable answer means *don't prompt* — never *prompt*;
+- they have not dismissed it on this device.
+The dismissal lives in `localStorage` under **`visns.passkeys.prompt.<userId>`**
+as `{dismissedAt, never}` — per user, because two accounts sharing a browser are
+two answers. "Not now" (and the X, the backdrop, and cancelling the browser's own
+sheet) writes a snooze; "Don't ask again" writes `never: true`. Every read and
+write is in a try/catch, so a browser with site data blocked degrades to "not
+remembered" rather than to a thrown error.
+Endpoints are the `config('visns-packages.passkeys.uris')` defaults, overridable
+one at a time through the existing `endpoints` prop, exactly like the sign-in
+pair:
+| key | default |
+| --- | --- |
+| `passkeyIndex` | `/ajax/passkeys` |
+| `passkeyRegisterOptions` | `/ajax/passkeys/options` |
+| `passkeyRegister` | `/ajax/passkeys/register` |
+| `passkeyDestroy` | `/ajax/passkeys/{id}` |
+The ceremony itself — options, `createPasskeyCredential`, store — is one shared
+`enrolPasskey(endpoints, { name })` in `auth/passkeyClient.js`, called by both
+the prompt and the profile tab so the two cannot drift.
+**The profile's Passkeys tab** (list, add, remove) appears whenever the feature
+is on, with no second prop to pass: `GenericAuth` mirrors the switch onto
+`<html data-passkeys="on">` and `Profile` reads it, the same arrangement
+`data-layout` uses — necessary because `Profile` is mounted by the consuming
+app's own `routeConfig` and is never handed `GenericAuth`'s props. `/profile/passkeys`
+and `?tab=passkeys` deep-link to it. A host can still force it either way with
+`<Profile passkeys={true|false} />`.
 ## Recent Updates (v6.32.3)
 ### The nav dropdowns open where the pointer left them
@@ -102,6 +431,32 @@ embedded rows already laid the same node out as a flex row with a 0.75rem gap;
 the `.crmtitle` / `.crmtitleSimple` bar now does the same (wrapping when the
 bar is narrow). CSS only; no markup or config change.
+### Also in this release, merged from `main`
+Five releases landed on `main` while this line was being built and are part
+of 6.34.0 as well:
+- **`SmsCampaigns`** — see below.
+- `SmsThreadPanel`: the opted-out note says Zoom enforces the block until the
+  number texts START.
+- `SmsCampaigns`: "Open conversation" on a campaign recipient navigates through
+  the router instead of a full reload.
+- `GenericDetail`: the open tab is remembered in the address bar as `?tab=`
+  (`src/utils/rememberTab.js`).
+- Every button says what it does on hover — action buttons carry a `title`.
+### `SmsCampaigns` — bulk sends from an imported list
+One screen for a mailshot: paste names and mobiles or drop a CSV/XLSX (parsed
+in the browser), pick the line, type one message with `{first_name}` /
+`{name}` / `{<column>}` chips beside a server-rendered preview and a segment
+count, review the server's report (invalid rows, duplicates, opted-out
+numbers), then start. A per-campaign view shows progress with pause, cancel
+and retry-failed, and an opt-out manager lists the numbers that texted STOP.
+`SmsInbox` gains `campaignsUrl`; `SmsThreadPanel` prints a muted line when a
+thread's number has opted out, disabling nothing. Ten routes added to
+`makeSmsEndpoints`.
 ## Recent Updates (v6.31.2)
 ### `MergeEntity` compares the two records it is actually merging
@@ -854,6 +1209,134 @@ and `.sms.updated`, both carrying `{thread, message}`.
 `message` (MessageSquare) and `messages` (MessagesSquare) were added to
 `SETTING_ICONS`.
+#### `SmsCampaigns` — bulk SMS on an imported list (6.31.0)
+The other half of the messaging module: one message to a list of numbers, sent
+one at a time down a line at the rate the server allows. The inbox is a
+conversation with a person; this is a send to a spreadsheet, and everything it
+does differently follows from that.
+| Prop | Default | Notes |
+| --- | --- | --- |
+| `endpoints` | `DEFAULT_SMS_ENDPOINTS` | Merged over the defaults, exactly as everywhere else in the module. |
+| `userProfile` | `null` | Accepted for consistency; unread. |
+| `canManage` | `true` | False leaves the list, a campaign's page and the opt-out register readable and takes away New campaign, every action button and the opt-out Add/Remove. |
+| `pageTitle` | `'SMS campaigns'` | |
+| `inboxUrl` | `'/messages'` | A sent recipient links to `` `${inboxUrl}?thread=<id>` `` — the same deep link `SmsInbox` reads. |
+| `pollMs` | `5000` | The list polls only while some campaign is `sending`; a campaign's own page polls only while it is. `0` turns both off. |
+Three views in one component, switched by local state. Only the detail view is
+worth a link, so it is the only one that writes to the address bar —
+`?campaign=<id>`, read once on mount and kept in step with
+`history.replaceState`, the arrangement `SmsInbox` makes with `?thread=`. The
+wizard's step is deliberately NOT in the URL: a half-built campaign is not
+something a link could restore, so a `?step=2` anybody could paste would open
+on an empty recipient list.
+**Step one takes a list two ways**, side by side and of equal weight. A `.csv`
+or `.xlsx` is parsed **in the browser** — `xlsx`, imported lazily on the first
+drop the way `qrDecode.js` imports jsQR — and then two selects say which column
+is the name and which the mobile, defaulted by header heuristics and re-derived
+as they change, so correcting one fixes the table in front of the person
+correcting it. Every other column travels with the row in `extra`, **keyed by
+its own heading**, which is what makes the placeholder chips honest: the chip
+inserts the same string the object is keyed by, so a heading called `Client Ref`
+and the token `{Client Ref}` cannot disagree. The other way in is a textarea of
+`Name, 04xx xxx xxx` lines — split on the tab where there is one, otherwise on
+the LAST comma, because the CRM writes people surname-first and splitting on the
+first would make "Darshini, 0412 345 678" the phone number.
+Two details in the parsing are worth knowing because both fail silently
+otherwise. A cell arriving as a JS **number** of nine digits beginning with 4 is
+an Australian mobile that Excel stored as `412345678`, and the leading zero goes
+back on. And a sheet whose first row is a person rather than a heading keeps
+that person — the test for it is narrow (nothing in row one reads as a heading
+we know AND one of its cells is a phone number) because both ways of guessing
+wrong are visible on the preview table immediately.
+**Step two counts the footer.** `segmentCount` is run over `body + "\n" +
+footer` whenever `footer_required`, because that is the message the recipient's
+phone is charged for — a body that fits one part beside a footer that does not
+is a two-part message, and a counter reading "1 SMS" would be wrong on every
+send. The body limit shown is `max_body_length − footer.length − 1` for the same
+reason. The preview panel on the right is fetched from `campaigns/preview`,
+debounced 400ms: **the server renders it**, so what is on screen is the same
+code that fills `{first_name}` when the campaign runs rather than a second
+implementation that agrees until it does not.
+**Step three draws the report before anything is sent.** Create answers with
+`{accepted, invalid, duplicates, opted_out}` and all four are shown — the
+invalid rows in a table with the reason per row — and only then is there a
+**Start sending** button, beside Save as draft. A 422 is printed at the top of
+the step, never as a toast alone: the refusal is about a list the person is
+standing in front of, and a notice that fades is no use for reading one.
+**Nothing is optimistic anywhere.** Every action posts and the campaign is then
+re-read. A Pause that greyed itself out and lost a race with the sender would
+leave the screen saying "paused" while messages went on going out, which is the
+one lie this page must never tell.
+`sending` is drawn in the brand tint rather than amber (`campaignPillLive`). A
+campaign doing exactly what it was told to do is not a warning, and a page of
+amber chips teaches people to stop reading them — which would cost the state
+that IS one: `paused`, where nothing is going out until somebody acts.
+#### The opt-out register
+A `StandardModal` off the campaign list — search, the table (number, source,
+note, who, when), an Add row, and Remove behind the library's confirm dialog.
+A campaign skips every number on it and says so in the report.
+One-to-one replies are deliberately NOT affected, and `SmsThreadPanel` says so:
+with `thread.opted_out` true it draws one muted line above the composer —
+*"This number has opted out of messages. A reply to their message is still
+allowed."* — and **disables nothing**. The person texted us; refusing to let a
+member of staff answer because a bulk send would skip them is the wrong answer
+to the wrong question.
+#### `SmsInbox` gains `campaignsUrl`
+`null` by default, and absent means no link: a deployment with no campaigns
+screen must not grow one. Set it and a quiet **Campaigns** ghost button appears
+beside Messaging settings — beside the settings link rather than beside New
+message, because a campaign is somewhere you GO and a new message is something
+you DO.
+#### Campaign endpoints
+Added to `makeSmsEndpoints`, so a consumer moving the base moves these too.
+```
+GET    {base}/campaigns                      -> {campaigns: [Campaign], settings: {per_minute, max_recipients, footer, footer_required, max_body_length}}
+POST   {base}/campaigns                      {line_id, name, body, recipients: [{name?, number, extra?}]}
+                                             -> 201 {campaign, report: {accepted, invalid: [{row, name, number, reason}], duplicates, opted_out: [{name, number}]}}
+POST   {base}/campaigns/preview              {body, recipients} -> {previews: [{name, number, body, segments}]}
+GET    {base}/campaigns/{id}                 -> {campaign}
+GET    {base}/campaigns/{id}/recipients?status&page  -> {recipients: [Recipient], meta: {total, per_page, current_page, last_page}}
+POST   {base}/campaigns/{id}/start | /pause | /cancel | /retry-failed  -> {campaign}   (422 {message} on an illegal transition)
+DELETE {base}/campaigns/{id}                 (draft only)
+GET    {base}/opt-outs?search                -> {opt_outs: [{id, number, display_number, source, note, user, created_at}]}
+POST   {base}/opt-outs                       {number, note?} -> 201 {opt_out}
+DELETE {base}/opt-outs/{id}
+```
+`Campaign` is `{id, name, status: draft|sending|paused|completed|cancelled,
+line, body, footer, user, counts: {total, pending, sent, failed, skipped},
+progress, last_error, started_at, completed_at, created_at,
+estimated_minutes_remaining}`; `Recipient` is `{id, name, number,
+display_number, status: pending|sent|failed|skipped, error, retries, sent_at,
+message_id, thread_id}`.
+Lines come from the module's own `GET {base}/lines`. **Both `{lines}` and
+`{data}` are read** — the first is the campaign contract's spelling, the second
+is what that route has always answered for the inbox — so the page works
+against either without a second route.
+Also exported: `DEFAULT_CAMPAIGN_SETTINGS`, `CAMPAIGN_STATUSES`,
+`RECIPIENT_STATUSES`, and the pure parsers `parsePastedRecipients`,
+`readSheetRows`, `recipientsFromRecords`, `defaultCampaignName` and
+`estimateMinutes`.
 #### The fixture
 `yarn dev:sms` serves `dev/sms-fixture.html` on port 5181 against an in-memory

package/package.json CHANGED Viewed

@@ -93,7 +93,7 @@
         "react-dom": "^17.0.0 || ^18.0.0 || ^19.0.0"
     },
     "name": "@visns-studio/visns-components",
-    "version": "6.32.3",
+    "version": "6.34.3",
     "description": "Various packages to assist in the development of our Custom Applications.",
     "main": "src/index.js",
     "files": [

package/src/components/DataGrid.jsx CHANGED Viewed

@@ -115,6 +115,7 @@ import {
     isPickerRowAction,
     normalisePickerOptions,
     pickerOptionsCacheKey,
+    resolveRowActionDisabled,
     splitSettingEntries,
 } from './utils/rowActionSettings';
@@ -4303,12 +4304,50 @@ const DataGrid = forwardRef(
                 return null;
             }
+            /*
+             * Every `case` above funnels through here, which is the point:
+             * `disabled` is answered ONCE, for whatever icon the id resolved
+             * to, rather than in twenty-four branches that would drift.
+             *
+             * `disabled` keeps the action in the row and makes it inert;
+             * `condition` (above) still removes it. See
+             * `resolveRowActionDisabled` in utils/rowActionSettings.js for the
+             * contract and for why a throwing predicate is NOT disabled.
+             */
             function getIconComponent(IconComponent) {
+                const { disabled, reason } = resolveRowActionDisabled(s, d);
+                /*
+                 * A disabled action still SWALLOWS the click. Dropping the
+                 * handler entirely would let the event reach the row
+                 * underneath, and on most grids that opens the record — so
+                 * "greyed out" would still navigate. `handleIconClick`'s own
+                 * first two lines are these two, for the same reason.
+                 */
+                const swallow = (event) => {
+                    event.preventDefault();
+                    event.stopPropagation();
+                };
                 return (
-                    <span key={`setting-${s.id}`} onClick={handleIconClick}>
+                    <span
+                        key={`setting-${s.id}`}
+                        onClick={disabled ? swallow : handleIconClick}
+                        className={
+                            disabled ? styles['vs-action--disabled'] : undefined
+                        }
+                        aria-disabled={disabled ? 'true' : undefined}
+                        tabIndex={disabled ? -1 : undefined}
+                    >
                         <IconComponent
                             data-tooltip-id="system-tooltip"
-                            data-tooltip-content={tooltipContent}
+                            /* The reason replaces the action's own tooltip:
+                               the cell is one 18px glyph and there is nowhere
+                               else for it to go. No reason given — a bare
+                               `true` — keeps the normal title. */
+                            data-tooltip-content={
+                                disabled && reason ? reason : tooltipContent
+                            }
                             strokeWidth={2}
                             size={18}
                             className={styles.tdaction}
@@ -7361,6 +7400,7 @@ const DataGrid = forwardRef(
                             <button
                                 type="button"
                                 className={styles.rowActionPickerClose}
+                                title="Close this list without choosing anything"
                                 aria-label="Close"
                                 onClick={closeActionPicker}
                             >
@@ -7392,6 +7432,7 @@ const DataGrid = forwardRef(
                                                     <button
                                                         type="button"
                                                         className={`${styles.rowActionPickerOption} ${styles.rowActionPickerClear}`}
+                                                        title="Clear this row's current choice and leave it set to nothing"
                                                         onClick={() =>
                                                             handleActionPickerChoice(
                                                                 null
@@ -7408,6 +7449,7 @@ const DataGrid = forwardRef(
                                                     className={
                                                         styles.rowActionPickerOption
                                                     }
+                                                    title={`Set this row to ${option.label}`}
                                                     onClick={() =>
                                                         handleActionPickerChoice(
                                                             option