Die Owner-Konsole

Die Owner-Konsole unter /admin ist die instanzweite Administrationsfläche. Sie ist eine Hülle mit einer Tab-Leiste; jeder Tab ist ein Query-Parameter derselben Route (/admin/?tab=<key>), den die Konsole als Locator-Chip unter dem Titel anzeigt. In der Seitenleiste heißt sie Owner und liegt in einem Admin-beschränkten Abschnitt zusammen mit der separaten Operator-Konsole. Nichts auf dieser Seite ist Workspace-bezogen – außer dort, wo ein Tab ausdrücklich so gekennzeichnet ist: Eine Änderung hier betrifft das Deployment für jede Organisation darauf.

Drei Konsolen, drei Geltungsbereiche

Diese drei Flächen werden regelmäßig verwechselt. Es sind eigenständige Routen mit eigenständiger Autorisierung.

Fläche	Route	Geltungsbereich	Wer sie öffnen darf
Owner-Konsole	/admin	Die ganze Instanz – Benutzer, Pläne, Entitlements, Marktplatz-Governance	Nur ein Instanz-Admin
Operator-Konsole	/operator	Die ganze Instanz – tenantübergreifender Betrieb plus der globale Not-Aus	Eine Instanz-Admin-Sitzung oder ein Deployment-Operator-Token
Bericht Betrieb	/reports/operations	Ein Workspace – dessen Dispatch, Routing und Circuit Breaker	Owner oder Admin dieses Workspace

/reports/operations ist ein Tab des Berichte-Hubs, keine Konsole: die lesende, tenant-bezogene Sicht auf dieselben Betriebsdaten – ein Workspace-Owner erreicht sie ohne jedes Instanz-Recht. Siehe Berichte. Die tenantübergreifenden Lesezugriffe und der globale Schalter global_dispatch liegen ausschließlich auf /operator – siehe Die Delivery-Engine betreiben.

Wer als Instanz-Admin gilt

Ein Benutzer ist Instanz-Admin, wenn seine Spalte user_profiles.is_admin wahr ist oder er die Zeile system_admin in user_roles hält. Dieses Kennzeichen wird bei der Profilanlage gesetzt – und nur dort: Eine E-Mail-Adresse, die groß-/kleinschreibungsunabhängig zu SUPACLOUD_INITIAL_ADMIN_EMAILS passt, wird freigeschaltet und als Admin angelegt; jede andere Registrierung als keines von beidem. Die Konsole bietet kein Bedienelement, um jemanden zum Admin zu machen – das ist ein Datenbank- oder Bootstrap-Konfigurationsvorgang, kein UI-Vorgang.

