Andrey Antukh 8853445951 🎉 Add the superuser admin panel
Operators get a full instance administration panel behind a new
"superuser" access rule. The :app.auth/superusers service resolves
the configured :superusers emails to profile ids once at startup,
so guarded calls are a plain contains? with no query. A token
carrying "superuser" as an operator-granted scope also passes, for
automation without a session; tokens are created with empty perms,
so this opens nothing by itself.

The check is a branch of wrap-authentication, after auth and
before params validation, so outsiders get 403
:superuser-required without leaking expected params. Other token
scopes keep their exact meaning. get-profile and the login
response report the same answer as :is-superuser; the team-scoped
:is-admin is untouched. On devenv any authenticated profile
passes, as the /dbg gate does. The :admins config becomes
:superusers (PENPOT_SUPERUSERS) with no compatibility layer:
operators must rename it or instance-admin access fails closed.
Quote notifications go to the same set.

Admin operations live in app.rpc.admin.* behind
/api/admin/methods, with the same auth wrapping as main but
excluded from the main API docs. Profiles can be listed,
inspected, blocked, unblocked, deleted and restored, teams listed
with members and features, projects and files listed with validate
and repair, error reports listed and shared through JWE links,
and the virtual clock read and set.

Delete and restore run as durable jobs on the unified job table:
the command stamps the object's own row inline so it reads back
instantly, then a delete-object or restore-object job walks the
rest of the tree through app.features.object-cascade. Listing
uses created-at cursors over the new 0157 indexes.

The panel itself is a static SPA served under /admin (public like
any asset; the JS gate reads :is-superuser from get-profile)
with dashboard, users, teams, projects, files and error-report
pages. Devenv points /admin at the backend.

Covered by backend-tests rpc-superuser-test plus
rpc-admin-{users,teams,project,file,delete,restore,misc,
error-reports,error-share} and http-admin tests, with green
regressions on profile, auth and quotes.

Relates to #12015

AI-assisted-by: muse-spark-1.3-contributor
2026-10-21 12:59:22 +02:00

72 lines
2.5 KiB
JavaScript

// Filter <-> query string sync: list pages keep their filters in
// the URL (replaceState, no history spam) so refresh restores the
// view and filtered views are bookmarkable. Only the keys the page
// owns are touched; `screen` (and `id`) survive untouched. The
// page cursor is deliberately left out: refresh restarts at page
// one with the same filters.
//
// List -> detail navigation carries the list URL in `from`, so
// "Back to list" returns to the same filters instead of a generic
// list. `from` is a plain query string (`?screen=users&search=…`);
// backUrl only trusts the five list screens.
export function readQuery(keys) {
const query = new URLSearchParams(location.search);
const out = {};
for (const key of keys) {
const value = query.get(key);
if (value !== null) {
out[key] = value;
}
}
return out;
}
export function writeQuery(patch) {
const query = new URLSearchParams(location.search);
for (const [key, value] of Object.entries(patch)) {
if (value === "" || value === null || value === undefined) {
query.delete(key);
} else {
query.set(key, value);
}
}
history.replaceState({}, "", "?" + query.toString());
}
const LIST_SCREENS = ["users", "teams", "projects", "files", "jobs", "error-reports"];
// Wrap a target query with the current list URL, so the detail
// page can send "Back to list" to the same filters. Any nested
// `from` is stripped first: cross-detail hops never build chains.
export function withFrom(base) {
const target = new URLSearchParams(base.startsWith("?") ? base.slice(1) : base);
const current = new URLSearchParams(location.search);
current.delete("from");
// The detail screens add `id`; the list screens only carry
// filters. Either way the whole query is the return target.
const restored = current.toString();
if (restored !== "") {
target.set("from", "?" + restored);
}
return "?" + target.toString();
}
// Detail link from a list row: `detailUrl("user", id)`.
export function detailUrl(screen, id) {
return withFrom(
"?screen=" + encodeURIComponent(screen) +
"&id=" + encodeURIComponent(id));
}
// Resolve "Back to list": the stored list URL when it points at
// a known list screen, else the generic fallback.
export function backUrl(fallback) {
const from = new URLSearchParams(location.search).get("from");
if (from && LIST_SCREENS.some((screen) =>
from === "?screen=" + screen || from.startsWith("?screen=" + screen + "&"))) {
return from;
}
return fallback;
}