Detaljerad kravspecifikation
Skoladmin > Organisation >
Radera användare med skyddad identitet
Rubriken ska vara funktionens namn på svenska, med område och gruppering enligt roadmap. Ange sedan här nedan funktionens namn på engelska samt ev. övriga kommentarer kring funktionens namn.
Funktionens namn på engelska: Delete user with protected identity
Bakgrund och syfte
Syfte: Möjliggöra för organisationsadministratörer att radera Vklass-konton som har skapats baserat på aliasuppgifter för personer med skyddad identitet, i syfte att minimera åtkomsten till känsliga personuppgifter.
Behov: Grundskoleförvaltningen i Göteborg ger personer med skyddad identitet ett konto i Vklass baserat på aliasuppgifter. Beslutet att radera konton med skyddade uppgifter är för att minimera åtkomsten till dessa personuppgifter.
Vklass rekommendation: Vklass rekommenderar principiellt att inga personer med skyddad identitet ska finnas i något datasystem, varken i elevregistret eller Vklass.
Alternativ: Trots rekommendationen finns det i nuläget vissa alternativ för att hantera konton med skyddad identitet i Vklass, eftersom hanteringen kan variera från fall till fall.
Roller, skolformer och andra access-regler
Skolformer och roller som berörs av funktionen
Ange vilka kombinationer av användarroller och skolformer som på något sätt är inblandade i att ta del av funktionen eller funktionens data.
| Skolform | Personal | Elev/Barn | Vårdnadshavare | Administratör (org-admin) |
|---|---|---|---|---|
| Förskola | Nej | Nej | Nej | Ja |
| Grundskola | Nej | Nej | Nej | Ja |
| Fritidshem | Nej | Nej | Nej | Ja |
| Gymnasium | Nej | Nej | Nej | Ja |
Noteringar
Samtliga skolformer - Orgadmin
Orgadmin har åtkomst till funktionen radera användare med skyddad identitet.
Organisationsadministratör (Org.admin) är den enda rollen som ska ha åtkomst till denna funktionalitet.
Vad skiljer funktionen åt mellan skolformer och roller
Här beskriver man vad som skiljer funktionen åt i olika skolformer. Te.x. om förskolan och fritidshem hanteras på något annat sätt eller om benämningar ska skilja mellan skolformer. Om elev, vårdnadshavare och personal har olika vyer med olika innehåll ska detta också nämnas här och sedan beskrivas mer i detalj under respektive User Story under “Funktioner” nedan.
Vad gör att funktionen finns tillgänglig i Vklass (utöver skolform och roll)?
Här ska det framgå om det finns särskilda regler som gör att funktionen visas/inte visas pga andra skäl än skolform och användarens roll. Det kan t.ex. vara konfiguration per skola etc.
Funktionen är enbart synlig för org-admin.
Funktionen ska implementeras i Vklass Adminverktyg.
Specifikation funktionalitet
Under denna rubrik och dess underrubriker ska allt kring funktionens funktionalitet specas.
Vilka entiteter?
Här beskriver man vilka entiteter som funktionen hanterar. Se denna checklista; https://vklass.slack.com/files/T034X2QPY/F01EP84AYRX.
Tänk på att ange fält-namn både på svenska och engelska. Om entiteten är elev kan det t.ex. se ut så här:
Elev / Student
En elev består av
Förnamn / First name
Efternamn / Last name
Användarkonto / Useraccount
(dbo.Vklass.Users)
Inklusive all data med kopplingar till användarkontot.
Entitetens fält (Ett X består av:)
Här beskriver man med en punktlista vilka fält/värden som lagras på entiteten samt vilka ev. andra entiteter som kan vara kopplade till entiten. (T.ex. är ett omdöme alltid kopplat till en student och en kurs.)
Fält / Field
Entitetens domänlogik
Här kan med med korta meningar i en punktlista förtydliga vad olika värden på entiteten får för följder/konsekvenser.
Navigation
Hur ska man nå funktionen?
Navigation 1: Organisationsadmin navigerar till funktionen genom vänstermeny och alternativet Skoladmin -> Användare -> Redigera elev
Navigation 2: Organisationsadmin navigerar till funktionen genom vänstermeny och alternativet Skoladmin -> Underhåll -> Hantera användare med skyddad identitet
Navigation 3: V2 Vklass Admin -> Användare -> Hantera användare med skyddad identitet
Funktioner (Use cases/User Stories)
[01] Användare orgadmin kan radera användare med skyddad identiet
Orgadmin kan radera ett specifikt användarkonto för användare med skyddad identitet i enlighet med gällande dataskyddsprinciper (GDPR).
All data som är kopplad till det raderade användarkontot ska raderas.
Alla raderings- och sammanslagningsåtgärder måste loggas med information om:
Tidpunkt för åtgärden.
Vilken Org.admin som utförde åtgärden.
Vilket konto/vilka konton som berördes.
Varningsinformation ska presenteras för Org.admin som tydliggör Vklass ståndpunkt att inga personer med skyddad identitet principiellt ska finnas i Vklass eller dess underliggande system.
- Administratören måste aktivt bekräfta att de har läst och förstått konsekvenserna av raderingen/sammanslagningen.
| Användarkonto | Skolkoppling | Klasskoppling |
|---|---|---|
| Personens fullständiga namn och personnummer | Skolans namn | Klassens namn |
[02] Användare med aliaskonto ska synkroniseras in från elevadministrativt system.
Efter radering av användarkonto med skyddad identitet ska ett nytt aliaskonto synkroniseras in från elevadministrativt system.
[03] Sammanslagning av konton
Funktionen ska inkludera möjlighet till sammanslagning av konton. Om en person med skyddad identitet senare får skyddet upphävt och ett nytt konto baserat på den riktiga identiteten skapas i Vklass, ska org-admin kunna slå ihop det nya kontot med det befintliga aliaskontot.
Säkerställ att all historisk data från aliaskontot överförs till det nya kontot med riktig identitet
Alla raderings- och sammanslagningsåtgärder måste loggas med information om:
Tidpunkt för åtgärden.
Vilken Org.admin som utförde åtgärden.
Vilket konto/vilka konton som berördes.
Varningsinformation ska presenteras för Org.admin som tydliggör Vklass ståndpunkt att inga personer med skyddad identitet principiellt ska finnas i Vklass eller dess underliggande system.
- Administratören måste aktivt bekräfta att de har läst och förstått konsekvenserna av raderingen/sammanslagningen.
| Nytt konto | Aliaskonto | Skolkoppling |
|---|---|---|
| Personens fullständiga namn och personnummer | Personens fullständiga namn och personnummer | Skolans namn |
Design
Länkar till bilder, med kortfattad beskrivning.
- [Skriv din text här med detta textformat.]
Vanlig text innan specialstycke
Ett textstycke kan ha text-formatet “Heading 6” för att sticka ut på detta sätt från den övriga textmassan. Det ska inte vara några extra tomrader före och efter.
Vanlig text efter specialstycke.
När utkast till spec finns
Ta ställning till om specen ska gås igenom med någon i utvecklingsteamet. Ta eventuellt upp denna frågan i PSO för gemensamt beslut.
Skicka i så fall specen till denna person och bjud in till arbetsmöte där specen bearbetas. Utkomsten av detta kan t.ex. vara men är inte begränsat till - Tekniska medskick - Prestandabegränsningar - Ev. splittning av User Stories - I vilken ordning bör saker utvecklas -> ordning på User Stories
Därefter kan specen gå till PSO för beslut.
Medskick till steg 4 inför “teknisk spec” (utvecklarna)
Under arbetets gång med detta dokument kommer flera personer vara inblandade, troligen även en eller flera utvecklare. För att inte tappa bort saker längs vägen kan denna del fyllas på med punkter som någon utvecklare snappar upp och som de kommer behöva diskutera med övriga utvecklare/systemarkitekt etc innan den faktiska implementationen påbörjas.
Se https://drive.google.com/file/d/1sNhtAcjl_DUJRHOJ8jsv-ApQkoX4Fq4y/view?usp=sharing, steg 3B
- [Skriv din text här med detta textformat.]
DSO:s återkoppling till PSO
- [Skriv din text här med detta textformat.]