Ett diagram räknar rätt först när fem saker är bestämda: vilken period det visar, att tomma dagar visas som noll, att veckan börjar på måndag, att dygnen räknas i svensk tid och att varje användare bara ser det hen får se. Skriv in dem i beställningen och prova med poster strax före och efter midnatt, en tom dag och ett andra konto.
Fyra fel som ser ut som ett riktigt diagram
En dashboard i appen är här en vy som räknar appens egna poster, till exempel bokningar, ärenden eller beställningar per dag och vecka. Besökare och sidvisningar är en annan fråga, som artikeln om att mäta användningen av appen tar upp. Vill du se vem som ändrade en enskild post är det i stället ändringshistorik.
De fel som gör ett diagram opålitligt syns sällan som fel. De ser ut som data:
- Tomma dagar försvinner. Räknar frågan bara de dagar som har poster finns det ingen rad för tisdag om ingen bokade något då. Diagrammet hoppar från måndag till onsdag, och en linje drar en sluttning rakt över den tomma dagen.
- Veckan börjar på söndag. Då hamnar söndagens poster i fel vecka och veckosumman stämmer inte med din kalender.
- Tidszonen flyttar poster. En bokning kl. 00:20 svensk tid är kl. 23:20 i UTC under vintertid. Räknar frågan dygn i UTC hamnar den på föregående dag.
- Alla ser allas siffror. Summan räknar hela tabellen i stället för den inloggade användarens rader.
Bestäm period, veckostart och tidszon
Perioden ska vara uttalad: från och med vilket datum, till och med vilket, och om dagens ofullständiga dygn räknas med. ”Senaste veckan” kan betyda de sju senaste dygnen eller den senaste kalenderveckan. Välj en och skriv den. För att kunna prova behöver diagrammet dessutom gå att ställa på en bestämd vecka, inte bara på ”nu”.
Dygnsgränsen beror på vilken tidszon räkningen görs i. PostgreSQL:s dokumentation om datum- och tidsfunktioner beskriver att date_trunc avrundar nedåt en tidpunkt med tidszon till midnatt i en viss zon, som standard sessionens tidszonsinställning, och att frågan kan ange en annan zon. Samma sida definierar ISO-veckor som veckor som börjar på måndag. Det betyder inte att just din app räknar så; det betyder att det går att beställa.
Visningen är ett eget lager. MDN:s sida om Intl.DateTimeFormat visar hur samma tidpunkt, 03:00 UTC den 20 december 2012, blir kl. 19:00 den 19 december när den formateras för Los Angeles. Utan angiven tidszon används körmiljöns standard. Be därför om Europe/Stockholm både när dygnen räknas och när datum visas. Hur datum skrivs på svenska hör till artikeln om svenska i appen.
Kopiera beställningen och byt ut postens namn
Texten är ett exempel. Byggaren kan välja ett annat diagrambibliotek eller en annan lösning än du väntar dig, och resultatet avgörs av provet, inte av prompten. Be om planen i ord innan något byggs.
Lägg till en dashboard som visar antal [bokningar] per dag som stapeldiagram och en summa för perioden. Ändra inget annat. Period: jag väljer en kalendervecka, måndag till och med söndag. Visa veckonummer och datum, till exempel "Vecka 45, 2–8 nov 2026". Förvalt är innevarande vecka. Tomma dagar: visa alla sju dagar i perioden, även de utan poster. En dag utan poster ska visas som 0, inte utelämnas. Veckostart: veckan börjar på måndag (ISO-vecka). Tidszon: räkna dygnsgränser i Europe/Stockholm, även när databasen eller webbläsaren använder en annan tidszon. Visa datum och klockslag i Europe/Stockholm. Behörighet: varje inloggad användare ser bara sina egna [bokningar] i diagram och summa. Kontrollen ska göras i databasen, inte bara genom att gömma rader i gränssnittet. Utloggad ska dashboarden inte visa några siffror. Visa vid sidan av diagrammet en tabell med dag och antal, så att jag kan läsa av exakta värden. Beskriv planen utan kod innan du bygger.
Kravet att kontrollen ska ligga i databasen hänger ihop med hur backenden är byggd. Lovable beskriver sin inbyggda backend, Cloud, som byggd på Supabases öppna grund. I Supabases dokumentation om radnivåsäkerhet beskrivs en regel som ett villkor som databasen lägger till på varje fråga, till exempel att en användare bara läser rader med sitt eget användar-id. Hur du granskar sådana regler står i guiden om behörigheter i Lovable.
Lägg in fyra testposter med känt facit
Använd två testkonton, A och B, och påhittade poster. Exemplet använder vecka 45, måndag 2 till söndag 8 november 2026. Den ligger efter sommartidens slut, så svensk tid är hela veckan en timme före UTC. Be byggaren skapa posterna med exakt de här tidpunkterna i svensk tid och läsa tillbaka dem innan du provar.
| Post | Konto | Tidpunkt, svensk tid | Vad den prövar |
|---|---|---|---|
| P1 | A | Söndag 1 nov kl. 23:40 | Veckostart: tillhör vecka 44 och ska inte räknas. |
| P2 | A | Måndag 2 nov kl. 00:20 | Tidszon: är 23:20 UTC på söndagen. |
| P3 | A | Onsdag 4 nov kl. 00:10 | Tidszon och tom dag: är 23:10 UTC på tisdagen. |
| B1 | B | Torsdag 5 nov kl. 12:00 | Behörighet: ska bara synas för B. |
Inloggad som A ska tabellen bredvid diagrammet visa måndag 1, tisdag 0, onsdag 1 och 0 för torsdag till söndag. Summan är 2. Inloggad som B ska torsdag visa 1 och summan vara 1. Det här är redaktionella provdata, inte resultat från en körd app.
Läs av diagrammet mot facit
Varje avvikelse pekar på ett bestämt fel, så skriv ned vad du ser innan du ber om rättning:
- Tisdag saknas eller axeln har färre än sju dagar: tomma dagar utelämnas.
- Måndag 0 och tisdag 1: dygnen räknas i UTC. P2 har hamnat på söndagen, utanför veckan, och P3 på tisdagen.
- Summan är 3 eller axeln börjar på söndag 1 nov: veckan börjar på söndag, och P1 räknas in.
- Torsdag visar 1 för A: B:s post räknas med. Det är ett behörighetsfel, inte ett diagramfel.
Rätta ett fel i taget och gör om hela provet efteråt. En rättningsbeställning kan lyda: ”P2 har tidpunkten måndag 2 nov kl. 00:20 svensk tid men räknas på söndag. Räkna dygn i Europe/Stockholm. Ändra inget annat.”
Byt också till vecka 44 som A. Där ska söndagen visa 1, bara P1. Visar den 2 har P2 flyttats dit av tidszonen. Logga sedan ut och öppna dashboardens adress direkt. Utloggad ska du inte se några siffror alls.
Vad ett godkänt prov visar
Godkänt betyder att den här veckan, de här posterna och de här två kontona gav facit. Provet säger inget om sommartid, där skillnaden mot UTC är två timmar, och inte om hur appen räknar när någon ändrar en posts datum i efterhand. Gör om provet med en vecka i juli om appen används runt midnatt även på sommaren.
Att B:s post inte syns för A i appens vanliga vy är ett funktionsprov, inte en säkerhetsgranskning. Det visar inte vad någon kan hämta direkt från databasen. Den kontrollen hör till behörighetsguiden. Spara datum, testkonton, observerade värden och avvikelser tillsammans med facit.
FAQ
Varför syns inte dagar utan poster i diagrammet?
Räknar frågan bara de dagar som har poster finns det ingen rad för en tom dag. Beställ att alla dagar i perioden visas och att en dag utan poster visas som 0.
Vilken tidszon ska en svensk app räkna dygn i?
Beställ Europe/Stockholm både när dygnen räknas och när datum visas. En post kl. 00:20 svensk tid är annars 23:20 UTC under vintertid och kan hamna på föregående dag.
Börjar veckan på måndag i diagrammet?
Det ska du inte räkna med. Skriv måndag i beställningen och prova med en post sent på söndagskvällen, som ska hamna i den föregående veckan.
Bevisar provet att andra inte kan se mina siffror?
Nej. Provet visar att ett andra kontos post inte syns i ditt diagram i appens vanliga vy. Det är ett funktionsprov, inte en säkerhetsgranskning.
Källor
Primärkällor kontrollerade 1 nov 2026. Beställning, provdata och facit är redaktionella exempel.
- Lovable: Cloud, den inbyggda backenden och dess grund i Supabase, i avsnittet om beställningen.
- Supabase: Row Level Security, regler som villkor på varje fråga, i avsnittet om beställningen.
- PostgreSQL: datum- och tidsfunktioner, date_trunc med tidszon och ISO-veckor som börjar på måndag.
- MDN: Intl.DateTimeFormat, samma tidpunkt som olika kalenderdag beroende på tidszon.