Systemstatus

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.)

ETAPE 1 færdig — standard vs. custom kunde-deploy: (1) En deploy-ZIP kan nu indeholde en deploy.json manifest i roden. Uden den = standard-release (opdaterer kernen for alle butikker, som hidtil). (2) Med {"type":"custom","target_tenant":"butik-id"} = custom deploy: filerne lander i butikkens egen mappe (data/tenants/{id}/custom/) og rører ALDRIG kernen — så de overskrives ikke ved næste standard-release. (3) Custom deploy validerer at butikken findes, ændrer IKKE den globale version, og logges på butikkens egen historik. (4) Deploy-resultatet viser nu om det var standard eller custom. Forbereder per-kunde tilpasninger uden at bryde delt kodebase.

FIX: Kunne ikke gemme ændringer under Indstillinger. (1) save_settings brugte array_replace_recursive som merger lister element-for-element — derfor kunne man IKKE slette en abonnementsplan eller label-størrelse (den gamle blev hængende). Nu erstattes lister helt, mens nøgle-sektioner stadig flettes korrekt. (2) Skrivefejl rapporteres nu (tidligere sagde serveren "ok" selv hvis settings.json ikke kunne skrives — relevant efter Simply-migration hvis data/vendor/ mangler skriverettigheder). (3) Gem-funktionen i admin er pakket i fejlhåndtering, så fejl vises som besked i stedet for at fejle lydløst. (4) system-blokken (version/changelog) bevares altid ved settings-gem.