Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Indholdsfortegnelse

fgrænsning af epic

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne (links i listen virker kun med STAR Jira konto):

Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)

Beskrivelse af epic

OBS! Denne epic fortsætter arbejdet fra 971.29. Der er pt. samme epic acceptkriterier, men det skal ryddes op, når 971.29 er afsluttet. 

971.37.2 Krav til sletning implementeres

Sletninger som specificeret i epic 971.36 er implementerede i VITAS.

STAR ønsker at implementere en generel slettefrist på 10 år på alle ordninger i VITAS. Dvs. ansøgninger, bevillinger, forlængelser, ophør, bilag mv. skal slettes med en slettefrist på 10 år.

Sletning skal gennemføres med en "forløb" som enhed for sletning. Dvs. samhørende ansøgninger, bevillinger, tillægsbevillinger, forlængelser, ophør, bilag mv. på ét sagsnummer (ID) slettes samlet og samtidig med tillægsbevillinger, der er knyttet til forløbet. Bevillinger og tilhørende tillægsbevillinger slettes altid samtidig ifm. sletning jf. slettefrist.

Slettefristen på 10 år er defineret i forhold til den seneste forretningsmæssige hændelse på forløbet, dvs. på ét af elementerne på sagsnummeret. Forretningsmæssige hændelser er:

• Indsendelse af ansøgning, forlængelse, ophør
• Godkendelse af ansøgning, forlængelse, ophør 
• Send bevilling, forlængelse, ophør til arbejdsgiver
• Godkendelse af ansøgning, bevilling, forlængelse, ophør
• Aktuel slutdato for bevillingsperiode (defineret af seneste bevilling, forlængelse, ophør)
• Personlig assistance eller hjælpemidler, som er permanente, slettes 10 år efter afgørelsesdatoen (Afventer endelig STAR beslutning)
• Ovenstående kriterier gælder også for tillægsbevillinger og seneste forretningsmæssige hændelser på en tillægsbevilling indregnes i seneste forretningsmæssige hændelser på den sag, som tillægsbevillingen tilhører.

Tekniske hændelser på et forløb, fx. ifm. konvertering ifm. ændring af datamodel, påvirker ikke slettefrister.

De forretningsmæssige krav er omsat til tekniske krav på databaseniveau jf. VIR-2429:

971.37 VITAS - GDPR sletninger 2021-4 - tekniske acceptkriterier

Arkitektoniske krav til implementering af sletning

Der skal udarbejdes en dokumenteret arkitektur for en "slettemotor" inden implementering af sletninger påbegyndes for at sikre, at "slettemotoren" får de ønskede egenskaber:

1. Sletninger skal kunne implementeres ensartet på tværs af ordningerne, selv om hver ordning har sine egne tekniske acceptkriterier
2. Sletningerne skal kunne implementeres omkostningseffektivt
3. Sletningerne skal kunne vedligeholdes omkostningseffektivt ifm. arkitekturomlægninger
4. Slettereglerne i programkoden, herunder SQL, skal være let forstålige af hensyn til vedligeholdelse
5. Slettemotoren skal understøtte en simuleringstilstand, hvor sager, der skal slettes, udtrækkes, men uden af de reelt slettes
6. Sletningerne skal understøttes af automatiserede tests, som kan afsløre evt. fejl ifm. arkitekturændringer i VITAS

Arkitekturen dokumenteres på denne side: /wiki/spaces/CITY/pages/3208740944

971.37.3 BI og VOA er orienterede om sletninger, da BI og VOA kan blive påvirket

BI og VOA skal kunne se hvilke sager, der er slettede for at de også kan slette de samme sager. Implementeres med tabel jf. 971.37.4.

971.37.4 VITAS indeholder en liste med sagsnumre, der er slettede

En forudsætning for krav 971.37.5.

971.37.5 Ved aktivering af deep-links til slettede sager (ansøgning, bevilling ...), får brugeren besked om at sagen er slettet

Ønske fra KSS.

971.37.7 En virksomhed har ikke adgang til ansøgninger og bevillinger, som ikke længere er relevante for virksomheden

Virksomheder må ikke kunne få adgang til ansøgninger, bevillinger, forlængelser og ophør, som ikke længere er relevante for virksomheden.

1. En virksomheder må ikke få adgang til sin ansøgning, når der er gået mere end 3 siden ansøgningen blev afvist.
2. En virksomheder må ikke få adgang til sin ansøgning, når der er gået mere end 3 siden tilbud vedr. ansøgningen blev lukket
3. Når der er gået mere end 3 siden en bevilling blev lukket, må virksomheden ikke længere kunne få adgang til bevillingen eller til den ansøgning, ophør eller de forlængelser, der er knyttet til bevillingen.

Gælder også deep link.

971.37.8 Der sendes WSRM, når en sag slettes - UDGÅET

KSS modtager WSRM ved sletning for at KSS kan foretage evt. konsekvensrettelser i deres data. 

VITAS kalder DFDGs VitasNotificationService.SendCaseNotification for at få dannet en WSRM, når en sag slettes - uanset om det er gamle ordninger (som ellers anvender fede WSRM'er) eller nye ordninger (som i forvejen anvender VitasNotificationService.SendCaseNotification). DFDG danner på den baggrund WsrmMessageService (Version 11).GetVitasCaseNotificationVersion1 som KSS aftager.

Når ansøgninger slettes er JobAllocationStatusTypeIdentifier = 9 (jf. 971.37.10)

Når bevillinger slettes er JobAllocationStatusTypeIdentifier = 14  (jf. 971.37.10).

Når VITAS anvender disse værdier ift. DFDG, for at få dannet slette WSRM'er, vil DFDG skåne/frafiltrere disse således, at KSS ikke modtager VitasNotificationService.SendCaseNotification med de nye id'er, men i stedet GDPR-slette-WSRM'er, der følger det nye/aftalte mønster for slette wsrm-erUdgået pga. indsigelser fra KSS. Der implementeres i stedet en anden WSRM-løsning i epic 971.50 i 2022-2.

BEMÆRK: Sagerne slettes først efter 10 år, så der vil gå 3 år før de første sager slettes og der sendes WSRM'er til KSS.

971.37.9 Jobcentre kan selv slette inaktive brugere 

Der tilføjes en ekstra kolonne med "Sidste log in", så jobcentret får mulighed for selv af slette brugere samt teams før de 12 måneder er gået, og VITAS automatisk sletter inaktive brugere. (Ønske fra Jeanette Gade Olesen/Københavns kommune på  mail 16/6-21 jf. udmelding om sletning på 6-by møde)

971.37.10 Der er nye kodeværdier for sletning jf. slettefrist i kodelisterne JobAllocationStatusTypeIdentifier og JobOfferStatusTypeIdentifier

JobOfferStatusTypeIdentifier

Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:

Særlige krav til test

* Batchjobs

• bør testes både med delta og fuldt load,
• bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden
• bør testes i samarbejde med teams som har afhængigheder
• kørselstid, særligt hvis det er en del af NightlyBatch

Konsekvenser for drift/idriftsættelse

I forbindelse med idriftsættelse:

• Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres
• skal der køres konvertering
• Skal der køres databasescripts for opdatering af tabeller i databasen

Efter idriftsættelse:

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder
• Nye snitflader
• Nye komponenter
• Nye miljøer
• Nye teknologier
• Nye aftagertyper
• Eller afvigelser fra principperne
• Eventuelle behov for reduktion af teknisk gæld skal afdækkes

Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.