Bündelt die letzten drei Commits zu einem Release:
- Anonymes Nutzungs-Dashboard für Admins
- Feedback-E-Mail in den Einstellungen
- Optionales Partner-Feld bei Diensteinträgen
- Neue Versions-URL /app/v262/, alle bisherigen Versionen leiten dorthin um
- PWA_APP_START_URL aktualisiert
- STATIC_VERSION auf 26.2 (Cache-Busting für CSS/JS)
- Update-Info-Text für Nutzer geschrieben (Partner-Feld, Feedback-Mail)
- README-Release-Checkliste um Deployment-Schritt ergänzt (Migration/
collectstatic/Gunicorn-Neustart), da jetzt zum ersten Mal ein echtes
Datenmodell existiert
Lokal getestet: kompletter Redirect-Kette (alte Versionen -> v262), v262 lädt,
Cache-Buster in den Asset-URLs, versionnumber im Markup, Track-Endpoint nach
Migration funktionsfähig.
Deployment auf den Server steht noch aus (SSH-Zugriff wird gerade
eingerichtet) - siehe Hinweis im Chat.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Neues Modell UsageEvent (device_id, Plattform/Browser aus User-Agent
serverseitig geparst, Standalone-Flag, Zeitstempel) - komplett anonym,
device_id ist eine zufällige, nur lokal im Browser gespeicherte ID
- POST /app/track/: nimmt ein Nutzungssignal entgegen (max. 1x pro Gerät/Tag,
siehe home01.js: pingUsageIfNeeded())
- GET /app/dashboard/: Übersicht für Admins (staff_member_required, nutzt
bestehenden Django-Admin-Login) - Geräte heute/7/30 Tage, Plattform- und
Browser-Verteilung, Standalone-Quote, letzte Signale
- UsageEvent zusätzlich im normalen Django-Admin registriert
- Migration bewusst nicht mitcommittet (Projekt-Konvention, siehe .gitignore) -
muss auf jedem Environment einmalig per `manage.py makemigrations app &&
manage.py migrate` erzeugt werden
Lokal getestet: Track-Endpoint, Dashboard-Rendering mit Testdaten, Admin-Login-
Schutz (unauthenticated -> 302), Django-Admin-Listing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Samuel Zielke