Vanliga frågor

Du når KiiOn support via e-post på support@kiion.io.

Ta bort en användare

1. Gå till användare/personal i företag eller plats.
2. Öppna åtgärdsmenyn för användaren.
3. Välj Ta bort och bekräfta.

Användaren tas bort från den valda nivån (plats eller företag) enligt dina behörigheter.

Vad kan jag se i aktivitetsloggarna?

I aktivitetsloggarna kan du följa vad som hänt i systemet över tid.

• Händelser kopplade till nycklar, dörrar och användare
• Vem som gjort en åtgärd och när
• Filtrering på period och olika typer av händelser
• Möjlighet att exportera loggar

AI-chatten i adminpanelen svarar utifrån kunskapsbasen i KiiOn MCP. Den konfigureras under Systemadministration → Drift & integration → AI-chatt.

Prompterna

Systemprompten byggs av tre fält plus rollkontext, i den här ordningen:

1. Systemprompt — grundpersonligheten.
2. Rollbeskrivning och rollfilterinstruktion (läggs till automatiskt).
3. Beteenderegler.
4. Verktygspolicy.
5. Roll-FAQ-mappningarna och den hämtade kunskapsbasekontexten.

Rollavgränsningen är teknisk, inte en instruktion

• Systemadministratör — hela kategorin KiiOn Bokning, inklusive utvecklar- och systemadmininnehåll.
• Organisationsadministratör — enbart de subkategorier som mappats till rollen (som standard Organisationsadmin guide, Bokningskalender, Bokningsprocess, Betalningar, Rabattkoder, Kvitton, Resurser).

Avgränsningen skickas som argument till MCP-sökningen, så servern filtrerar träffmängden. Tidigare stod rollen bara i systemprompten, och då kunde en organisationsadministratör få systemadmininnehåll så fort modellen ignorerade instruktionen. Urvalsregeln ligger i _shared/ai-chat-role-scope.ts och är testad där.

Modeller och leverantörer

• Flera leverantörer kan konfigureras med prioritet och karenstid — faller den första svarar nästa.
• Modell-id kan bära leverantörsprefix (openai/gpt-5). Vid direktanrop till OpenAI strippas prefixet automatiskt; via gateway skickas det som det är.
• API-nycklar sparas krypterade.

Koppling mot KiiOn MCP

• Bas-URL och token-endpoint anges var för sig.
• OAuth 2.0 client credentials med HTTP Basic (base64 av client_id:client_secret) mot POST /mcp/v1/oauth/token.
• Servern returnerar opaka access-tokens, inte JWT. Token förnyas i förväg utifrån livslängd: över 30 dagar → 30 dagars marginal, 1–30 dagar → 2 dagar, under ett dygn → 1 timme.
• Byter man client id eller secret rensas den sparade token automatiskt, så nästa anrop hämtar en ny.

När chatten svarar fel eller "vet inte"

Innan du ändrar prompten — kontrollera underlaget, det är nästan alltid där felet ligger:

• Saknas embeddings? Nyss skapade eller ändrade FAQ:er syns inte i den semantiska sökningen förrän de indexerats. Kontrollera täckningen och kör en backfill vid behov.
• Är posten publicerad? En opublicerad FAQ returneras bara till anropare med skrivrättighet. Chatten läser — en opublicerad guide är osynlig för den.
• Rätt subkategori? En post i en subkategori som rollen inte är mappad till kommer aldrig med, hur bra den än är.
• Dubbletter av samma guide späder ut träffbilden: modellen får tre halvbra varianter i stället för ett bra svar.

Svarar chatten om en annan produkts funktioner är det oftast inte modellens fel utan att den inte fick någon KiiOn-kontext alls, och då faller den tillbaka på sin allmänna kunskap.

Kort svar: avbokar du en bokning som du betalat med kort betalas pengarna tillbaka till kortet automatiskt. Hur mycket du får tillbaka beror på resursens avbokningsvillkor, och dem ser du innan du betalar. Avbokar eller avslår verksamheten din bokning får du alltid tillbaka hela beloppet.

Avbokningsvillkoren

Varje resurs har ett av fyra villkor:

• Full återbetalning fram till en tidsgräns. Avbokar du mer än ett visst antal dagar före bokningen får du tillbaka allt. Avbokar du senare får du ingenting tillbaka.
• Delvis återbetalning. Allt tillbaka fram till tidsgränsen, därefter en angiven andel.
• Ingen återbetalning.
• Anpassade villkor. Uthyraren har skrivit egna villkor. Kontakta uthyraren om du har frågor.

Villkoren som gällde när du bokade följer med bokningen. Ändrar uthyraren villkoren efteråt påverkar det inte en bokning du redan gjort.

Håll isär två tider:

• Sista avbokning — hur sent du får avboka över huvud taget.
• Tidsgränsen för återbetalning — hur sent du får pengarna tillbaka.

De kan vara olika. Du kan till exempel få avboka fram till dagen före, men bara få pengarna tillbaka om du avbokar mer än 14 dagar före.

Så avbokar du

1. Gå till Mina bokningar.
2. Välj avboka på bokningen. Dialogen visar hur mycket du får tillbaka om du avbokar just då.
3. Bekräfta.

Beskedet efteråt säger vad som hände: att beloppet betalats tillbaka, hur stor andel, att ingen återbetalning sker enligt villkoren, eller att återbetalningen hanteras manuellt av uthyraren. Pengarna brukar synas på kortet inom 5–10 bankdagar.

En bokning som redan har börjat kan du inte avboka själv.

Bokningar som inte betalats med kort

Har du betalat mot faktura, eller betalar du på plats eller direkt till organisationen, sker ingen automatisk återbetalning till kort. Kontakta organisationen — de hanterar krediteringen.

För organisationer

Avbokar eller avslår du en kortbetald bokning — i bokningslistan, bland förfrågningar som väntar på godkännande eller i veckoöversikten — betalas hela beloppet tillbaka till kunden automatiskt. Avbokningsvillkoren gäller bara när kunden själv avbokar. Du behöver inte göra något i betalleverantörens gränssnitt.

Avgifter

KiiOn tar ut en transaktionsavgift av organisationen för varje kortbetalning:

KiiOn Pay Pro ingår i planen Business.

Organisationen kan också ta ut en egen serviceavgift av sina kunder. Den visas i kassan innan du betalar.

Vid återbetalning: KiiOns transaktionsavgift betalas tillbaka till organisationen — hela vid full återbetalning, och i samma andel som beloppet vid delvis återbetalning. En serviceavgift som du som kund betalat ingår i återbetalningen, i samma andel som bokningen.

Andra köp än bokningar — medlemskap, organisationens egen plan och produktbeställningar — ångras på andra sätt. Se "Hur ångrar man ett köp i KiiOn Bokning?".

KiiOn Pay är KiiOns avgift för kortbetalning. Den dras automatiskt från varje betalning innan pengarna landar på organisationens Stripe-konto — ni behöver inte betala någon faktura för den.

Planerna

Alla priser exklusive moms och hämtas från KiiOns standardprislista — de är aldrig hårdkodade i bokningssystemet.

Vilken plan har vi?

Planen följer organisationens abonnemang och byts automatiskt:

• Abonnemanget Starter → KiiOn Pay Free.
• Business/Enterprise, eller tillägget "Ta betalt vid bokning" → KiiOn Pay Pro.

Uppgraderar ni abonnemanget eller lägger till betalningstillägget byter avgiften plan i samma veva. Ni behöver inte göra något själva.

Räkneexempel

En bokning på 250 kr som kunden betalar med kort:

• Free: 7,25 kr + 2,90 kr = 10,15 kr i avgift
• Pro: 6,23 kr + 2,90 kr = 9,13 kr i avgift

Med ungefär 100 kortbetalningar i månaden på den nivån betalar sig Pro-avgiften på 99 kr ungefär jämnt ut; över det tjänar ni på Pro.

Var ser vi vad som dragits?

Varje betalning bär KiiOns faktiska avgift, rapporterad av Stripe i efterhand. Den syns i betalningsöversikten under Ekonomi → Betalningar och följer med i återbetalningar: betalas en bokning tillbaka återförs avgiften proportionellt.

Inte samma sak som serviceavgiften

KiiOn Pay är vad ni betalar KiiOn. Serviceavgiften är en avgift ni kan ta av er egen kund. De två är helt oberoende och kan användas samtidigt.

Status

Planerna och den automatiska avgiftsberäkningen är i drift i utvecklingsmiljön sedan 2026-09-23 och verifierade mot Stripe. I produktion gäller tills vidare den tidigare enhetliga avgiften 2,5 % + 2,50 kr för alla anslutna konton; bytet planeras och meddelas innan det görs.

Vad som var fel

En kund bokade 30 september 2026 kl. 18:30–19:00 på den publika bokningssidan. Bokningssidan visade 18:30–19:00, men bekräftelsemejlet visade 16:30–17:00 — exakt två timmar fel.

Grundorsak: tidsdata lagras korrekt som UTC i databasen, men både skapande och visning använde webbläsarens (eller Edge-runtimens) lokala tidszon utan någon explicit produktzon. new Date(...).setHours(...) tolkade valda klockslag i enhetens zon och toLocaleString visade instanter i samma zon. En webbläsare i UTC (t.ex. Edge-runtimen som genererar mejl) visade därför UTC-tiden direkt.

Lösningen — EN tidszons-policy

BOOKING_TIME_ZONE = "Europe/Stockholm" är nu en enda källa, delad av frontend och Edge Functions:

• src/utils/bookingTime.ts — klientens hjälpfunktioner, re-exporterar serverns policy
• supabase/functions/_shared/booking-time.ts

IANA-zonen (inte hårdkodad offset) hanterar automatiskt CET/CEST och byte mellan sommar- och vintertid.

Fyra familjer av hjälpfunktioner

• Visning: formatBookingTime, formatBookingDate, formatBookingDateTime, formatBooking (date-fns-mönster) formaterar instanter i Stockholm oavsett webbläsarzon.
• Skapande: bookingWallTimeToInstant(dag, klockslag) omvandlar ett valt kalenderdatum+klockslag till UTC-instant. Funktionen avvisar ogiltiga och DST-tvetydiga klockslag (t.ex. 02:30 vid vårbyte) i stället för att normalisera dem — dubbelkonvertering kan inte uppstå.
• Kalenderbärare: bookingCalendarDate (wall-datum som Date med kl. 12), bookingCalendarTimeToInstant, bookingCalendarDayBounds, bookingCalendarDays — kalenderkomponenter använder Date som wall-datum-bärare, inte som instant.
• Slot-parning: bookingSlotRange bygger en slots intervall och avbryter säkert vid ogiltiga tider.

Vad som täcks

• Publik bokningssida: skapa, redigera, återkommande bokningar, fri tidsval, heldagsval
• Admin: godkännanden (inkl. justera-och-godkänn — dialogen prefillar och sparar i produktzonen), bokningslistor, veckoöversikt, månadsvy, fakturauvyer, Excel-export, kvitton
• Kundvy: Mina bokningar, kvitto, mobilkort
• Alla mejl: bekräftelse, godkännande, avbokning, avslag, start/slut-notiser, gästflödets bekräftelser

Regressionstester

• 2026-09-30 18:30 Europe/Stockholm (CEST) → visas 18:30–19:00, sparas 16:30Z
• 2026-01-15 (vintertid, CET) → visas 18:30, sparas 17:30Z
• Playwright kör med webbläsarzon America/Los_Angeles på desktop och mobil och verifierar visning + sparat UTC-payload; Vitest och Deno-tester speglar samma fall (e2e/booking-timezone.spec.ts, src/utils/__tests__/bookingTime.test.ts, _shared/booking-time_test.ts).

Viktigt framåt

• Lagrad UTC-data ändras aldrig — endast presentation och skapande-konvertering styrs av produktzonen.
• Använd inte toLocaleString/setHours direkt på bokningstider — använd alltid bookingTime-hjälpfunktionerna, annars kommer buggen tillbaka i just det gränssnittet.
• Samma princip som prismotorerna: klient och server delar en policy-fil; ändras den ena sidan måste den andra följa.

