Platform Admin vs. Org Admin: warum der Unterschied zaehlt

“Admin” ist ein überladenes Wort in einer Multi-Tenant-Plattform. Die Plattform hat Admins. Jede Tenant Org hat Admins. Sie teilen das Wort, aber nicht die Befugnisse. Die URL-Struktur der Plattform macht den Unterschied sichtbar.

Platform-only pages

/admin/platform/trust-scoring (platform-wide trust scoring weights konfigurieren), /admin/escrow/disputes (Disputes über Tenants hinweg adjudicaten), /admin/auction/strikes/[companyId] (Strikes pardonen — nur platform-staff), /admin/exchange-rates (Rate Feed verwalten). Diese Seiten werden durch getAdminScope() gated, das eine platform-tier role zurückgibt; ein Org-Admin erreicht sie nicht, egal wie seine Permissions konfiguriert sind.

Org-only pages

/admin/organizations/[slug] (eigene Org Settings, Users, Billing verwalten), /admin/users (Users der eigenen Org verwalten), /admin/storage (eigene Storage Tier), /admin/email-provider (eigene outbound email config). Diese Seiten lassen einen Org-Admin alles innerhalb seiner eigenen Tenancy tun, ohne andere Tenants zu sehen.

Cross-Tenant Sichtbarkeit

Platform Staff kann aus Supportgründen tenantübergreifend lesen — ein Customer meldet ein Ticket zu einem Deal, der hängen geblieben ist, und Platform Staff muss den Deal sehen, um zu untersuchen. Die Sichtbarkeit wird geloggt: Jeder cross-tenant read schreibt einen Eintrag in den Activity Log mit Staff User, Target Tenant und Action. “Hat jemand von der Plattform unsere Daten angesehen?” hat also eine Antwort, die kein Raten ist.

Warum zwei URL-Präfixe

Weil Platform-only Pages und Org-only Pages im selben URL-Baum zu Access-Control-Fehlern führen. /admin/platform/* ist eindeutig. /admin/organizations/* ist eindeutig. Bei einer Seite unter /admin/[ambiguous-name] muss man Code lesen, um zu wissen, welche Rolle sie enforced. Naming macht den Audit einfacher.