Systemstatus

ETAPE 6 — Terminal live-mode + label-print: (1) Scan-terminalen registrerer nu rigtige scanninger via scan_in (var allerede live for scanning) — bekræftet og ryddet op. (2) ÆGTE label-print: ved scan (med auto-print til) eller via knap sendes labelen nu til printeren via browserens print-dialog. Labelen er formateret med @page 62x50mm så den passer til typiske afhentningslabels/labelprintere, med kurér, kønummer (sidste 4 cifre), modtagernavn, fuld stregkode og tidsstempel. (3) "Genudskriv sidste label"-knap. (4) Label-preview vises nu altid ved scan (ikke kun ved auto-print), så genudskrivning altid virker. (5) Demo-knappen omdøbt til "Test-scan" med advarsel om at den opretter en RIGTIG testpakke — så der ikke er tvivl om hvad der er live vs. test. (6) Terminalen kræver nu terminal-modulet aktivt (jf. Etape 4).

ETAPE 5 — Kurér-styring (admin-kontrolleret): (1) Centralt kurér-katalog i vendor admin → Kurérer & TMS: definér kurerer (GLS, PostNord, DAO, Bring, DHL, UPS m.fl.) med navn, farve, scan-præfikser og TMS-flag. (2) Pr. pakkeshop krydses af hvilke kurerer de må modtage fra — i en matrix. Kunden kan IKKE længere selv tilføje eller vælge kurerer. (3) Tenant-siden er nu read-only: pakkeshoppen ser kun deres tildelte kurerer (med besked om at kontakte support for ændringer). save_config accepterer ikke længere carriers fra tenant. (4) Scan-terminal og display bruger nu de vendor-tildelte kurerer. (5) TMS-flag pr. kurér er forberedt i kataloget — selve TMS-adgang og track & trace bygges i Etape 7. Bagudkompatibelt: pakkeshops uden tildeling beholder deres eksisterende kurerer indtil vendor tildeler fra kataloget.

ETAPE 4 — Modulsystem + trial med auto-lukning: (1) Nyt Modules-system: tilkøbsmoduler (Kundedisplay, Selvbetjening, Label-salg, Scan-terminal, REST API) defineres i vendor admin → Moduler med pris pr. måned. (2) Pr. kunde krydses moduler af i en matrix; den månedlige pris beregnes automatisk som sum af aktive moduler. (3) Modul-gating: display.php, selfservice.php og label.php kræver nu at kunden har det relevante modul aktivt — ellers vises en pæn besked. (4) Trial med auto-lukning: pr. kunde sættes en prøveperiode-slutdato i vendor admin. Når datoen passeres, lukkes adgangen AUTOMATISK ved næste sidevisning (passiv kontrol — kræver ikke cron). Kunden ser en "prøveperiode udløbet"-side; data slettes ikke. (5) "Forlæng trial"-knap og status-styring (trial/aktiv/suspenderet) pr. kunde. (6) Suspenderede/udløbne kunder blokeres også i API. Bagudkompatibelt: eksisterende kunder uden modul-opsætning beholder fuld adgang indtil moduler tildeles.

FIX: Migreret admin blev ikke betragtet som superadmin og kunne ikke oprette brugere. Årsag: login-sessionen var oprettet FØR migrationen til det nye brugersystem, så sessionens rolle var forældet (ingen/admin i stedet for superadmin). Auth::role() læser nu altid den aktuelle rolle fra brugerdatabasen (først via bruger-id, ellers via e-mail) i stedet for at stole på den gemte session-værdi. Dermed genkendes en migreret eller rolle-ændret bruger korrekt med det samme — uden at logge ud og ind.

ETAPE 3 — Brugere & Roller + sikkerhed (vendor): (1) Flere vendor-brugere med roller: superadmin (alt), admin (alt undt. brugeradmin+deploy), support (kun support+læs), finans (fakturering/betaling/bogføring). Rolle-baseret adgangskontrol via UserManager::can(). (2) To-faktor-login (2FA/TOTP) — ægte RFC 6238, virker med Google Authenticator/Authy m.fl. QR-kode genereres lokalt, secret gemmes AES-krypteret, engangs-backup-koder (Argon2id-hashed, vises kun én gang). (3) Brute-force-beskyttelse: lockout pr. IP efter X fejlede forsøg (konfigurerbart). (4) Audit-log: login, ændringer, brugeradministration logges. (5) Session-regenerering ved login. (6) Sikker migration: eksisterende admin-login konverteres automatisk til superadmin — ingen lockout. Argon2id password-hashing var allerede på plads og bevares. Tenant-side 2FA kommer som opfølgning.