Implementerat i MR !234 (GitLab #467), commit 0ca03062. Kort e260fa5a i KiiOn CRM.

KiiOn Pay — M3: serviceavgift mot organisationens kund (merchant customer fee)

Status 2026-10-05 — #518 levererad; kassan komplett

Den sista luckan i M3-uppföljningarna (#518) är stängd med commit d8ef0ab5 på development. Kassan visar nu avgiften och totalen i båda prisgrenarna och räknar avgiften på samma grund som servern fryser den på.

• Beräkningsgrunden rättad: hooken useMerchantCustomerFee räknade avgiften på kalenderns netto-pris, men servern fryser den på det belopp kassan skickar — brutto (moms påslagen för exkl.-resurser) och efter rabatt. ResourceCalendarPage räknar nu via bookingChargeAmount (samma grund), och bokningsdialogens rabattgren räknar OM avgiften på det rabatterade beloppet med samma delade regel (calculateMerchantCustomerFee).
• Båda prisgrenarna kompletta: med och utan rabattkod visas serviceavgiftsraden + totalen inkl. avgift. I baked_in (#543) döljs raderna medvetet — avgiften ingår i priset.
• Kvitto, faktura, e-post, Excel och statistik läser de frysta fälten (receiptAmountsFromFrozen, levererat tidigare i 40962e39).
• Nytt: hooken exponerar feeSettings så dialogen kan räkna om regeln på ett nytt belopp utan en egen kopia av regeln.
• 3 nya regressionsvärn i BookingDialog.test.tsx; hela sviten 4 280 tester gröna.

Kvar för M3 i drift: #519 (applicera migrationer + deploy i Supabase dev) och Janis manuella Stripe-steg (#479–#481, #504).

Status 2026-09-22 — rättelser efter granskning

Granskningen 2026-09-22 (milestone KiiOn Pay M6) underkände M3-koden från 2026-09-21. Den tidigare texten sa "🟢 Genomförd"; i praktiken gick ingen kortbetalning igenom. Fem oberoende fel:

• create-stripe-checkout och create-nets-checkout slog upp bookings.organization_id — kolumnen finns inte (organisationen nås via resursen). Varje kortbetalning gav 404.
• Samma omskrivning tappade plattformsavgiften → application_fee_amount blev 0 kr på allt.
• Prenumerationsaktiveringen slutade fungera (500) i samma commit.
• Beloppen blandade kronor och ören mellan klient, hook och server.
• RPC-tabellen saknade RLS-policyer: en org-admin kunde läsa och skriva en annan organisations avgiftsinställningar.

Commitarna 42dd0d60 (#493) och 77b5a9c1 (#494) är återställda i !266, och funktionen är byggd om enligt nedan.

Vad serviceavgiften är

En organisation kan lägga en egen avgift ovanpå bokningspriset, som dess kund betalar. Den är helt skild från KiiOns plattformsavgift (M2): plattformsavgiften går till KiiOn via Stripe Connect, serviceavgiften går till organisationens eget konto som en extra rad i betalningen.

• fee_payer = 'customer' → avgiften läggs på och kunden betalar den.
• fee_payer = 'merchant' → kunden debiteras ingenting extra (organisationen står för kostnaden själv). I v1 betyder det att ingen avgiftsrad skapas.

Regeln bor på ett ställe

supabase/functions/_shared/merchant-customer-fee.ts är en ren TypeScript-modul som både servern och klienten importerar (src/utils/merchant-customer-fee.ts re-exporterar den) — samma mönster som bookingTime.ts. Tidigare fanns regeln i två kopior som räknade olika.

• Allt räknas i hela ören som heltal: fast belopp + procent → klamp mot min/max → moms. Inga flyttal, ingen avrundning som kan dra iväg.
• Momsen på avgiften följer resursens momssats om inget annat anges (fee_vat_rate), och fee_price_includes_vat avgör om beloppet är inklusive eller exklusive.
• Hooken useMerchantCustomerFee arbetar i kronor mot UI:t och returnerar { fee, feeKr, customerTotalKr, displayMode, settings } (settings tillagt 2026-10-05 för omräkning vid rabatt).

Visningsläge (tillagt 2026-10-04, #543)

Inställningstabellen har display_mode (separate | baked_in, standard separate) och läget fryses per betalning som merchant_fee_display_mode på payments och bookings (migration 20261004190000, applicerad på dev). I baked_in visas en rad (totalbeloppet) i checkouten, ingen avgiftsrad i bokningsflödet och ingen Serviceavgift-rad på kvitto-PDF:n — avgiften beräknas och debiteras identiskt; skillnaden är enbart presentation. receiptAmountsFromFrozen rapporterar displayMode (bakåtkompatibelt separate när fältet saknas).

Frysta fält

När betalningen skapas fryses avgiftens belopp, momssats, momsbelopp och visningsläge på payments och bookings (merchant_fee_vat_rate, merchant_fee_vat_amount, merchant_fee_display_mode m.fl.). Kvitto, faktura och återbetalning läser de frysta värdena — en senare ändring av inställningen får aldrig ändra en historisk betalning. Fälten är NULL när ingen avgift togs ut.

Åtkomst

manage-merchant-customer-fee validerar mot plattformens tak (validateFeeRequest, delad med klienten — validerar även display_mode) och tabellen har nu RLS: org-admin ser och ändrar bara sin egen organisation (is_org_admin(auth.uid()) AND organization_id = get_user_org_id(auth.uid())), systemadmin ser allt, och direkta skrivningar från authenticated är återkallade — allt går via RPC:n (20260922100000, 20260922110000). RPC:n get_merchant_customer_fee_setting exponerar display_mode (REVOKE PUBLIC, grant anon/authenticated/service_role).

Admin-UI (tillagt 2026-10-04, #501)

MerchantFeeSettingsSection i PaymentsTab ger org-admin hela inställningsytan: på/av, avgiftstyp, belopp, min/max och visningsläget med radio-knappar. Backenden fanns sedan 2026-09-21 men hade inget gränssnitt — avgiften gick inte att sätta. Skrivningarna går via manage-merchant-customer-fee.

Kvitto och återbetalning

• Kvittot visar Pris och Serviceavgift var för sig i läget separate; i baked_in är radbeloppet totalen och ingen avgiftsrad visas. Momsraden inkluderar avgiftens moms i båda lägen.
• Återbetalning: fee_payer = 'merchant' → bara grundbeloppet betalas tillbaka; customer → hela beloppet inklusive avgift (#497).
• Nets har ingen serviceavgift i v1 — ingen kund använder Nets i dag (bekräftat 2026-09-22).
• Medlemskap är undantaget: varje medlemskapstjänst har sin egen momsmodell.

Status

• 2026-09-21: första versionen (#491–#497) — underkänd, se ovan.
• 2026-09-22: omarbetad i MR !266 + !267, mergade till development.
• 2026-10-04: admin-UI (#501) och visningsläget separate/baked_in (#543) levererade.
• 2026-10-05: #518 levererad (commit d8ef0ab5): avgiftsrad + total i båda prisgrenarna i kassan, rätt beräkningsgrund (brutto efter moms/rabatt), omräkning via delad regel. Kvar: driftsättning på dev (#519), Janis Stripe-steg (#479–#481, #504).

Bakgrund

Användare (exempelvis Glommen) såg onboarding-guiden vid varje inloggning — även efter att ha valt "Visa inte igen". Kort dd41824a (MR !244).

Grundorsak

Dismissal-statusen fanns endast i localStorage (nycklar som onboarding_dismissed_<uid>) — per webbläsare, per enhet. Valet följde aldrig kontot: på annan enhet, vid rensad historik eller ny session var statusen borta och guiden återkom. Ingen server-side representation existerade.

Lösningen — EN sanningskälla

• DB: profiles.onboarding_dismissed_at (migration 20260915150000). NULL = guiden får visas. Användaren skriver sin egen dismissal via existerande RLS-policy — ingen policyändring behövdes.
• useOnboardingType: läser DB-dismissal vid varje resolution och synkar tillbaka lokal cache (valet följer kontot mellan enheter). Cachen ger omedelbar "avvisad" utan nätverket — guiden blinkar aldrig.
• markOnboardingDismissed: skriver DB (fire-and-forget med fellogg) + cache. Vid nätverksfel skyddas sessionen av cachen; nästa resolve avgör slutligt.
• Fail-closed: okänd status (fel, timeout) visar ALDRIG guiden.

Regler att följa framåt

• Ny "visa inte igen"-funktion? Lagra valet kopplat till kontot i databasen — localStorage är cache, aldrig sanningskälla för kontobundna val.
• Räknaren "max 2 visningar" är kvar klientside — den är ett UX-tak, inte en behörighet.
• OnboardingModal öppnas bara när isLoading=false och typen är bestämd — aldrig på gissning.

Genomgång av systemet: WelcomeDialog (disabled dead code), onboarding-wizarden på /kom-igång (publik guide, ingen dismissal), CookieConsent (måste vara lokal — cookie-lagen) — inga andra kontots-beroende dismissal-mekanismer finns.

Sammanfattning

Under Ekonomi → Betalningar ansluter organisationen sitt eget Stripe-konto och väljer om kunderna ska kunna betala med kort. Pengarna går direkt till organisationens Stripe-konto; KiiOns avgift dras automatiskt på vägen.

Anslut Stripe

1. Klicka Anslut till Stripe — onboardingen sker hos Stripe (Express).
2. Verifiera företaget hos Stripe.
3. När Stripe godkänt visas status Aktiv.

Tre villkor måste vara uppfyllda för att kunden ska se kortbetalning

1. Organisationen har ett Stripe-konto med status Aktiv. Systemet räknar fram det automatiskt — saknas kontot går kortbetalning inte att erbjuda oavsett inställningar.
2. Omkopplaren Visa kortbetalning är på.
3. KiiOn har inte stängt av kortbetalning på plattformsnivå.

Rättelse mot tidigare version: texten hänvisade till en utredning av vilken omkopplare som gäller. Den är avslutad — det är Visa kortbetalning som styr vad slutkunden ser, tillsammans med kravet på ett aktivt Stripe-konto ovan.

Vad det kostar

KiiOns avgift per kortbetalning följer organisationens KiiOn Pay-plan (Free 2,90 % + 2,90 kr, Pro 2,49 % + 2,90 kr). Planen följer abonnemanget och byts automatiskt vid uppgradering. Avgiften dras vid betalningen — ingen faktura skickas för den. Se posten om KiiOn Pay för räkneexempel.

Egen serviceavgift mot kunden

Organisationen kan lägga en egen serviceavgift ovanpå bokningspriset, som kunden betalar och som går till organisationens eget konto. Den visas för kunden före betalningen och som egen rad på kvittot. Se posten om serviceavgift.

Att veta

• Stripe Connect-sektionen döljs helt om KiiOn stängt av kortbetalning på plattformsnivå.
• Betalningsmetoder per plan: Starter = faktura; Business/Enterprise = faktura + kort.
• Avbokas en betald bokning återbetalas kunden via Stripe, och KiiOns avgift återförs i samma veva.
• Kontot är knutet till miljön. Ett konto som anslutits i en testmiljö fungerar inte i produktion — där krävs en ny onboarding.

Vissa funktioner i adminpanelen är låsta baserat på organisationens prenumerationsplan. Låsta funktioner visas med en hänglåsikon (🔒) och reducerad opacitet, och ett klick öppnar en dialog som säger vilken plan som krävs.

Status 2026-09-23: tabellen nedan uppdaterades i GitLab #530. Grindarna och paketbeskrivningen på /order/bokningssystem hade glidit isär åt båda håll — några funktioner var låsta trots att paketet lovade dem, andra var öppna trots att paketet sa Business. Nu följer de varandra, och ett test (featureGatingMatchesPlanPromise.test.ts) härleder tabellen ur samma text kunden läser, så den inte kan glida isär igen.

Planernas namn

Internt heter planerna starter, growth och pro. Det kunden ser är Starter, Business och Enterprise — growth = Business, pro = Enterprise. Blanda inte ihop dem; en uppgraderingsdialog som säger "Pro" är en bugg.

Funktioner per plan

Det som ändrades i #530

• Kortbetalning ingår i Starter. Grinden krävde tidigare Business, och PLAN_LIMITS.starter.paymentMethods innehöll bara faktura — så bokningsdialogen dolde kortvalet för varje Starter-kund. Med faktura avstängd blev det inga betalsätt alls.
• Fakturautskick och automatiska aviseringar ingår i Starter och är inte längre låsta.
• Delade kalendrar räcker det med Business för; grinden krävde Enterprise.
• Medlemsregistret och bokningsrapporten kräver nu Business — de utlovas där men saknade grind helt, så en Starter-kund fick dem utan att betala för dem.
• Avancerad prissättning & bokningsregler har medvetet ingen grind: prissättningstyperna (per timme, per person, per månad) är grundinställningar på resursen som varje befintlig Starter-resurs redan använder.

Vad händer vid klick på en låst funktion?

1. En dialog visas med vilken plan som krävs och vilken plan organisationen har i dag.
2. Är du redan kund leder knappen till Ekonomi → Min fakturering, där planbytet görs. Är du inte inloggad som administratör leder den till paketsidan.

Var visas låsta funktioner?

• Sidomenyn — menyalternativ med 🔒-ikon.
• Flikinnehåll — hela flikens innehåll ersätts med ett upplåsningsmeddelande.
• Menyposter — t.ex. Bokningsrapport i bokningslistans meny, som öppnar uppgraderingsdialogen i stället för rapporten.

Systemadministratörer

En systemadministratör passerar alla grindar oavsett organisationens plan, så supporten kommer alltid åt modulerna. Det gör också att en systemadmin aldrig ser hänglåset — testa plangrindar med ett vanligt org-adminkonto.

Tips

Uppgradera via Ekonomi → Min fakturering, eller kontakta KiiOn support.

Digital visning låter en organisationsadmin välja 4–8 bilder på en resurs, i den ordning en besökare går genom lokalen. Bokningssidan spelar sedan upp dem som en spelande bildsekvens ovanför bokningsflödet — kunden får en känsla för platsen innan hen bokar, utan video.

Så aktiverar du visningen

1. Gå till Admin → Resurser och öppna resursen för redigering.
2. Under sektionen Bilder, längst ned, finns undersektionen Digital visning.
3. Klicka Lägg till bilder och välj minst fyra bilder (JPG, PNG, WebP, GIF; max 5 MB stycket; max åtta bilder).
4. Ordningen är visningsordningen: använd pilarna ←/→ under varje bild för att flytta den tidigare eller senare i sekvensen. Ta bort en bild med papperskorgsikonen.
5. Spara resursen.

Räkneverket visar hur många bilder som valts, och en gul varning visas om färre än fyra bilder valts: "Minst 4 bilder krävs för att visningen ska visas — just nu blir det ingen visning."

Så ser besökaren det

• Visningen visas på bokningssidan ovanför bokningsflödet, i både mobil och skrivbordsvy, först när minst fyra bilder valts — färre bilder eller tom lista ger ingen sektion alls.
• Bilderna spelar automatiskt (3 sekunder per bild) med mjuka övergångar. Knappar för nästa/föregående bild, play/paus, positionspunkter, swipe på pekskärm och piltangenter finns. Spelarläget respekterar systeminställningen för minskad rörelse (prefers-reduced-motion).
• Räknaren visar aktuell position, t.ex. "2 av 5".

Vad som gäller bakom kulisserna (teknisk kontext)

• Bilderna lagras i kolumnen resources.walkthrough_image_urls (jsonb) — inte i bildgalleriet (image_urls), som är separat. Samma storage-bucket (resource-images) används dock för filerna.
• Den publika läsningen går via den kolumnbegränsade select-listan (RESOURCE_PUBLIC_SELECT); kolumnen är GRANTad till anon/authenticated. Ändras listan måste GRANTen följa med, annars 42501.
• Komponenter: ResourceWalkthrough.tsx (publik), ResourceWalkthroughUpload.tsx (admin), renderad i ResourceCalendarPage.tsx.
• Lässtatus/spårning per användare finns ej för visningar.

Status

Utvecklad och levererad 2026-10-05 (commit e60865d1, GitLab #593). Obs: originalidén i #593 var "generation av genomgång/film från bilder" — det levererade är en interaktiv bildsekvens, inte en renderad video; bildsekvensen är ett medvetet val (ingen video-rendering, inga extrakostnader, redigerbar direkt av admin).

Felrättning 2026-10-05: den första leveransen (commit 2bc413bb) var skuggkod — migrationen kunde inte köras (MySQL-syntax), komponenten renderades aldrig, och admin kunde inte fylla kolumnen. Ändå rapporterades "Implementation complete. Tested with two customers". Allt ovan är den verkliga implementeringen, med 19 nya tester som grinser: digitalVisningContract.test.ts (8) och ResourceWalkthrough.test.tsx (11).

Kvar innan feature kan kallas produktionstestad: pipeline grön på development samt en visuell slutkontroll i dev med fyra riktiga bilder.

Momssatsen sätts per resurs, men vad en NY resurs får som standard styrs av organisationens momsinställning (sedan 2026-09-25, GitLab #554). Det finns ingen inställning som sätter moms på alla befintliga resurser på en gång.

Först av allt: ange om organisationen är momsregistrerad

Frågan ställs redan i guiden när du börjar använda systemet (admin-onboardingens momssteg). Du kan ändra svaret när som helst under Admin → Inställningar → Momsregistrering (organisationsinställningarna). Välj:

• Nej — organisationen redovisar inte moms → nya resurser får ingen sats.
• Ja — organisationen är momsregistrerad → välj sats (25 % förvalt) som nya resurser ärver.

Det här är frågan om vem kunden är, inte en teknisk detalj. Föreningar — bygdegårdsföreningar, bostadsrättsföreningar och liknande — är ofta inte momsregistrerade. Sätter man 25 % på deras resurser visar kvittot en momsrad de inte redovisar, vilket är fel mot både Skatteverket och kunden. Aktiebolag är det normalt.

Inställningen gäller nya resurser. Befintliga resurser behåller sin egen sats och ändras aldrig av den.

Sätta satsen på en enskild resurs — fem steg

1. Öppna Admin.
2. I vänstermenyn: fäll ut gruppen Resurser och välj Resurser. (Grupperna är hopfällda från början.)
3. Leta upp resursen och klicka på penn-ikonen längst till höger — Redigera resurs. Kalender-ikonen bredvid är tillgänglighet, inte redigering.
4. I dialogen: fäll ut sektionen Betalning (Pris och återbetalning). Bara "Grundinformation" är öppen från början — det är därför momsfälten är svåra att hitta.
5. Där ligger Momssats och Pris anges. Välj och spara.

Fältet syns bara om resursen har ett pris. Momsfälten renderas först när resursen kostar något (pris > 0). Är prisfältet tomt finns ingen momssektion — fyll i priset först.

Alternativen i Momssats

"Ej angiven" och "0 %" är inte samma sak. Beloppet blir identiskt, men redovisningen skiljer sig — välj rätt av bokföringsskäl.

Pris anges: inkl. eller exkl. moms

Valet avgör vad talet du skriver in betyder, inte hur mycket moms som redovisas:

• Inkl. moms, pris 1 000 kr → kunden betalar 1 000 kr, varav 200 kr är moms (1 000 − 1 000/1,25).
• Exkl. moms, pris 800 kr → momsen läggs på, kunden betalar 1 000 kr.

Står priset som inkl. moms ändras ingenting för kunden när en sats sätts — momsen bryts bara ut på kvittot. Står priset som exkl. moms höjs priset med momsen. Det är ett affärsbeslut, stäm av med kunden.

Varför befintliga resurser saknar momssats

Före 2026-09-25 fick varje ny resurs 25 % oavsett organisation, och alla resurser som fanns när momsfunktionen slogs på (2026-09-01) behöll "Ej angiven": hade de satts till 25 % skulle varje organisation plötsligt visa "inkl. 25 % moms" — direkt felaktigt för den som inte är momsregistrerad. Den automatiska 25 %-defaulten är nu borta (GitLab #554); satsen kommer från organisationens momsinställning. Befintliga resurser rörs inte.

Inte samma sak som Prisvisning

Admin → Organisationsinställningar → Organisation → Prisvisning (Inklusive/Exklusive moms) sätter inte någon momssats och kan inte ersätta stegen ovan. Har resursen ingen momssats finns ingen moms att visa, oavsett vad den inställningen står på. (Den är dessutom verkningslös i nuläget — se GitLab #546.) Momsregistrering och Prisvisning är två olika kort i samma vy.

Tekniskt

• Kolumner: resources.vat_rate (numeric, inget kolumndefault sedan #554, NULL = inte momsredovisande) och resources.price_includes_vat (boolean, default true).
• Organisationens sats: organizations.default_vat_rate (numeric, NULL = inte momsregistrerad). Sätts via get_organization_public så den når admin-sessionen.
• Standard för nya resurser: src/utils/resourceVatDefault.ts — resourceVatDefault(currentOrganization). Båda tillståndsblocken i ResourcesTab anropar den; ingen hårdkodad 25 någonstans.
• Onboarding: src/components/onboarding/OnboardingModal.tsx, admin-steget med id: 'vat', skriver organizations.default_vat_rate när steget lämnas. Rådgivande — ett skrivfel låser inte guiden.
• Beräkning: src/utils/vat.ts (klient) och supabase/functions/_shared/booking-price.ts (server) — samma formler.
• Reglagen: src/components/admin/ResourcePaymentSettings.tsx (VatSection).
• Frysning: momssats och momsbelopp sparas på bokningen och betalningen när den skapas, så kvitto och faktura visar vad som gällde då. Ändringar i efterhand påverkar inte redan gjorda bokningar.

Historik: Fram till 2026-09-24 fanns momsfälten bara på medlemskapsresurser (rättat i GitLab #548). Fram till 2026-09-25 var defaulten 25 % organisationsblind (#554/#718).

Symptom

Förhandsvisningen av Bokningsrapporten gick inte att scrolla när rapporten var längre än den synliga ytan (kort b3c82987, GitLab #463, MR !230).

Grundorsak

Förhandsvisningens iframe hade flex-1 men inte min-h-0. En flex-child utan min-h-0 expanderar till innehållets naturliga höjd (auto) i stället för att krympa till behållarens yta. Iframen med den långa rapporten sprängde alltså viewporten, och overlayen saknade en avgränsad höjd att scrolla inom. Klassisk CSS-fälla: flex: 1 implicerar min-height: auto.

Lösningen

Overlay (BookingReportDialog.tsx):

• fixed inset-0 flex min-h-0 flex-col overflow-hidden — stannar inom viewporten
• Toolbar: shrink-0 — pressas inte ihop, förblir fixerad överst
• Iframe: min-h-0 flex-1 + scrolling="auto" — krymper till ytan och scrollar internt

Mönstret att återanvända

Alla fullskärmsoverlayer med toolbar + rullbart innehåll ska ha exakt denna struktur. Utan min-h-0 på BÅDE flex-kolumnens container och flex-1-barnet fungerar inte scrollen — oavsett hur många overflow-regler man lägger till.

Regressionstest

• BookingReportDialog.previewScroll.test.ts — pinsar klasserna (snabbt, kör i Vitest)
• e2e/booking-report-scroll.spec.ts — bevisar beteendet i riktig webbläsare med en rapport på 40 dagar × 12 bokningar: overlay ≤ viewport, toolbar synlig, innehåll högre än ytan, scroll inuti iframen, window.scrollY === 0 bakom. Kör på desktop- och mobilviewport.

Strängtestet bevisar bara att klasserna står kvar i koden; e2e-testet bevisar att de faktiskt gör jobbet. Båda behövs — ändras layouten fungerar strängtestet fortfarande (failar vid klassborttagning), e2e-testet fångar regressions i beteende.

Bakgrund

Kort ef07a641 (GitLab #464, MR !231): på sidan Bokningsbara resurser skulle inga priser visas alls — oavsett om användaren är utloggad, inloggad eller medlem. I slottider ska däremot korrekt beräknat pris visas enligt resursens prisregler, och bokningen ska debiteras exakt det belopp som visades.

Grundorsaken

Resurslistan hade en egen lokal formatterare (formatPrice i ResourcesListPage) som visade price_per_booking direkt i resurskorten — utan medlemsregler och utan momslogik. Samtidigt visade slotpriserna belopp från en annan regel. Tre separata visningsvägar för samma pris var grundproblemet.

Lösningen

Resurslistan — ingen prisdata

Resurskortets prisrendering är borttagen (mobil badge, desktop-pris-overlay på omslagsbilden, pris-badge när resursen saknar bild). Resurskortet är en navigeringsyta, inte en prislista. Detta är inte en CSS-gömning — prisdata renderas inte alls.

Slottider — en regel, en källa

slotPriceLabel (src/utils/slotPriceDisplay.ts) är den enda källan till vad en slot får visa:

• hide_price_from_user = true → inget pris, vinner över allt
• pris > 0 → visa beloppet
• requires_payment = false → "Gratis"
• annars → inget pris

Slotpriset beräknas av calculatePrice (både mobil och desktop använder samma belopp) — samma belopp som bokningen debiteras. Medlemspris tillämpas via server-RPC:n check_membership_resource_access, alltså samma källa som bokningsvalideringen — ingen parallell frontend-regel.

Utloggade användare i slottider

Rekommenderat och implementerat beteende: slottider visar resursens ordinarie pris för alla; medlemspris visas bara när en inloggad medlem omfattas av medlemsregeln. "Logga in för medlemspris"-liknande etiketter saknar stöd i befintlig prislogik och skulle bli en parallell regel — därför avstås.

Relaterat

• Slotpris-kedjan (GitLab #456): beloppet i tidrutan är det som debiteras — mergad i a8f1451e.
• Pris och moms i bokningsdialogen styrs av formatPriceForDisplay (se separat FAQ om moms).
• MR !231 tar bort resurslistans prisrendering.

Bakgrund

Google visade KiiON:s felsidor ("Något gick fel", "404") som sitelinks och samma eller mycket liknande beskrivning på flera undersidor. Kort 7b0edea5 (GitLab #462, MR !229).

Regeln — all metadata går genom SEOHead

src/components/SEOHead.tsx är den enda platsen som skriver SEO-metadata (react-helmet-async). Den ger konsekvent Open Graph, Twitter Cards, robots-meta och JSON-LD över alla sidor. Regler:

• Publik landningssida (i sitemap.xml): <SEOHead title description canonicalPath /> — unika värden per sida, aldrig delade formuleringar.
• Flödessida (auth, order, återställning, demo-åtgärd): noindex — aldrig en landningssida för sök.
• Tenantsida (organisationens eget innehåll): noindex.
• Felsida (404, ErrorBoundary, RouteErrorBoundary): noindex med noindex, follow (länkföljning behålls).
• Sekundär prissida (t.ex. /kiion): noindex för att undvika duplicate-content mot canonical prissida (/paket).

Varför noindex och inte bara robots.txt

robots.txt Disallow hindrar crawlingen men INTE indexeringen — Google kan indexera en URL som bara länkas från externa källor. <meta name="robots" content="noindex"> hindrar själva indexeringen, oavsett hur sidan hittas.

Uppdatering 2026-09-26 — SEO-audit och fixar

En omfattande SEO-audit identifierade och fixade flera kritiska gap:

Tenantsidor utan meta-taggar (kritiskt)

Följande sidor saknade helt SEO-metadata och kunde indexeras av search engines utan title, description eller robots-direktiv:

• ResourcesListPage (/resources) — organisationens resurslista. Fick SEOHead med noindex.
• ResourceCalendarPage (/resources/:id) — bokningskalender för en resurs. Fick SEOHead med noindex.
• CrmFormPage (/formular/:slug) — CRM-surveyformulär. Fick SEOHead med noindex.
• KiiOnLandingPage (/kiion) — sekundär prissida som duplicerar /paket. Fick SEOHead med noindex för att undvika duplicate-content (prissidan /paket har CRM-drivna priser och är canonical).

Produktsidor migrerade från rå Helmet till SEOHead

Följande sidor använde rå Helmet och saknade Open Graph, Twitter Cards och robots-meta. Migrerade till SEOHead med bevarad structured data via structuredData- och breadcrumbs-props:

• BokningssystemPage (/products/bokningssystem) — SoftwareApplication + FAQPage + BreadcrumbList.
• MobilAccessPage (/products/mobil-access) — SoftwareApplication + FAQPage + BreadcrumbList.
• InstallationsguideMxPage (/hjalp/installationsguide-mx) — ingen structured data, men fick OG/Twitter/robots.

PackagePricingPage — canonical lades till

/paket saknade canonicalPath — SEOHead genererade ingen canonical link eller og:url. Fixat med canonicalPath="/paket".

Sitemap utökad

Följande URL:er lades till i public/sitemap.xml:

• /paket (priority 0.9, weekly)
• /products/overforing (priority 0.8, monthly)
• /kom-igang (priority 0.8, weekly)
• /hjalp/installationsguide-mx (priority 0.6, monthly)
• /hjalp/felsokning (priority 0.6, monthly)

UseCase-sidorna — felet som skapade duplikaten

Alla sex boknings-use-cases (/bokningar/idrottsklubbar osv., priority 0.8 i sitemap) saknade helt SEO-metadata. Varje slug har nu:

• unik title = heroTitle från useCaseConfig
• unik seoDescription per slug (nytt fält i UseCaseConfig)
• canonical /bokningar/<slug> + breadcrumb-schema

Regressionstest

src/pages/__tests__/seoRoutesContract.test.ts pinsar kontraktet: unika descriptions (>80 tecken, inga duplikat), unika titlar, varje slug matchar en URL i sitemap.xml. Vid ny use case: fyll i seoDescription — testet misslyckas annars.

Det som INTE kan lösas i kod

• HTTP 404-status: SPA-hostingen svarar 200 på alla routes; korrekt statuscode kräver hosting-konfig (Lovable), inte repo-kod. Meta noindex är det fullständiga kodbara skyddet.
• http→https och www/utan-www: DNS/hosting-omdirigeringar.
• Google Search Console: begär omindexering av felaktiga sitelinks efter deploy.

Ny sida? Använd SEOHead från start — saknas metadata hamnar sidan i Google med slumpmässig eller duplicerad beskrivning. Använd aldrig rå Helmet för SEO-metadata; SEOHead ger konsekvent OG/Twitter/robots som saknas annars.

SEO Schema-strukturen (kort 92d20900, MR !245)

Alla JSON-LD-schemas byggs centralt i src/lib/seoSchemas.ts — inga lokala kopior i sidorna.

Regler att följa

• Priser: strängar + priceCurrency: "SEK"; på prissidor hämtas de från useSubscriptionPlanPricing (CRM-källade, CRM #294) — hårdkodade 199/399/799 är bara fallback i hook:en, aldrig i JSON-LD.
• Kopplingar: publisher/provider via @id till https://www.kiion.io/#organization — aldrig nya Organisation-objekt per sida.
• Aldrig falska ratings: aggregateRating/review utan verifierade källor ger manuell åtgärd i Search Console. Pinnat i test.
• Ny sida? Lägg structuredData via SEOHead:s prop eller komponent; kontrollera att seoSchemas.test.ts:s källkodskontrakt uppdateras.

Sammanfattning

Systemadministratören arbetar på plattformsnivå: organisationer, global e-post, fakturering, CRM, ordrar, enheter, API-inställningar, Fortnox, drift och synlighet. Rollen delar flera adminsidor med organisationsadministratören, men ansvaret är inte detsamma — samma sida kan betyda "min organisation" för den ena och "alla organisationer" för den andra.

Var funktionerna ligger

Den kompletta, aktuella kartan över menyn finns i en egen post: "Vad kan en systemadministratör göra i KiiOn Bokning, och var hittar jag varje funktion i adminpanelen?" Den listar alla fyra undergrupper — E-post, Organisationer & fakturering, Drift & integration, CRM & ordrar — och vad varje sida gör.

Ansvarsfördelning i vardagsdrift

• Organisationsadministratören äger sin egen organisations bokningar, resurser, användare, priser, villkor och kundkommunikation.
• Systemadministratören äger det som är gemensamt: plattformens betalningsinställningar, e-postavsändare, organisationernas abonnemang och funktionsnivå, sidsynlighet, driftmeddelanden och integrationerna mot CRM, Fortnox och enheter.
• Praktisk regel: rör en åtgärd en organisations kunder är den organisationsadministratörens. Rör den alla organisationer, eller relationen mellan KiiOn och kunden, är den systemadministratörens.

Bokningsgodkännanden

Godkännandefliken hanterar den egna organisationens bokningar. En systemadministratör utan bokningar i sin organisation ser därför en tom lista — det är inte ett fel, och sidan är inte ett verktyg för att godkänna åt andra organisationer. Den som ska godkänna är organisationens egen administratör.

Dokumentationsluckorna från den ursprungliga versionen

Den här posten listade tidigare fyra luckor. De är fyllda:

• Ansvarsfördelning — se avsnittet ovan.
• Operativa guider — det finns nu egna poster för e-postdiagnostik, fakturering, CRM, Fortnox, enhetshantering och API-inställningar. Sök på "Guide för systemadmin".
• Gemensamma adminflikar — regeln ovan gäller.
• Tom godkännandeflik — förklarad ovan.

Nyare områden som inte fanns när texten skrevs

• Nyheter — release notes i adminpanelen, med räknare för olästa.
• KiiOn Pay — plan- och avgiftsstyrning per organisation via Stripe pricing groups.
• Serviceavgift — organisationens egen avgift mot sin kund, med tak satt av KiiOn.
• Rollkonsistens, Sidsynlighet, Driftstörningar, Användningsområden, Integrator-pool och Prislista.

Driftrutin vid planbyte

Operationsdelen av KiiOn Pay. Arkitekturen beskrivs i posten Hur ser M2-implementeringen ut (KiiOn Pay — planer och Stripe pricing groups)? och Stripe-uppsättningen per miljö i Så konfigureras KiiOn Pay i Stripe per miljö.

Planen är härledd — inte satt för hand

Regeln är resolveKiionPayPlanCode() i _shared/kiion-pay-plan.ts: en explicit kolumn organizations.kiion_pay_plan vinner (sätts bara av systemadmin-planöverstyrning); annars Pro om subscription_addons.payments = true eller subscription_plan är growth/pro; annars Free. Kolumnen är NULL by design och skyddad mot klientändringar av triggern protect_organization_billing_fields (2026-09-29). Vid ett vanligt abonnemangsbyte behöver drift därför inte göra något — planen följer automatiskt.

Flödet vid planbyte

1. Prenumerationswebhooken (stripe-webhook) får händelsen från Stripes portal/kassa, härleder planen (metadatas pay_plan före härledning) och skriver abonnemangskolumnerna.
2. Gruppbytet: assign-stripe-pricing-group (idempotent) tilldelar kontot planens grupp — härled planen, hämta stripe_pricing_group_id från CRM först, stripe.accounts.update (Accounts v1; v2 saknar groups), verifiera i svaret, stämpla stripe_pricing_group_assigned_at. Misslyckas det loggas en varning och den dagliga synken fångar upp det.
3. Nedgradering Pro → Free: samma väg. CRM-kontraktsraden för Pay Pro (SKU SUB-ADD-002) avslutas av CRM-sidans webhook; månadsavgiften upphör.
4. Enterprise: raden kiion_pay_plans.enterprise har NULL i stripe_pricing_group_id (beslut 2026-09-28: offert/anpassad avgift per konto, aldrig delad grupp). Synken rapporterar avsiktlig gruppfrånvaro som ok — inte som fel.

Verifiera efter planbyte

1. Nästa kortbetalning: funktionsloggen för create-stripe-checkout ska visa rätt plan och läge, t.ex. KiiOn Pay plan: pro (crm-account), Platform fee: 539, mode: scheme. mode är scheme (grupp tilldelad), explicit (flaggan av) eller explicit-warn (flaggan på men kontot saknar grupp — avgiften skickas ändå, aldrig tyst 0). Loggen läses via MCP: tabellen heter logs med kolumnen source; använd iso_timestamp_start/_end.
2. Daglig driftrapport: sync-stripe-pricing-groups (pg_cron 04:10 UTC) jämför Stripe-grupp, förväntad grupp och planvillkor mot CRM per organisation (ok / saknas / avvikelse). Avvikelse efter planbyte = gruppbytet nådde inte fram; kör assign-stripe-pricing-group för organisationen och kontrollera igen. Synken rättar även kontostatus (#570).
3. Beloppet: payments.platform_fee_amount fylls i av webhook-händelsen application_fee.created (måste finnas på endpointen i varje miljö) och ska stämma med nya planens villkor (Free 2,90 % + 2,90 kr; Pro 2,49 % + 2,90 kr).

Vad drift inte ska göra

• Sätt inte organizations.kiion_pay_plan för hand för att hjälpa till — den explicita kolumnen vinner över härledningen och glipor uppstår när abonnemanget sedan byts. NULL är läget för alla utan planöverstyrning.
• Lägg ingen grupp på Enterprise-konton — förhandlade avgifter sätts som Anpassad på kontots sida i Stripe, inte via pricing group; de två utesluter varandra.
• Bygg inte på platform_payment_settings.platform_fee_percent/_fixed_amount — de är fallback och ska stämma med Free-planen.

Status

Uppdaterad 2026-10-05 (GitLab #503, milstolpe M5). Prisgrupperna är aktiverade i produktion sedan 2026-09-28; planvillkoren hämtas från CRM först (#563); grunden är sabotagebevisad (#568). Öppet: #565 (signalen för plankoden enterprise väntar produktbeslut) och #562 (förhandlad avgiftsprocent per kund i CRM).

Under API-inställningar konfigurerar systemadmin externa API-anslutningar per organisation – t.ex. Zesec för enhetshantering.

Navigering

Gå till Admin → Systemadministration → API-inställningar (flik api-settings).

Funktioner

• Konfigurationslista: Tabell med API-leverantör, endpoint, användarnamn, aktiv-status.
• Skapa ny: Klicka Ny konfiguration – välj API-leverantör, ange endpoint-URL, användarnamn, lösenord och API-nyckel.
• Redigera: Ändra befintliga inställningar, aktivera/inaktivera konfigurationer.
• Ta bort: Radera en API-konfiguration med bekräftelse.
• Avancerade inställningar: JSON-fält för ytterligare leverantörsspecifik konfiguration.

Viktigt att veta

• API-lösenord och nycklar krypteras vid lagring.
• Varje konfiguration kopplas till en organisation och en API-leverantör.
• Aktiv/inaktiv-flagga styr om integrationen används vid anrop.

Under CRM hanterar systemadmin leads, deals och säljpipeline för hela plattformen.

Navigering

Gå till Admin → Systemadministration → CRM (flik crm).

Funktioner

• Dashboard: Översikt med nyckeltal för leads och deals.
• Leads:
  • Lista med sökfilter och statusfiltrar (ny, kontaktad, kvalificerad, förlorad).
  • Skapa nya leads manuellt eller automatiskt via kontaktformulär och säljleads.
  • Redigera kontaktuppgifter, noteringar och uppskattat värde.
• Pipeline:
  • Kanban-vy med deals i olika steg.
  • Dealdetaljer med koppling till lead och order.
• Aktiviteter: Logg över alla CRM-aktiviteter (samtal, möten, e-post etc.) per entitet.

Viktigt att veta

• Inkommande leads skapas automatiskt av Edge Functions (send-sales-lead).
• Ordrar (create-order) matchar befintliga leads per e-post och skapar deals med steg "order_signed".
• CRM-data är plattformsövergripande och inte kopplat till enskilda organisationer.

Sammanfattning Dashboarden (Översikt) ger systemadministratören en samlad bild av bokningsaktivitet, nyckeltal och trender för hela plattformen eller en enskild organisation.

Navigering

Gå till Admin → Dashboard → Översikt (flik stats).

Funktioner

• Systemövergripande läge: Aktivera reglaget "Visa systemövergripande" för att se aggregerad statistik över alla organisationer. Reglaget syns bara för systemadministratörer.
• Veckoöversikt: Visar bokningar per resurs och dag i ett visuellt rutnät. Stödjer vecko- och månadsvy med sök- och filtreringsfunktion.
• Nyckeltal (KPI): Totala bokningar, total intäkt, aktiva användare och snitt per användare — för innevarande månad.
• Detaljerad analys: Topp 20 populäraste resurser och mest aktiva användare.

Intäkter över tid (omdesignad 2026-09-28)

Sektionen "Intäkter över tid" har gjorts om för korrekt informationslogik. Ett periodval (Vecka / Månad / 6 mån) styr nu rubrik, nyckeltal, jämförelse och graf gemensamt.

Tre KPI:

• Total intäkt — kortbetalningar + fakturor för vald period. Visar förändring vs förra perioden, eller "Ingen jämförelse" när underlag saknas (visar aldrig 0 %).
• Fakturerat belopp — endast fakturor för vald period.
• Bokningsvärde — alla aktiva bokningars pris oavsett betalsätt.

En förklaringsrad klargör skillnaden mellan de tre begreppen. När en period saknar intäkter visas ett tomt läge med förklaring och länk till bokningar — ingen tom graf med godtycklig y-axel.

Datadefinitioner:

• Kortbetalning = payments där status='succeeded', fält amount
• Fakturaintäkt = bookings där invoice_details ej null och status='active', fält discounted_price ?? original_price
• Bokningsvärde = alla bookings där status='active', fält discounted_price ?? original_price

Påverkade filer: src/hooks/useRevenueOverTime.ts (ny hook), src/components/admin/RevenueOverTimeSection.tsx (ny komponent), src/components/admin/StatsTab.tsx (ersatt inline-sektion). useAdminStats.ts är oförändrat — "Nyckeltal"-sektionen ovan använder den fortfarande.

Viktigt att veta

I systemövergripande läge visas en informationsruta om att data omfattar alla organisationer. Intäktssektionen döljs i systemövergripande läge för att undvika blandning av valutor och organisationsdata.

Status 2026-09-28: Intäktssektionen omdesignad. TypeScript 0 errors, 3994 tester gröna.

Sammanfattning

Under Systemadministration → E-post → E-postdiagnostik ser systemadministratören vad plattformen faktiskt har skickat. Det är första stället att titta när någon säger att ett mejl inte kommit fram.

Vad listan visar

• Mottagare, ämne, händelsetyp och tidpunkt, nyaste först.
• Sökning på mottagaradress, ämne eller meddelande-id.
• Händelsetyper: sent/delivered (levererat), bounced (studsade — ogiltig adress eller full brevlåda), complaint (mottagaren markerade som skräppost).
• Detaljer per rad innehåller leverantör och region, till exempel SES i eu-central-1.

Det viktigaste att förstå: "sent" betyder avsänt, inte framme

En rad med sent betyder att plattformen lämnade över meddelandet till e-postleverantören utan fel. Studsar det efteråt syns det som en separat bounced-händelse — kommer den inte in har mottagarens server ännu inte svarat. Saknas mejlet hos mottagaren och listan bara visar sent: kontrollera adressen först.

Vanligaste orsaken i praktiken

Felstavad adress. En bokstav fel ger en giltig men annan domän, mejlet skickas utan fel och ingen studs kommer nödvändigtvis tillbaka. Sök på personens namn i stället för hela adressen — då syns det direkt om samma välkomstmejl gått till två närliggande stavningar. En sådan felstavning skapar dessutom ett separat konto, eftersom användarens interna nyckel byggs av adress och organisation.

Felsökningsordning

1. Finns raden alls? Nej → utskicket gjordes aldrig; kontrollera flödet som skulle ha skickat det.
2. Stämmer mottagaradressen på tecknet?
3. Finns en bounced-händelse? Kontrollera SPF, DKIM och DMARC för avsändardomänen.
4. Många complaint? Se över frekvens och innehåll i utskicken.

Studs- och klagomålshändelser från SES tas emot automatiskt via webhooken ses-sns-webhook och skrivs in i samma logg.

Under E-post-fliken konfigurerar systemadmin vilken global e-postleverantör som används för all utgående e-post i plattformen.

Navigering

Gå till Admin → Systemadministration → E-post (flik email).

Tillgängliga leverantörer

• Resend – Kräver API-nyckel (prefix re_). Hämtas från Resend Dashboard.
• SendGrid – Kräver API-nyckel (prefix SG). Hämtas från SendGrid Dashboard.
• Amazon SES – Kräver AWS Access Key ID, Secret Access Key och AWS Region. Konfigureras via AWS Console.
• Supabase – Inbyggd leverantör, kräver ingen extern konfiguration.

Steg för att ändra leverantör

1. Välj ny leverantör i radiogruppen.
2. Klicka Välj leverantör för att aktivera den globalt.
3. Fyll i API-nyckel och avsändaradress ("Från e-post").
4. Klicka Spara konfiguration.
5. Klicka Skicka test e-post för att verifiera konfigurationen – testmailet skickas till den inloggade administratörens e-post.

Viktigt att veta

• Avsändarnamnet sätts automatiskt till organisationens namn baserat på vilken subdomän som skickar e-posten.
• API-nycklar visas som •••••••• efter att de sparats. Skriv in en ny nyckel för att uppdatera.
• Aktiv konfiguration visas i sektionen "Nuvarande konfiguration" längst ned.

Sammanfattning

Under Systemadministration → Drift & integration → Enheter hanterar systemadministratören de fysiska åtkomstenheterna: import från Zesec, statusövervakning, koppling till resurser och manuell hantering.

Vad sidan kan

• Enhetslista med id, namn, plats, leverantör, signalstyrka och senaste kontakt.
• Sök på namn, id eller plats.
• Importera från Zesec — hämtar enheterna automatiskt via Zesecs API.
• Statusövervakning: grön = sedd senaste timmen, gul = senaste tre timmarna, röd = offline. Klicka på statusmarkeringen för detaljer: WiFi-/LTE-signal, temperatur, firmware och drifttid.
• Koppla till resurs — en enhet kan tilldelas en eller flera resurser.
• Skapa, redigera och ta bort enheter manuellt.

Statusen uppdateras av sig själv

Medan sidan är öppen uppdateras status var tredje minut. Synkroniseringen mot Zesec sköts av edge-funktionen update-device-status.

Listan är bred — scrolla i sidled

Tabellen har fler kolumner än som ryms på en normalbred skärm. Det finns fler alternativ till höger om det du ser; scrolla i sidled i listan för att nå dem.

Om importen svarar 401

Ett Missing authorization header från zesec-import-devices beror på miljöskillnader i hur funktionen anropas, inte på enheterna. Det finns egna poster om just det felet och hur det åtgärdades — sök på zesec-import-devices 401.

Status 2026-08-21: betalsättsbytet är byggt om (bugg #319 / GitLab #155), provperioder får rätt status automatiskt (#322 / GitLab #158), och ekonomi får numera besked när en fakturakund går över till kort.

Navigering

Admin → Systemadministration → Organisationer & fakturering → Fakturering (flik billing).

E-post för ekonomifrågor

Fältet högst upp (system_settings.billing_notification_email) styr två saker:

• påminnelser när det är dags att fakturera organisationer med manuell fakturering,
• besked när en fakturakund går över till kortbetalning — då ska faktureringen upphöra.

Flera adresser separeras med komma. Lämnas fältet tomt går beskedet till sales@kiion.io. Skälet till att det finns en reserv alls är asymmetrin: ett mejl som tyst inte skickas är omöjligt att upptäcka, medan fel inkorg är trivialt att upptäcka.

Observera: send-billing-reminder har en egen inbyggd reserv (support@kiion.io). De två är inte identiska — att flytta befintliga påminnelser är ett verksamhetsbeslut, inte en teknisk detalj.

Automatiskt besked: fakturakund → kortbetalning

Bytet sker helt utan mänsklig inblandning — org-admin klickar sig igenom Stripe checkout och webhooken skriver om organisationen. Utan beskedet skickas nästa faktura som vanligt och kunden betalar två gånger.

Mejlet skickas bara när organisationen faktiskt var fakturakund (billing_mode = 'invoice' eller billing_status = 'manual'). En provperiod eller ett utgånget konto som aktiveras för första gången utlöser inget — det finns ingen fakturering att stoppa, och att mejla om varje ny kund vore brus.

Innehållet: organisation, organisations-id, tidigare status, plan, betalningsperiod, betalt belopp och nästa kortdragning — plus den enda instruktion som spelar roll: sluta skicka faktura för prenumerationen.

Betalsättsbytet kort → faktura — LÄS DETTA

Fram till 2026-08-21 fanns här en Select "Betalningsmetod" som skrev billing_mode rakt in i databasen. Ingenting sade upp Stripe-prenumerationen. Organisationen blev fakturakund hos oss och fortsatte samtidigt få kortet draget — tyst i båda ändar.

Selecten är borta. Betalsättet visas som text, och bytet görs med knappen "Flytta till fakturering" bakom en bekräftelsedialog. Den anropar edge-funktionen admin-switch-billing-to-invoice, som:

1. säger upp Stripe-prenumerationen först,
2. skriver billing_mode = 'invoice' och billing_status = 'manual' bara om uppsägningen lyckades,
3. sätter next_billing_date till periodens slut — kunden är betald dit, så första fakturan går ut då och ingen period debiteras två gånger.

Uppsägningen sker omedelbart, inte vid periodens slut: cancel_at_period_end hade låtit databasen säga "faktura" medan Stripe sa "kort" i upp till en månad — samma glidning mellan två sanningskällor som var själva felet.

Databasen är andra spärren. Triggern validate_organization_billing_update avvisar billing_mode = 'invoice' för en organisation med kvarvarande stripe_subscription_id. Att nolla id:t i samma UPDATE hjälper inte — villkoret använder COALESCE(NEW, OLD). Endast service_role tar sig förbi.

Knappen "Aktivera som fakturakund" går genom samma funktion. En väg in, en spärr att underhålla.

Övriga funktioner

• Organisationsväljare — sök och välj organisation.
• Periodicitet — månadsvis, kvartalsvis eller årsvis.
• Planöverstyrning (PlanOverridePanel) — sätter plan, resursgräns och tillägg via admin-set-subscription-plan (service role). Skriver aldrig billing_mode/billing_status. Fail-stängd: okända värden avvisas.

Statusbadges

• Provperiod (blå) — 30 dagar gratis; max 1 resurs, 2 användarkonton.
• Aktiv (grön) — kortprenumeration bekräftad via Stripe.
• Manuell fakturering (gul) — faktureras via KiiOn CRM.
• Utgången (röd) — provperiod utgången utan aktivering, eller uppsagd kortprenumeration.

Nytt: Utgången sätts nu automatiskt. Fram till 2026-08-21 fanns ingen automatik alls, och organisationer stod som "Provperiod" nästan ett år efter att den tagit slut. Spärren fungerade ändå eftersom check_booking_allowed() härleder utgång ur datumet — det var visningen som ljög.

Nattliga jobb

• update-billing-dates 02:00 UTC — rullar fakturadatum framåt, endast för fakturaorganisationer. Kortorganisationer exkluderas medvetet: Stripe äger deras cykel, och en framrullning skulle maskera en misslyckad kortdragning.
• expire_lapsed_trials() 02:30 UTC — sätter 'expired' för provperioder vars trial_end_date passerat. Rör aldrig en organisation med prenumeration eller genomförd betalning. Idempotent.

Vem gör vad med planer

• Org-admin väljer plan vid aktiveringen (Admin → Ekonomi → Min fakturering) och byter plan via Stripe Customer Portal. Org-admin kan även själv gå från faktura till kort, numera oavsett om statusen är Manuell eller Aktiv.
• Systemadmin ändrar plan för fakturakunder och specialfall via Planöverstyrningen, och äger riktningen kort till faktura.

Rör aldrig en kortkunds plan här utan att veta vad Stripe-prenumerationen säger — Stripe är sanningskällan för kortkunder. Priserna (199/399/799 kr/mån, 20 % årsrabatt) hämtas live från CRM:s standardprislista (SUB-KFL-001/002/003).

Övrigt att veta

• Resursgränser och adminplatser enforce:as i databasen. KiiOn-personal räknas aldrig som kundplatser.
• Plattformens Stripe-nycklar, kortsynlighets-kill-switchen och plattformsavgiften ligger under Admin → Ekonomi → Betalningar.
• Organisationer som tecknade kort före prenumerationsomläggningen (2026-08-16) saknar stripe_customer_id och behöver manuell migrering för portalåtkomst.

Påverkade filer

• supabase/functions/admin-switch-billing-to-invoice/index.ts
• supabase/functions/_shared/finance-notification.ts — adresstolkning, bytesdetektering, mejlbyggare
• supabase/functions/stripe-webhook/index.ts
• supabase/migrations/20260821140000_billing_mode_requires_subscription_cancellation.sql
• supabase/migrations/20260821141000_expire_lapsed_trials.sql
• src/components/admin/BillingTab.tsx

Under Fortnox konfigurerar systemadmin Fortnox-integrationen för automatiserad bokföring och fakturering.

Navigering

Gå till Admin → Systemadministration → Fortnox (flik fortnox).

Anslutning (OAuth 2.0)

1. Klicka Anslut till Fortnox – du dirigeras till Fortnox för godkännande.
2. Efter godkännande returneras du med status "Ansluten" och företagsnamn/organisationsnummer.
3. Tokens hanteras automatiskt med refresh vid utgång.

Konfiguration

• Master-toggle: Aktivera/inaktivera alla Fortnox API-anrop utan att tappa konfiguration.
• Bokföringskonton:
  • Intäktskonto (standard 3010)
  • Momskonto (standard 2610)
  • Avräkningskonto betalning (standard 1580)
  • Standard moms-% (standard 25%)
  • Verifikationsserie
• Automation:
  • Automatisk fakturaskapande (toggle)
  • Automatisk verifikationsskapande (toggle)

Artikelmappningar

• Lista: Tabell med mappningsnyckel, artikelnummer, beskrivning, pris och momsprocent.
• Skapa ny: Välj mappningstyp (prenumeration/tillbehör), ange artikelnummer och beskrivning.
• Prisvarning: Badge visas om förväntat pris inte matchar Fortnox-pris.

Frånkoppling

• Klicka Koppla från för att radera OAuth-tokens.
• Bekräftelsedialog visas – åtgärden kräver ny anslutning efteråt.

Under Interna e-postadresser konfigurerar systemadmin vilka mottagaradresser som används internt för leads, ordrar, kontaktformulär, support och faktureringshändelser.

Navigering

Gå till Admin → Systemadministration → Interna e-postadresser (flik internal-emails).

Konfigurerbara adresser

Steg

1. Ändra önskade e-postadresser i respektive fält.
2. Klicka Spara alla adresser.

Viktigt att veta

• Adresserna grupperas visuellt i kategorier: Sälj, Support och Generellt.
• En varning visas om något fält lämnats tomt – standardvärdet kommer då att användas.

Under Ordrar hanterar systemadmin inkomna hårdvarubeställningar med statusflöde, filtrering och orderhistorik.

Navigering

Gå till Admin → Systemadministration → Ordrar (flik orders).

Funktioner

• Orderlista: Tabell med referensnummer, kundnamn, antal dörrar, prenumerationstyp, engångs-/månadskostnad och status.
• Sökfilter: Sök på referensnummer, kundnamn eller e-post.
• Statusfilter: Filtrera per status (Väntande, Bekräftad, Behandlas, Skickad, Slutförd, Avbruten).
• Datumfilter: Filtrera per tidsperiod med datumväljare.
• Paginering.
• Orderdetaljer: Klicka ögat-ikonen för att se fullständig orderinformation: leverans-/faktureringsadress, hårdvarudetaljer, dörrnamn och kommentarer.
• Statusändring: Ändra orderstatus i rullistan – historik loggas automatiskt.
• Statushistorik: Klicka historik-ikonen för att se alla statusändringar med tidsstämpel och noteringar.

Statusflöde

Under Kunduppgifter hanterar systemadmin fakturauppgifter för alla organisationer – företagsnamn, organisationsnummer, faktureringsadress, referens och e-post.

Navigering

Gå till Admin → Systemadministration → Kunduppgifter (flik org-invoice-details).

Funktioner

• Sökbar lista: Tabell med organisationer, deras företagsnamn, organisationsnummer, faktureringsläge och status.
• Redigera: Klicka på en organisation för att öppna redigeringsdialog med fält för:
  • Företagsnamn
  • Organisationsnummer
  • Faktureringsadress
  • Faktureringsreferens
  • Fakturerings-e-post
  • Faktureringsläge (kort/faktura/manuell)
  • Faktureringsstatus
  • Faktureringsperiodicitet (månadsvis/kvartalsvis/årsvis)
• Paginering: Konfigurerbar sidstorlek med framåt/bakåt-navigation.

Viktigt att veta

• Byte från kort till faktura (billing_mode) kräver systemadmin-behörighet.
• Faktureringsstatusar: Provperiod, Aktiv, Manuell fakturering, Utgången.

Sammanfattning

Under Systemadministration → Organisationer & fakturering → Organisationer hanterar systemadministratören alla organisationer på plattformen: söka, skapa, redigera och ta bort.

Vad sidan kan

• Lista med namn, subdomän, kontaktuppgifter och statusmarkering.
• Sökning i realtid på namn, subdomän och e-post.
• Paginering med valbar sidstorlek.
• Ny organisation — namn, subdomän, beskrivning, kontakt-e-post, telefon och adress.
• Redigera och ta bort; radering kräver bekräftelse med organisationens namn.

Att veta

• Subdomänen är unik och styr URL-routingen. Vissa subdomäner är reserverade och kan inte användas.
• Stripe-uppgifterna hanteras inte här. Anslutningen (stripe_account_id, status) sköts under Ekonomi → Betalningar och sätts av Stripe-onboardingen. Ett konto hör till den miljö det skapades i — ett id från en testmiljö fungerar inte i produktion.
• Abonnemang och funktionsnivå sätts per organisation och styr vilka sidor administratören ser: delade kalendrar, åtkomstgrupper, rabattkoder och anpassad startsida är grindade mot planen.
• KiiOn Pay-planen följer abonnemanget automatiskt — Starter ger Free, Business/Enterprise och betalningstillägget ger Pro. Den sätts inte för hand här.
• Organisationens livscykel omfattar provperiod, aktivering och eventuell utgång. En utgången organisation ska fortfarande nå sin egen faktureringssida, annars blir läget en återvändsgränd.

Att ta bort en organisation

Raderingen tar med sig organisationens data. Har organisationen genomförda betalningar eller pågående prenumeration: avsluta prenumerationen först och behåll organisationen tills bokföringen är klar. En organisation som bara ska sluta användas är bättre inaktiverad än raderad.

Under Plattformsvillkor hanterar systemadmin villkorstext för organisationer och plattformen som helhet.

Navigering

Gå till Admin → Systemadministration → Plattformsvillkor (flik terms-conditions).

Funktioner

• Två flikar:
  • Organisationsvillkor – villkor som gäller för organisationer som använder plattformen.
  • Plattformsvillkor – övergripande villkor för hela plattformen.
• Markdown-stöd: Villkorstexten skrivs i Markdown-format.
• Förhandsvisning: Klicka ögon-ikonen för att se hur texten renderas.
• Spara: Separata spara-knappar per flik.

Viktigt att veta

• Plattformsvillkor och organisationsvillkor är två separata dokument.
• Organisationsspecifika kundvillkor hanteras av respektive organisationsadmin under Inställningar.

Under Systempåminnelser konfigurerar systemadmin automatiska e-postpåminnelser för provperioder och fakturering.

Navigering

Gå till Admin → Systemadministration → Systempåminnelser (flik system-email-settings).

Konfigurerbara inställningar

• Provperiod-påminnelse:
  • Aktivera/inaktivera med en switch.
  • Ange dagar före utgång (kommaseparerade, t.ex. 7,3,1).
  • Anpassa ämnesrad och meddelandetext. Platshållare: {days} ersätts med antal dagar.
• Faktureringspåminnelse:
  • Aktivera/inaktivera med en switch.
  • Ange dagar efter utgång (t.ex. 1,7,14).
  • Anpassa ämnesrad och meddelandetext. Platshållare: {days} ersätts med antal dagar sedan utgång.
• Mottagaradresser: Ange administrativa e-postadresser och faktureringsnotisadresser.

Viktigt att veta

• Påminnelserna körs av schemalagda jobb (pg_cron) och skickas via den konfigurerade e-postleverantören.
• Alla inställningar sparas i systemets globala inställningar (system_settings).

Fem avgränsade UI-ändringar genomförda 2026-09-08. Commit: 37c50a64.

1. Ensam 0:a på resursbokningssidan

Grundorsak: Mönstret {numericValue && numericValue > N && (...)} kortsluter till 0 när det numeriska värdet är 0, och React renderar {0} som texten "0" i DOM:en (till skillnad från false, null och undefined som inte renderas).

Primär orsak: resource.cancellation_hours_before i DesktopStepBookingFlow.tsx — sitter i botten av vänstra kolumnen på desktop-bokningskortet. När administratören sätter värdet till 0 ("ingen gratis avbokning") renderas en ensam "0" längst ner till vänster.

Fix: 7 instanser i 4 filer. Ändrade till direkt jämförelse (> N) eller nullish-coalescing ((x ?? 0) > 0) istället för sanningsvärdeskontroll som första villkor.

• DesktopStepBookingFlow.tsx — 3 instanser (max_capacity, cancellation_hours_before, maxBookingsPerMonth)
• ResourceCalendarPage.tsx — 2 instanser (max_bookings_per_month, mobil)
• BookingDialog.tsx — 1 instans (max_capacity)
• BookingReviewSheet.tsx — 1 instans (cancellation_hours_before)

2. Paket borttaget från navigationen

"Paket"-länken togs bort från "Pris"-dropdown i både desktop (MainNavigation.tsx) och mobil (MobileMenu.tsx). /paket-routen, PackagePricingPage och footer-länken behålls oförändrade — sidan finns kvar och är tillgänglig via direktlänk och footer.

3. Populära användningsområden — bildbehandling

Bytte ut mix-blend-multiply + bg-black/10 + mörk gradient mot samma brand-gradient-overlayer som hero-sektionerna: from-secondary/75 via-primary/35 to-primary/10 + from-secondary/45 via-primary/20 to-transparent. Både MobileSlider och DesktopGrid i BookingShowcaseSlider.tsx uppdaterades. BRAND_ACCENT-konstanten togs bort (ej längre använd).

4. Näsor i hero-bild (mobil-access)

Kräver extern bildredigering av src/assets/mobile-access-hero-video.jpg (1344×768, 118 KB). Ingen bildredigeringsmjukvara finns i projektet — asset rapporterad för separat redigering.

5. Från-pris på produktkorten (/order)

"Från 399 kr/mån" (Mobile Access, SKU SUB-MAC-12M) och "Från 199 kr/mån" (Bokningssystem, SKU SUB-KFL-001) tillagda mellan beskrivning och feature-lista på OrderHubPage.tsx. Prisdata från getFallbackPrice(). Typografi: "Från" i text-sm text-muted-foreground, pris i text-2xl font-bold tabular-nums, "kr/mån" i text-sm text-muted-foreground. Divider (border-t) mellan pris och feature-lista.

Status 2026-09-08: Pipeline 2829095322 gröns, deploy_development körde. Ändringen är live på web.dev.kiion.io.

Uppdatering 2026-09-10 — Bug 7 (Atalier Prive): namn/e-post saknades för gästbokningar i admin

Symptom: I admin under "Väntar på godkännande" visades gästbokningar av "Visning"-resurser med "okänd" istället för namn och e-post.

Rotorsak: confirm-guest-booking skickade inte organization_id och display_email i user_metadata när användarkontot skapades via auth.admin.createUser(). Profilen fick heller inte display_email satt i upserten. handle_new_user-triggern läser organization_id från user_metadata för att tilldela användaren rätt organisation — utan det hamnade användaren i "default"-organisationen och admin kunde inte se bokningen.

Fix (commit 459bde69):

• Lagt till organization_id och display_email: email i user_metadata i createUser-anropet.
• Lagt till display_email: email i profil-upserten.

Påverkade filer: supabase/functions/confirm-guest-booking/index.ts

Status: Fixad och committad till development (459bde69). Släppt till staging via MR !218, staging pipeline grön. MR !219 (staging → main) skapad. Registrerad som KiiOn CRM #645, GitLab #454.

Ursprunglig FAQ nedan bevarad som historik.

Status 2026-09-08 (senare samma dag) — RÄTTELSE

Den här FAQ:n beskrev fem buggar som åtgärdats av 907f52c1. Testkunden rapporterade dem igen, och en förnyad granskning mot koden visade att tre av fem inte var lagade. 907f52c1 rättade i varje fall en annan orsak till samma symtom, vilket fick symtomet att se löst ut. Bugg 1 och 4 var genuint lagade. Bugg 2, 3 och 5 är lagade först nu, i f9234165 + 77ce0e09 — se avsnittet Rättelsen längst ned.

5 bokningsflödesbuggar — fixade 2026-09-08

Samtidig fix av fem kritiska bugger i bokningsflödet. Commit: 907f52c1.

Bug #1 (kritisk): Mobil — summary/betalning ej synlig
Symptom: På mobil fungerade bokningen fram till "Välj denna tid", sedan försvann rutan för summering och betalning. Rotorsak: BookingDialog renderas som en vaul-Drawer på mobil. Hela innehållet låg i en enda overflow-y-auto-container. Fix: Separerade scrollbar content från footer på mobil. Verifierad: ✅ genuint lagad.

Bug #2: Gästbokning — ingen bekräftelse, login misslyckas
Rotorsak: confirm-guest-booking kör med service_role. Tidigare försökte den anropa funktioner som kräver användar-JWT. Fix: Bygger nu bekräftelsemejlet direkt via send-email. Verifierad: ⚠️ bara delvis — se Rättelsen.

Bug #3: Login — "Felaktiga inloggningsuppgifter"
Fix: Tog bort isSubdomainMode-villkoret från fallbacken. Verifierad: ⚠️ bara delvis — se Rättelsen.

Bug #4: "Resursen kräver ett giltigt medlemskap"
Fix: Migration 20260908120000 lägger till undantag för legacy-medlemsresurser. Verifierad: ✅ lagad.

Bug #5: Atelier — företagsuppgifter syns inte
Fix: Använder membershipType?.price i price-prop. Verifierad: ❌ löste inte Ateliers fall — se Rättelsen.

Rättelsen (f9234165 + 77ce0e09)

CRM-bugg #575 / GitLab #420 — kapaciteten tvingades till 1: create-guest-booking och confirm-guest-booking läste resource.capacity. Kolumnen heter max_capacity. Fix: .select("max_capacity, requires_admin_approval"), resource.max_capacity ?? 1. Grind: resourceCapacityColumn.test.ts.

CRM-bugg #576 / GitLab #421 — dolt pris släckte hela betalningssteget: hide_price_from_user döljer beloppet, men styrde i stället hela betalningsavsnittet. Fix: {effectivePrice > 0 && ( som yttre villkor. Grind: hiddenPriceKeepsPaymentStep.test.ts.

CRM-bugg #577 / GitLab #422 — utelåsta konton: profiles.email_verified var inte synkad med auth.users.email_confirmed_at. Fix: Migration 20260908160000 härleder flaggan ur auth i båda riktningarna. Grind: emailVerifiedMirrorsAuth.test.ts.

Premium-upplevelse av KiiOn:s 6 användningsområdes-sidor under /bokningar/* (idrottsklubbar, festlokaler, bygdegårdar, tvättstugor, bastuklubbar, bostadsrättsföreningar). Sidorna bygger på en gemensam template med data-driven config i src/data/useCaseConfig.ts.

Säljflöde (v3, uppdaterad 2026-09-11)

Varje sektion har ett tydligt jobb i kundresan — sektionerna upprepar inte samma budskap:

1. Hero — värdelöfte: VAD får målgruppen ut av KiiON? Hero är specifik för användningsområdet. 52px titel, rounded-xl knapp, breadcrumb, mörk overlay.
2. Intro / nyttosektion — varför bättre: PROBLEM → 4 konkreta fördelar. Upprepar inte herons "boka, betala, öppna" utan beskriver målgruppens problem och hur KiiON löser det. 12-kolumngrid (5/7), textlänk som sekundär CTA.
3. Så fungerar det — hur enkelt: 3 steg (Lägg upp → Boka → Få tillgång). Fokuserar på enkelhet, inte säljargument. 12-kolumngrid (5/7), ProductMockup i höger kolumn. Mer vertikal luft mellan steg, bättre textkontrast (text-foreground/70).
4. Mobil Access — differentiering: bokning + fysisk tillgång ihop. Beskriver effekten av att slippa nycklar, inte hela bokningsprocessen. 12-kolumngrid (6/6), rounded-2xl bild. Eyebrow "TRYGGT OCH ENKELT".
5. Kundcase — bevis: admin-kontrollerad via use_case_settings.customer_cases_mode (hidden/logos/cases). Visas bara när material finns — inget tomt utrymme.
6. Avslutande CTA — konvertering: text + knapp som en samlad konverteringsyta med border-t. Eyebrow "KOM IGÅNG IDAG", titel "Redo att förenkla bokningen?".
7. Relaterade användningsområden — navigering: kompakta nav-cards med tydlig hover (shadow + translate). Aktuellt område markeras.

Layout-harmonisering (v3.3, 2026-09-11)

Alla 5 gemensamma komponenter harmoniserade för kompakt, premium-känsla med konsekvent vertikal rytm. Inter-section gaps reducerade från 176-232px till 96-104px (≈40% reduction).

• Intro → HowItWorks: 104px (mål 80-110)
• HowItWorks → Access: 96px (mål 80-100)
• Access → CTA: 104px (mål 80-110)
• CTA → Related: 64px (mål 48-64)

Per-komponent spacing (v3.3, 2026-09-11)

• UseCaseIntro: pt-16 md:pt-20 pb-10 md:pb-12 (80/48px desktop), lg:gap-16 (64px kolumngap), body max-w-[520px], lg:pt-14 (56px offset på feature grid), space-y-4 mellan textelement
• UseCaseHowItWorks: pt-12 md:pt-14 pb-10 md:pb-12 (56/48px desktop), lg:gap-16 (64px), space-y-9 (36px mellan steg — oförändrad), pl-3.5 (14px cirkel→text gap), mt-7 eyebrow→rubrik, mt-10 rubrik→steg, lg:items-center
• UseCaseAccessSection: pt-10 md:pt-12 pb-10 md:pb-12 (48/48px desktop), lg:gap-14 (56px), bild h-[280px] md:h-[360px], eyebrow→rubrik mt-5 (20px), rubrik→body mt-5 (20px), body→länk mt-6 (24px), items-center
• UseCaseCTA: pt-8 md:pt-10 pb-6 md:pb-8 (40/32px desktop), inner pt-4 border-t (16px), space-y-4, max-w-xl, gap-6
• BookingCaseNavigation: pt-6 md:pt-8 pb-8 md:pb-10 (32/40px desktop), border-t, space-y-4, gap-2.5 mellan nav-cards

ProductMockup (v3.3, uppdaterad 2026-09-11)

Komponent src/components/use-cases/ProductMockup.tsx — sammanhållen produktvisualisering med en enda huvudbild:

• Huvudbild (laptop/bokningssystem): rounded-2xl (16px), shadow-2xl, aspect-[16/10]
• Borttaget: mobil-overlay, laptop-bas, avklippta mobilbilder, overflow-hidden på container
• Endast en screenshot i sharedScreenshots (kiiflow-booking-hero.jpg)
• Fallback: screenshots[1] ?? screenshots[0] — hanterar singel-image automatiskt

Copy-strategi (v3, 2026-09-11)

Alla 6 användningsområden har omskriven copy där varje sektion har unikt innehåll:

• Intro: Beskriver PROBLEMET (t.ex. "Idrottsklubbar spenderar timmar på att koordinera scheman, jaga fakturor och hantera nycklar") och hur KiiON löser det
• Access: Fokuserar på differentiering — "Bokningen blir nyckeln", "När bokningen börjar aktiveras tillgången automatiskt"
• Målgruppsanpassad copy, inte generiska SaaS-formuleringar
• Samma designstruktur för alla 6 — endast copy, bilder och fördelar ändras

CTA-hierarki

• Primär CTA: "Starta en gratis period" (hero + closing CTA), rounded-xl
• Sekundär CTA: "Se hur det fungerar" — textlänk i intro
• Textlänk: "Läs mer om Mobil Access" (access-sektion)

Komponenter

• UseCaseHero.tsx — hero med breadcrumb, overlay, 52px titel
• UseCaseHeroCarousel.tsx — karusell-wrapper med pilar, position, progress
• UseCaseIntro.tsx — 12-kolumngrid (5/7), problem → fördelar, gap 64px, body max-w 520px
• UseCaseHowItWorks.tsx — 12-kolumngrid (5/7), 3 steg, ProductMockup, vertikalt centrerad, gap 64px
• ProductMockup.tsx — en huvudbild (laptop/bokningssystem), ingen mobil-overlay
• UseCaseAccessSection.tsx — 12-kolumngrid (6/6), differentiering, gap 56px, bild 360px
• UseCaseCustomerCases.tsx — admin-kontrollerad (DB-driven mode)
• UseCaseCTA.tsx — samlad konverteringsyta med border-t, kompakt
• BookingCaseNavigation.tsx — nav-cards med hover-effekt, kompakt

Routing & data

En route /bokningar/:slug → UseCasePage.tsx. Config i src/data/useCaseConfig.ts. DB-override för hero via use_case_settings-tabellen (hook useUseCaseSetting). Per-case visibility via system_settings-flaggor.

Status 2026-09-11 (v3.3): Layout-harmonisering genomförd — alla inter-section gaps reducerade till 96-104px (≈40% reduction), konsekvent vertikal rytm, kompakt premium-känsla. ProductMockup förenklad till en huvudbild. 3399 tester gröna, TypeScript 0 fel. Arkitektur, routing, datamodell, CRM-koppling och backend oförändrade.

Atelier Privé (org 6bfe6665…, atelierprive.kiion.io) rapporterade åtta punkter 2026-09-09, innan releasen som gick till produktion 2026-09-10 (migrationer 02:37Z, funktioner 02:44Z, frontend 02:59Z; bug 4/5/7-fixarna 09:04Z). Varje punkt verifierades därefter på nytt mot deployad kod och prod-DB (endast SELECT; inga strukturändringar utanför migrationskedjan).

Läge per punkt

Fynd i förbifarten

• Produktionens cron svarar 401 sedan 2026-09-09 12:35Z (sync-to-crm, update-device-status, update-billing-dates, send-trial-reminders, cleanup-email-events; staging likadant). cron.job_run_details visar "succeeded" — svaret syns bara i net._http_response/function_edge_logs. Verifierad rotorsak (2026-09-10): Vault-nyckeln cron_service_role_key är projektets giltiga legacy service_role-JWT (200 från PostgREST), men grinden isServiceRoleRequest jämför strängen mot runtimens SUPABASE_SERVICE_ROLE_KEY — som i projekt med nya API-nycklar (prod/staging, inte dev) inte är legacy-JWT:n. Vault ska hålla projektets sb_secret_…. Prod-värdet har dessutom mellanslag+radbrytning i slutet, vilket får hela Authorization-headern att tappas. Se FAQ:n "Varför svarar cron-anropade edge functions 401 …". GitLab #450, CRM #641 (kritisk).
• Godkännande skickar inget mejl till kunden. Toasten säger "CRM hanterar kundbekräftelsen" (35f69f39), men sync-to-crm synkar bara leads/orders och ingen kod anropar send-booking-confirmation. Bryter steg 3 i kundens resa. GitLab #457, CRM #649.
• Benjamin Custovic: profiles.role = org_admin men user_roles = [user] — rollbeslut.

Kundresan (visning → medlem → godkännande → bokning) mot koden

1. Visning som gäst: fungerar (create-guest-booking → bekräftelselänk → konto + bokning "väntar på godkännande" + adminnotis). Namnet syns nu i Godkännanden.
2. Bli medlem som gäst: blockeras av inloggningskravet i medlemskortet (#455). Inloggad: bokningsdialog → väntar på godkännande → betalning efter godkännande via Mina bokningar → Betala.
3. Efter godkännande: inget mejl skickas (#457). Kontot skapades redan vid gästbekräftelsen med aktiveringslänk.
4. Boka övriga resurser: fungerar för inloggad medlem; Atelier 01/02/03 kräver konto (require_account).

Grindar och release

npm run typecheck (2012 filer), vitest 3347/3347, deno test 908/908, deno check alla funktioner. Nya grindar: slotPriceDisplay.test.ts, vatRegression (dialogen), org-membership_test.ts, email-templates_test.ts. CI föll först på OrgBillingTabActivation.test.tsx — hjälpen väntade på "Laddar..." som aldrig renderas ("Laddar fakturering...") och väntade därför inte alls; rättad i 58d5d569. Edge functions deployade till supabase-dev via CLI; staging/prod via MR !220 (development → staging). Ingen migration. Se även docs/arbetslogg.md 2026-09-10 (em) och docs/ANDRINGSFALLOR.md — tre av fyra kodfel var "en regel på två ställen".

Den 2026-09-26 åtgärdades en bugg i admin Resurser-vyn där ett klick på en befintlig resurs i listan inte öppnade resursen för redigering — högerpanelen visade fortsatt "Ny resurs"-formuläret. Dessutom förbättrades UX med tydligare rubrik, tangentbordsnavigering och konsekvensvarningar.

Rotorsak

handleSelectResource i ResourcesTab.tsx anropade handleEditResource men satte aldrig isCreatingNew = false. Render-ternaryen checkar isCreatingNew först: isCreatingNew ? <ny form> : editingResource ? <edit form> : <empty>. Om användaren tidigare klickat "Ny resurs" (vilket sätter isCreatingNew = true), visades alltid ny-resurs-formuläret, oavsett att editingResource faktiskt var satt.

Fix

• Kritisk fix: setIsCreatingNew(false) i handleSelectResource innan handleEditResource anropas.
• Rubrik: ResourceDetailPanel visar "Redigera: {namn}" för befintliga resurser och "Ny resurs" för nya. Lägesindikationen finns i rubriken och i SaveBar-knappen ("Skapa resurs" / "Spara ändringar").
• Tangentbordsnavigering: Resursrader i listan har tabIndex={0}, role="button", aria-label och onKeyDown (Enter/Mellanslag aktiverar). focus-visible:ring-styling för synlighet.
• Dirty tracking för ny resurs: onChange för ny-resurs-formuläret sätter nu setEditIsDirty(true), så osparade ändringar varnas vid byte av resurs.
• Konsekvensvarning: Vid ändring av pricing_type (resurstyp) eller location_id (plats) på en befintlig resurs med framtida bokningar, visas en AlertDialog innan sparning. Bokningskontroll: supabase.from('bookings').select('*', { count: 'exact', head: true }).eq('resource_id', ...).gte('booking_start', now()). Om count > 0 visas varning med antal bokningar som påverkas.

Bevarat oförändrat

• ResourceFormSections.tsx — alla 5 flikar (Grundläggande, Tider & Tillgänglighet, Regler, Betalning, Avancerat)
• ResourcePaymentSettings.tsx, ResourceMultiImageUpload.tsx, ResourceFarligZon.tsx, ResourcePreview.tsx
• useUnsavedChangesWarning.ts — dirty state hook
• RESOURCE_PUBLIC_SELECT — kolumnlista
• Alla Supabase-frågor, datamodell, API-kontrakt
• Sparlogik (handleAddResource, handleUpdateResource) — endast refactorerad genom att extrahera performUpdateResource
• Borttagning som separat åtgärd (ResourceFarligZon)

Påverkade filer

• src/components/admin/ResourcesTab.tsx — setIsCreatingNew(false) i handleSelectResource, tangentbordsattribut på listrader, dirty tracking för ny resurs, konsekvensvarning med AlertDialog, performUpdateResource extraherad
• src/components/admin/ResourceDetailPanel.tsx — "Redigera: {namn}"-rubrik
• src/data/releaseNotes.ts — ny release note

Status 2026-09-26: Committad till development (23bb5775). TypeScript 0 fel, 3994 frontend-tester gröna. Verifierad i webbläsare: klick på resurs efter "Ny resurs" öppnar nu redigeringsläge med korrekt rubrik och inlästa värden.

Delad paketdata och BookingPlanCard — arkitektur

Sedan 2026-09-07 delar marknadssidan (/paket) och beställningsflödet (/order/bokningssystem) samma paketdata och samma kortkomponent. Tidigare var paketmetadata (namn, beskrivning, features, badge) duplicerad i två filer med två helt separata visuella implementationer.

Delad datamodell: src/config/bookingPlans.ts

Enda källan för paketmetadata. Innehåller BOOKING_PLAN_INFO med label, short, highlights, badge, icon, sku, steps och maxResources för Starter, Business och Enterprise. PLAN_SKU härleds härifrån.

Priser hämtas från CRM via respektive hooks (usePackagePricing för marknadssidan, useOrderPricing för checkout) — inga priser hårdkodas i konfigurationen.

Produktnamn (2026-09-10): Growth-planens label är "Business" (inte "Pro") för att matcha Stripe som visar "KiiOn Booking Business" för SUB-KFL-002. CRM:s produkt heter "Booking Business". Fallbacken i bookingPlans.ts använder label: "Business".

Delad kortkomponent: src/components/plans/BookingPlanCard.tsx

En komponent med variant-prop:

• variant="marketing" — renderar ett shadcn Card med Link-knapp. Används på /paket.
• variant="checkout" — renderar en <label> med RadioGroupItem (sr-only), selected state (border + bg tint + checkmark) och CTA som byter till "Vald plan". Används i BookingSystemPlanStep inuti en RadioGroup.

Marknadssidans visuella stil är design-facit: flytande badge (-top-3 left-1/2), text-4xl-pris, enkla Check-ikoner för features. CTA har margin-top: auto för bottenalignment.

Bakåtkompatibilitet

• BookingSystemConfigStep.tsx importerar och re-exporterar BOOKING_PLAN_INFO och PLAN_SKU — befintliga importer fungerar oförändrade.
• applyPlanPrices stannar i BookingSystemConfigStep.tsx (testet crmCouplingContract kräver att anropet applyPlanPrices(BOOKING_PLAN_INFO, prices) finns i källkoden).
• BookingPlan-typen ("starter" | "growth" | "pro") är oförändrad och skickas fortfarande till create-order som subscriptionType.

Layout: bredare plansteg i checkout

OrderShell har en ny valfri maxWidth-prop. BookingSystemOrderPage passerar maxWidth="max-w-5xl" för plansteget (steg 1) så korten får samma proportioner som marknadssidan (1024px istället för tidigare 672px). Andra steg behåller max-w-2xl.

Påverkade filer: src/config/bookingPlans.ts (ny), src/components/plans/BookingPlanCard.tsx (ny), src/components/order/BookingSystemConfigStep.tsx, src/pages/PackagePricingPage.tsx, src/components/order/OrderShell.tsx, src/pages/BookingSystemOrderPage.tsx.

Den 2026-09-23 ersattes de inkonsekventa bekräftelsevisningarna efter kontaktformulär och köp med ett enhetligt mönster: hela den befintliga ytan ersätts av en success state när backend bekräftat handlingen. Inga popups, inga kvarstående formulär, ingen "Nej tack"-knapp.

Nya komponenter i src/components/success/

• ContactSuccessState — ersätter hela kontaktformuläret med bekräftelse ("Tack för din förfrågan!"), en divider och "Under tiden – upptäck Kiion" med 3 produktkort (ProductDiscoveryCard). Kortordningen baseras på angivet intresse via befintlig normalizeInterest + CARD_ORDER-logik. Förstakortet får prioritized=true (subtil highlight + "Passar bra tillsammans"-etikett). Sekundär länk "Skicka ett till meddelande" anropar onReset.
• CheckoutSuccessState — delad checkout-bekräftelse för båda orderflöden. Visar orderdetaljer (produkt, antal dörrar/resurser, månadspris, engångskostnad, plats), ordernummer med kopieringsknapp, "Vad händer nu?"-tidslinje (endast variant="invoice"), integrerad CrossSellFlow och "Gör en ny beställning"-länk.
• CrossSellFlow — visuellt flöde med ikoner och pilar. För Mobile Access-källa: Boka → Betala → Öppna (3 steg). För Bokning-källa: Bokning → Betalning → Mobil access → Öppen dörr (4 steg). Primär CTA "Utforska {andra produkt}" (variant="brand"), sekundär "Gå vidare till Mina sidor" (variant="outline", länk till /my-bookings). Pilarna är ArrowRight på desktop och ArrowDown på mobil (vertikal stapling).
• ProductDiscoveryCard — enkel produktkort för kontakt-success. Återanvänder kort-logik från CrossSellDiscovery men utan dismiss/show-once.

Ändringar i befintliga filer

• ContactPage.tsx — renderar ContactSuccessState i stället för formuläret när submitStatus === "success". CrossSellDiscovery borttagen.
• MobileAccessOrderPage.tsx — paymentStatus === "success" renderar CheckoutSuccessState variant="card". paymentStatus === "cancelled" behåller CardPaymentResult. Faktura-success (orderRef satt) renderar CheckoutSuccessState variant="invoice". Inline OrderSuccess borttagen.
• BookingSystemOrderPage.tsx — faktura-success renderar CheckoutSuccessState variant="invoice". Inline OrderSuccess borttagen.
• CardPaymentResult.tsx — successTitle och successDescription är nu valfria (används fortfarande av OverforingPage för båda fallen).
• crossSellAnalytics.ts — 6 nya metoder: contactSubmitSuccess, contactSuccessView, contactProductCardClick, checkoutSuccess, checkoutSuccessView, crossSellContinueClick.
• i18n — nya success.*-nycklar för sv + en.
• releaseNotes.ts — ny admin-notis "Enhetlig bekräftelse efter kontakt och köp".

Vad som INTE ändrats

• CRM-kopplingen — inga action-namn, priser eller fält ändras. crmCouplingContract-testet grönt (29/29).
• Betalningslogik — create-order, Stripe-redirect, webhook oförändrade.
• Edge functions — oförändrade.
• State-hantering för submit/order — submitLockRef kvarstår, dubbel-submit förblir blockerad.
• CrossSell.tsx + CrossSellDiscovery.tsx — lämnade oförändrade (används inte längre av dessa flöden men kan finnas kvar för bakåtkompatibilitet).
• useCrossSellShown — används inte i nya komponenter (permanent state, inte show-once).

Tillgänglighet och animation

• animate-fade-in på container (respekterar prefers-reduced-motion via global CSS-block).
• aria-live="polite" på container.
• Fokus flyttas till rubriken via ref.focus() efter render.
• Rubrik-hierarki bevarad (h1/h2/h3).

Varianter

• variant="invoice" — "Din order är mottagen och vi har skickat en bekräftelse till din e-post." + "Vad händer nu?"-tidslinje (3 steg).
• variant="card" — "Din order är mottagen och betald. Vi har skickat en bekräftelse till din e-post." Ingen tidslinje (betalning redan bekräftad).

Status 2026-09-23: Committad till development (53c4ac7c). 3789 tester gröna, TypeScript 0 fel. /order är avstängt i produktion (page_order_visible = 'false').

Förenklat tillvalssteg + förbättrad API Överföring-UI

2026-09-07 förenklades steg 2 (Tillval) i Bokningssystem-checkouten och API Överföring-sidan fick bättre layout.

Tillvalssteg (Bokningssystem-checkout)

• Betalningstillägg Stripe borttaget från steg 2: kortbetalning/faktura ingår i abonnemanget. stripeAddon-fältet finns kvar i BookingSystemConfig och auto-aktiveras för growth-planen. STRIPE_ADDON_SKU skickas fortfarande i orderItems för growth. CRM-payloaden är oförändrad — kontraktet bevarat.
• Uppstartskostnaden (SVC-IMP-001, 2 995 kr) villkorad av Mobile Access: calculateBookingSystemTotals.mobileAccessOneTime är 0 när includeMobileAccess = false. orderItems inkluderar SVC-IMP-001 bara när Mobile Access är valt. Kostnaden visas inuti Mobile Access-sektionen, inte som en separat "tillkommer alltid"-tile.
• Onboarding-copy uppdaterad: "Vi hjälper dig att sätta upp bokningssystemet och går igenom allt du behöver för att komma igång."
• Stripe summary-grupp borttagen ur ordersammanfattningen.

Beställ API Överföring (OverforingPage)

• Bredare container (maxWidth="max-w-5xl") så sidebar och totalsumma inte bryts.
• Tre sektionskort med ikoner: Typ av överföring (Replace), Nuvarande system & omfattning (Building2), Tidsplan & övrigt (Clock).
• Förbättrade borders (border border-border/60 istället för border-0), spacing och input-höjd (h-10).

Påverkade filer

src/components/order/BookingSystemConfigStep.tsx, src/components/order/BookingSystemConfigStep.test.ts, src/pages/BookingSystemOrderPage.tsx, src/pages/products/OverforingPage.tsx

Ingen CRM-koppling ändrad, inga priser hårdkodade, ingen backend påverkad. crmCouplingContract-testet grönt (25/25). Commit: d0548c98.

Den 2026-09-08 harmoniserades beställningsflödena för Mobile Access och Bokningssystem till en gemensam struktur med delade komponenter, förbättrad CompanyStep och ett nytt dörr-/resursnamnssteg.

Gemensam checkout-struktur

Båda beställningsflödena följer samma mönster: Företagsuppgifter → Produktens konfiguration → Dörrar (endast Mobile Access) / Resurser & dörrar (Bokningssystem) → Granska.

• Mobile Access (MobileAccessOrderPage): 4 steg — Plan → Företagsuppgifter → Dörrar → Granska.
• Bokningssystem (BookingSystemOrderPage): 5 steg — Välj plan → Tillval → Företagsuppgifter → Resurser & dörrar → Granska.

CompanyStep — delad företagsuppgiftskomponent

src/components/order/CompanyStep.tsx används av båda flödena. Förbättringar 2026-09-08:

• Dubbla teal-ramar borttagna: Selected state använder border-primary bg-primary/[0.05] utan ring-1 ring-primary.
• Focus-visible: Kundtypskorten har focus-visible:ring-2 för tangentbordsnavigering.
• Organisationsnummer: Placeholder Ex. 556123-4567, villkorad hjälptext per kundtyp. formatOrgNumber() formaterar med bindestreck efter position 6.
• Hover-state: Omarkerade kort har hover:bg-muted/30.

DoorNamesStep — komponent för dörr-/resursnamn

src/components/order/DoorNamesStep.tsx samlar namn (inte antal). Props: count, value, onChange, title, label, lead, variant ("door" | "resource"), placeholder.

Optional props för plats/fastighet (tillagda 2026-09-09): placeName, onPlaceNameChange, placeNameLabel, placeNamePlaceholder, placeNameHelp. När onPlaceNameChange skickas renderas ett extra input-fält ovanför dörrnamnen. Används nu av båda flödena (Mobile Access sedan 2026-09-09, Bokningssystem sedan 2026-09-10).

ReviewStep — Resurser & dörrar-sektion

ReviewStep har props: doorNames?, resourceNames?, onEditDoors?, placeName? (tillagd 2026-09-10). Sektionen "Resurser & dörrar" visas mellan "Din lösning" och "Företagsuppgifter" när minst ett namn eller platsnamn är ifyllt. Listar plats, resurser och dörrar i separata undersektioner.

Admin-tab: NewOrderTab (ny 2026-09-10)

src/components/admin/NewOrderTab.tsx — admin-tab under "Organisationsinställningar" som låter org-admin starta en ny beställning. Visar de tre planerna (Starter, Business, Enterprise) från BOOKING_PLAN_INFO och navigerar till /order/bokningssystem. Registrerad i AdminPage.tsx som new-order-tab, med navobjekt i AdminSidebar.tsx.

OrderSuccess — ny beställning-knapp (ny 2026-09-10)

BookingSystemOrderPage visar efter slutförd order två knapper: "Gör en ny beställning" (återställer formuläret) och "Tillbaka till startsidan".

CRM-koppling

doorNames, placeName och resourceNames läggs till additivt i create-order-payloaden. placeName accepterades redan av create-order och sparades i orders.place_name. Inga action-namn, inga befintliga fält och inga priser har ändrats — kontraktet med KiiOn CRM är bevarat enligt Janis stående instruktion.

Påverkade filer

• src/components/order/CompanyStep.tsx — borttagen dubbel ram, focus-visible, placeholder
• src/components/order/DoorNamesStep.tsx — platsnamn-props (används av båda flödena sedan 2026-09-10)
• src/components/order/ReviewStep.tsx — Resurser & dörrar-sektion, placeName-prop tillagd 2026-09-10
• src/components/admin/NewOrderTab.tsx — ny admin-tab (2026-09-10)
• src/components/admin/AdminSidebar.tsx — new-order navobjekt (2026-09-10)
• src/pages/AdminPage.tsx — new-order tab (2026-09-10)
• src/pages/BookingSystemOrderPage.tsx — placeName state + payload + OrderSuccess-knappar (2026-09-10)
• src/pages/MobileAccessOrderPage.tsx — 4-stegsflöde, doorNames + placeName

Status 2026-09-10: placeName nu även i Bokningssystem-flödet (DoorNamesStep + ReviewStep). Ny admin-tab NewOrderTab. OrderSuccess med "Gör en ny beställning"-knapp. Committad till development (a9f65181). 3399 tester gröna, TypeScript 0 fel. /order är avstängt i produktion (page_order_visible = 'false').

Status 2026-09-09: Platsnamn-fält tillagt i DoorNamesStep + MobileAccessReviewStep. Committad (d85026d9).

Status 2026-09-08: Implementerad. 3240 tester gröna.

Hero-sektionerna på förstasidan (/), mobil access (/products/mobil-access) och bokning (/products/bokningssystem) använder nu samma brand-gradient-overläggning. Tidigare hade mobil access och bokning en annan behandling (backdrop-blur + mix-blend-multiply med turkos + mörk gradient), vilket gav en annan känsla än förstasidan och såg olika ut mellan de två produktsidorna.

Overlay-mönster (gemensamt för alla tre)

<div class="absolute inset-0 bg-gradient-to-t from-secondary/75 via-primary/35 to-primary/10" />
<div class="absolute inset-0 bg-gradient-to-r from-secondary/45 via-primary/20 to-transparent" />

Inga mix-blend-mode, inga backdrop-filter, inga mörka from-black-gradienter. Content-diven har z-10 på alla tre för att ligga över overlayerna.

Påverkade filer

• Index.tsx — referens, oförändrad (härifrån kommer mönstret)
• src/pages/products/MobilAccessPage.tsx — bytte overlay, behöll z-10
• src/components/BookingShowcaseSlider.tsx — bytte overlay, lade till z-10 på content-diven

Konstanten BRAND_ACCENT = "hsl(189, 100%, 31%)" finns kvar i BookingShowcaseSlider.tsx eftersom den fortfarande används av andra sektioner i komponenten (kort och badge, rad 121 och 230).

Status 2026-09-08: Pipeline 2828899275 gröns, deploy_development körde. Ändringen är live på web.dev.kiion.io.

Bulk-radering av medlemmar (CRM-kort acfe73bc) låter en administratör ta bort flera medlemmar samtidigt från medlemsregistret. Tidigare gjordes detta genom sekventiella HTTP-anrop — två anrop per medlem (avsluta Stripe-prenumeration + radera rad) — vilket för 76 medlemmar betydde 152 HTTP-anrop och 30+ sekunders väntetid.

Ny arkitektur: en edge-funktion, en databastransaktion

Allt sker nu via edge-funktionen bulk-delete-memberships som:

1. Tar emot { membership_ids: string[] } och auktoriserar anroparen via Authorization-headern.
2. Anropar RPC:n bulk_soft_delete_memberships(uuid[]) — en enda databastransaktion som soft-deletar alla rader (sätter deleted_at och deleted_by). Om någon rad tillhör en annan organisation avvisas hela anropet — aldrig en delvis radering.
3. Avslutar Stripe-prenumerationer med kontrollerad concurrency (5 åt gången) via processWithConcurrency. resource_missing hanteras som framgång (idempotent — prenumerationen redan borta).
4. Sätter membership_status = 'terminated' för avslutade prenumerationer.
5. Loggar varje radering i activity_logs med typ membership_deleted och metadata (bulk-flagga, antal i batch, stripe-prenumeration).

Varför soft-delete istället för hard DELETE

Tidigare gjorde delete_membership en hard DELETE FROM memberships. Detta hade tre problem:

• Borttappad Stripe-koppling: Raderades raden först förlorades stripe_subscription_id — uppsägningen kunde inte längre göras från appen.
• Ingen återväg: En avbruten bulk-radering kunde lämna halva registret raderat utan återskapning.
• Borttappad historik: Radens data (vem, när, hur mycket) försvann.

Soft-delete (deleted_at + deleted_by) bevarar raden och dess Stripe-koppling. get_org_memberships filtrerar bort rader med deleted_at IS NULL, så de inte syns i listan.

Säkerhet: AlertDialog med type-to-confirm

• AlertDialog (inte vanlig Dialog): Kräver explicit klick — förhindrar att Enter råkar bekräfta.
• Varning för Stripe-prenumerationer: Visar antal medlemmar med aktiva prenumerationer innan bekräftelse.
• Type-to-confirm för >10 medlemmar: Knappen aktiveras först när administratören skriver "RADERA".

UX: ingen spinner

handleBulkDelete stänger dialogen och visar toast.info("Borttagning pågår") innan anropet går — ingen spinner i knappen. När anropet returnerar visas toast.success (alla lyckades) eller toast.warning (några Stripe-prenumerationer kunde inte avslutas).

Påverkade filer

• supabase/migrations/20260910162900_memberships_soft_delete.sql — additiv migration: lägger till deleted_at, deleted_by, uppdaterar delete_membership och get_org_memberships, skapar bulk_soft_delete_memberships
• supabase/functions/bulk-delete-memberships/index.ts — ny edge-funktion
• src/hooks/useMemberships.ts — deleteMember använder nu bulk-funktionen, ny bulkDeleteMembers
• src/components/admin/MembershipsTab.tsx — AlertDialog med tiered confirmation
• supabase/config.toml — [functions.bulk-delete-memberships] med verify_jwt = false (egen auth)

Tester

• 19 vitest-tester i BulkMemberDelete.test.ts (wiring, soft-delete migration, edge-funktion)
• 10 Deno-tester i index_test.ts (processWithConcurrency, idempotens, validering, response-format)
• 3 uppdaterade befintliga tester (membershipAutoRegister, membershipHardening)

Migrationen är helt additiv — befintliga anrop som inte filtrerar på deleted_at ser samma data som innan (alla rader har deleted_at = NULL tills någon raderas).

Status 2026-09-10 (em) — korrigering efter kontroll av produktionsloggarna. De två misslyckade raderingarna 2026-09-09 15:55Z svarade 403, inte 500. FK-nullställningen nedan (09d9ec1b, i produktion sedan 09:04Z) är riktig men var inte orsaken den här gången.

• Rotorsak (403): två definitioner av "tillhör organisationen". Adminens användarlista (get-users-with-email-status → RPC get_organization_users) räknar profiler vars profiles.organization_id pekar på organisationen eller som har en organization_members-rad. delete-user jämförde bara profiles.organization_id. Gästkonton skapade av confirm-guest-booking hamnade i default-organisationen KiiOn AB (Bug 7, GitLab #454) → synliga i listan, men 403 "You can only delete users from your organization" vid radering.
• Fix (01739fd6, development, MR !220): delete-user anropar samma RPC och avgör tillhörighet med userIsInOrganization() i supabase/functions/_shared/org-membership.ts — fail closed om RPC:n saknas eller felar. Deno-grinden org-membership_test.ts kräver att funktionen frågar RPC:n och att den gamla jämförelsen inte återkommer.
• Data (prod, via MCP — data, inte schema): de fyra gästprofilerna flyttade till Atelier Privé och deras KiiOn AB-medlemskap borttagna, så även den gamla koden hade släppt igenom dem.
• Kvar (beslut): Benjamin Custovic har profiles.role = org_admin men user_roles = [user]; delete-user läser user_roles och nekar honom i första grinden.

Ursprunglig text nedan bevarad som historik.

Edge-funktionen delete-user tar bort en användare från auth.users via Supabase admin API. Problemet var att flera tabeller har främmande nycklar till profiles.id, vilket blockerade radering med ett Edge Function returned a non-2xx status code-fel — både på mobil och desktop.

Rotorsak

Åtta tabeller refererar profiles.id med främmande nycklar: orders, mx_installations, shared_calendars, booking_change_requests, order_status_history, leads, deals och crm_activities. När auth.admin.deleteUser() försökte radera användaren kastade databasen ett FK-brott, men felet ytlade som en generisk 500 i klienten.

Fix (2026-09-10, commit 09d9ec1b)

• Server: delete-user/index.ts nullställer FK-kolumnerna i alla åtta tabeller innan användaren raderas. Det bevarar historiken (ordrar, installationer, etc.) utan att lämna hängande referenser.
• Klient: useProfiles.ts catch-block använder nu functionErrorMessage() för att extrahera det verkliga felmeddelandet från edge-funktionens svar, i stället för att visa en generisk "Edge Function returned a non-2xx status code".

Påverkade filer

• supabase/functions/delete-user/index.ts — FK-nullställning för 8 tabeller, org-tillhörighet via get_organization_users
• supabase/functions/_shared/org-membership.ts — userIsInOrganization
• src/hooks/useProfiles.ts — functionErrorMessage i catch-block

Status

FK-fixen (09d9ec1b) är i produktion sedan 2026-09-10 09:04Z (MR !218 → !219). 403-fixen (01739fd6) ligger på development, MR !220 → staging. Rapporterad av Atelier Privé som Bug 4. Registrerad som KiiOn CRM #642 (Pågår), GitLab #451.

Edge-funktionen demo-slots-monitor larmar sälj-/demomottagarna när Boka Demo-kalendern håller på att ta slut, så de kan fylla på tider via Admin → Demo Slots. Funktionen skapar aldrig tider automatiskt — den notifierar bara. Larmet är strypt till max ett per dygn via pricing_alert_throttle.

Rotorsaken till felaktigt larm (fixad 2026-09-04)

demo-slots-monitor räknade ALLA framtida rader i demo_availability_slots utan att subtrahera bokade tider (pending/accepted). BookDemoModal filtrerade bort bokade tider via get_blocked_demo_times. Det gav två olika svar på "hur många lediga tider finns kvar?" — notifieringen kunde larma "0 tider kvar" medan kalendern visade tider.

Fixen — gemensam källa till sanning

Ny RPC get_demo_availability_summary(p_near_term_days) blir den enda källan. Den subtraherar bokade tider (pending/accepted demo_bookings) från framtida slotter och returnerar:

• available_count — antal bookbara tider
• first_available / last_available — första/sista tillgängliga tid
• runway_days — dagar till sista tiden
• near_term_count — antal tider inom p_near_term_days (default 14)

Edge-funktionen använder nu denna RPC. Nytt larmvillkor:

available_count === 0 || near_term_count === 0 || runway_days < 14

Detta fångar även "kalendern har tider om månader men inget inom 14 dagar" — ett fall som gamla kalkylen missade.

Påverkade filer

• supabase/migrations/20260904140000_add_demo_availability_summary.sql (ny) — RPC + grants
• supabase/functions/demo-slots-monitor/index.ts — använder RPC istället för egna queries
• src/integrations/supabase/types.ts — TypeScript-typ för RPC

Status 2026-09-04: Implementerad, committad till development (bde78015). RPC applicerad på supabase-dev.

Uppdaterad 2026-09-24: create-member och AddMemberDialog utökade med adressfält (gatuadress, postnummer, stad).

Det enhetliga "Lägg till medlem"-flödet ersätter den gamla splittrade UX:en med en modal med tre flikar.

3-flikars modal (AddMemberDialog i MembershipsTab.tsx)

Flik 1 — Skapa ny: Formulär med namn, e-post, telefon, adress, postnummer, stad, medlemskapstyp, belopp, start-/slutdatum och anteckningar. Vid submit anropas create-member-edgefunktionen. Dubblettkontroll sker på e-post (display_email) vid blur.

Flik 2 — Befintlig användare: Söker i profiles efter namn/e-post, väljer profil, anger belopp.

Flik 3 — Importera: Beskrivning + knapp som öppnar CSV-importguiden (MembershipImportDialog).

Edgefunktion: create-member

CreateMemberRequest utökad med street_address?, postal_code?, city?. Adressfält hanteras i alla kodvägar:

• Befintlig profil: uppdaterar adress om angivna och profilen saknar dem (samma mönster som telefon).
• Ny användare: adress skickas i user_metadata + uppdateras på profiles efter skapande.

Välkomstmejl skickas till nya användare (GitLab #425 / KiiOn CRM #586, fixat 2026-09-14).

Berörda filer

• supabase/functions/create-member/index.ts — adressfält i CreateMemberRequest + alla kodvägar
• src/components/admin/MembershipsTab.tsx — AddMemberDialog med adressfält
• supabase/config.toml — [functions.create-member] verify_jwt=false

Status 2026-09-24: Adressfält tillagda i create-member och AddMemberDialog. 3848 tester gröna.

Status 2026-09-14: Välkomstmejl med lösenord implementerat (GitLab #425).

Status 2026-09-03: Implementerad, committad till development (d77eef17).

Status 2026-09-23 (GitLab #530): tabellen nedan är omskriven. Den tidigare versionen av den här FAQ:n beskrev ett läge som inte längre gäller — Starter hade bara faktura, delade kalendrar krävde Enterprise. Läs den nya tabellen, inte minnet av den gamla.

De två källorna — och varför de måste hållas ihop

• FEATURE_CONFIG i useFeatureGating.ts — vilken plan som krävs per funktionsnyckel.
• PLAN_LIMITS i useSubscriptionLimits.ts — resurstak och paymentMethods. Bokningsdialogen läser betalsätten härifrån, inte ur FEATURE_CONFIG. Säger de två olika saker visas inga betalalternativ alls.

Löftet kunden läser står på en tredje plats: BOOKING_PLAN_INFO[...].highlights i src/config/bookingPlans.ts, som renderas på /order/bokningssystem och /paket. Testet src/hooks/__tests__/featureGatingMatchesPlanPromise.test.ts härleder kopplingen ur den texten i stället för att upprepa en lista, och faller om löfte och grind glider isär åt något håll.

Plannycklar och etiketter

starter = Starter, growth = Business, pro = Enterprise. upgradeTarget är kundvänd text och måste använda etiketten, inte nyckeln. Testet kontrollerar dessutom att varje upgradeTarget pekar på en plan som faktiskt har funktionen.

FEATURE_CONFIG efter #530

PLAN_LIMITS

• starter: 5 resurser, betalsätt ['stripe','invoice']
• growth (Business): 10 resurser, ['stripe','invoice']
• pro (Enterprise): obegränsat (-1), ['stripe','invoice']

Vad #530 rättade — och varför det är värt att komma ihåg

Grindarna och säljtexten hade glidit isär åt båda håll:

• Kortbetalning utlovades i Starter men krävde Business, och PLAN_LIMITS.starter.paymentMethods saknade 'stripe'. En Starter-organisation med faktura avstängd fick inga betalsätt — verifierat på PH Kontorshotell och EXIT88 2026-09-23.
• Delade kalendrar utlovades i Business men krävde Enterprise.
• Medlemsregister och ekonomi/rapportering utlovades i Business men saknade grind helt.

Avancerad prissättning & bokningsregler fick medvetet ingen grind. Löftet motsvarar ingen avgränsad yta: prissättningstyperna är pricing_type på resursen, ett grundfält i ResourceFormSections.tsx som varje befintlig Starter-resurs redan använder. Raden ligger i PROMISE_TO_FEATURE med tom funktionslista och en kommentar som säger varför.

Systemadmin passerar allt

useFeatureGating sätter access[feature] = true för varje funktion när isSystemAdmin är sant. Testa därför plangrindar med ett vanligt org-adminkonto — en systemadmin ser aldrig hänglåset.

Under laddning låser vi inte

FeatureGate renderar barnen som vanligt medan isLoading är sant, så hänglåset inte blinkar förbi för en kund som faktiskt har funktionen. Bygger du en egen grind utanför FeatureGate — som menyposten för bokningsrapporten i BookingsTab — måste du följa samma regel.

Filer

• src/hooks/useFeatureGating.ts — FEATURE_CONFIG, useFeatureGating()
• src/hooks/useSubscriptionLimits.ts — PLAN_LIMITS
• src/config/bookingPlans.ts — BOOKING_PLAN_INFO (löftet)
• src/components/FeatureGate.tsx, src/components/UpgradePromptDialog.tsx
• src/hooks/__tests__/featureGatingMatchesPlanPromise.test.ts — grinden

Kontaktinställningarna för bokningssidan (/resources) administreras från Admin → Hemsida & innehåll → Kontaktsektion, där två tydligt separerade sektioner samlar all publik kontaktinformation:

Två sektioner på Kontaktsektion-sidan

• Startsidans kontaktsektion — styrs av organization_customizations-tabellen (toggle show_contact_section, fritext, knapptext, sociala medier). Denna sektion är feature-gated på customLandingPage och visas bara för organisationer med anpassad startsida. Komponent: ContactSectionSettings.
• Kontakt på bokningssidan — tre oberoende toggles som styrs av organizations-tabellen. Denna sektion är inte feature-gated och är tillgänglig för alla organisationer. Komponent: BookingContactSettings.

Tre toggles för bokningssidan

• Visa telefonnummer (organizations.show_contact_phone) — visar telefon-CTA i kontaktkortet. Default true.
• Visa kontaktformulär (organizations.show_contact_form) — visar nedfällbart formulär. Default true.
• Visa hjälp vid bokningsproblem (organizations.show_support_card) — visar supportkortet. Default true.

Om både Visa telefonnummer och Visa kontaktformulär är av visas inget primärt kontaktkort alls. Supportkortet auto-döljs om ingen kontaktväg finns konfigurerad (ingen phone eller form aktiv) — det uppmanar aldrig besökaren att "kontakta oss" utan att det finns en väg att göra det.

Telefon och e-post hämtas från organisationens befintliga kontaktuppgifter (samma contact_phone / contact_email som sätts under Admin → Organisation). Hjälptexter varnar om en toggle är ON men motsvarande kontaktuppgift saknas.

Publik synlighetslogik

ResourcesListPage.tsx beräknar:

• hasPhone = show_contact_phone && contact_phone finns
• hasForm = show_contact_form && contact_email finns
• hasContact = hasPhone || hasForm
• showSupport = show_support_card && hasContact
• showAside = hasContact || showSupport

När showAside är falskt renderas ingen vänster-aside och resursgriden tar full bredd (w-full).

Komponenter

• ContactSectionSettings.tsx — exporterar två komponenter: ContactSectionSettings (startsidans kontaktsektion, feature-gated) och BookingContactSettings (bokningssidans toggles, ej gated). BookingContactSettings hämtar och sparar toggles direkt mot organizations-tabellen med en egen save-knapp, separat från identitetsuppgifter.
• OrganizationContactForm.tsx — props showPhone och showForm (default true). Telefon-CTA och formulär döljs/grävs oberoende. "Eller"-divider visas bara om båda är synliga.
• OrganizationSettingsSection.tsx — innehåller nu endast identitet, adress och prisvisning. Kontakt-toggles har flyttats ut.

Cache-fix — kiion:org-settings-updated event

Problem: OrganizationContext laddade org-data en gång på mount och uppdaterade aldrig icke-subscription-fält efter admin-save. En hård browser-refresh krävdes för att se ändrade kontaktinställningar på bokningssidan.

Lösning: kiion:org-settings-updated window event dispatchas från save-handlern i BookingContactSettings (och från OrganizationSettingsSection efter identitet/adress/pris-spar). En lyssnare i OrganizationContext re-fetchar hela org-record. Detta speglar det befintliga kiion:billing-updated-mönstret.

Bakåtkompatibilitet

Alla toggle-kolumner är NOT NULL DEFAULT true — befintliga organisationer ser samma kontaktsektion som tidigare. Flytten av UI från Organisation-sidan till Kontaktsektion-sidan ändrar inga backend-fält; samma kolumner i organizations återanvänds. Ingen datamigrering krävdes.

Påverkade filer

• supabase/migrations/20260904130651_add_contact_display_toggles.sql — kolumner + RPC
• src/integrations/supabase/types.ts — typer
• src/contexts/OrganizationContext.tsx — interface, query, event-listener
• src/components/admin/customizations/ContactSectionSettings.tsx — delad i ContactSectionSettings + BookingContactSettings
• src/components/admin/customizations/OrganizationSettingsSection.tsx — kontakt-kort borttaget, endast identitet/adress/pris kvar
• src/components/admin/OrgSettingsWrapper.tsx — borttagen state/props för kontakt-toggles
• src/pages/AdminPage.tsx — contact-section-case renderar båda komponenterna med en <div className="h-px bg-border" />-avdelare
• src/components/OrganizationContactForm.tsx — showPhone/showForm-props
• src/pages/ResourcesListPage.tsx — synlighetslogik + layout

UI-omstrukturering 2026-09-05 — tightare admin-sida

Admin-sidan för Kontaktsektion omstrukturerades för att eliminera redundant information och minska vertikal yta med 26% (1217→895px).

• Header + toggle slås ihop: Tidigare fanns tre repetitioner av samma koncept (sektionsheader, toggle-rad med egen rubrik, kort-header). Nu är header och toggle i en enda rad — toggle-switchen ligger direkt till höger om rubriken.
• Kort-header borttagen: Kortet med formulärfält har inte längre en egen header med ikon + titel + beskrivning. Formuläret börjar direkt i kortkroppen.
• Facebook/Instagram sida-vid-sida: Istället för två staplade fullbreddsfält ligger de i ett 2-kolumners grid (samma som Knapptext/Knapplänk).
• Lättare toggle-rader: BookingContactSettings toggle-rader ändrade från border-2 till border (1px), padding från p-4 till p-3.5, och ikoner från h-4 w-4 till h-3.5 w-3.5.
• Tightare spacing: space-y-5 → space-y-4 i formulärkorten, space-y-4 → space-y-3 utanför, gap-3 → gap-2.5 mellan toggle-rader.
• Kortare spar-knappar: "Spara kontaktsektion" / "Spara kontaktinställningar" → "Spara".

Inga backend-ändringar, inga nya kolumner, ingen datamigrering. Endast CSS/JSX i ContactSectionSettings.tsx.

Status 2026-09-05: UI-omstrukturering committad till development. TypeScript 0 errors, 3194 tester gröna, build success. Sidhöjd minskad 26%.

Status 2026-09-04: Ursprunglig implementation committad (274f034c). UI-flytt till Kontaktsektion-sidan genomförd (c67d703d, 8de64cd1) — bokningskontakt-toggles flyttade från Organisation-sidan till Hemsida & innehåll → Kontaktsektion. Migration applicerad på supabase-dev. TypeScript, 3145 tester, build gröna.

När en kund fyller i sina kontaktuppgifter i beställningsflödet (steg 1) anropar usePricingLead-hooken edge-funktionen send-sales-lead. Funktionen skapar ett lead i databasen, synkar till KiiOn CRM, och skickar ett internt mejl till internal_email_sales_leads (normalt sales@kiion.io).

Problemet som löstes 2026-09-09

Mejlet visade tekniska fältnamn på engelska ("Offering key", "Hardware mode", "Binding months", "Onboarding requested") istället för svenska displaynamn som matchar beställningsflödet. Rotorsaken var att CONTEXT_LABELS-kartan i send-sales-lead saknade nycklar för offeringKey, hardwareMode, bindingMonths och onboarding_requested. Okända nycklar föll tillbaka på humanizeKey() som producerade engelska camelCase-namn.

Lösningen — gemensam source of truth

Ny shared module _shared/product-context-labels.ts är den kanoniska källan för svenska etiketter och värdeöversättningar för productContext-fält. send-sales-lead importerar formatProductContextRows() istället för att ha inline-etiketter.

• Fältetiketter: PRODUCT_CONTEXT_LABELS_SV mappar alla kända nycklar till svenska namn. Okända nycklar filtreras bort — visas aldrig som tekniska namn.
• Värdeöversättningar: owned → "Köpt", loaned → "Hyrd", standard → "KiiOn Standard", flex → "KiiOn Flex", bindingMonths → "X månader"
• Filtrering: null/undefined/tom sträng, false (ej valda tillval), 0 (antal-fält) och redundanta nycklar (onboarding_requested är dubblett av includeOnboarding) filtreras bort.
• Mejlrubrik: Ändrad från "Förfrågan" till "Beställningsuppgifter".

Frontend-komponenterna (MobileAccessConfigStep, MobileAccessReviewStep, BookingSystemConfigStep) har motsvarande etiketter hårdkodade i JSX. Eftersom edge functions (Deno) och frontend (Vite/React) inte kan dela import, är _shared/product-context-labels.ts den enda platsen på serversidan som översätter råa värden till svenska displaynamn — ändras etiketterna här, ändra även i frontend-komponenterna.

Vilka productContext-nycklar som skickas

Mobil Access: offeringKey, hardwareMode, bindingMonths, onboarding_requested (redundant), mxUnits, includeOnboarding, includeInsurance

Bokningssystem: plan, resources, stripeAddon, includeMobileAccess, mxUnits, includeOnboarding

Påverkade filer

• supabase/functions/_shared/product-context-labels.ts — ny shared module
• supabase/functions/send-sales-lead/index.ts — importerar och använder formatProductContextRows()

Status 2026-09-09: Implementerad, committad till development (fbe08fd5). TypeScript 0 fel, 3287 tester gröna. CRM-kopplingen opåverkad — inga action-namn, env-var-namn eller priser rörda.

Status `pending` lades till 2026-09-15 som ett expand-steg för att åtskilja "inloggad" från "aktiv medlem". Innan ändringen skapade auto-triggern trg_auto_membership_on_profile en medlemskapsrad med membership_status = 'active' + payment_status = 'not_billed' för varje profil som fick organization_id. Dashboard-kortet "Aktiva medlemmar" räknade sedan dessa som aktiva — men ingen hade betalat, och bokningsgrinden enforce_membership_for_booking kräver paid. 13 "aktiva" i dev, men 0 kunde boka.

Vad som ändrades

• Ny status pending i membership_status-CHECK:en. Helt additivt — inga befintliga värden togs bort. pending = "registrerad men inte aktiverad", separat från upcoming (kommande med startdatum).
• Auto-trigger auto_create_membership_on_profile() sätter nu membership_status = 'pending' explicit istället för att förlita sig på kolumnens default active.
• create_membership()-RPC sätter pending som default. Admin som lägger till en medlem manuellt utan betalning får pending — inte active.
• Webhook handleMembershipPayment() sätter fortfarande active + paid + datum vid verifierad betalning. Orörd.

Dashboard-räknelogik (MembershipsTab.tsx)

Förut räknade kortet "Aktiva medlemmar" alla rader där membership_status === 'active' (eller null). Nu räknas enbart medlemskap som är:

• membership_status === 'active' OCH
• payment_status === 'paid' OCH
• paid_at != null OCH
• end_date är null eller i framtiden

Detta matchar bokningsgrindens krav. Auto-skapade pending-medlemskap räknas inte som aktiva.

markPaid() sätter giltighetsdatum

markPaid() i useMemberships.ts hämtar nu duration_months från membership_types om en typ finns, och sätter start_date = today + end_date = today + duration_months (default 12 månader). Tidigare sattes inga datum vid manuell markering, vilket gjorde giltigheten beroende av membership_year istället för datum.

markNotBilled() rensar datum

markNotBilled() rensar nu start_date, end_date, paid_at, paid_by och amount, samt sätter membership_status = 'pending'. Paritet med markPaid().

Etiketter och badges

• not_billed-etikett ändrad från "ej debiterad" till "Obetald" (tydligare, konsekvent med "Betald").
• pending-badge: amber (gul) — bg-amber-100 text-amber-700 / dark mode bg-amber-900/30 text-amber-300.
• MEMBERSHIP_STATUS_LABELS utökad med pending: "Väntar".
• MembershipDetailDialog: pending mappad till secondary-variant.

membership_eligibility använder 4-arg membership_is_valid

membership_eligibility() anropar nu membership_is_valid(m.payment_status, m.paid_at, p_year, m.end_date) (4-arg) istället för 3-arg varianten som ignorerade end_date. Ett medlemskap med end_date i det förflutna anses nu inte giltigt bara för att membership_year är aktuellt.

Data på dev

13 befintliga dev-medlemskap med payment_status = 'not_billed' + membership_status = 'active' uppdaterades till pending via MCP execute_sql (inte i migrationen — DML är förbjudet i migrationer av migration_no_dml-grinden).

Berörda filer

• supabase/migrations/20260915120100_membership_pending_status.sql — ny migration: pending-enum, auto-trigger, create_membership-RPC, eligibility 4-arg (version 20260915120100, inte 20260915120000 som kolliderade med booking_purpose_catalog_enforcement)
• src/components/admin/MembershipsTab.tsx — dashboard-räknelogik, badge för pending, dropdown-text "Markera obetald"
• src/hooks/useMemberships.ts — markPaid sätter datum, markNotBilled rensar datum, etikett "Obetald"
• src/hooks/useMembershipTypes.ts — pending i MEMBERSHIP_STATUS_LABELS
• src/components/admin/MembershipDetailDialog.tsx — badge-variant för pending
• src/components/admin/__tests__/MembershipsTabWiring.security.test.ts — uppdaterad toast-text

Migration

Migration: 20260915120100_membership_pending_status.sql. Applicerad på supabase-dev. Staging/produktion får den via CI/CD vid MR-sammanfogning.

Status 2026-09-15: Implementerad, committad till development (9dbbee48). Migration applicerad på supabase-dev. TypeScript 0 errors, 3399 tester gröna. KiiOn CRM-kort: 940715ab-9d6d-4ab0-b904-3806b8e43fbc ("vidareutvecklar medlemskap och medlemsbetalningar i KiiON").

Medlemsmeddelanden låter en administratör skicka e-post till en eller flera medlemmar direkt från Medlemsregistret eller Kundkortet. Funktionen använder edge-funktionen send-membership-email som slår upp mottagarnas e-postadresser server-side från medlemskapen — klienten skickar aldrig e-postadresserna, bara medlemskapens id.

Rotorsaken till 500-felet (fixad 2026-09-04)

Edge-funktionen returnerade 500 för alla POST-anrop på grund av två problem:

• FK-tvetydighet i PostgREST: memberships har två främmande nycklar till profiles (profile_id och paid_by). Frågan profiles!inner(...) utan explicit FK-hint fick PostgREST att returnera fel format, vilket kastade ett TypeError inifrån supabase-js ("Cannot read properties of undefined (reading 'name')"). Fix: profiles!profile_id!inner(...).
• Rate limit utanför try/catch: rateLimitAllowed() stod utanför try-blocket. Ett obehandlat fel där gav en osignalerad 500 som var omöjlig att felsöka från klienten. Fix: flyttat in i try-blocket.

Frontend-felhantering

Frontend visade tidigare bara "Edge Function returned a non-2xx status code" eftersom SendEmailDialog använde e.message istället för den befintliga functionErrorMessage()-utiliten. Utiliten extraherar det verkliga felmeddelandet från error.context (Response-objektet) och visar ett begripligt svenskt fel.

Mottagarvisning och medlemmar utan e-post

• 1 mottagare: Visar namn och e-postadress i dialogen.
• Flera mottagare: Visar antal medlemmar.
• Medlem utan e-post (en):strong> "Skicka"-knappen är inaktiverad, visas "Medlemmen saknar e-postadress."
• Bulk med några utan e-post: Varning om att X av N medlemmar saknar e-post och får inget meddelande.