Erfolg durch KI

Admin

Betriebshandbuch

Interne Referenz für Preismodell, Permissions, Slide-QA und Deploy-Pipeline. Kein Kundendokument — nur für den Admin-Bereich.

01

Pakete & Preise

Modell B — Access-Pass

User kaufen keinen Einzelkurs, sondern einen zeitlich unbegrenzten Zugangs-Pass (Paket). Das Paket enthält eine definierte Liste von Schulungen plus optionale Permission-Bits. Preisänderungen wirken immer nur für Neukäufe — bestehende Paketzuweisungen bleiben unverändert (Grandfathering).

Preisfelder

price_eur
Tatsächlicher Verkaufspreis. Pflichtfeld wenn das Paket verkauft werden soll.
compare_at_price
Streichpreis. Nur angezeigt wenn größer als price_eur.
badge_label
Text auf dem Highlight-Badge, z.B. „Beliebt" oder „Angebot".
is_highlighted
Hebt das Paket auf der Landingpage hervor (Badge + prominente Platzierung).

Sonderflags

access_all
Gewährt Zugriff auf alle neutralen Schulungen, auch zukünftige. PST-Varianten immer ausgenommen. Nur für Premium/Unbegrenzt-Pakete setzen.
is_free / Köder
Schulung ohne Paket für alle eingeloggten User frei. Kein Package-Eintrag nötig.
Grandfathering: Preisänderungen und Paket-Änderungen gelten ausschließlich für neue Käufe/Zuweisungen. Bestehende User-Pakete werden nicht automatisch angepasst — weder billiger noch teurer, weder um neue Schulungen ergänzt (außer bei access_all).
02

Permission-System

Auflösungs-Priorität

Die erste Regel, die greift, gewinnt. Weiter unten liegende Regeln werden nicht mehr geprüft.

  1. 1. user_overrides Direkt-Permission auf User ↔ Schulung. Absoluter Vorrang, auch wenn das Paket nichts enthält.
  2. 2. courses.is_free Schulung ist für alle eingeloggten User frei — kein Paket nötig.
  3. 3. access_all-Paket User hat ein Paket mit access_all = 1 → alle neutralen Schulungen freigegeben.
  4. 4. package_courses Schulung ist im Paket des Users enthalten (und Paket ist dem User zugewiesen).

Permission-Bits

view

Schulung anschauen — Slides + Player sichtbar. Voraussetzung für alle anderen Bits.

handout

HTML-Skript-Download. Erfordert view = 1.

pdf

ZIP-Archiv mit Vorlagen. Erfordert view = 1. Im UI oft als "ZIP" beschriftet.

Bits lassen sich sowohl auf Paket-Ebene (gilt für alle User des Pakets) als auch per Direkt-Permission (gilt für einen einzelnen User) setzen.

03

Slide-Q&A

Approval-Status

auto Admin-eigene Einträge. Keine Freigabe nötig, sofort sichtbar.
pending_review Eingang von regulären Usern. Nur für den Admin sichtbar, bis manuell freigegeben.
approved Freigegeben, für andere User sichtbar.
rejected Verworfen, wird nirgendwo angezeigt.

Standard-Workflow

  1. 1 User markiert Feedback auf einer Folie → landet als pending_review in der DB.
  2. 2 Admin öffnet Slide-Q&A, sieht alle pending_review-Einträge.
  3. 3 Admin ergänzt optional eine Notiz und exportiert als Markdown.
  4. 4 Markdown wird in Claude Code eingefügt → alle betroffenen Folien werden angepasst.
  5. 5 Nach dem Update: Bulk-Resolve-Button nutzen oder einzeln auf resolved setzen.
  6. 6 Resolved-Einträge verschwinden aus der Standard-Ansicht (Filter „Alle" zeigt sie noch).

Token-Action: resolve-ids

Maschinenlesbare Endpoint-Action, die Claude Code nach einem Bulk-Fix aufrufen kann, um eine Liste von Feedback-IDs auf resolved zu setzen — ohne manuellen Admin-Klick.

POST /api/admin/slide-qa.php?action=resolve-ids
Headers: X-CSRF-Token: <token>
Body: { "ids": [42, 43, 44], "token": "$APP_SECRET" }

APP_SECRET liegt im Secret-Store unter pst/erfolg-durch-ki/app-secret — niemals in den Code.

04

Deploy-Pipeline & Fallen

Pipeline-Übersicht

01 Hub bearbeiten
Markdown-Quellen in ~/Dokumente/nextcloud/privat/projekte/ki_schulungen/<schulung>/src/ editieren.
02 Build lokal
python3 build.py all → erzeugt dist/{pst,neutral}/. Kein CI, kein Container.
03 Sync ins Portal
sync_from_master.sh kopiert Hub-dist/ nach ~/Projekte/erfolg-durch-ki/content/<slug>/.
04 git push
cd ~/Projekte/erfolg-durch-ki && git add -A && git commit && git push origin main
05 CI/CD + lftp
GitHub Actions baut das Astro-Frontend und deployed via lftp auf den Server. Dauert 16–22 Minuten. Jobs laufen sequenziell — kein paralleles Deployen!

Bekannte Fallen

Migration läuft NICHT automatisch

Nach einem Deploy mit neuen DB-Migrationen muss manuell aufgerufen werden:
/api/admin/migrate.php?token=$APP_SECRET
Erst aufrufen wenn die CI-Queue komplett leer ist — sonst läuft die Migration gegen den alten Stand. Der Migrator stoppt bei der ersten fehlerhaften Migration und rollt nicht zurück.

Kurs-Assets kommen über die Manifest-Whitelist

CSS, JavaScript, Bilder, Filme und Untertitel dürfen relativ eingebunden werden. scripts/build_course_manifest.py führt sie getrennt von den sichtbaren Materialien unter assets. Der Sync ruft den Generator automatisch auf. Fehlt eine Datei dort, blockiert serve.php sie bewusst. MP4- und WebM-Filme werden mit HTTP-Range-Unterstützung ausgegeben; Spulen und das Fortsetzen eines Abrufs funktionieren dadurch auch im Browser. Inter-Schriften liegen global unter /fonts/.

CI-Jobs laufen sequenziell

Zwei schnell aufeinanderfolgende Pushes queuen sich. Der zweite startet erst nach Abschluss des ersten. Plan: warte mit Migrationen, bis du weißt dass kein weiterer Push in den nächsten 25 Minuten kommt.

Migration — Kurzanleitung

  1. 1 git push → warten bis CI-Queue leer (GitHub Actions → alle grünen Häkchen).
  2. 2 Migration-Endpoint aufrufen: /api/admin/migrate.php?token=$APP_SECRET
  3. 3 Response prüfen: {"status":"ok","applied":N} oder {"error":"...","failed_at":"..."}
  4. 4 Bei Fehler: Logs im Backend prüfen, Migration manuell fixen, erneut pushen + warten + aufrufen.
Internes Dokument — wird manuell aktualisiert. Bei Abweichungen gilt der Code als Wahrheit.