Ändringshistorik i appen: se vem som ändrade vad

Skilj posthistorik från två andra sorters historik

Anta att du bygger en app för påhittade uppdrag. Posten DEMO-17 har status ”Planerad”. Senare står det ”Klar”, men ingen vet vem som ändrade den. Att rätt status finns kvar efter omladdning besvarar en fråga om sparande. Det besvarar inte frågan om vem som gjorde ändringen. Börja med autospara i appen om själva sparbekräftelsen ännu är oklar.

Håll isär tre frågor i beställningen. Posthistoriken handlar om verksamhetsdata: exempelvis statusen i DEMO-17. Byggverktygets kodversioner handlar om hur appen byggts och ändrats. Inloggningshistoriken handlar om åtkomst till konton. Be verktyget visa vilken av dessa frågor dess föreslagna historik faktiskt besvarar. Ett versionsnamn eller en lyckad inloggning räcker inte som facit för en ändrad uppdragsstatus.

Som konkret källkontroll beskriver Supabase Auth Audit Logs autentiseringshändelser, exempelvis inloggningar och lösenordsändringar. Supabase Platform Audit Logs beskriver organisationsmedlemmars plattformsåtgärder, exempelvis ändrade projektinställningar. Av dessa två dokumentationssidor följer inte att din apps uppdrag automatiskt får före- och eftervärden. Här beställer du därför posthistoriken separat och provar vad som faktiskt visas.

Välj en posttyp och två fält först

Börja med uppdrag och fälten Status och Prioritet. Be om en knapp ”Historik” på varje uppdrag och en vy där postens namn och id står kvar över listan. Då kan du upptäcka om en rad råkat hamna på fel uppdrag. Beställ nyaste ändringen överst och en uttrycklig tomtext: ”Inga registrerade ändringar”. Tomtexten ska inte lova att posten aldrig har ändrats före den tidpunkt då funktionen började användas.

Bestäm även hur tid visas. I provet använder du datum, klockslag med sekunder och namngiven tidszon. Ett ensamt ”nyss” gör två testhändelser svåra att jämföra. Be verktyget beskriva varifrån tiden och aktören hämtas. Aktören ska vara kontot som genomförde ändringen, inte personen som just nu tittar på listan eller ett namn som skrivits i ett vanligt textfält.

Kopiera funktionsbeställningen

Byt hakparenteserna till dina egna begrepp. Texten är ett förslag till acceptanskrav, inte en beskrivning av en färdig standardfunktion. Be verktyget redovisa vad som saknas om det bara kan göra en visuell prototyp. Lägg inte in riktiga kunduppgifter för att fylla en sådan prototyp med innehåll.

Bygg en historikvy för [uppdrag], först för fälten [Status och Prioritet].
Visa postens namn och stabila id, samt nyaste bekräftade ändringen överst.
Varje ändring ska visa det inloggade konto som genomförde den,
fältets namn, tidigare värde, nytt värde, datum och tid med tidszon.
Identiteten ska hämtas från den genomförda ändringen och får inte kunna
väljas fritt i formuläret. Behåll samma aktör när ett annat konto läser vyn.

En bekräftad ändring ska ge en historikhändelse för det ändrade fältet.
Att öppna posten eller spara samma värde ska inte ge en ny ändringsrad.
Ett avvisat försök ska inte visas som genomförd ändring. Om försök visas
separat måste de vara tydligt märkta som avvisade och hållas åtskilda.
Vid fel eller okänt utfall ska vyn visa detta, inte en falsk tom historik.
Historiken ska finnas kvar och ge samma facit efter omladdning.

Visa bara historik för den post som öppnats. Ge endast uttryckligen
behöriga konton tillgång till historiken. Prova historikläsning separat
från rätten att ändra posten. Den vanliga vyn ska sakna möjlighet att
redigera eller radera historikrader. Ta inte med hemligheter eller
andra fält än de två beställda. Visa tydlig tomtext när listan är tom.

Ordna provet i testmiljö med två syntetiska konton: Test-Alva och Test-Bo.
Låt båda först ändra och läsa historik för DEMO-17. Efter två lyckade
ändringar ska Test-Bo förlora ändringsrätten men behålla läsrätten.
Prova ett avvisat försök. Ta sedan bort Bos historikläsrätt separat,
behåll läsrätten till själva posten och prova även en direkt historiklänk.
Ingen riktig persondata får användas. Beskriv begränsningarna och visa
testutfallet. Återställning, kodversioner och juridisk revisionsgaranti
ingår inte i denna beställning. Ändra inget annat i appen.

