routers/admin_flows.py: pro Organisation unbestätigte Geräte anzeigen
und bestätigen (Bereitstellungsvorlage zuweisen), Enrollment Sessions
anlegen/widerrufen. Confirm-Aktion ruft direkt anodes bestehenden
resolve-Endpoint auf.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
routers/admin_technik.py: Merkmale (anlegen/bearbeiten inkl. Kategorie
und Katalogfähigkeit), Kategorien (anlegen), Workspaces (anlegen +
Zusammensetzung aus Merkmalen - Grundbaustein des Workspace-Creators),
Backends/Blueprints nur zur Anzeige.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
routers/admin_geraete.py mit echter Funktionalität: alle Geräte aller
Organisationen auflisten, pro Gerät der Auftragskatalog (Wiederverwendung
von auftragskatalog.html und der Logik aus routers/geraete.py, nur ohne
Org-Besitz-Check - Admins dürfen jedes Gerät direkt per ID öffnen).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
routers/admin_kunden.py mit echter Funktionalität: Organisationen
auflisten/anlegen, pro Organisation Aktivierungscodes erzeugen und
Kundenkonten anlegen (direkt in der Kundenplattform-eigenen
benutzer-Tabelle, kein anode-Aufruf nötig). Löst das bisherige manuelle
create_user.py-Skript für den Alltagsgebrauch ab.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
app.py auf APIRouter-Module umgestellt (db.py, templating.py,
anode_client.py, auth.py, routers/geraete.py + vier Admin-Router als
Platzhalter). benutzer.ist_admin (Migration 0002) + require_admin-
Dependency (403 ohne Admin-Flag). Admin-Nav-Link im Header nur für
Admin-Konten sichtbar. create_user.py um --admin-Flag erweitert.
Die vier Admin-Bereiche (Technik/Datenbank, Geräte, Flows, Kunden) sind
als Platzhalterseiten unter /admin/... verdrahtet und bekommen in den
nächsten Schritten echte Funktionalität.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
