Overview - Ghost

Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
main
a5e10857 🐛 Fixed complimentary members being unable to upgrade on non-USD sites (#29055) fixes https://linear.app/ghost/issue/ONC-1877/ ## Problem Complimentary members on sites that don't sell in USD saw "Sorry, no paid plans are available." on the change-plan page instead of the available paid plans, blocking upgrades entirely. ## Root cause Three pieces interact: 1. Ghost core builds a synthetic subscription for comped members with a **hardcoded USD currency** and an **empty `price_id`** (`attachSubscriptionsToMember` in `member-bread-service.js`). 2. Portal's `AccountPlanPage.getInitialState()` filtered the available prices by the active price's currency whenever an active price existed — including the synthetic one. On any non-USD site this left zero plans. 3. #22512 (June 10) added an empty state that renders "Sorry, no paid plans are available." when the plans list is empty. Before that commit the empty list was harmless, because the upgrade section renders products from `getUpgradeProducts()`, which already skips the currency filter when `price_id` is empty — so comped members still saw all plans and could upgrade. This is why the bug only reproduces on non-USD sites: on USD sites the synthetic currency happens to match. ## Fix Guard the currency filter with `activePrice?.id` instead of `activePrice`, matching the existing guard in `getUpgradeProducts()`. Real Stripe subscriptions always carry a `price_id`, so paid members' behaviour is unchanged; synthetic complimentary/gift subscriptions no longer wrongly empty the plans list. A core-side follow-up (using the tier's real currency instead of hardcoded USD when building the synthetic subscription, which also affects gift members whose gift lookup fails) is tracked separately.
by Peter Schulz
Succeeded
main
83e6dd9e Gated automations sidebar link on Owner/Admin access (#28900) ## Summary The **Automations** sidebar nav link was gated on `canManageMembers`, which returns true for **Owner, Administrator, and Super Editor**. However, the automations API only grants `browse`/`read`/`edit` permission to **Administrator** and **Admin Integration** (the **Owner** role inherits all permissions). As a result, a **Super Editor** saw the Automations link in the sidebar but hit a permission error from the API when trying to view or edit an automation. This tightens the frontend to match what the API actually allows, by gating on an automations-specific Owner/Admin check rather than `canManageMembers`. ## Changes - Added a `canManageAutomations(user)` helper in `apps/admin-x-framework/src/api/users.ts` that returns true only for **Owner** and **Administrator** (mirrors the API permission rows; the Owner role inherits all permissions). - Gated the Automations sidebar nav link in `apps/admin/src/layout/app-sidebar/nav-content.tsx` on `canManageAutomations` instead of `canManageMembers`. - Added a unit test for `canManageAutomations` covering Owner/Admin (allowed) and Super Editor/Editor/Author/Contributor (denied). ## Testing - `pnpm exec vitest run test/unit/api/users.test.ts` — passes (4/4) - Lint + typecheck clean for `apps/admin-x-framework` and `apps/admin` Co-authored-by: Claude <noreply@anthropic.com>
by Peter Schulz
Succeeded
claude/slack-session-i55dx8
e3200614 Merge 5b734e17749f155369f067c0f7f83a853cb8bec7 into 1de328d8203cbfc81beadfea966982b049293fa2
by Peter Schulz