ETAPE 3 — Brugere & Roller + 2FA + sikkerhed: (1) Flere vendor-brugere med roller: superadmin (alt), admin (alt undt. brugere/deploy), support (kun support/læseadgang), finans (fakturering/betaling/bogføring). Den eksisterende admin migreres automatisk til superadmin — login fortsætter uden afbrydelse. (2) To-faktor-login (2FA/TOTP) som ren PHP (RFC 6238) — kompatibel med Google Authenticator, Authy m.fl. QR-kode genereres lokalt så hemmeligheden aldrig forlader systemet. Backup-koder (Argon2id-hashet) vises én gang ved aktivering. (3) Hemmeligheden gemmes AES-256-GCM-krypteret. (4) Brute-force-beskyttelse: vedvarende lockout pr. IP (overlever cookie-rydning), styret af max forsøg + lockout-minutter fra indstillinger. (5) Audit-log: login, ændringer, deploys, brugeradministration — synlig under Brugere & Roller. (6) Session regenereres ved login. Brugeradministration kræver superadmin. Delt TwoFactor-komponent klar til også at dække tenant-login.

ETAPE 2.5 — Menu-omlægning: vendor admin er nu opdelt i grupperede sektioner i stedet for at have alt gemt under Indstillinger. DRIFT (Dashboard, Pakkeshops, Support) · ØKONOMI (Fakturering, Betalingsløsninger, Bogføring) · PRODUKT (Moduler, Labels, Kurérer & TMS) · INTEGRATIONER (API & Webhooks) · SYSTEM (Brugere & Roller, Deploy, Oprydning, Indstillinger). Labels har nu sit eget menupunkt (åbner label-editoren direkte). De nye menupunkter Betalingsløsninger, Bogføring, Moduler, Kurérer & TMS og Brugere & Roller står klar med info om hvilken etape de bygges i — så al kommende UI lægges det rigtige sted fra start. Indstillinger rummer fortsat det generelle: brand, tema, forside, funktioner, abonnementer, FAQ, e-mail, fakturering, sikkerhed, kontakt.

ETAPE 2 — Hardkodet data → variabler + rebranding-rester: (1) Forsidens kurér-chips (GLS, PostNord, Bring osv.) og deres farver var hardkodet i index.php — nu styres de fra vendor admin → Indstillinger → Forside med en chip-editor (tilføj/fjern, navn + farve via color-picker eller hex). Overskriften over chips er også redigerbar. (2) "Test fra PackShop" i webhook-test bruger nu systemnavnet fra brand-indstillinger. (3) Rebranding-rester: "Packshop REST API" og webhook-kommentarer rettet til PackTrack. (4) X-Packshop-Signature/X-Packshop-Event headers BEVARES bevidst som protokol-identifikatorer — ændring ville bryde eksisterende webhook-integrationer hos kunder. Semantiske UI-farver (fejl=rød, success=grøn) og tema-fallbacks beholdes som defensive standardværdier; de faktiske temafarver er allerede redigerbare under Tema.

FIX: "Kunne ikke samle data: Cannot read properties of undefined" ved gem af indstillinger. collectPlans() læste input-felter via positions-indeks (inputs[0]..inputs[6]) — hvis bare ét felt manglede, kastede .value en fejl der afbrød hele gem-processen. Alle plan-felter har nu navngivne CSS-klasser (pl-name, pl-price osv.) og læses sikkert med null-guards. Samme robusthed tilføjet til collectFeatures, collectFaq, collectHours og collectResponseTimes — tomme rækker frafiltreres automatisk. Gem af indstillinger virker nu pålideligt.

FIX: Kunne ikke slette abonnementsplan. Slet-knappen brugte this.closest("div").remove() — men knappen lå i en indre flex-div, så kun den øverste række blev fjernet mens resten af plan-kortet (og dermed planen) blev hængende. Knappen fjerner nu hele plan-kortet via en data-row-markør, og collectPlans matcher kun markerede kort. Sletning af abonnement virker nu. (Bemærk: abonnementer flyttes til eget menupunkt under ØKONOMI i Etape 2.5 jf. kortlægningen.)