tim/collector
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
84 commits 1 branch 0 tags 5.1 MiB
Find a file
Exact
Tim Schleibach 65046da121 docs(help): Face ID auf dem iPhone - was geht und was iOS nicht vorsieht 
Ein User wollte die installierte App per "Face ID anfordern" sperren und fand
die Option nicht. Nachgeprueft: iOS bietet den App-Sperr-Eintrag im
Kontextmenue nur fuer echte Apps an, nicht fuer Web-Apps auf dem
Startbildschirm. Das ist eine Plattform-Grenze - es gibt kein Manifest-Feld,
kein meta-Tag und keinen Header, mit dem eine Website das anfordern koennte.
Also kein Fehler auf unserer Seite und nichts, was sich hier fixen laesst.

Statt es unkommentiert zu lassen, steht es jetzt in der Hilfe: die Grenze
selbst, plus der Teil, der tatsaechlich funktioniert (Passwort im
iCloud-Schluesselbund speichern -> Autofill beim Anmelden laeuft ueber Face
ID), plus der Hinweis, dass Discord-Anmelder bei uns gar kein Passwort haben
und Face ID dort nur greift, wenn Discord selbst fragt. Abschliessend das, was
wirklich zaehlt: abmelden, wenn man das Geraet aus der Hand gibt - eine offene
Sitzung ist offen, in der App wie im Browser.

Beim Pruefen kontrolliert und in Ordnung: die Anmelde- und
Passwort-setzen-Formulare tragen die richtigen autocomplete-Werte
(username / current-password / new-password), sonst wuerde der
Schluesselbund gar nicht anbieten zu speichern und zu fuellen.

Nur Text, ungegated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-01 21:34:48 +02:00
.claude feat: Phase 1 MVP – Runden + Bedarfserfassung mit Discord-Auth 2026-07-26 11:21:43 +02:00
.githooks build: ESLint mit react-hooks als vierter Torwaechter (Phase 14c) 2026-08-01 17:42:53 +02:00
packages docs(help): Face ID auf dem iPhone - was geht und was iOS nicht vorsieht 2026-08-01 21:34:48 +02:00
scripts docs(help): Face ID auf dem iPhone - was geht und was iOS nicht vorsieht 2026-08-01 21:34:48 +02:00
.dockerignore feat: Phase 1 MVP – Runden + Bedarfserfassung mit Discord-Auth 2026-07-26 11:21:43 +02:00
.env.example feat(addresses): freiwillige verschluesselte Versandadressen (Phase 5) 2026-07-31 18:19:33 +02:00
.env.production.example feat(addresses): freiwillige verschluesselte Versandadressen (Phase 5) 2026-07-31 18:19:33 +02:00
.gitattributes docs+build: Deployment über Forgejo-Registry (Build-Rechner -> Registry -> VPS) 2026-07-26 17:44:16 +02:00
.gitignore feat: Phase 1 MVP – Runden + Bedarfserfassung mit Discord-Auth 2026-07-26 11:21:43 +02:00
CLAUDE.md feat(ux): W1-W5, M6-M9 und G10 fuer alle freigegeben - Gate entfernt 2026-08-01 19:47:41 +02:00
DEPLOYMENT.md feat(pwa): installierbar + "Neue Version"-Hinweis, Platzhalter im Zahlungsfeld 2026-08-01 18:12:09 +02:00
docker-compose.build.yml feat(pwa): installierbar + "Neue Version"-Hinweis, Platzhalter im Zahlungsfeld 2026-08-01 18:12:09 +02:00
docker-compose.yml feat(addresses): freiwillige verschluesselte Versandadressen (Phase 5) 2026-07-31 18:19:33 +02:00
eslint.config.mjs build: ESLint mit react-hooks als vierter Torwaechter (Phase 14c) 2026-08-01 17:42:53 +02:00
IMPROVEMENTS.md feat(shipping): Versand-Tracking pro Teilnehmer (Phase 5a) 2026-07-31 19:15:58 +02:00
package.json build: ESLint mit react-hooks als vierter Torwaechter (Phase 14c) 2026-08-01 17:42:53 +02:00
PLAN.md feat(ux): W1-W5, M6-M9 und G10 fuer alle freigegeben - Gate entfernt 2026-08-01 19:47:41 +02:00
pnpm-lock.yaml build: ESLint mit react-hooks als vierter Torwaechter (Phase 14c) 2026-08-01 17:42:53 +02:00
pnpm-workspace.yaml feat: Phase 1 MVP – Runden + Bedarfserfassung mit Discord-Auth 2026-07-26 11:21:43 +02:00
README.md feat(ops): Offsite-Backup per Pull vom NAS (S7) 2026-07-31 22:14:45 +02:00
UX-BACKLOG.md feat(ux): W1-W5, M6-M9 und G10 fuer alle freigegeben - Gate entfernt 2026-08-01 19:47:41 +02:00

