* fix(web): show admin chrome only on the admin account's primary profile The top-right ServerActivity indicator and the sidebar Admin section were gated on the account-level role alone, so every profile on an admin account — including child profiles — saw admin system notifications and the indicator polled four admin endpoints on their behalf. Gate both on the active profile being the household primary, matching the existing is_primary idiom in SettingsLayout and the server-side quota exemption. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(web): resolve active profile via useCurrentProfile in admin route gates RequireAdmin/RequirePrimaryOrAdmin read the profile from useAuth(), but the admin chrome (AppSidebar, Layout) gates on useCurrentProfile(), which resolves the selected profile. Use the same source in the route gates so the redirect and the visible admin UI can never disagree. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(web,api): centralize acting-admin policy and enforce it server-side Address code-review findings on the primary-profile admin gate: - Add isActingAdmin to web/src/lib/permissions.ts as the single client-side definition of the policy (admin role + primary or no profile), with a useIsActingAdmin hook on top. Route gates, sidebar, Layout, and realtime channel gating all use it now, so the gate and the chrome can no longer disagree on null-profile handling. - Convert the admin-gated surfaces the original change missed (MediaItemMenu, EditMetadataDialog images tab, AddToCollectionDialog, MarkerEditor, theme CatalogBrowser, PersonDetail, SettingsLayout, ItemDetail content pages) so an admin on a non-primary profile is a regular viewer everywhere, not just in the sidebar. - Make the role-derived permission bypass (metadata curation, marker edit) follow the same policy on both client and server. - Enforce the policy server-side: RequireActingAdmin middleware refuses admin routes when the request declares a non-primary profile via X-Profile-Id, and the metadata-curation middleware holds admins on non-primary profiles to explicitly assigned permissions. - Stop spreading the profiles query result from useCurrentProfile so route gates only re-render when the resolved profile changes, and make it safe outside AuthProvider. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(web,api): fail closed on unresolved profiles in acting-admin policy Address review feedback on the acting-admin gate: - Server: actingAdminAllowed now denies when the declared profile cannot be resolved to one of the caller's profiles, so a bogus X-Profile-Id can no longer restore admin powers to a non-primary session. - Client: useIsActingAdmin returns false while a selected profile id has not yet resolved (e.g. hard refresh before the profiles query returns), instead of briefly treating it as "no profile selected". useCurrentProfile exposes hasSelectedProfile to make that state distinguishable. - hasPermission/canCurateMetadata/canEditMarkers now require the profile argument (resolved profile or explicit null), so a missed call site fails the typecheck instead of silently restoring the admin bypass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Code <noreply@anthropic.com> Co-authored-by: Quick <31828688+Quick104@users.noreply.github.com>
67 lines
2.5 KiB
TypeScript
67 lines
2.5 KiB
TypeScript
import type { Profile, User } from "@/api/types";
|
|
|
|
export const PERMISSION_METADATA_CURATION = "metadata_curation";
|
|
export const PERMISSION_MARKER_EDIT = "marker_edit";
|
|
|
|
/**
|
|
* Whether the account is currently acting with admin powers. Admin powers are
|
|
* reserved for the admin account's primary (household parent) profile; any
|
|
* other profile on the account (e.g. a kid's profile) is treated as a regular
|
|
* viewer. With no profile selected (e.g. right after login) the account keeps
|
|
* admin powers so the admin area stays reachable.
|
|
*
|
|
* This is the single client-side definition of the policy — route gates,
|
|
* chrome, and per-item admin actions must all go through it (usually via the
|
|
* useIsActingAdmin hook) so they can never disagree.
|
|
*/
|
|
export function isActingAdmin(
|
|
user: Pick<User, "role"> | null | undefined,
|
|
profile: Pick<Profile, "is_primary"> | null | undefined,
|
|
) {
|
|
if (user?.role !== "admin") return false;
|
|
return !profile || profile.is_primary === true;
|
|
}
|
|
|
|
export function hasPermission(
|
|
user: Pick<User, "role" | "permissions"> | null | undefined,
|
|
permission: string,
|
|
profile: Pick<Profile, "is_primary"> | null,
|
|
) {
|
|
if (!user) return false;
|
|
// The role-derived grant only applies while acting as admin; an admin on a
|
|
// non-primary profile keeps only explicitly assigned permissions. Callers
|
|
// must pass the resolved active profile, or explicit null for the "no
|
|
// profile selected" case — the parameter is required so a missed call site
|
|
// can't silently restore the admin bypass.
|
|
if (isActingAdmin(user, profile)) return true;
|
|
return Array.isArray(user.permissions) && user.permissions.includes(permission);
|
|
}
|
|
|
|
export function canCurateMetadata(
|
|
user: Pick<User, "role" | "permissions"> | null | undefined,
|
|
profile: Pick<Profile, "is_primary"> | null,
|
|
) {
|
|
return hasPermission(user, PERMISSION_METADATA_CURATION, profile);
|
|
}
|
|
|
|
export function canEditMarkers(
|
|
user: Pick<User, "role" | "permissions"> | null | undefined,
|
|
profile: Pick<Profile, "is_primary"> | null,
|
|
) {
|
|
return hasPermission(user, PERMISSION_MARKER_EDIT, profile);
|
|
}
|
|
|
|
export function hasAssignedPermission(permissions: string[] | undefined, permission: string) {
|
|
return Array.isArray(permissions) && permissions.includes(permission);
|
|
}
|
|
|
|
export function setAssignedPermission(permissions: string[], permission: string, enabled: boolean) {
|
|
const next = new Set(permissions);
|
|
if (enabled) {
|
|
next.add(permission);
|
|
} else {
|
|
next.delete(permission);
|
|
}
|
|
return Array.from(next).sort();
|
|
}
|