Die Autorisierung wird an zwei unabhängigen Stellen durchgesetzt. Der gesamte Unterrouter /api/admin/* liegt hinter einer require_system_admin-Middleware, und jeder Handler ruft zusätzlich require_admin_user auf – das zuerst ein freigeschaltetes Konto verlangt und dann das Admin-Kennzeichen. Die Seite selbst leitet einen Nicht-Admin nach dem Laden des Profils auf /settings um, und der Seitenleisten-Eintrag bleibt ohne das Kennzeichen verborgen; beides ist nicht die Sicherheitsgrenze.

Die Operator-Konsole hat keine clientseitige Sperre

/operator verlässt sich auf das Ausblenden im Menü plus 401/403 vom Server – ihre Seitenkomponente prüft is_admin nicht selbst. Sie akzeptiert außerdem statt einer Sitzung ein Deployment-Operator-Token (SUPACLOUD_OPERATOR_TOKEN) im Header Authorization: Bearer; so erreichen sie headless- und CI-Aufrufer. Das Token wird zuerst geprüft, eine Sitzung erst danach.

Die dreizehn Tabs

Tab	Route	Was er steuert	Folgenschwerste Änderung
Benutzer	?tab=users	Die Freischaltung jedes Kontos auf der Instanz	Ablehnen – löscht den wartenden Kontodatensatz endgültig
Funktionen	?tab=features	Nichts – meldet, welche optionalen Funktionen verdrahtet sind	Nur lesend
SEO	?tab=seo	Nichts – meldet den Metadaten-Zustand der Marketing-Site	Nur lesend
Pläne	?tab=plans	Preis, Intervall, inkludierte Sitzplätze und Sichtbarkeit jedes Plans	Eine Änderung an amount_cents rotiert den Stripe-Preis
Vorlagen	?tab=templates	Die Transaktions-E-Mails, die die Instanz versendet	Speichern überschreibt Betreff und Inhalt für alle Empfänger
Kunden	?tab=customers	Nichts – listet jeden Workspace mit Plan und Abo-Status	Nur lesend
Overrides	?tab=overrides	Entitlement-Zuteilungen oberhalb des Plans	Eine globale (bereichslose) Zuteilung ändert Entitlements für jeden Tenant
Queues	?tab=queues	Nichts – meldet Stripe-Event-Rückstau und Reconciliation-Status	Nur lesend
Audit	?tab=audit	Nichts – der anfügende Nachweis der Admin- und Billing-Änderungen	Nur lesend
Marktplatz-Auszahlungen	?tab=payouts	Verkäufer-Auszahlungen und die Plattform-Gebührensätze	Absenden – schickt einen SEPA-Batch an die Bank; kein Zurück
Fehlerseite	?tab=error-page	Die Standard-Fehlerseite der Instanz	Speichern ersetzt den ganzen JSON-Bag; es wird nicht gemischt
Marketplace-Prüfung	?tab=marketplace-review	Das Installations-Gate auf Katalog-Einträgen	Freigeben – setzt einen Eintrag auf verifiziert und damit installierbar
Marketplace-Quellen	?tab=marketplace-sources	Die Quellen-Registry des aktiven Workspace, nicht der Instanz	Eine Quelle löschen (abgelehnt, solange sie veröffentlichte Einträge hat)

Ein unbekannter oder fehlender tab-Parameter fällt auf Benutzer zurück.

Benutzer

Getragen von GET /api/admin/users/pending und GET /api/admin/users, dazu POST /api/admin/users/{user_id}/approve und DELETE /api/admin/users/{user_id}/reject.

Der Tab hat zwei Blöcke: Wartende Benutzer – eine warnfarben gerahmte Aktionsliste mit Freischalten / Ablehnen je Zeile – über Alle Benutzer, der vollständigen Liste mit Admin-Abzeichen und einem Status Freigeschaltet / Wartend je Konto.

Eine Selbstregistrierung landet wartend – und bleibt es, bis sie hier freigeschaltet wird

user_profiles.approved steht standardmäßig auf falsch. Nur eine E-Mail-Adresse aus SUPACLOUD_INITIAL_ADMIN_EMAILS wird freigeschaltet angelegt; jede andere Registrierung liefert HTTP 202 mit pending_approval: true und kann das Produkt danach gar nicht benutzen. Die Web-App ersetzt ihre gesamte Oberfläche durch einen Wartebildschirm mit nur einem Abmelden-Knopf, und die zentrale Freischaltungsschicht des Servers weist jeden nicht ausgenommenen /api-Aufruf mit 403 Account pending approval ab. Nur dieser Tab hebt das auf. Auf einer frischen Installation, in der niemand eine Initial-Admin-Adresse hat, kann niemand jemanden freischalten – setze SUPACLOUD_INITIAL_ADMIN_EMAILS vor der ersten Registrierung.

Ablehnen ist unumkehrbar. Es ist keine Statusänderung: Der Server löscht die Zeile in user_profiles hart (WHERE approved = false). Es gibt kein Zurück und keine Liste abgelehnter Konten; die Person muss sich neu registrieren. Freischalten ist dagegen ein einseitiges UPDATE ... SET approved = true und kann gefahrlos wiederholt werden.

Dieser Tab zeigt das Admin-Kennzeichen an, setzt es aber nie.

Funktionen

Getragen von GET /api/admin/feature-availability. Nur lesend.

Der Verfügbarkeitsbericht beantwortet genau eine Frage: Welche optionalen, secret-gestützten Funktionen sind in diesem laufenden Prozess tatsächlich konfiguriert? Eine KPI-Leiste trägt das aufgelöste Secret-Backend (env oder openbao), einen Zähler „verfügbar von gesamt“, ein Abzeichen Boot-kritisch, die Edition des Deployments (Community oder Enterprise) und die Zahl der nicht verfügbaren Funktionen. Darunter steht eine Zeile je Funktion – Kategorie, Name, die Chips mit den Env-Variablennamen und ein Abzeichen Verfügbar / Nicht verfügbar – mit einer Detail-Schublade je Zeile.

Nur Env-Variablennamen – nie Werte

Der Bericht trägt bewusst ausschließlich die Namen der Variablen, die eine Funktion aktivieren würden, nie deren Werte, und es gibt kein Aufdecken. Ein fehlendes Secret bricht den Server nicht: Die Funktion ist schlicht nicht verfügbar, alles andere läuft weiter. Boot-kritische Einträge sind die Ausnahme – ohne sie verweigert eine Prod-Startprüfung den Start.

Dieser Tab schreibt nichts. Um zu ändern, was er meldet, setzt du die genannte Variable in der Umgebung oder in der OpenBao-Map supacloud/app und deployst neu – siehe Umgebungsvariablen, die SECRET_BACKEND-Matrix und die Secret-Bereitstellung. Die gemeldete Edition stammt aus dem Lizenz-Token, nicht aus diesem Tab; siehe Eine Edition-Lizenz einspielen.

SEO

Getragen von GET /api/admin/seo. Nur lesend.

Eine Diagnose der Metadaten der öffentlichen Marketing-Site: ein Score, die Zahl der indexierten Routen, die ausgelieferten Locales, die Zahl der öffentlichen Pläne, dann die Search- und Social-Assets – kanonische Basis-URL, Open-Graph-Bild mit Abmessungen und Live-Vorschau sowie der Twitter-Card-Typ – und schließlich eine Zeile je Prüfung mit ihrem Status. Etwas daran zu ändern ist eine Konfigurations- oder Build-Änderung der Marketing-Site; der Tab hat keine Bedienelemente.

Pläne

Getragen von GET /api/admin/plans, PUT /api/admin/plans/{plan_id} und POST /api/admin/plans/{plan_id}/stripe-sync.

Jeder Abrechnungsplan der Instanz, inklusive der inaktiven und nicht öffentlichen. Jede Zeile ist ein editierbarer Entwurf – Anzeigename, Betrag in Cent, Inkludierte Sitzplätze, Intervall (month, year, one_time, custom) und Währung (EUR, USD, GBP) – der je Zeile mit Speichern übernommen wird, dazu die Schalter Aktiv und Öffentlich und ein Stripe-Sync je Plan.

• Ein Plan ist ein geteiltes Instanz-Objekt. Ihn zu ändern ändert ihn sofort für jede Organisation, die ihn abonniert hat.
• Eine Änderung an amount_cents rotiert den Stripe-Preis des Plans. Die Sync-Aktion ist eine Vorschau dieses Abgleichs, nicht die Geldbewegung selbst.
• Inkludierte Sitzplätze ist das Entitlement users.max des Plans: eine nichtnegative ganze Zahl oder das Literal unlimited. Alles andere wird abgelehnt. Wie Kontingent und Überhang abgerechnet werden, steht in Sitzplätze und Abrechnung verwalten – diese Seite wiederholt es nicht.
• Jedes Speichern schreibt einen Audit-Eintrag mit Vorher/Nachher, sichtbar im Tab Audit.

Vorlagen

Getragen von GET /api/admin/templates und PUT /api/admin/templates/{key}.

Die Transaktions-E-Mail-Vorlagen, die die Instanz versendet – in der Datenbank gespeichert, nicht im Image. Drei Spalten: die Liste der Vorlagen-Schlüssel, ein Editor (Betreff, Inhalt, optional Grund für die Änderung) und eine Live-Vorschau, die den Inhalt gegen einen Beispielkontext rendert. Erkannte Platzhalter {{variable}} erscheinen als Chips unter dem Editor, und der Kopfbereich zeigt, ob der Entwurf ungespeichert ist.

Speichern ersetzt Betreff und Inhalt für die ganze Instanz – die nächste E-Mail dieser Art nutzt den neuen Text. Der Änderungsgrund wandert ins Audit-Log, aber der Tab bietet kein Zurücksetzen und keine Versionsliste; eine frühere Formulierung holst du aus dem Audit-Eintrag zurück.

Kunden

Getragen von GET /api/admin/customers. Nur lesend.

Jeder Workspace der Instanz, gruppiert unter seiner besitzenden Organisation: ein Organisationskopf (Name, ein Abzeichen Persönlich / Organisation, Zahl der Workspaces) über je einer Zeile pro Workspace mit Plan-Id und einem Abzeichen für den Abo-Status. Ein Workspace, dessen Organisation die Antwort nicht mitliefert, fällt in einen einzelnen ungruppierten Eimer, statt zu verschwinden. Es gibt keine Bedienelemente.

Overrides

Getragen von GET /api/admin/overrides/board (serverseitig paginiert, mit Facetten für Feature, Geltungsbereich und Status sowie Freitextsuche), POST /api/admin/overrides und POST /api/admin/overrides/{override_id}/revoke.

Ein Entitlement-Override erteilt ein Entitlement außerhalb des Plans. Das Formular nimmt einen Feature-Schlüssel, einen JSON-Wert (eine Zahl, eine Zeichenkette wie "unlimited" oder ein Objekt), eine Begründung, optional einen Workspace- und/oder Benutzer-Geltungsbereich und optional ein Ablaufdatum. Die Tabelle listet Feature, Geltungsbereich, Wert, Läuft ab und Status; eine Zeile ohne Bereich zeigt Global.

Ein bereichsloser Override wirkt instanzweit

Bleiben Workspace- und Benutzer-Bereich leer, erhält jeder Tenant der Instanz das Feature. Overrides stehen in der Auflösungsreihenfolge über dem Plan, eine globale Zuteilung übersteuert also stillschweigend das, wofür jede Organisation bezahlt. Bevorzuge eine begrenzte, ablaufende Zuteilung mit Begründung. Wo Overrides gegenüber Sitzplätzen, Plan und Edition stehen, steht in Editionen und Berechtigungen.

Widerrufen ist ein Stempel, kein Löschen: Die Zeile bleibt mit dem Status widerrufen in der Tabelle – genau das macht die Zuteilungshistorie prüfbar. Zuteilen und Widerrufen schreiben beide Audit-Einträge.

Queues

Getragen von GET /api/admin/queues. Nur lesend.

Drei Zahlen auf einer Karte: Stripe Events (insgesamt empfangen), Wartend (empfangen, aber noch nicht verarbeitet) und ein Abzeichen für den Reconciliation-Status. Er beantwortet, ob der Stripe-Webhook-Rückstau abfließt. Ein Wiedereinstellen oder Nachspielen gibt es hier nicht.

Audit

Getragen von GET /api/admin/audit/board.

Das Admin- und Billing-Audit-Log – Planänderungen, Zuteilung und Widerruf von Overrides, Vorlagenänderungen – je Eintrag mit Vorher/Nachher-Schnappschüssen. Die Tabelle ist serverseitig paginiert, mit Facettenfiltern auf Aktion und Zielart, Freitextsuche und Sortierung über die Kopfzeile nach Aktion und Ziel.

Dieses Log ist aus der Konsole heraus nur anfügend: kein Löschen, kein Bearbeiten, keine Aufbewahrungssteuerung auf diesem Tab.

Nicht dasselbe wie der Workspace-Bericht Audit

Dies ist das Log auf Instanzebene. Der Nachweis „wer hat was getan“ je Workspace ist der Tab Audit des Berichte-Hubs unter /reports/audit, beschränkt auf Owner/Admin des Workspace und ein Plan-Entitlement. Siehe Berichte.

Marktplatz-Auszahlungen

Getragen von GET /api/admin/marketplace/payouts/queue, GET|POST /api/admin/marketplace/payouts/batches, den Batch-Aktionen approve, submit, tan, cancel, reconcile und sepa_xml sowie GET|PUT /api/admin/marketplace/fee-settings. Drei Unter-Tabs, geroutet über einen zweiten Query-Parameter (&subtab=):

Unter-Tab	Route	Inhalt
Warteschlange	&subtab=queue	Verkäufer mit auszahlbarem Guthaben; daraus einen Batch anlegen
Batches	&subtab=batches	Der Batch-Lebenszyklus – freigeben, absenden, TAN, abbrechen, abgleichen, SEPA-XML
Gebühreneinstellungen	&subtab=fees	Die Plattform-Gebührensätze für Pakete und Runner

Absenden bewegt echtes Geld und lässt sich nicht rückgängig machen

Absenden übergibt einen freigegebenen Batch per FinTS/SEPA an die Bank und kann eine TAN-Abfrage zurückgeben, die bestätigt werden muss. Der TAN-Wert geht an die Provider-Sitzung und wird nie gespeichert. Abbrechen gilt nur vor dem Absenden. Freigeben und Abbrechen arbeiten als Compare-and-Set: Hat der Batch pending_approval bereits verlassen, liefert der Aufruf 409, statt auf veraltetem Stand zu handeln. Abgleichen vermerkt eine Bankreferenz an einer Auszahlungsposition; es dreht keine Überweisung zurück.

Die Gebühreneinstellungen sind eine instanzweite Einzelzeile. package_fee_percent und runner_fee_percent müssen jeweils zwischen 0 und 100 liegen; der Server weist alles außerhalb ab. Eine Änderung gilt für künftige Abrechnungen – sie bepreist keinen Batch rückwirkend um, der schon in der Warteschlange steht.

Fehlerseite

Getragen von GET /api/admin/error-page und PUT /api/admin/error-page.

Ein roher JSON-Editor für die einzelne Standard-Fehlerseite der Instanz (error_page_config) – die Rückfallebene für eine deployte App, wenn weder die App- noch die Workspace-Fehlerseite gesetzt ist. Die Konfiguration ist ein undurchsichtiger Bag, daher ist der Tab ein Textfeld und kein Formular; ungültiges JSON wird schon im Browser abgewiesen, bevor die Anfrage rausgeht.

Speichern ersetzt den ganzen Bag, statt hineinzumischen – eine Änderung, die einen Schlüssel weglässt, entfernt ihn. Der Wert ist die letzte Rückfallebene für jede gehostete App der Instanz; siehe Separates App-Hosting.

Marketplace-Prüfung

Getragen von POST /api/admin/marketplace/items/{id}/review/approve und .../review/reject, jeweils mit optionaler Begründung.

Das Prüf-Gate für Katalog-Einträge. Jede Zeile zeigt Name und Slug des Eintrags, sein aktuelles Verdikt-Abzeichen und ein Begründungsfeld, dazu Freigeben und Ablehnen.

• Freigeben setzt marketplace_items.verified – das Installations-Gate –, womit ein kostenpflichtiger oder zentraler Eintrag instanzweit installierbar wird. Das ist der folgenschwere Vorgang auf diesem Tab.
• Ablehnen hält die Ablehnung fest und lässt verified falsch, der Eintrag bleibt auf dem kostenpflichtigen/zentralen Weg also uninstallierbar.
• Ein entschiedener Eintrag fällt aus der Warteschlange; der Tab listet nur unentschiedene.

Die Warteschlange ist abgeleitet, nicht abgerufen

Es gibt keinen Endpunkt, der offene Prüfungen listet. Der Tab liest den öffentlichen Katalog, holt zu jedem Eintrag das letzte Verdikt und behält die noch unentschiedenen – gar keine Prüfung, pending oder der Saatzustand unverified. Die praktische Folge: Ein Eintrag, der nicht im öffentlichen Katalog steht, erscheint hier nicht, auch wenn er auf eine Entscheidung wartet.

Wie das Veröffentlichen von der anderen Seite aussieht, steht in Ein Marktplatz-Bundle veröffentlichen.

Marketplace-Quellen

Getragen von GET|POST /api/marketplace/sources, PATCH|DELETE /api/marketplace/sources/{id} und POST /api/marketplace/sources/{id}/sync.

Die Quellen-Registry: auflisten, anlegen, bearbeiten, löschen und Sync je Quelle, mit einer Art (Git oder Workspace) und einem Abzeichen Aktiviert / Deaktiviert / Sync-Fehler je Zeile.

Dieser Tab ist die Ausnahme – er ist Workspace-bezogen

Seine Endpunkte liegen nicht unter /api/admin. Sie lösen den aktiven Workspace des Aufrufers auf und verlangen Workspace-Admin, nicht Instanz-Admin. Die Zeilen, die du hier siehst und bearbeitest, sind also die Quellen des aktiven Workspace, und ein Workspace-Wechsel ändert, was dieser Tab zeigt. Jeder andere Tab dieser Konsole wirkt instanzweit.

Zwei serverseitige Schutzregeln gelten unabhängig von der Rolle:

• Die kuratierte offizielle Quelle (Art official, keinem Workspace zugeordnet) ist hier nur lesbar: Sie zeigt Status und einen Sync-Knopf, und der Server weist ein Bearbeiten oder Löschen ab.
• Löschen wird mit 409 abgewiesen, solange die Quelle noch veröffentlichte Einträge hat, damit das Entfernen einer Quelle ihren Katalog niemals stillschweigend mitreißt. Ziehe zuerst die Einträge zurück.

Wie du aus einer synchronisierten Quelle installierst, steht in Einen Marktplatz-Connector installieren.

---

Siehe auch: Berichte (die tenant-bezogene Betriebssicht), Die Delivery-Engine betreiben (die /operator-Konsole), Sitzplätze und Abrechnung verwalten, Editionen und Berechtigungen, Umgebungsvariablen und Navigation und Hubs.