README.md

Collector

Bedarfserfassung für Sammelbestellungen mit Discord-Login. Details zur Architektur: PLAN.md.

Lokale Entwicklung

Voraussetzungen: Node ≥22, pnpm ≥9, Zugriff auf die LAN-PostgreSQL (192.168.2.10:5433).

pnpm install
git config core.hooksPath .githooks     # Pre-Push-Prüfung aktivieren (siehe unten)
cp .env.example packages/backend/.env   # Discord-Werte + JWT_SECRET eintragen
pnpm --filter @collector/backend db:push
pnpm --filter @collector/backend db:seed
pnpm dev                                # Backend :3001 + Frontend :3000

Optional, aber empfohlen: ADDRESS_ENCRYPTION_KEY setzen (pnpm --filter @collector/backend generate-key), sonst ist die Adressfunktion aus.

Discord-App (einmalig)

  1. Discord Developer Portal: Application anlegen
  2. OAuth2 → Redirect URI: http://localhost:3001/auth/callback
  3. DISCORD_CLIENT_ID, DISCORD_CLIENT_SECRET, DISCORD_GUILD_ID (Server-ID) in packages/backend/.env
  4. Eigene Discord-ID als INITIAL_ADMIN_DISCORD_ID eintragen, dann pnpm --filter @collector/backend db:seed

Tests

pnpm test                                        # ALLE Tests (pnpm -r)
pnpm --filter @collector/backend test            # nur Backend-Integrationstests
pnpm --filter @collector/frontend test           # nur Frontend-Unit-Tests
pnpm --filter @collector/backend test auth       # einzelne Test-Datei

Die Backend-Tests laufen gegen das Schema collector_test in derselben PostgreSQL-Instanz – die Dev-Daten bleiben unberührt. Die Frontend-Tests sind reine Unit-Tests (Geldrechnung in lib/charges.ts, Formatierung in lib/format.ts) und brauchen keine Datenbank.

Pre-Push-Prüfung

Es gibt kein CI (Forgejo ist hier nur Versionskontrolle + Registry, keine Runner), deshalb übernimmt ein Git-Hook die Rolle: .githooks/pre-push fährt vor jedem Push Typecheck → Frontend-Build → Frontend-Tests → Backend-Integrationstests.

git config core.hooksPath .githooks   # einmal pro Arbeitskopie
git push --no-verify                  # Notausgang, wenn es wirklich eilt

Ist die LAN-Datenbank nicht erreichbar, werden nur die Backend-Tests übersprungen (mit deutlicher Warnung) statt den Push zu blockieren – von unterwegs pushen können ist wichtiger als ein hartes Nein. Typecheck, Build und Frontend-Tests laufen immer, sie brauchen keine Datenbank.

Produktion

Vollständige Anleitung: DEPLOYMENT.md (Build-Rechner → Forgejo-Registry → VPS hinter bestehendem Caddy)

Backups liegen nächtlich auf dem VPS; die Offsite-Kopie zieht sich dein NAS mit scripts/backup-pull.sh (Cron) – der VPS bekommt dafür bewusst keine Zugangsdaten. Einrichtung samt eingeschränktem SSH-Zugang: DEPLOYMENT.md, Abschnitt „Offsite-Backup".

Kurzfassung:

# Build-Rechner (braucht nur Docker)
cp .env.production.example .env    # REGISTRY eintragen
./scripts/build-push.sh            # baut + pusht, taggt mit git-SHA und latest

# VPS
cp .env.production.example .env    # Domain, Secrets, Discord, Caddy-Netz
docker compose pull && docker compose up -d
docker compose exec collector-backend pnpm exec tsx prisma/seed.ts   # einmalig

Der Stack bringt eine eigene PostgreSQL mit und veröffentlicht bewusst keine Host-Ports – HTTPS und Routing übernimmt ein externes Caddy über ein gemeinsames Docker-Netz. Migrationen laufen automatisch beim Container-Start. Es gibt keine Build-Zeit-Secrets: dasselbe Image läuft in jeder Umgebung, die Konfiguration steckt komplett in der .env des VPS.