20 Commits

Author SHA1 Message Date
ec11de1ee9 feat: Self-Service-Kontenverwaltung + Organisationsdaten unter /organisation
Neue Rolle ist_organisationsadmin (auth.py), bewusst getrennt von
is_superuser: is_superuser bleibt exklusiv internes, organisationsuebergreifendes
Tuxflotte-Personal mit Zugriff auf /admin/* - ist_organisationsadmin ist
auf die eigene Organisation beschränkt und kann nie über Self-Service
gesetzt werden (organization_id/is_superuser kommen bei
POST /organisation/konten nie aus dem Formular, sondern immer aus der
Session).

/organisation zeigt jetzt Kontakt-/Stammdaten (bearbeitbar) und die
Kolleg:innen-Liste der eigenen Organisation (für alle sichtbar,
Verwaltung nur für Org-Admins/internes Personal via require_org_admin).
Selbstlöschung des eigenen Kontos wird verweigert.

fetch_benutzer_fuer_organisation() von admin_kunden.py nach auth.py
verschoben (jetzt von beiden Routern importiert, kein Duplikat) -
liefert zusätzlich id + ist_organisationsadmin. admin_kunden.py bekommt
eine neue Organisationsdaten-Sektion (nutzt denselben PATCH-Endpoint)
und die neue Checkbox beim Konto-Anlegen, um den ersten Org-Admin einer
neuen Organisation zu bootstrappen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-20 07:40:05 +02:00
36d0346172 feat: Logo im Header + 'Geräte' in der Navigation zu 'Flotte' umbenannt
pics/tuxflotte-beschriftet-schatten.svg (das laut platform-docs bereits
als 'das Logo' referenzierte Markenbild, siehe
13-live-provisioning-boot.md) als static/tuxflotte-logo.svg eingebunden,
im Header neben dem Kundenplattform-Link (wirkt dadurch auch auf der
Login-Seite, die base.html erbt). Passend dazu buchstabiert das Logo
selbst bereits 'Tux'/'Flotte' als Wortmarke.

Nav-Link '/geraete' zeigt jetzt 'Flotte' statt 'Geräte' - sowohl im
Kundenportal-Header (base.html) als auch im Admin-Sidebar
(admin/layout.html), für konsistente Beschriftung über die ganze
Weboberfläche. Reine Anzeigetext-Änderung, URLs/Routen unverändert.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-19 20:36:57 +02:00
24ac11137d feat: Gruppen-Mitgliedschaft direkt aus der Kundenportal-Geräteliste verwalten
Gegenstück zur bestehenden Verwaltung von der Gruppen-Seite aus
(/gruppen/{id}) - jetzt auch umgekehrt vom Gerät aus möglich, ohne
anode-Änderung (fetch_gruppen() aus routers/gruppen.py wiederverwendet,
Diff-Berechnung gegen bestehende add/remove-Endpunkte).

geraete_liste(): neue Spalte 'Gruppen' (aktuelle Mitgliedschaft),
Aktionen-Dropdown bekommt eine Checkbox-Liste aller Organisations-
Gruppen; POST /geraete/{id}/gruppen berechnet die Differenz zur
gewünschten Auswahl und ruft die bestehenden Endpunkte entsprechend auf.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-19 20:21:06 +02:00
ca25ce030e feat: Konfigurationsgruppen im Admin-Auftragskatalog-UI
- Bugfix: auftragskatalog.html hatte Select/Deselect-Formular-Ziele fest
  auf /geraete/... verdrahtet statt zurueck_url zu nutzen - Admin-Ansicht
  eines fremden-Org-Geraets scheiterte dadurch mit 404. Jetzt dynamisch.
- Herkunfts-Anzeige ('via OE'/'via Gruppe') ist jetzt anklickbar, sofern
  ein Sprungziel existiert (neue anreichere_mit_quelle_url()-Hilfsfunktion
  in routers/geraete.py, von geraete.py und admin_geraete.py genutzt).
- Admin-Geräteliste (/admin/geraete) bekommt OE-Spalte + 'In OE
  verschieben', analog zur Kundenportal-Liste.
- Neue, bewusst schlanke Admin-OE-Ansicht
  (/admin/kunden/{org}/organisationseinheiten/{oe}/merkmale) - nur der
  Merkmale-Editor als Sprungziel, kein OE-CRUD (bleibt laut ADR-0012
  Kunden-Self-Service unter /struktur).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-12 21:28:10 +02:00
ea92b3c54c feat: Gruppen-Selfservice im Kundenportal
Kund:innen können jetzt eigene Gruppen selbst verwalten (/gruppen) statt
nur intern über /admin/kunden - reiner Kundenplattform-Zusatz, keine
Backend-Änderung nötig (anode-API war bereits organisationsgebunden und
generisch aufgebaut, siehe ADR-0012). Admin-Zugang bleibt zusätzlich
bestehen (Support/Onboarding), beide teilen sich dieselbe anode-API.

Neuer Router routers/gruppen.py (eng an struktur.py angelehnt, gleiches
Besitz-Validierungsmuster), Templates gruppen_liste/gruppe_detail
(Merkmale-Tristate-Editor + Geräte-Mitgliedschaft, wie
admin/gruppe_detail.html)/gruppe_umbenennen/gruppe_loeschen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-12 20:57:48 +02:00
232d621245 feat: Struktur (OE-Selfservice) + Gruppen-Verwaltung (Admin)
Kundenportal:
- Neue Seite /struktur - OE-Baum (rekursives Jinja-Makro), Anlegen/
  Umbenennen/Löschen (Standard-OE 'Neue Geräte' geschützt), Merkmale-
  Editor pro OE mit Tristate aktiv/inaktiv/nicht festgelegt.
- geraete_liste.html: neue Spalte 'OE', Aktionen-Dropdown um 'In OE
  verschieben' erweitert.
- auftragskatalog.html: zeigt jetzt die Herkunft einer Einstellung an
  (OE/Gruppe/manuell), sofern sie nicht vom Workspace-Default kommt.

Admin (/admin/kunden/{id}):
- Neue Sektion 'Gruppen' - Anlegen/Löschen, verlinkt auf neue
  Detailseite (admin/gruppe_detail.html) mit Merkmale-Editor (wie OE)
  und Geräte-Mitgliedschaft-Checkliste. Bewusst nur intern verwaltbar
  in v1 (siehe Konfigurationsgruppen-Diskussion).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-12 16:41:04 +02:00
af6e93067f fix: E-Mail wird als bytes statt str angezeigt (b'...' in der Navbar)
_row_to_user() dekodierte bislang nur hashed_password von bytes zu str,
obwohl psycopg dieselbe Eigenart (TEXT-Spalte kommt teils als bytes
zurück) auch bei email zeigt. Sichtbar z.B. im Header als
b'name@domain.tld' statt name@domain.tld.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-10 13:53:33 +02:00
dd12dd7b74 feat: Aktionen-Spalte in der Geräteliste (/geraete)
Hardware-Informationen, Installations-/Aktions-Log, De-/Reprovisionieren,
Gerät löschen (Soft Delete, mit Bestätigungsseite) - via Pico-Dropdown,
kein zusätzliches JS. Spricht die neuen anode-Endpunkte aus
provisioning-server an.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-10 13:04:58 +02:00
d0cf308c0a hardening: systemd-Sandboxing fuer kundenplattform.service erweitern
Audit ergab: der Dienst laeuft korrekt als unprivilegierter User (nicht
root, kein sudo, nologin-Shell, bestaetigt per ps/id auf anode), aber
systemd-analyze security kam trotz der vier bestehenden Basis-Direktiven
(NoNewPrivileges/PrivateTmp/ProtectSystem=strict/ProtectHome) nur auf
8.3/10 "EXPOSED" - der volle Capability-Bounding-Set, kein
Syscall-Filter, keine Namespace-/Kernel-/Proc-Beschraenkungen.

Ergaenzt: CapabilityBoundingSet= (leer - der Dienst braucht keine
einzige Linux-Capability), SystemCallFilter=@system-service,
RestrictAddressFamilies (nur INET/INET6/UNIX), RestrictNamespaces,
RestrictSUIDSGID, LockPersonality, MemoryDenyWriteExecute,
ProtectKernel{Modules,Tunables,Logs}, ProtectControlGroups,
ProtectClock, ProtectHostname, ProtectProc=invisible, ProcSubset=pid,
PrivateDevices, RemoveIPC, RestrictRealtime, UMask=0077.

Vor dem Scharfschalten per systemd-run mit exakt dieser
Direktivenkombination gegen den echten Code getestet (nicht nur gegen
eine leere Testanwendung): Login/JWT-Signierung, Postgres-Lese-/
Schreibzugriff via psycopg, ausgehender HTTP-Aufruf via httpx an
provisioning-server, Fernet-Verschluesselung des WLAN-PSK - alles ohne
Fehler unter der vollen Sandbox.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-07 08:00:40 +02:00
43c75df1ed feat: Bereitstellungsvorlagen im Kunden-Admin-Bereich anlegen
Neue Sektion auf der /admin/kunden/{id}-Detailseite: Liste bestehender
Bereitstellungsvorlagen der Organisation + Formular zum Anlegen einer
neuen (Workspace, Backend, Root-Dateisystem, Default/Diskverschluesselung/
Secure-Boot), ruft den neuen provisioning-server-Endpoint auf. Schliesst
die in Phase 5 dokumentierte Luecke: bisher hatte eine frische
Kundenorganisation keine Moeglichkeit, ueberhaupt eine Vorlage zu
bekommen, und damit eine leere Auswahl auf der
Installationsmedium-Selfservice-Seite.

Lokal end-to-end verifiziert (siehe provisioning-server-Commit).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-07 01:59:34 +02:00
19b39af0ce feat: Selfservice-UI fuer Organisation + Installationsmedium (Phase 5)
Zwei neue Menuepunkte fuer eingeloggte Kunden (nicht der
organisationsuebergreifende /admin/-Bereich):

- "Organisation": Name bearbeiten (ruft Phase-3-PATCH auf
  provisioning-server auf).
- "Installationsmedium": WLAN-SSID/-Passwort, Vorlagenwahl, Kontingent
  und Gueltigkeitsdauer speichern, personalisierte Kunden-ISO per
  Klick erstellen (Phase-4-Endpoints), Fortschritt/Status-Anzeige
  (Meta-Refresh waehrend pending/running), Download + dd/Rufus-
  Anleitung. Getrennte "aufladen"-Aktion erhoeht Kontingent/
  Gueltigkeit der bestehenden Enrollment Session (neuer PATCH-
  Endpoint), ohne eine neue ISO zu erzeugen - die bereits ausgeteilte
  bleibt gueltig.

Neue Tabelle installationsmedium_konfiguration (Migration 0004, eigene
DB, kein Foreign Key auf provisioning-server-Ressourcen, siehe
ADR-0011) haelt SSID/verschluesselten PSK/Vorlage/Kontingent-Defaults
sowie die IDs der aktuell gueltigen Enrollment Session und des
zugehoerigen ISO-Baus.

WLAN-PSK wird Fernet-verschluesselt gespeichert (encryption.py, neuer
KUNDENPLATTFORM_ENCRYPTION_KEY) - echte Zugangsdaten, kein
Passwort-Hash-Fall. Download laeuft ueber einen Streaming-Proxy
(anode_stream() in anode_client.py) statt eines direkten Links, weil
der Browser kein KUNDENPLATTFORM_TOKEN besitzt.

Lokal end-to-end verifiziert (Wegwerf-Postgres fuer beide Services,
echter build_customer_iso.sh-Lauf ueber die Kundenplattform-UI):
Formular -> Enrollment Session + ISO-Bau -> Status-Polling ->
Download-Proxy liefert byte-identische, korrekt personalisierte Datei
(SSID/PSK/Aktivierungscode per xorriso-Extraktion gegengeprueft) ->
Aufladen erhoeht Kontingent/Gueltigkeit der bestehenden Session ohne
neuen Bau -> "neues Installationsmedium erstellen" erzeugt neue
Session + ISO, alte Session bleibt unangetastet nutzbar (alter
ISO-Bau wird laut Phase-4-Cleanup automatisch entfernt), leeres
PSK-Feld uebernimmt das zuvor gespeicherte PSK korrekt.
Organisation-Name-Aenderung ueber PATCH verifiziert. Unauthentifizierter
Zugriff auf beide neuen Routen leitet korrekt zu /login um.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-07 01:36:46 +02:00
576613ed0f feat: Auth auf fastapi-users umstellen
Ersetzt die handgestrickte bcrypt+Session-Auth durch fastapi-users
(CookieTransport+JWTStrategy statt Starlette-Session, custom
psycopg3-async-Adapter statt SQLAlchemy). Bestehende bcrypt-Hashes
bleiben gültig und werden beim nächsten Login automatisch auf Argon2
angehoben (pwdlib-Default-PasswordHelper). ist_admin wird zu
is_superuser, damit fastapi-users' eingebaute Semantik direkt nutzbar
ist - require_admin/get_current_user bleiben als Wrapper unter
gleichem Namen, alle Router-Dateien bis auf geraete.py (dict- zu
attribut-Zugriff auf user.organization_id) unverändert.

Lokal end-to-end gegen eine Wegwerf-Postgres-Instanz (podman) verifiziert:
Migration, Bestandskonto-Login mit altem Passwort samt Argon2-Upgrade,
Admin-Kontoanlage über beide Aufrufstellen (create_user.py und
admin_kunden.py), 403 für Nicht-Admins, Logout.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-06 08:29:51 +02:00
b4bd160536 feat: Flows-Verwaltung im Admin-Bereich (Enrollment Sessions, Neugerät-Bestätigung)
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>
2026-08-05 09:32:57 +02:00
eb9fc6b8a7 feat: Technik/Datenbank-Verwaltung im Admin-Bereich
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>
2026-08-05 09:21:11 +02:00
33c4aebfec feat: organisationsübergreifende Geräteverwaltung im Admin-Bereich
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>
2026-08-05 09:12:45 +02:00
b44096b48f feat: Kunden-Management (Organisationen, Aktivierungscodes, Konten)
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>
2026-08-05 09:03:34 +02:00
ed38f103f2 feat: modulare Struktur für Admin-Bereich (Schritt 1)
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>
2026-08-05 08:51:46 +02:00
c35145ef8e feat: Pico.css für Dark/Light-Mode und Responsivität
Klassenloses CSS-Framework (self-hosted unter static/, kein CDN), passt
zum bestehenden Ansatz ohne JS-Build-Schritt. Bringt automatisches
Dark/Light-Mode (prefers-color-scheme) und Responsivität ohne
Zusatzaufwand. Templates auf Picos semantische Konventionen umgestellt
(label/input-Paare, article für die Login-Karte, figure um Tabellen für
horizontales Scrollen). Eigene CSS-Regeln auf die zwei Farb-Utility-
Klassen (state-present/state-absent) reduziert, Rest kommt von Pico.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-05 08:16:43 +02:00
21c6210869 fix: password_hash aus DB als bytes statt str behandeln
psycopg liefert die TEXT-Spalte password_hash beim SELECT als bytes
zurück, nicht als str wie beim create_user.py-Insert - bcrypt.checkpw()
schlug dadurch bei jedem Login-Versuch mit AttributeError fehl. Gefunden
beim ersten E2E-Login-Test auf anode.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 17:06:18 +02:00
c4825acd61 feat: initiale Kundenplattform (Login + Auftragskatalog-Auswahl)
Neuer, von provisioning-server (anode) getrennter Dienst, siehe ADR-0011:
FastAPI + Jinja2, eigene Postgres-DB (benutzer-Tabelle), eigenes
Service-Token (TUXFLOTTE_KUNDENPLATTFORM_TOKEN) für die Kommunikation mit
anode. Org-Zugehörigkeits-Prüfung passiert hier in der Anwendung vor jedem
Aufruf gegen anode.

Umfang v1: Login, Geräteliste, Auftragskatalog geräteweise aus-/abwählen
(inkl. der standardbrowser-Option für Brave). systemd-Unit läuft unter
eigenem unprivilegiertem System-User statt root.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 17:00:03 +02:00