Admin Panel: Users + Workspaces + Audit log (V27 → V30)

[MichaelUray]

Admin Panel: Users + Workspaces + Audit log (V27 → V30)

This PR introduces a full admin panel under /login/admin with three
sections — Users, Workspaces, and Audit log — backed by four DB
migrations (V27 → V30) and a suite of new admin-only RPC methods on
@hcengineering/account. Self-hosted Huly operators can now manage
accounts and workspaces, audit administrative actions, and bulk-disable
or archive at scale, all without dropping to SQL.

Companion docs: hcengineering/huly-docs#71 — adds a top-level Admin panel section to the docs site with Overview / Users / Workspaces / Audit log / Configuration pages and screenshots.

Scope note (revised 2026-05-27): This PR provides Disable, not erasure or anonymization. Hard-delete was originally part of this PR but has been removed in response to @ignatremizov's review (see iteration table). Other lifecycle paths (anonymize, hard-delete with content cascade) are deferred to follow-up PRs.

The problem this solves

(Added in response to @ignatremizov's first-round review.)

Self-hosted Huly operators have to drop to raw SQL for everything
cross-workspace today: disabling a compromised account, force-logging
out a user after a security event, finding orphan accounts (no
workspace memberships), checking who has admin access on which
workspace, bulk-archiving stale workspaces, or auditing what an admin
did last quarter. There is a workspace-scoped Settings → Members
surface, but no global-account surface — and once you have more than
~5 workspaces, the per-workspace Settings pane stops scaling.

What already existed (so this is exposure, not reinvention). The
account service already shipped the primitives — assignWorkspace,
unassignWorkspace, social-id management, setWorkspaceMemberRole,
the ADMIN_EMAILS env gate. They just had no UI and were not exposed
via account-client. This PR wires UI + bulk endpoints + audit on top
of what the account service already enforces.

Why a separate route instead of expanding an existing one. Two
existing surfaces were in scope to extend rather than add:

1. Per-workspace Settings → Members — workspace-scoped, member-of-
   workspace view. Can't cross workspace; can't disable an account
   globally; can't show which workspaces a person is in. Wrong domain
   to bolt cross-workspace controls onto.
2. The tiny system-manager plugin — runs inside the per-workspace
   transactor session pipeline and doesn't talk to the account DB
   directly. The admin panel uses the account-service RPC instead,
   which is the source of truth for accounts and workspaces.

We chose /login/admin because of the session boundary (the panel must
work even when no workspace is open). If you'd rather see this folded
under system-manager once the dust settles, the routes can be moved.

Multi-tenancy. Huly already supports one account → many workspaces.
ADMIN_EMAILS was the existing RBAC primitive; before this PR, "being
admin" had no UI meaning — it only gated server-side mass operations
callable from internal scripts. This PR is the first surfaced consumer
of that primitive.

Iteration since the first review

Five commits were added on top of the original 159-commit history in
response to your feedback. Each one is small and addresses one specific
concern:

Commit	Concern (from review)	What changed
0c3af29d1c	"Bulk actions bars are usually at the top of the table, either appearing just under the header row, or above the table, rarely below it"	Move BulkActionBar from sticky-bottom to sticky-top in AdminUsers.svelte; the bar now appears between the filter row and the table, hidden when no rows are selected.
384a81d979	Audit table was always empty (found during end-to-end testing)	AdminAudit.svelte was calling getAccountClient(null).listAuditAdmin() — explicitly passing no token. Server-side assertAdmin consequently always returned Forbidden. Fix: use the default token (getAccountClient()) so the existing admin claim travels with the call, like every other admin-panel RPC.
ab2589361e	Two UX papercuts surfaced during the Playwright sweep	(a) Audit log to-date parsed as UTC midnight 00:00:00.000, which excluded every event logged "today" — the default "Last 3 days" preset hid the freshly-created disable / delete entries until the admin manually picked a Custom range. Anchor to to end-of-day (23:59:59.999) inside the listAuditAdmin params builder. (b) Drawer offered the Disable button on the admin's own row; the server guard cannot_self_disable caught it, but only after the admin had clicked through. Surface isSelf client-side by decoding the JWT payload locally — no extra RPC — and grey out the button with an explanatory label. The server guard still enforces as the security primitive; this is purely a UX preview of the impossible action.
086b7f9530	Reviewer @ignatremizov flagged that hard-delete cannot ship as proven safe without a cross-reference audit + sole-owner workspace guard	Hard-delete UI and RPC removed entirely from this PR. DeleteAccountConfirm.svelte deleted; deleteAccount function, postgres impl, mongo impl, AccountDB.deleteAccount interface method, 'deleteAccount' from AccountMethods union, 'delete_account' from AdminAuditAction, the client-binding in account-client, and the delete_account entry in the audit-action dropdown all removed. deleteAccount.test.ts deleted. Static grep verifies zero stragglers. Disable remains as the only account-state action in this PR. If hard-delete returns, it will be a separate smaller PR with a full content/reference audit, a sole-owner workspace guard, and an impact preview before confirmation.
08472f43e8	Operational ergonomics — admin had to manually navigate from the user drawer to the corresponding workspace	V5a: each workspace-membership row in the user drawer now exposes an Open ↗ link to /workbench/<wsUrl> in a new tab. Workspace-root link only; an Employee deep-link via per-workspace Ref<Employee> lookup is deferred to a future enrichment.
2869af32ba	Audit-log UX papercut — switching the date-range preset to Custom range cleared the From/To inputs and forced the admin to re-enter both	V7: switching to Custom range now retains the From/To values from the previously-active preset; only on a cold-start with both inputs empty does the dialog fall back to a 3-day window.
cb8c4a2409	Audit-log timestamps were ambiguous between local time and UTC	V8: each timestamp cell exposes a two-line title tooltip on hover — Local time: ... (<TZ>, UTC<offset>) and UTC: .... Extracted tzTooltip helper into its own module with 5 unit tests covering the Intl-unavailable degraded path.
1d61952b93	Denied admin actions had no audit trace	V13: cannot_self_disable and last_admin (for Disable) now write an admin_action_denied audit row before throwing. Rate-limited per (actor, reason, method) in a 1-hour window. Pre-auth Forbidden writes no row. Instrumentation lives in disableAccountInternal (Step 5a), disableAccount is refactored to delegate to it (Step 5b, eliminates 50 lines of duplicate body), and bulkSetDisabled adds a pre-bulkLoop self-audit because bulkLoop short-circuits self-targets before the per-target call runs (Step 5c). 7 unit tests cover the decision matrix. Audit-action dropdown gains admin_action_denied.

Identities / Employee / Contact mapping

You asked about Employee / canonical contacts / HR integration. Where
this PR sits today:

• Subject of the panel: the global account.uuid plus its
  email-typed social_id. Person / Employee / Contact / HR records
  are workspace-internal and untouched.
• Per-workspace Employee bridge: lives in the workspace's
  transactor DB, not the account DB. The admin panel is a global-
  account view and does not enumerate Employee rows.
• Guest / client-contact accounts: show up the same way as User+
  accounts (each has a global account row + email social-id). The
  drawer's role picker and the table's role chip reflect what's in
  global_account.workspace_members.role for that workspace.
• GitHub OIDC-linked accounts: one global account row with an
  additional github-typed social-id. The drawer surfaces this in the
  Identities section but does not link out to the IdP — deferred.

If the value would be there, the drawer can be extended in a follow-up
to add a "in workspace X, you're Employee Y" back-link. Not in this PR.

Status: Implementation complete, deployed and live-verified on
our self-hosted Huly v0.7.423 instance (CockroachDB backend) for ~8
days. All admin-targeted test suites pass — 568 + 7 + 5 = 580 of
584 (the 4 pre-existing failures are in postgres-real.test.ts,
which requires a live CockroachDB and fails identically at
upstream/develop merge-base).

159 + 5 = 164 commits, intentionally not squashed — the original
history is grouped into 6 logical phases, the new 5 commits are
review-driven and each addresses one concern. Reviewers who prefer
to read chronologically can follow the per-phase ranges below.

Per-phase commit ranges

Phase	Range	Focus
1a — Foundations	394e3db143 … efe42d1617 (~110 commits)	V27 migration (account disable + token version + last activity + admin_audit_log table). New collections + service operations: listAccountsAdmin, getAccountDetails, disableAccount / enableAccount, setWorkspaceMemberRole, removeWorkspaceMember, triggerPasswordReset, addToWorkspace, bulkSetDisabled, bulkSendPasswordReset, bulkAddToWorkspace, bulkRemoveFromWorkspace. Force-logout hook (AccountDisabled Tx → client-side store). Admin-only RBAC via assertAdmin. UI: AdminShell, AdminUsers + drawer, AdminWorkspaces + drawer, MassActionConfirm, FilterPresetMenu, ColumnFilterPopup. V28 migration to relax admin_audit_log.target_account NOT NULL + 5 query-tuning indexes.
1c — Polish + tests	c5da4d170c … d80a9710d0 (~10 commits)	decodeFilterParam extract with strict base64 + recursive prototype-pollution rejection + 32-level depth cap (15 tests). Shared csvEscape/csvLine in @hcengineering/account-client (9 tests). mergeColumnFilters + DEBOUNCE_MS extract (5 tests). A11y basics — html lang, <th scope="col">, drawer close aria-label. Audit empty state component. AdminAudit render cap (200 rows). 10s → 30s throttle on workspace stats poll.
1d — Audit infrastructure	9e03bc3948 … d97b80f8c0 (~4 commits)	Per-token CSV rate-limit (5/min, SHA-256-keyed in-memory TokenBucketLimiter, 4 tests). AUDIT_RETENTION_DAYS env-driven daily prune cron with Mongo auto-disable. V29/V30 migration: batch_id UUID NULL column + partial index WHERE batch_id IS NOT NULL, split into two migrations because CockroachDB rejects partial-index DDL on a same-tx-added column. Bulk-action service calls stamp one UUID across all their audit rows; UI groups consecutive same-batch rows under a non-interactive header.
1e — Visual design pass	4da2f06f8e … cff6e8a19e (~6 commits)	Members icon prefix on Users stats row. Tabular-nums + truncate-with-tooltip on Last-activity column. Audit Details JSON collapse-by-default. GlobalSearch empty-state with query echo (later removed). Workspaces stats two-band layout (counts vs capacity). V29/V30 migration split (CockroachDB partial-index-on-new-column constraint).
Audit log redesign	a267d3d2f4 … 9461de3092 (~5 commits)	Removed UUID-typing filter inputs in favor of admin name/email substring + target name/url substring + actions multi-select dropdown. Sortable column headers with arrow indicator only on active sort. Per-column filter icons that scroll-and-focus the relevant top-bar input. Date-range preset dropdown (1d / 2d / 3d / 1w / 2w / 1m / Custom; default Last 3 days).
Final UX cleanup	83b9cdeedb … 60e4d27e1d (9 commits)	CSV token moved from URL to Authorization header (admin UI side; legacy server fallback retained — see Security). enableAccountInternal extracted (drops N redundant assertAdmin per bulk-enable). Workspaces selection-bar count vs Mass Archive count clarified. Orphan-as-clickable-pill with row badge. All stat pills toggleable as filters. "Add workspace" primary button on Workspaces. Export CSV moved next to Presets in the filter row, regular kind. Three-button preset trio collapsed into a single Presets dropdown. postgres.test.ts mock SELECT projection updated to match V25–V27 column additions.
Review iteration	0c3af29d1c … 1d61952b93 (8 commits)	Bulk-bar position; audit-listing token bug; audit date inclusive end-of-day + self-disable UI guard; hard-delete REMOVED from this PR per safety review; V5a workspace-root backlink; V7 audit Custom-range prefill; V8 timezone tooltip; V13 admin_action_denied audit. Detail in the table above.

Database migrations

Migration	DDL	Purpose
V27	disabled_at, token_version, last_activity_at on account + admin_audit_log table	Foundation for disable / force-logout / audit
V28	admin_audit_log.target_account NULLABLE + 5 query indexes	Workspace-level audit entries + admin-panel query perf
V29	admin_audit_log.batch_id UUID NULL	Bulk-action correlation
V30	partial index on admin_audit_log(batch_id) WHERE batch_id IS NOT NULL	Small-footprint index (single-action rows dominate)

All migrations are forward-only with IF NOT EXISTS guards. Rollback
is "leave the schema, redeploy the previous account pod" — no down-
migrations.

Security posture

• decodeFilterParam: strict base64 + JSON-object + recursive __proto__/constructor/prototype rejection + 32-level depth cap. Returns 400 Bad Request with a structured reason; never silently accepts malformed input.
• LIKE wildcards (%, _, \) escaped on every user-supplied substring filter (Users search, audit substring filters) with explicit ESCAPE '\' clauses.
• CSV-export rate-limit: 5/min per SHA-256(token). Token is hashed before entering the limiter Map so a leaked heap dump / APM sample doesn't expose a usable admin Bearer.
• CSV export: the admin UI now uses fetch + Authorization: Bearer + blob download instead of window.open(url-with-token). The server retains the legacy ?token=… query-string fallback for one release with a deprecation warning log, so any out-of-band scripts that bookmarked the URL keep working. Removing the legacy fallback is in the deferred list.
• assertAdmin gates every admin-only RPC. Single-source-of-truth: ADMIN_EMAILS env. Force-logout when an active admin is disabled mid-session.

Tests

Pass: 575 / 579 across the admin-targeted suites (4 failures in postgres-real.test.ts are infra-bound, identical at upstream/develop merge-base).

Suite	Result
server/account (all)	575 / 579 — 4 failures in postgres-real.test.ts are pre-existing CockroachDB-required integration tests, identical at upstream/develop merge-base
server/account-service rateLimiter	4 / 4
server/account adminActionDenied.test.ts	7 / 7 (self-disable + last_admin audit-write paths, rate-limit dedup by key, bulk method tag, pre-auth Forbidden no-audit) — new in iteration
plugins/login-resources tzTooltip.test.ts	5 / 5 (Local time / UTC line format, Intl-unavailable fallback, DST/non-DST) — new in iteration
server/account listAuditAdmin.test.ts	5 / 5
foundations/core/packages/account-client csv + listAccountsAdmin	47 / 47
plugins/login-resources (mutex, columnFilters, signupTokenGuard)	12 / 12

Total new tests added by this PR: ~125 (decodeFilterParam, csv,
columnFilters, rateLimiter, pruneAuditOlderThan, escapeLike,
bulkActions, listAccountsAdmin, listAuditAdmin, getAccountDetails,
assertAdmin, adminActionDenied, tzTooltip).

Reviews completed before this PR

1. Per-task implementation review — every task in Plans 1c/1d/1e
   passed spec-compliance review + code-quality review before
   integration.
2. Independent full-codebase code review — found and we fixed: LIKE
   wildcard escape, bulk-enable redundant validation, CSV CRLF + BOM,
   429 charset, token-in-URL.
3. Playwright UI/UX walkthrough (original) — found and we fixed:
   status filter sending wrong field shape, double Popup host, stuck
   sort arrow, orphan-mapper drop, header/body alignment, audit filter
   UX, ~6 more.
4. Three rounds of user-feedback fixes during deployment.
5. Pre-PR test review — caught the stale postgres.test.ts mock
   that hadn't been updated for the V25–V27 SELECT projection
   additions (fixed in b90bbbcc30).
6. End-to-end Playwright sweep of the full panel (new) — exercised
   T1 stat-pill filters → T9 Workspaces table. Caught the audit-token
   bug (Forbidden on every audit reload), the audit-date end-of-day
   cutoff, and the self-disable/self-delete UX gap; all three fixed in
   384a81d979 and ab2589361e.

Deliberately deferred (tracked, not blocking this PR)

• Reverse-batch CTA — design stub for a future iteration. Six open
  product/security questions; what's the inverse of archive_workspace
  in 6 months? Reset_password has no inverse. Doing this wrong is
  worse than not doing it.
• Remove legacy ?token=… query-string fallback on the CSV export
  route once one release has shipped with the new Authorization-header
  flow. Currently emits a deprecation warning when hit.
• Streaming-loop catch-all on /admin/export/accounts.csv: if
  listAccountsAdmin or ctx.res.write throws after the 200 header
  has been sent, the request fails mid-stream without a structured
  error envelope. Pre-existing behaviour, not introduced here, but worth
  hardening alongside the legacy-token-fallback removal.
• Trigram index for audit ILIKE substring filters — only matters at

  100k row scale.

• Unbatched audit DELETE in retention prune — only matters at >10M
  row scale.
• Three duplicate workspace-picker popups (~464 LOC overlap, AddTo /
  BulkPick / AddMember) — refactor candidate, not a feature.
• Pre-existing Huly icon-API drift (fill/inline/disabled props
  rejected by 6 icon components) — 39 console warnings per page load,
  upstream-side cleanup more appropriate than admin-panel side.
• Drawer back-link to per-workspace Employee row (in response to the
  identities question above).

Live deployment evidence

Deployed and live-verified on a self-hosted Huly v0.7.423 instance
with the CockroachDB backend and OIDC SSO. The following behaviours
have been exercised end-to-end on a 12-user / 14-workspace test
dataset: 5 clickable stat pills with per-pill filter state, drawer
reactive refetch on row swap, outside-click + Escape drawer dismiss,
Workspaces per-row selection + selection-driven Mass Archive,
batch_id row grouping in the audit log, date-range presets, CSV
export with Authorization header, CSV rate-limit 429 response,
and self-disable UI guard on the admin's own row (Disable button greyed with explanatory label when the caller is the target).

Screenshots in hcengineering/huly-docs#71 (src/assets/screenshots/huly/admin-panel/).

Notes for upstream reviewers

• CommunityDB.ts (CockroachDB) backend only — Mongo collection
  stubs throw "not implemented" with a meaningful error. The audit
  retention cron auto-disables itself on Mongo to avoid log spam.
• English-only UI strings so far; getEmbeddedLabel everywhere so
  i18n is a future drop-in.
• No new dependencies added to package.json (uses existing Huly
  primitives: @hcengineering/ui Button / ButtonMenu / Dropdown / CheckBox,
  @hcengineering/platform getEmbeddedLabel, postgres.js Sql template tag).
• Sign-off + DCO compliant; single author across all 164 commits.
• Squash-merge is fine if you prefer a single commit on develop.
  We've kept the granular history as documentation, not because we
  insist on preserving it.

[MichaelUray]

This is a fair concern. I re-checked the delete path and agree it should not ship in this PR.

I'm removing the hard-delete UI and RPC from #10883. Disable remains as the only account-state action in this PR. It's reversible — it preserves the account / person / social-id anchors, blocks login via the disabled_at flag, and doesn't touch authored workspace content.

If hard-delete comes back, I'll do it as a separate, smaller PR with an explicit content/reference audit, sole-owner workspace guard, and an impact preview before confirmation. I also want to separate that from a privacy-oriented anonymization path, since deleting authored project content is not the same problem as removing personal identifiers.

The structural removal commit is 086b7f9530 — DeleteAccountConfirm.svelte deleted, deleteAccount RPC + DB cascade + types-union entries + client binding + delete_account from the audit-action dropdown all removed; deleteAccount.test.ts deleted. Static grep against the working tree shows zero deleteAccount / delete_account / DeleteAccountConfirm / cannot_self_delete references outside lib/ and *.d.ts output. Disable's existing cannot_self_disable + last_admin guards stay as before.

Four additional commits layered on top while this branch was up for review (V5a workspace-root link in the drawer, V7 audit Custom-range pre-fill, V8 audit timestamp timezone tooltip, V13 admin_action_denied audit event for the surviving Disable / last_admin denials). The PR body's iteration table has the per-commit detail.

Thanks for catching this before it shipped as default-on — the answer to "is hard-delete safe?" was "we haven't proven it yet," and shipping with that assumption would have been wrong.

[ignatremizov]

Cool, yeah it's good to not include it. I'd also suggest to update PR body to remove that block about hard delete.

Edit: I see removed already 👍

[ignatremizov]

Hey @MichaelUray, curious whether you continued this work or have follow-up branches around workspace-level RBAC / access management.

From looking through current Huly settings, this PR seems to solve the global instance-admin surface well: users across workspaces, workspace membership, audit, disable/enable, bulk operations, etc. The gap I am seeing is the in-workspace access model: workspace account roles (Owner / Maintainer / User / Guest / read-only), space/project members / owners / private / autoJoin, per-space-type roles/permissions, chat channel public/private/members, Office room access/guest links, and inherited visibility for issues/docs/cards/files.

Have you explored a centralized Workspace Access Center that sits inside a workspace and lets an owner see/edit access per person and per resource?

Potential MVP:

• People: workspace role, guest/user status, accessible projects/channels/spaces.
• Resources: tracker projects, chat channels, document/drive/teamspaces, card spaces, Office rooms, guests.
• For each resource: app/type, public/private, auto-join, owners, members, role assignments where applicable.
• Common edits: change workspace role, add/remove members, toggle private/auto-join, assign per-space roles.

I would avoid making Classes or Space Types the user-facing RBAC UI. They are useful platform primitives, but operational admins need a consolidated view over Space.members, owners, private, autoJoin, and role assignment fields. Separately, the current Settings labels could use clarification: Members -> Workspace Members, Spaces -> Global Space Admins, Space Types -> Advanced / Schema.

Would be interested if you already have work in this direction, or thoughts on whether this PR's admin table/drawer/audit patterns could be reused for an in-workspace access center.

[MichaelUray]

Hi @ignatremizov — quick follow-up to your Workspace Access Center question. Thank you for the suggestion — it was a clear framing of where workspace administration could use a centralized surface, and gave me a concrete direction to work toward.

I implemented a v1 of that direction in my fork: a per-workspace settings panel with People, Resources, My Access, Audit, and Guest Settings tabs, plus common access-management actions and audit visibility for workspace Owners.

It is not an upstream PR yet because the account-service host wiring builds on helpers introduced in this Admin Panel PR (listAccountsAdmin, CSV rate-limiting / filter decode helpers, etc.). Once #10883 lands, I can open the Workspace Access Center PR against develop — at which point the code becomes reviewable as a clean diff on top.

Until then, the user-facing surface and design are captured in:

• User-facing docs draft (8 pages + 12 screenshots): hcengineering/huly-docs#73

The v1.5 preview features (Permission Templates, Webhooks, Time-bounded Grants, CSV Bulk-Invite, Effective Permissions Drilldown) are intentionally out of scope for the first upstream PR.

Any comments or suggestions on the direction, scope, or specific design decisions would be welcome at this stage — much easier to adjust now than after the upstream PR opens. Sharing as context for the admin/access-management direction; no action needed unless useful.

[MichaelUray]

@ArtyomSavchenko — following up on the question of direction here.

This PR has grown large and now conflicts with the recent revocable-API-tokens work in server/account. Before rebasing the full PR, I could prepare a small standalone, backend-only PR against current develop, with the admin-panel UI left as a stacked follow-up. This is account/admin infrastructure (lifecycle, audit, listing) — orthogonal to the object-permission model, not another take on it. The proposed foundation would cover:

• account lifecycle: disable/enable and a token-version bump to force logout;
• an admin audit log, including the database migration; and
• admin listing/filter queries (listAccountsAdmin, assertAdmin, decodeFilterParam).

For the new disable flow, it would also ensure that the disabled account's API tokens are invalidated. Would that foundation be useful upstream, and if so, what shape would you prefer? Or would you rather design instance-admin/account tooling separately? I'd prefer to align before investing in the extraction.

[MichaelUray]

@ArtyomSavchenko — following up on the question above (2026-08-09). The branch now conflicts with current develop, and I'd rather not rebase the full backend + UI diff if the shape is going to change.

If a backend-only foundation PR is a shape you'd review — account disable/enable with a token-version bump, the admin audit log with its migration, and the listAccountsAdmin / assertAdmin / decodeFilterParam helpers, with the admin-panel UI stacked on top later — I can prepare it against current develop. If you'd rather approach instance-admin tooling differently, a short note on that is equally useful; I'll adjust before investing in the extraction.

[ArtyomSavchenko]

@ArtyomSavchenko — following up on the question above (2026-08-09). The branch now conflicts with current develop, and I'd rather not rebase the full backend + UI diff if the shape is going to change.

If a backend-only foundation PR is a shape you'd review — account disable/enable with a token-version bump, the admin audit log with its migration, and the listAccountsAdmin / assertAdmin / decodeFilterParam helpers, with the admin-panel UI stacked on top later — I can prepare it against current develop. If you'd rather approach instance-admin tooling differently, a short note on that is equally useful; I'll adjust before investing in the extraction.

Hi @MichaelUray
Yes, I think the backend-only foundation PR is better

[MichaelUray]

Thanks @ArtyomSavchenko. The backend-only foundation is now up as #11055, as a fresh port against current develop.

In #11055:

• account disable/enable with a token-version bump
• a central disabled-principal check in wrap(), which covers session, API and user-scoped service tokens
• the admin_audit_log table and its migration. It is idempotent and tested on top of this PR's earlier V27-V30 migrations.
• assertAdmin, listAccountsAdmin, and a reduced listAuditAdmin

Not in #11055:

• UI
• workspace-membership admin RPCs and bulk operations
• CSV export and decodeFilterParam (its only consumer is the CSV export)
• realtime session eviction

I'll keep this PR open as the stacked follow-up for the admin panel UI (and the workspace-membership part) and move it to draft. Once the foundation is merged I'll rebase it, and the diff will shrink to those parts.

[MichaelUray]

@ignatremizov following up on this: I opened a short design question for the in-workspace access overview in #11057, scoped down to an Owner-only, read-only overview of space membership and configuration over the existing Space primitives (no new server mechanism). I'd value your and @ArtyomSavchenko's view there before I write code.