feat(admin): Switch User — swap login between two existing accounts

[giladresisi]

Why this is needed

Occasionally a user wants to replace the login on their account with the login of another account they own — for example, they signed up with Google but now want to sign in with email/password, or they keep two separate accounts and want one account's credentials to reach the other's data — without losing anything (organization, subscription, channels, media, history). Today an admin has no safe way to do this.

This PR adds a super-admin "Switch User" action in the impersonation bar that swaps the login identity between two existing accounts while each account keeps all of its data in place, so each login now reaches the other's account. It is fully reversible — switching the same two back restores the original state.

What is swapped (and what is not)

Only the login identity on the two User rows moves: email, password (bcrypt hash), OAuth provider/id, and the activated (email-verification) flag. Everything that makes up the account — its User.id, organization memberships, roles, subscription, channels, media — stays exactly where it is. After the switch, signing in with account A's new email authenticates as account A and reaches all of A's data; the two people effectively swap seats.

Multi-user organizations

Because the swap rewrites only the two User rows (never memberships or Organization rows), multi-member orgs on either or both sides — including a shared org — cannot cause errors or move any data. The org-scoped side effects are guarded so nothing spills onto co-members:

• the in-app "your login changed" notice is posted only for orgs where the switched user is the sole member (a shared org's other members must not see it); the email always reaches the switched login;
• the Stripe billing-email sync is owner-only (SUPERADMIN), so a non-owner's switch cannot rewrite a shared org's receipts email;
• that sync is de-duplicated per customer, so two co-owners of the same org never race concurrent updates.

The other members' accounts, roles, and data are never touched.

How the swap is atomic

(email, providerName) is a unique index checked per-statement, so two emails cannot be traded directly. The swap runs inside a single Postgres interactive transaction with a deterministic FOR UPDATE lock on both rows: it parks one account on a unique throwaway email, then fills each freed slot in order. This is atomic and restart/redeploy-safe — a crash before commit rolls back cleanly and the throwaway email never persists — and disjoint switches can run in parallel.

Why the three preceding commits

The main feature sits on top of three smaller commits that fix pre-existing gaps in the admin/billing surface it touches. They are kept separate so each is reviewable and revertable on its own:

1. fix(admin): don't hit Stripe for admin-granted subscriptions — admin-granted subscriptions store the user id in Organization.paymentId (not a real cus_... customer), so every billing path that fed it to Stripe threw "No such customer" (flooding the logs on billing-page load). This guards them all to skip Stripe when there is no real customer, hides the billing-portal button, and rejects the portal/cancel endpoints with a clean 400.
2. fix(admin): exclude the current admin from the impersonation search — the impersonation/switch picker listed the acting admin themselves; this excludes them so an admin cannot impersonate or switch into their own account.
3. feat(admin): allow removing an admin-granted subscription — the impersonation bar could grant a free/admin subscription but not undo it; this adds a super-admin "Remove Subscription" action (DB-only, no Stripe) and hides the now-redundant Cancel controls for admin-granted subs.

These are cleanup and fixes of real errors and logical/semantic gaps in the same admin area; Switch User builds on the corrected behavior.

Testing

Validated end-to-end (details in the individual commit messages): credential swap with round-trip restore, an admin-granted ↔ real-Stripe swap, the bidirectional Stripe email sync verified directly in the Stripe test dashboard, admin-granted billing paths producing no Stripe errors, and the cancel-control hides.

Deferred (not in this PR): replacing the paymentId overload for admin grants with an explicit isAdminGranted flag (so a churned user's real cus_ customer is preserved on grant) requires a Prisma migration and is left as a follow-up.

🤖 Generated with Claude Code

[postiz-agent]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[sentry]

Bug: When an admin is impersonating a user, the 'Switch User' search incorrectly includes the admin's own account, allowing them to swap credentials with the impersonated user.
_{Severity: HIGH}

Suggested Fix

The original admin's user ID needs to be tracked throughout the impersonation session. The auth middleware should attach the original admin's user object to the request, for example as req.originalUser. This ID should then be passed to getImpersonateUser to ensure the admin's own account is excluded from the search results, preventing the switch.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: apps/backend/src/api/routes/users.controller.ts#L171-L177

Potential issue: When an admin impersonates a user, the auth middleware replaces
`req.user` with the impersonated user's data but does not preserve the original admin's
identity. Consequently, when the admin uses the 'Switch User' feature, the
`getImpersonateUser` function is called with the impersonated user's ID to exclude from
search results. This fails to exclude the admin's own account, allowing it to appear in
the search. If the admin selects their own account, the `POST /user/switch` endpoint
validation passes because it only checks against the impersonated user's ID, resulting
in a successful but unintended credential swap between the admin and the impersonated
user.

Also affects:

• apps/backend/src/api/routes/users.controller.ts:204-270

_{Did we get this right? 👍 / 👎 to inform future reviews.}