Prov 1: två konton gör var sin ändring

Använd en testmiljö och två separata inloggade sessioner, så att du kan se vilket konto varje fönster använder. Skapa DEMO-17 med Status ”Planerad” och Prioritet ”Normal” som testets startläge. Anteckna befintliga historikrader innan du börjar; skapandet av posten ingår inte i de två ändringar som nu ska räknas. Både Test-Alva och Test-Bo ska till en början få ändra posten och läsa dess historik.

Låt Test-Alva byta Status från ”Planerad” till ”Pågår”. Vänta på bekräftad sparning och kontrollera raden. Öppna sedan den uppdaterade posten som Test-Bo och byt Prioritet från ”Normal” till ”Hög”. Vänta på bekräftelsen igen. Läs historiken från båda kontona och efter omladdning. Du ska få samma två nya händelser med rätt aktörer, även när den som läser är någon annan.

Tabellen är ett konstruerat facit för den 24 oktober 2026 i tidszonen Europe/Stockholm. Dina verkliga testtider ska motsvara när du genomför provet. Detta är inte ett redovisat resultat från en provkörd app.

Kontrollera också att Status fortfarande är ”Pågår” och Prioritet ”Hög” i själva posten. Öppna en annan testpost och se att dessa händelser inte följer med dit. Spara sedan DEMO-17 utan att ändra något. Antalet nya ändringshändelser ska fortfarande vara två. En extra rad för oförändrat värde klarar inte den beställning du nyss gjorde.

Prov 2: ett avvisat försök ändrar inte historiken

Ta bort Test-Bos rätt att ändra DEMO-17 i testmiljön, men behåll rätten att läsa posten och historiken. Be verktyget ordna ett kontrollerat avvisat ändringsförsök om gränssnittet döljer redigeringsknappen. Att knappen är borta visar inte i sig att ett försök avvisas. Låt Bo försöka byta Status från ”Pågår” till ”Klar” och dokumentera felbeskedet.

Facit är att posten fortfarande har Status ”Pågår”, att de två lyckade ändringarna finns kvar och att ingen ny genomförd ändring till ”Klar” syns. Kontrollera från Alvas session efter omladdning också. Om appen visar avvisade försök i en separat lista får försöket stå där som avvisat, men det får inte räknas som en genomförd dataändring. En säkerhetsnotering och en ändrad uppdragsstatus har olika betydelse för läsaren.

Prov 3: läsbehörighet är en egen kontroll

Låt Test-Bo behålla läsrätten till uppdraget men ta bort rätten att läsa dess historik. Öppna historiken som Bo, även med en tidigare kopierad direktlänk, och ladda om. Facit är nekad åtkomst utan att aktörer eller gamla fältvärden visas. Kontrollera samtidigt att Test-Alva fortfarande kan läsa de två händelserna. Om din app inte kan skilja dessa rättigheter åt ska verktyget redovisa det som en kvarstående begränsning.

Provet behövs eftersom historikvyn i din beställning innehåller tidigare värden, inte bara postens aktuella innehåll. Börja därför med de två valda fälten. En fritextanteckning som senare tagits bort ska inte oavsiktligt exponeras genom en utökad historikvy. Bestäm vilka fält och roller som ska omfattas innan du beställer fler posttyper.

Skriv ett litet protokoll före godkännande

Anteckna testmiljö, datum, testkonton, roller före varje steg, postens id, förväntade och faktiska värden samt skärmbilder med enbart syntetiskt innehåll. Markera varje prov som godkänt, underkänt eller inte genomfört. Ett saknat behörighetsprov är inte ett godkänt prov. Vid fel anger du vilken rad som saknas, är extra eller har fel aktör och vilket konto som läste den.

Godkänn den här avgränsade funktionen när de två ändringarna får rätt aktör och före-/eftervärde, det avvisade försöket hålls utanför genomförda ändringar och läsbehörigheten fungerar separat. Att standardvyn saknar redigering av historiken visar bara det gränssnittets beteende. Det är inget belägg för manipulationssäkerhet eller juridisk revisionsduglighet. Vill du kunna ångra en ändring behöver du en egen beställning; läs återställ appen från backup för återställningsbehovet.

Källor och avgränsning

Primärkällorna kontrollerades 24 oktober 2026. De används i avsnittet om tre historiker för att avgränsa dokumenterade loggtyper. Beställningen och provfaciten är redaktionella förslag; ingen backendlösning eller genomförd appkontroll redovisas.

• Supabase: Auth Audit Logs – autentiseringshändelser.
• Supabase: Platform Audit Logs – organisationens plattformsåtgärder.