15 Commits

Include renames

Author	SHA1	Message	Date
Nick SzaunigandClaude Opus 5.5	fb9c2353c6	feat: Archiv-Tab fuer Bestellungen, Retouren und Produkte im Admin ... Abgeschlossene Eintraege wandern automatisch in einen Tab "Archiv", damit die aktiven Listen nur zeigen, was noch zu tun ist: - Bestellungen: versendet/abgeholt/storniert, keine offene Retoure, seit einem Monat nicht bearbeitet - Retouren: angenommen/abgelehnt/erstattet, seit einem Monat nicht bearbeitet - Produkte: seit einem Monat Bestand 0 (nur Admin-Sicht, Shop unveraendert) Die Automatik laeuft beim Oeffnen der jeweiligen Liste (hoechstens alle 5 Minuten) und holt Eintraege zurueck, sobald sie wieder offen sind. Zusaetzlich "Archivieren"/"Wiederherstellen" per Hand; von Hand archivierte Eintraege fasst die Automatik nicht an. Alle Verschiebungen landen im Audit-Log. Neue Felder archivedAt/archivedManually samt Index an orders, return_requests und products (Migration 20260925010000_archive_fields). Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>	2026-09-25 04:05:10 +02:00
Nick SzaunigandClaude Opus 5	2bbb38c31a	fix: SSO umging die Admin-2FA; perf: Dashboard und fehlende Indizes ... SICHERHEIT — "Mit Microsoft anmelden" uebersprang die eigene 2FA auch bei Admin-Konten. requireAdmin (admin/actions/_shared.ts) laesst eine Admin-Aktion nur zu, wenn am Konto twoFactorEnabled steht. Das Flag soll zusichern, dass hinter jeder Rueckerstattung und jedem Blick in die Kundendaten tatsaechlich ein zweiter Faktor stand. Der SSO-Rueckweg legte aber direkt eine vollstaendige Session an und lieferte damit ein Flag, das "geprueft" behauptet, obwohl in diesem Anmeldevorgang nichts geprueft wurde — die Zusicherung hing allein an einer Annahme ueber die MFA-Richtlinie des Entra-Mandanten, die dieser Code nicht nachpruefen kann. Ein ADMIN mit aktivierter 2FA laeuft jetzt auch per SSO durch denselben TOTP-Schritt wie beim Passwort-Login. Ausgesperrt wird dabei niemand: twoFactorEnabled heisst, dass der zweite Faktor eingerichtet ist. Fuer KUNDENkonten bleibt der bequeme Weg wie dokumentiert bestehen. PERFORMANCE — zwei unbegrenzte Abfragen auf dem Admin-Dashboard. Die Startseite des Admin-Bereichs lud bei jedem Aufruf 1. JEDE Bestellposition, die es je gab, samt Produkt-Join — um daraus fuenf Zeilen "Top-Produkte" zu rechnen, und 2. JEDE Bestellung, die es je gab — um daraus eine einzige Zahl ("Stammkunden") zu machen. Die Begruendung im Code lautete, Prisma koenne kein HAVING. Es kann. Beides erledigt jetzt die Datenbank per groupBy. Aus "waechst mit jedem Verkauf" wird "eine Zeile je verkauftem Produkt" bzw. "eine Zeile je Stammkundschaft". Die Kategorie haengt am Produkt und laesst sich nicht mitgruppieren; sie kommt aus einer kurzen Nachfrage ueber die Primaerschluessel der tatsaechlich verkauften Produkte. PERFORMANCE — fehlende Indizes auf order_items. PostgreSQL legt fuer Fremdschluessel-Spalten keinen Index an (anders als MySQL/InnoDB). Auf der am schnellsten wachsenden Tabelle des Shops fehlten dadurch zwei: - productId: hasCustomerPurchased (lib/reviews.ts) prueft den "verifizierten Kauf" bei JEDEM Aufruf einer Produktseite durch eine angemeldete Kundschaft — bisher als vollstaendiger Tabellenscan. - batchId: das Loeschen einer Charge prueft ueber onDelete: Restrict gegen dieselbe Tabelle. Migration 20260919010000_order_item_fk_indexes. tsc: 0 Fehler. vitest: 328/328 gruen. eslint: 0 Warnungen. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-19 04:22:53 +02:00
Nick SzaunigandClaude Opus 5	a3f91b83fc	fix: abgebrochener Checkout gibt die reservierte Ware sofort wieder frei ... Eine Bestellung entsteht vor der Zahlung und reserviert dabei sofort Lagerbestand — sonst könnte zwischen Kaufentscheidung und Zahlung jemand anders dasselbe Glas kaufen. Bricht die Kundschaft bei Stripe ab, passierte danach: nichts. Die Seite /checkout/cancel war reiner Text, die Bestellung blieb auf "NEU", und der Bestand kam erst zurück, wenn Stripe die Sitzung für abgelaufen erklärte — nach Voreinstellung 24 Stunden später. Das ist nicht nur unschön, es ist ausnutzbar. Zehn Checkouts pro Stunde und IP, bis zu zwanzig Stück je Position, fünfzig Positionen: damit lässt sich der Shop leerräumen, ohne einen Cent zu zahlen, und das Lager bleibt einen Tag lang blockiert. Drei Schichten dagegen, jede für sich wirksam: 1. Die Stripe-Sitzung läuft nach 32 statt 24 Stunden ab (expires_at). Stripe lässt als Untergrenze 30 Minuten zu; die zwei Minuten Aufschlag sind Puffer gegen auseinanderlaufende Uhren, sonst kann die Erstellung als "weniger als 30 Minuten" abgewiesen werden. 2. Der Abbruch-Knopf bucht sofort zurück. Die cancel_url trägt dazu einen eigenen Token (Order.cancelToken, 32 Byte), nicht die Bestellnummer: die steht in jeder Bestätigungsmail und auf jeder Rechnung, mit ihr ließe sich also die offene Zahlung einer fremden Person abbrechen. Der Token wird nach Gebrauch aus der Adresszeile entfernt. {CHECKOUT_SESSION_ID} wäre der naheliegende Weg gewesen, ist aber nur für success_url und return_url dokumentiert, nicht für cancel_url — darauf baut hier nichts. 3. Ein CronJob prüft alle 30 Minuten nach, was liegengeblieben ist. Er greift genau dann, wenn Schicht 2 nicht greifen kann: checkout.session.expired ist im Dashboard nicht abonniert, der Endpunkt war nicht erreichbar, die Zustellversuche sind abgelaufen. Ohne ihn bliebe der Bestand dauerhaft blockiert, und zwar unsichtbar — eine solche Bestellung sieht im Admin aus wie jede andere offene. Gefragt wird an jeder Stelle zuerst Stripe, nie die Uhr allein. Ist die Sitzung dort "complete", war der Aufruf kein Abbruch, sondern ein Zurück-Klick nach erfolgreicher Zahlung — dann bleibt alles unangetastet. Umgekehrt vorzugehen hieße, eine bezahlte Bestellung zu stornieren und ihre Ware ein zweites Mal zu verkaufen. Findet der Aufräumlauf eine Bestellung, die bei Stripe bezahlt ist, hier aber noch auf "NEU" steht, rührt er sie nicht an: das nachträglich selbst zu erledigen hieße, Rechnung, Bestätigungsmail und Gutscheinzählung zu überspringen. Er meldet den Fall und endet mit Exit-Code 1, damit er als fehlgeschlagener Job auffällt statt in einer Logzeile zu verschwinden. Das Stornieren samt Rückbuchung liegt jetzt einmal in lib/order-release.ts statt verteilt. Der Statuswechsel ist ein einzelnes bedingtes UPDATE ("nur wenn noch NEU"), damit Abbruch-Klick und Webhook im selben Moment den Bestand nicht doppelt gutschreiben. Weiter in diesem Zug: - Betragsabgleich im Webhook: weicht session.amount_total von der eigenen Summe ab, hat etwas außerhalb dieses Codes mitgerechnet (am ehesten eine im Dashboard eingeschaltete automatische Steuer). Die Bestellung bleibt bezahlt — das Geld ist geflossen —, aber die Abweichung wird laut geloggt. Sonst wird bei zu wenig eingezogenem Geld stillschweigend mit Verlust versendet, und bei zu viel weicht die Rechnung vom belasteten Betrag ab. - preflight prüft, ob der Webhook-Endpunkt alle vier Ereignisse abonniert hat. Ein eingeschränkter Schlüssel darf die Liste womöglich nicht lesen; dann meldet die Prüfung "ungeprüft" statt "in Ordnung". - Packstation-Bestellungen waren vollständig kaputt: die Muster für Packstation- und Postnummer lauteten /^d{1,10}$/ und /^d{6,10}$/. Ohne Backslash trifft das nicht "Ziffer", sondern den Buchstaben d — jede echte Nummer wurde abgewiesen, gültig wären nur Eingaben wie "dddddd" gewesen. Der Fehler war beim Lesen kaum zu sehen, weil die Fehlermeldung daneben das Richtige sagte. Drei Tests halten das jetzt fest. - Das Laufzeit-Image bekommt src/lib vollständig statt zweier einzelner Dateien: der CronJob zieht über order-release.ts weitere Module nach, und einzeln aufgezählt fällt so etwas erst im Cluster mit "Cannot find module" auf. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-18 02:07:22 +02:00
Nick SzaunigandClaude Opus 5	e525db84ef	feat: fortlaufende Rechnungsnummer statt Zufallszahl ... § 14 Abs. 4 Nr. 4 UStG verlangt eine FORTLAUFENDE Rechnungsnummer. Bisher stand dort "RE-2026-<8 Hex>": eindeutig ja, fortlaufend nein. Bei einer Betriebsprüfung ließe sich damit nicht zeigen, dass keine Rechnung fehlt — aus einer Lücke in einer Zufallsfolge lässt sich nichts ablesen, aus einer Lücke in 0001, 0002, 0004 sehr wohl. Das war der letzte offene Rechtspunkt vor dem Live-Gang, und der einzige, der sich ohne Absprache schließen ließ. Die Nummer heißt jetzt RE-<Jahr>-<laufende Nummer>, also RE-2026-0001. Die Zählung beginnt jedes Jahr neu bei 0001; das ist zulässig, solange das Jahr Teil der Nummer ist. Die laufende Nummer kommt aus der neuen Tabelle invoice_counters, eine Zeile je Jahr. Der naheliegende Weg "höchste vorhandene Nummer + 1" wäre falsch: zwei gleichzeitig eintreffende Stripe-Webhooks läsen denselben Höchstwert und vergäben dieselbe Nummer. Das upsert mit { increment: 1 } sperrt die Zeile, solange es zählt, und serialisiert damit die Vergabe. Vor dem Hochzählen prüft dieselbe Transaktion, ob zur Bestellung bereits eine Rechnung existiert. Stripe stellt denselben Webhook erneut zu, wenn die Bestätigung ausbleibt — ohne diese Prüfung verbrauchte jeder Wiederholungs- versuch eine Nummer und risse genau die Lücke, die hier vermieden werden soll. Vier Stellen halten die Nummern gleich lang und damit sortierbar; ab der zehntausendsten Rechnung eines Jahres wächst die Nummer mit, statt abgeschnitten zu werden — eine abgeschnittene Nummer wäre nicht mehr eindeutig. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-18 01:26:18 +02:00
Nick SzaunigandClaude Opus 5	625b73a8c8	feat: Steuersatz je Kategorie und je Produkt, Rechnung weist mehrere Saetze aus ... Ein einziger Satz fuer den ganzen Shop war fachlich falsch: der Steuersatz haengt in Deutschland an der Art der Ware, nicht am Betrieb. Honig ist ein Lebensmittel und ermaessigt besteuert (Anlage 2 zum UStG), eine Bienenwachskerze nicht. Der Satz wird jetzt in drei Stufen bestimmt, die erste gewinnt: 1. Produkt — neues Feld "Umsatzsteuersatz" unter Admin -> Produkte, fuer Ausnahmen, die sich nicht aus der Kategorie ergeben. 2. Kategorie — VAT_RATE_PERCENT_HONIG / _KERZEN / _PROPOLIS. 3. VAT_RATE_PERCENT als gemeinsamer Rueckfallwert. Die Kategorie-Stufe ist der Normalfall: aendern sich die gesetzlichen Saetze, genuegt eine Aenderung an der Konfiguration statt an jedem Produkt. Leer am Produkt heisst ausdruecklich "Satz der Kategorie" und NICHT 0 — 0 bedeutet steuerfrei nach § 19 UStG. Das Formularfeld hat dafuer einen eigenen Zweig im Validierungsschema, sonst haette z.coerce.number() aus dem leeren Feld eine 0 gemacht. Damit kann eine Rechnung mehrere Saetze tragen, sobald Honig und Kerze im selben Paket liegen. Sie weist deshalb je Satz eine eigene Netto- und Steuerzeile aus. Versand und Rabatt verteilen sich im Verhaeltnis der Warenwerte: der Versand ist umsatzsteuerlich eine Nebenleistung und teilt das Schicksal der Hauptleistung — gibt es mehrere, teilt er sich anteilig auf. Die Verteilung nutzt Hare-Niemeyer, damit dabei keine Cent verschwinden oder entstehen; zugesichert ist, dass die Summe aller Zeilen exakt den Rechnungsbetrag ergibt. Der Satz wandert von der Rechnung an die BESTELLPOSITION (OrderItem.vatRatePercent) und gehoert damit zum Snapshot wie der Preis: wird ein Produkt spaeter umkategorisiert, bleiben bestehende Rechnungen unveraendert. Invoice.vatRatePercent entfaellt wieder — ein einzelner Satz je Rechnung ist bei gemischten Saetzen nicht darstellbar. Die Spalte entstand in der vorigen Migration und wurde nie in Betrieb beschrieben. VAT_RATE_PERCENT_PROPOLIS steht auf 19, weil der volle Satz im Zweifel der sicherere ist — als Lebensmittel waeren 7 richtig, als Nahrungsergaenzungs- oder Kosmetikprodukt 19. Im README als zu pruefen vermerkt. Der Manifest-Test hat die neuen Variablen zunaechst als "liest niemand" gemeldet: lib/vat.ts bekommt die Umgebung als Parameter, damit sich die Saetze ohne globalen Zustand testen lassen, und greift auf die Kategorie-Saetze ueber einen berechneten Schluessel zu — beides kann eine Regex nicht sehen. Dafuer gibt es jetzt eine begruendete Ausnahmeliste. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-17 06:54:26 +02:00
Nick SzaunigandClaude Opus 5	7c59283ede	feat: Umsatzsteuer ueber VAT_RATE_PERCENT konfigurierbar und auf der Rechnung ausgewiesen ... Die Rechnung wies bisher gar keine Steuer aus — weder Satz und Betrag noch den Pflichthinweis nach § 19 UStG. Der Satz kommt jetzt aus VAT_RATE_PERCENT und steht auf PDF und HTML-Ansicht: 7 (ermaessigt, Honig als Lebensmittel), 19 (voll) oder 0 fuer die Kleinunternehmerregelung, bei der anstelle der Steuerzeilen der vorgeschriebene Hinweis erscheint. DIE SHOP-PREISE SIND BRUTTOPREISE. Gegenueber Verbrauchern ist der Gesamtpreis inklusive Umsatzsteuer anzugeben (§ 1 PAngV), und genau dieser Betrag steht in Product.priceCents und Order.totalCents. Die Steuer wird deshalb herausgerechnet, nicht aufgeschlagen — ein Aufschlag ergaebe einen anderen Endpreis als den, den die Kundschaft im Warenkorb gesehen und bezahlt hat. Gerechnet wird auf der Gesamtsumme statt je Position, damit sich Rundungen einzelner Zeilen nicht aufsummieren, und der Steuerbetrag ergibt sich als Rest statt aus einer zweiten Rundung: nur so gilt immer netto + steuer === brutto. Eine Rechnung, die sich nicht aufaddiert, ist keine brauchbare Rechnung. Der Versand traegt den Satz der Ware, er ist umsatzsteuerlich eine Nebenleistung. Der Satz wird als Invoice.vatRatePercent FESTGESCHRIEBEN statt bei jeder Anzeige aus der Umgebung gelesen. Wechselt der Steuerstatus des Betriebs, muessen alte Rechnungen weiterhin den damals ausgewiesenen Satz zeigen — ein Beleg ist die Aufzeichnung eines vergangenen Vorgangs, keine Ansicht auf die heutige Konfiguration. Bestehende Rechnungen tragen null und zeigen wie bisher keine Steuerzeilen, weil rueckwirkend nicht feststellbar ist, welcher Satz gegolten haette. Ein unbrauchbarer Wert faellt auf 7% zurueck und wird laut geloggt, statt eine bereits bezahlte Bestellung scheitern zu lassen. Damit das nicht unbemerkt bleibt, prueft "pnpm preflight" den Wert jetzt als Blocker und warnt zusaetzlich bei einem in Deutschland unueblichen Satz. Der bisherige legalNote war ein Platzhalter ("Kleinunternehmerregelung / Umsatzsteuerausweis gemaess tatsaechlichem Status ergaenzen") und ist ersetzt, da die Angabe nun tatsaechlich erfolgt. Bekannte Grenze, im README vermerkt: es gibt genau EINEN Satz. Honig ist ermaessigt besteuert, Kerzen nicht — werden beide verkauft, braucht es einen Satz je ProductCategory. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-17 06:32:12 +02:00
Nick SzaunigandClaude Opus 5	70ede77dde	feat: Rechnungen werden abgelegt, gesichert und mitversendet ... Die Rechnung entstand bisher nur als Datenbankzeile; das PDF wurde bei jedem Abruf neu gerendert und tauchte in keiner E-Mail auf. Das hatte drei Nachteile: Gastbestellungen haben kein Konto, in dem sie den Beleg finden koennten; eine Sicherung der Datenbank sicherte den Beleg nicht mit; und ein spaeter erneut gerendertes PDF konnte nach einer Aenderung an Firmendaten oder Layout anders aussehen als das, was die Kundschaft in Haenden hielt. Ablage jetzt unter INVOICE_DIR, nach Jahr und Kunde sortiert: invoices/2026/mustermann-erika/RE-2026-A3F9C1B2.pdf Das Jahr zuerst, weil sich die Aufbewahrungsfrist danach richtet — ein abgelaufener Jahrgang laesst sich als ganzes Verzeichnis archivieren. Der relative Pfad steht als Invoice.pdfPath in der Datenbank, damit eine spaetere Aenderung an der Pfadbildung keine bereits abgelegten Belege unauffindbar macht. Dafuer wurde die nie gelesene Spalte "pdfUrl" umbenannt; eine URL war ohnehin das falsche Konzept. INVOICE_DIR ist bewusst ein ANDERES Verzeichnis als UPLOAD_DIR: app/uploads/[...path] liefert jede Datei unterhalb von UPLOAD_DIR ohne Anmeldung aus. Laegen Rechnungen dort, koennte jede Person, die den Pfad erraet, fremde Rechnungen samt Anschrift und Bestellinhalt herunterladen. Auf das Rechnungsverzeichnis zeigt keine oeffentliche Route; der Abruf laeuft weiter ueber /rechnung/<nummer>/pdf mit Besitzpruefung. Der Abruf liefert jetzt die abgelegte Datei aus und rendert nur neu, wenn keine da ist — also bei Rechnungen aus der Zeit davor. Versand: das PDF haengt an der Bestellbestaetigung. sendMail nimmt dafuer optionale Anhaenge entgegen, alle zehn bestehenden Aufrufe bleiben unveraendert. Schlaegt das Erzeugen oder Ablegen fehl, geht die Bestaetigung trotzdem raus und die Rechnung bleibt abrufbar: ein 500er an Stripe waere die falsche Antwort auf eine volle Platte, denn die Zahlung ist erfolgt und ein Wiederholungslauf aenderte daran nichts. Sicherung: der taegliche CronJob packt das Verzeichnis als rechnungen-<Zeitstempel>.tar.gz neben den Datenbank-Dump und haengt das Volume nur lesend ein. Vermerkt ist dort auch die Einschraenkung, dass wabenhain-invoices als ReadWriteOnce nur von Pods auf demselben Knoten einhaengbar ist — bei mehreren Knoten braucht es ReadWriteMany, sonst bleibt der Sicherungs-Pod lautlos in "Pending". Weiterhin offen und im README vermerkt: die Rechnungsnummer ist eindeutig, aber nicht fortlaufend (§ 14 Abs. 4 Nr. 4 UStG), und das PDF weist keine Umsatzsteuer aus. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-17 04:12:44 +02:00
Nick SzaunigandClaude Opus 5	c525735285	feat: ein Shop-Produkt je Jahrgang statt je ApiCore-Artikel ... Der Produkt-Sync bildete den Fall gleichnamiger Jahrgaenge nicht ab. In ApiCore ist "Waldhonig 500 g" EIN Katalogartikel, an dem jedes Jahr eine weitere Abfuellung haengt; der Sync legte daraus genau ein Wabenhain-Produkt an. Ab dem zweiten Jahr passierte damit nichts mehr: das Produkt existierte schon und wurde uebersprungen, und die Charge des neuen Jahrgangs blieb unverknuepft, weil linkProductsToBatches nur eingesprungen ist, solange Product.batchId leer war. In Wabenhain gehoert ein Produkt zu genau einer Charge, und das ist richtig so: jeder Jahrgang hat eigenen Preis, eigenen Verkaufstext, eigenes Geschmacksprofil und eigene Bewertungen. Honig ist ein Naturprodukt, die Bewertung des Waldhonigs von 2026 sagt ueber den von 2027 nichts aus. Der Sync laeuft deshalb jetzt ueber die ABFUELLUNGEN statt ueber den Artikelkatalog und legt je Abfuellung einen Jahrgang an, bereits mit Charge und Ernte verknuepft. Die nachtraegliche Verknuepfung entfaellt ersatzlos. Wiedererkannt wird ein Jahrgang ueber die neue Spalte Product.apicoreBottlingId (nullable, unique; manuell angelegte Produkte tragen null). Bewusst nicht ueber den Slug: der ist die oeffentliche Adresse und soll lesbar bleiben. Er traegt stattdessen den Jahrgang ("waldhonig-2026") und faellt bei mehrfacher Abfuellung im selben Jahr auf die Losnummer zurueck - hochgezaehlt wird nicht, "waldhonig-2026-2" sagt niemandem etwas. Weitere Entscheidungen, jeweils zugunsten dessen, was tatsaechlich im Glas ist: das Gewicht kommt aus der Glasgroesse der Abfuellung statt aus dem Artikel, und der Lagerbestand startet bei 0 statt bei der Abfuellmenge - wie viele Glaeser in den Webshop gehen und wie viele in Hofladen oder Wiederverkauf, entscheidet Wabenhain. Ein in ApiCore ausgelaufener Artikel bekommt keinen neuen Jahrgang mehr, bereits importierte bleiben unveraendert im Verkauf: solange Glaeser im Regal stehen, ist "nicht mehr produziert" kein Grund, den Abverkauf abzubrechen. Fehlt die Charge eines Jahrgangs noch, meldet der Lauf das als "wartet auf den Ernten-Sync" statt als Fehler. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-17 03:24:02 +02:00
Nick SzaunigandClaude Opus 5	9dd71ffb9a	feat: Packstation ueber DHL-Standortsuche als Lieferziel waehlbar ... Im Checkout laesst sich unter "Versand" jetzt zwischen der eigenen Anschrift und einer DHL-Packstation waehlen. Postleitzahl eingeben, suchen, Packstation aus der Trefferliste anklicken, DHL-Postnummer eintragen — die Auswahl wird an der Bestellung gespeichert. Aufbau: - lib/dhl-locations.ts: Client fuer die DHL Location Finder Unified API (GET /find-by-address). Bewusst getrennt von lib/dhl.ts — das ist ein anderer DHL-Dienst mit anderer Authentifizierung: nur der API-Key im Header, kein OAuth und kein Geschaeftskundenvertrag. Die Packstation-Auswahl funktioniert damit auch, solange die Versandmarken-Erstellung noch nicht eingerichtet ist. - api/shop/packstationen: serverseitiger Zwischenschritt, damit der DHL-API-Key nicht ins Browser-Bundle geraet. Streng rate-limitiert (15/Minute statt 60 wie die Produktsuche) und mit 15-Minuten-Cache: dahinter steht ein FREMDES Kontingent von 500 Aufrufen pro Tag, das ein ungebremstes Suchfeld an einem Nachmittag aufbrauchen koennte. - Order/Address: packstationNumber + postNumber (Migration 20260915222938_add_packstation_delivery, beide nullable). - checkoutSchema: Postnummer als 6-10 Ziffern, plus zwei refine-Regeln — ohne Postnummer keine Packstation (DHL verlangt sie zwingend), und eine Packstation nur bei Versand, nicht bei Abholung. Zwei Entscheidungen, die Folgearbeit ersparen: - Bei Packstation-Auswahl tragen street/zip/city zusaetzlich die lesbare Anschrift ("Packstation 145", PLZ, Ort). Dadurch zeigen Rechnung, Bestaetigungsmail, Sendungsverfolgung und Admin-Ansicht ohne jede Aenderung etwas Sinnvolles; packstationNumber/postNumber tragen daneben das, was DHL technisch braucht. - lib/dhl.ts baut daraus einen Locker-Empfaenger statt einer Hausanschrift. DHL kennt fuer den Empfaenger zwei sich ausschliessende Formen; eine Packstation als Strassentext zu schicken ergaebe eine Marke auf eine Anschrift, die es nicht gibt. Die Option erscheint nur, wenn DHL_API_KEY gesetzt ist — sonst wuerde Kundschaft in eine Suche laufen, die immer fehlschlaegt. Geprueft: sechs Tests fuer das Umsetzen der DHL-Antwort (die Packstation-Nummer steht in location.keywordId, NICHT in location.ids[0].locationId — letzteres ist ein Systemcode, mit dem weder Kundschaft noch DHL etwas anfangen kann). Dazu am laufenden Produktions-Build: ohne Key liefert der Endpunkt 503 und der Checkout zeigt die Option gar nicht; mit Key 400 bei ungueltiger PLZ und ein echter Aufruf an api.dhl.com, der mit 401 quittiert wird — URL, Header und Anfrageformat stimmen also. Im Browser durchgeklickt: Umschalten blendet das Strassenfeld aus und Postnummer samt Suche ein, die Suche ruft die Route und zeigt die Fehlermeldung an. Feldnamen beider DHL-APIs vorab gegen developer.dhl.com geprueft. Ein Lauf gegen einen echten Schluessel steht noch aus. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-16 00:37:00 +02:00
Nick SzaunigandClaude Sonnet 5	7d5c172487	feat: eigene Bilder pro Charge ... Chargen hatten bisher kein eigenes Bild-Feld (nur Ernten und Produkte) — neue Migration ergaenzt Batch.images (Json-Array, gleiches Muster wie Harvest.images/Product.images). Admin kann Chargenfotos jetzt unter /admin/chargen/[id] hochladen (AdminImageListField, identisch zum Ernten-Formular). Die oeffentliche Chargen-Seite (/charge/[code]) zeigt diese Fotos jetzt bevorzugt, faellt ohne eigene Chargenbilder weiterhin auf die Erntebilder zurueck. Hinweis fuer den naechsten Live-Deploy: die generierte Migration hat nebenbei eine bereits laenger bestehende Schema-Abweichung mitkorrigiert (harvests.images und products.images/tasteTags werden jetzt als NOT NULL erzwungen, wie im Schema schon laenger deklariert) - "prisma migrate deploy" schlaegt fehl, falls dort noch echte NULL-Werte stehen sollten. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-12 04:08:39 +02:00
Nick SzaunigandClaude Sonnet 5	04cc3061cf	perf: DB-Indizes, Footer als Server Component, Site-weite Fehlerseiten ... Datenbank (prisma/migrations/20260904120000_add_performance_indexes): 7 fehlende Indizes auf Fremdschluessel-/Filter-Spalten ergaenzt (Order.customerId+createdAt, Order.status, Order.createdAt, Order.discountCodeId, OrderItem.orderId, Address.customerId, AuditLog.createdAt) — bislang volle Tabellenscans bei Bestelluebersicht, Admin-Dashboard, Checkout-Gutscheinpruefung und Audit-Log. Bundle-Groesse: Footer (TikTok/YouTube/Instagram-Icons, Copyright-Zeile) aus dem client-seitigen site-chrome.tsx in eine eigene Server Component (site-footer.tsx) ausgelagert — brauchte "use client" nur wegen useI18n(), jetzt getDictionary()-Server-Aufruf wie auf jeder Admin-Seite. Entfernt ungenutztes clientseitiges JS/Hydration aus jedem Seitenaufruf (Footer steht im Root-Layout). UX: app/not-found.tsx und app/error.tsx ergaenzt (Next.js-Konventionen fuer 404 bzw. Laufzeitfehler) — beide fehlten komplett, unbekannte Routen und Rendering-Fehler zeigten bisher Next.js' generische, unbrandete Standardseiten statt einer zur Seite passenden Nutzerfuehrung. Dictionary-Kollision dabei aufgefallen und aufgeloest: eine bereits bestehende, admin-interne errorPage-Uebersetzung (src/app/admin/error.tsx, seit dem urspruenglichen App-Grundgeruest vorhanden) blieb unangetastet, die neue site-weite Fehlerseite nutzt einen eigenen Schluessel (siteErrorPage). Verifiziert: tsc --noEmit clean, 118/118 Tests gruen, pnpm build clean. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-04 09:07:37 +02:00
Nick SzaunigandClaude Sonnet 5	b6db9254a9	fix: fehlende Dateien aus vorherigem Commit nachreichen ... CSRF-Schutz, DHL-Versandmarken, Entra-ID-SSO, ApiCore-Sync und die Harvest-isPublished-Migration waren gestaged aber nicht im letzten Commit enthalten — Gitea-Actions-Build brach mit "Module not found" fuer genau diese Dateien ab. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-03 20:10:50 +02:00
Nick Szaunig	0753a3bc8a	SQL and Seed into App	2026-08-19 08:06:09 +02:00
Nick Szaunig	68781589d8	SQL and Seed into App	2026-08-19 07:27:27 +02:00
Nick Szaunig	c7927f2883	feat: Wabenhain Honig-Shop Anwendung ... Vollstaendige Next.js/Prisma-E-Commerce-Anwendung fuer eine Imkerei: Shop, Warenkorb, Stripe-Checkout, Kundenkonto mit 2FA, Admin-Bereich (Produkte, Ernten, Chargen, Bestellungen, Gutscheine, admin-editierbare Website-Inhalte), i18n (DE/EN), Rate-Limiting/CSP/Audit-Log-Haertung, PostgreSQL- und MySQL-Unterstuetzung ueber austauschbare Prisma- Treiber-Adapter, Unit-/Komponenten-/E2E-Tests.	2026-08-17 14:30:28 +02:00