Commit Graph
3 Commits
Author SHA1 Message Date
qciganoandClaude Sonnet 5 5df0643a9d Fix: Bestell-E-Mail wird jetzt zuverlässig verschickt (await statt waitUntil)
context.waitUntil() lief in dieser Pages-Functions-Umgebung nicht zuverlässig zu
Ende, bevor die Anfrage beendet wurde - Bestellungen wurden korrekt gespeichert,
aber die Benachrichtigungs-Mail an [email protected] kam nie an.
Mit echten Live-Bestellungen verifiziert: mit waitUntil kam nichts bei Resend an,
mit await kam die Mail sofort und zuverlässig an.

Außerdem: "Auf Lager"-Feld im Produkt-Formular (Admin) steht jetzt über "Kategorie"
statt darunter, wie gewünscht.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-03 22:48:45 +02:00
qciganoandClaude Sonnet 5 af729ba571 Gutscheine "nur einmal pro Person" + Bestell-E-Mail-Benachrichtigung
1) Gutscheincodes können jetzt im Adminbereich auf "nur einmal pro Person einlösbar"
   gestellt werden. Wird serverseitig durchgesetzt (neue Spalte orders.gutschein_code +
   Prüfung in functions/api/orders.js gegen die echte Bestelldatenbank, case-insensitiv
   nach E-Mail-Adresse) — kann also NICHT durch Löschen von localStorage/einen anderen
   Browser umgangen werden, anders als die bisherige rein clientseitige Rabattlogik.
   Stornierte Bestellungen zählen nicht als "schon benutzt". Ausführlich getestet: echter
   Browser-Checkout mit Einmal-Code funktioniert beim ersten Versuch, wird beim zweiten
   Versuch (gleiche E-Mail) korrekt mit klarer Fehlermeldung abgelehnt, mit anderer E-Mail
   weiterhin nutzbar.

2) Bestell-E-Mail-Benachrichtigung an [email protected]: recherchiert und
   vorbereitet (existierte vorher nirgends im Code). Läuft über Resend (kostenlos bis
   3.000 E-Mails/Monat), im Hintergrund per context.waitUntil() nach jeder neuen
   Bestellung — verzögert nie die Antwort an die Kundschaft und kann eine Bestellung
   niemals zum Scheitern bringen, selbst wenn der Versand fehlschlägt (mit ungültigem
   Testschlüssel verifiziert: Bestellung bleibt trotzdem erfolgreich gespeichert). Wird
   automatisch aktiv, sobald ein RESEND_API_KEY als Secret hinterlegt wird.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-03 22:16:38 +02:00
qciganoandClaude Sonnet 5 fb7a7b76c2 Echtes Bestellsystem: Cloudflare D1 statt Beispieldaten in der Verwaltung
Ersetzt die Phase-1-Beispieldaten in /verwaltung/ durch ein echtes, funktionierendes
Bestellsystem:

- Neue D1-Datenbank (vans-diy-bastelbedarf-db) mit orders/order_items-Tabellen,
  an das Pages-Projekt gebunden (wrangler.toml).
- Neue API-Routen (Pages Functions): POST /api/orders legt beim Checkout eine echte
  Bestellung an (mit Validierung); GET/PATCH /api/verwaltung/orders(/:id) listen bzw.
  ändern Bestellungen — beide zusätzlich zur Middleware nochmal eigenständig gegen die
  Zugangscode-Sitzung geprüft (Verteidigung in der Tiefe). Gemeinsame Auth-Logik aus
  _middleware.js nach functions/_shared/auth.js ausgelagert.
- Checkout (4 Sprachen) sendet beim Absenden die echte Bestellung an die API, zeigt bei
  einem Fehler eine klare Meldung statt einfach auf die Danke-Seite weiterzuleiten.
- /verwaltung/ lädt Bestellungen jetzt live per fetch(), mit Lade-/Fehlerzustand, und
  erlaubt direktes Ändern des Bestellstatus per Dropdown (sofort in der Datenbank
  gespeichert). Neuer Status "storniert" (zählt nicht in Umsatz/Auswertung mit).

Vollständig lokal end-to-end getestet (wrangler pages dev + lokale D1): echter
Browser-Checkout -> Bestellung landet in der Datenbank -> erscheint sofort in der
Verwaltung -> Status ändern bleibt nach Neuladen bestehen.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-03 20:32:46 +02:00