@the-portland-company/shell 0.55.0 → 0.57.0
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.
- package/CHANGELOG.md +70 -0
- package/dist/app-chrome.cjs +412 -63
- package/dist/app-chrome.cjs.map +1 -1
- package/dist/app-chrome.d.cts +13 -0
- package/dist/app-chrome.d.ts +13 -0
- package/dist/app-chrome.js +136 -10
- package/dist/app-chrome.js.map +1 -1
- package/dist/{chunk-K5GWJSHE.js → chunk-TMOZTLUZ.js} +281 -58
- package/dist/chunk-TMOZTLUZ.js.map +1 -0
- package/dist/native.cjs +279 -54
- package/dist/native.cjs.map +1 -1
- package/dist/native.d.cts +6 -1
- package/dist/native.d.ts +6 -1
- package/dist/native.js +1 -1
- package/package.json +1 -1
- package/dist/chunk-K5GWJSHE.js.map +0 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,3 +1,73 @@
|
|
|
1
|
+
## 0.57.0 — 2026-09-30
|
|
2
|
+
|
|
3
|
+
### Fixed — 10DLC alert no longer auto-redirects on every login (`src/native/chromeActions.tsx`)
|
|
4
|
+
|
|
5
|
+
The once-per-session `10dlc_registration` alert redirect fired on every
|
|
6
|
+
login because every login is a new browser session (a fresh
|
|
7
|
+
`sessionStorage`), so the full-page `window.location.assign` re-booted the
|
|
8
|
+
app on every single sign-in — visible to the user as a second loading-screen
|
|
9
|
+
blink that always lands on
|
|
10
|
+
`/organization-settings/subscription-billing/text-email`. The auto-redirect
|
|
11
|
+
is removed entirely. The alert still surfaces in the notifications
|
|
12
|
+
bell/panel (unread, like any other alert) — that panel is now the only
|
|
13
|
+
user-visible surface for it.
|
|
14
|
+
|
|
15
|
+
### Added — Spec overlay top-bar action, Spencer + Ben only (`./native`, `./app-chrome`)
|
|
16
|
+
|
|
17
|
+
A new `SpecOverlayAction` top-bar control (wired into `ChromeTopBarActions`,
|
|
18
|
+
between DevNotes and Support) shows the live spec/visual-regression status
|
|
19
|
+
of the current page, sourced from the Specs app's overlay API
|
|
20
|
+
(`https://specs.politogyvrm.com/api/overlay/access` and `/api/overlay/status`).
|
|
21
|
+
It renders nothing — no icon, no network noise — for anyone the access
|
|
22
|
+
check doesn't allow; the allow/deny answer is cached in `sessionStorage`
|
|
23
|
+
for the session. When allowed, a "Spec" button shows a rounded
|
|
24
|
+
mismatch-percentage badge (green when the compare passed, red when it
|
|
25
|
+
didn't, a neutral "—" when the page has no compare target yet) and opens a
|
|
26
|
+
480px right-hand drawer with the spec title, "Open spec" / "Compare tab"
|
|
27
|
+
links, and an iframe of the live overlay. Status re-fetches (debounced
|
|
28
|
+
300ms) on route change and org change. All calls are plain
|
|
29
|
+
`fetch(..., { credentials: 'include' })` against the Specs origin — this
|
|
30
|
+
does NOT go through the same-origin chrome proxy `fetchJson`.
|
|
31
|
+
|
|
32
|
+
### Fixed — de-duped chrome fetches + lazy DevNotes boot fetch (`src/native/chromeActions.tsx`, `src/app-chrome/index.tsx`)
|
|
33
|
+
|
|
34
|
+
`useChromeOrgs`, `me`, `FuelAction`'s `communications/fuel-status`, and
|
|
35
|
+
`NotificationsAction`'s `notifications` were each fetched 2-4x per page load
|
|
36
|
+
(consumers mounting independently), costing 1-3.5s per redundant call. Added
|
|
37
|
+
a provider-scoped in-flight-promise + 30s-TTL cache
|
|
38
|
+
(`dedupedFetch`/`invalidateChromeCache` on `useNavChrome`) keyed by
|
|
39
|
+
`(path, orgId)`, so concurrent consumers share one request and org switches
|
|
40
|
+
naturally miss the cache. Separately, DevNotes' boot-time reads (tasks,
|
|
41
|
+
task types, task lists, collaborators, app-link status, capabilities — up to
|
|
42
|
+
6.8s cold) are deferred until the DevNotes panel is first opened by wrapping
|
|
43
|
+
the adapter passed into `@the-portland-company/devnotes`'s
|
|
44
|
+
`DevNotesProvider`; the launcher button renders instantly and unblocks the
|
|
45
|
+
gated calls via `onPointerDownCapture` before the click fires. The unread
|
|
46
|
+
badge count still resolves on boot, via `requestIdleCallback` instead of
|
|
47
|
+
blocking it.
|
|
48
|
+
|
|
49
|
+
## 0.56.0 — 2026-09-30
|
|
50
|
+
|
|
51
|
+
### Fixed — mode continuity for dual-mode apps (a2p)
|
|
52
|
+
|
|
53
|
+
a2p (Specs/A2P) is the SMS/MMS delivery engine for BOTH Relationship Mode and
|
|
54
|
+
Campaign Mode, but it was registered `mode: 'campaign'` only, so the
|
|
55
|
+
Relationship tree's "SMS/MMS Blast" row sent users into a2p and the whole left
|
|
56
|
+
nav flipped to the Campaign tree + "Campaign Mode" pill — a jarring identity
|
|
57
|
+
switch for a user who never left Relationship Mode.
|
|
58
|
+
|
|
59
|
+
`POLITOGY_APPS[app]` now supports an optional `dual: { modes, defaultMode }`.
|
|
60
|
+
a2p declares `dual: { modes: ['relationship', 'campaign'], defaultMode:
|
|
61
|
+
'campaign' }`; its EFFECTIVE mode is resolved per-visit by the new
|
|
62
|
+
`resolveActiveMode` (`src/mode-preference.ts`): `?mode=` query param → the new
|
|
63
|
+
cross-subdomain `politogy_active_mode` cookie → the app's own default. Every
|
|
64
|
+
pinned app and core writes that cookie with its own mode, so arriving at a2p
|
|
65
|
+
after using Relationship Mode elsewhere resolves to Relationship even without
|
|
66
|
+
an explicit `?mode=` link. The Relationship tree's "SMS/MMS Blast" row now
|
|
67
|
+
links straight to a2p with `?mode=relationship` (the dead
|
|
68
|
+
`/relationship/sms-mms-blast/*` core routes are removed); the Campaign tree's
|
|
69
|
+
existing A2P row is unchanged.
|
|
70
|
+
|
|
1
71
|
## 0.55.0 — 2026-09-30
|
|
2
72
|
|
|
3
73
|
### Fixed — org pill body no longer takes the Mode accent (`./native`)
|