752.9 752.9 Min plan - Integrationskontrakt på Jobnet
Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
(Skabelon af dato 17/12-2015)

Indholdsfortegnelse
1 Ændringslog
2 Afgrænsning af epic
3 Oversigt over berørte web services
4 Beskrivelse af epic
5 Særlige krav til test
6 Kendte udeståender fra udviklingsfasen
7 User stories
7.1.1 Spike af overgang til PSS v19 CPR. (US 1887)
7.1.2 Integrationskontrakt i GUI på dummy data (US 1888)
7.1.3 Spike omkring faneblade (US 1914)
7.1.4 Løft til PSS version 19 (US 1966)
7.1.5 Mapping af services mod viewmodel (US 2070)
7.1.6 Opgradering tuil PSS version 20 (US 2235)

Ændringslog

Afgrænsning af epic

Oversigt over berørte web services

Beskrivelse af epic

Acceptkriterie 752.9.1 – serviceløft

Borgere med integrationskontrakt skal i Jobnet kunne se denne, på et særskilt faneblad under "Min Plan". Faneblad skal kun fremkomme for borgere med integrationsplan. Data fra integrationsplan ligger til dels i PSS servicen, som i den anledning skal løftes til version 19 (og siden til version 20 viste det sig ved implementering, da PSS19 alligevel ikke var tilstrækkelig).
Ved løftet ønskes metoden der pt. anvendes af jobnet (GetVariablePersonStatusCV) erstattes af metoden GetVariablePersonStatus. Dette fordi GetVariablePersonStatus allerede indeholder de nødvendige informationer (som GetVariablePersonStatusCV ellers skulle udvides med) og Jobnet derfor tidligt i release kan påbegynde løft. Men også fordi GetVariablePersonStatusCV metoden, når den ikke længere kaldes af Jobnet, kan fases ud i kommende versioner af PSS.

Acceptkriterie 752.9.2 Integrationsfaneblad på Min plan

Jobnet rettes til, så borgers eventuelle integrationsplan fremgår som et særskilt faneblad til højre for Min Plan.
Responsiviseringen af integrationsfanebladet hører under denne epic, i kraft af, at integrationsfanebladet er nyudvikling og nyudvikling skal være responsiv. Responsivisering af "Min plan" i øvrigt falder ind under epic 752.2.

Særlige krav til test

Kendte udeståender fra udviklingsfasen

Link til søgeresultat fra FogBugz på epic-nummer:

User stories

Link til regneark, hvor alle felter fremgår: https://dokumentationsarkiv.star.dk/STAR%20Epic%20Bibliotek/752.4%20Bilag%201%20Letasyl-DFDG%20%20mapning%20af%20snitflader.xlsx
Regnearket er master og altid opdateret. Mockups er til inspiration og opdateres ikke nødvendigvis med alle afklaringer.
Link til mockup af jobnet: http://enuxgk.axshare.com/#g=1&p=min_plan_m_integration_-_foldet_sammen

Spike af overgang til PSS v19 CPR. (US 1887)

"Som FA ønsker jeg spiket om PSS CPR V19 upgrade skal ske globalt i JN eller kun lokalt ved integrationskontrakt"
Jobnet gør brug af metoden PSSVariableCV version 18. Logisk vil en opgradering til version 19 af samme metode derfor være at foretrække. Dataservice ønsker dog, at vi overgår til PSSVariableCPR – da det er dyrt og skaber dobbelt vedligehold at have services rettet mod Jobnet, fremfor at Jobnet blot aftager samme service som KSS'er med flere. I CV metoden indgår de nye komponenter der skal bruges heller ikke. I PSSVariableCPR v. 19 indgår allerede de felter og collectioner, som Jobnet skal bruge i relation til Integrationskontrakten. Skal de fremgå af PSSVariableCV, skal Dataservice arbejde for at udstille dem og så er service ikke klar til løft. PSScpr udstiller dog markant flere oplysninger end PSScv. Det er en partialservice, så Jobnet kan nøjes med at trække på de collectioner der er brug for. Det interessante er dog, om der er forskel i struktur på de collectioner og værdier der trækkes på, i forhold til struktur på PSSCV? I spike bedes vurderet, om vi med fordel kan opgradere til PSScv, med fokus på om ændringer er få. Er det blot inputparameter CV der skal erstattes med CPR? Eller skal der arbejdes med output også?
Endelig bedes vurderet, om det bedste alternativ er at opgradere fra PSScv v. 18 til v. 19 og derefter som lokal håndtering - og kun i relation til integrationskontrakten - tillige at implementere PSScpr ind.
Bemærk: Resultat af spike er indsat i Jira på US 1887

Integrationskontrakt i GUI på dummy data (US 1888)

"Som PO ønsker jeg integrationskontraktens 6 containere udarbejdet i GUI jf. wireframe og mappet til view model."
Acceptkriterier:

• Et fanebladsystem laves på den eksisterende side for Min Plan jf. spike US 1914.
  • Venstre faneblad, der er default, kaldes "PLAN"
  • Højre faneblad kaldes "INTEGRATION"

• På fanebladet "INTEGRATION"oprettes et foldeind/foldeud element, for hver af følgende 6 containere på integrationsoverblikket, jf. Wireframe

• • Stamdata
  • Personlige forhold
  • Supplerende kompetencer og kvalifikationer
  • Helbredsmæssige forhold
  • Visitation
  • Fritagelser/særlige hensyn

• De 6 containere er default foldet ind.

• • Ved klik på element der er foldet ind, hvor pil peger nedad, folder element ud og pil peger opad.

• • Ved klik på udfoldet element, hvor pil peger opad, folder element ind og pil peger nedad.

• • Ved klik på dobbeltpilene på fanebladet:

• • • Klik på "2 pile ned" folder alle boksene ud. Ved klik på "2 pile op" foldes alle boksene ind.
  • De to Fold ind/fold Ud pile beholdes ved siden af "Gem som PDF" og "Vis PDF og udskriv", efter aftale med Helle Kierkegaard, d.5/7-17.

• Gui mappes til viewmodel, således at felterne kan vises udfyldt med dummy data.
• Containere og indhold skal fungere responsivt i understøttede breakpoints, jf. wireframe.
• Felterne er "read only" og størrelsesmæssigt skal de tilpasse sig den tekst der indlæses.
• Er der ingen data til felterne i en container, skal container ikke vises.
• Er der ingen data til et felt i en container, skal hverken felt eller feltets label vises.
• Særligt for container "Stamdata": Linket til Integrationserklæring hardkodes til http://uim.dk/arbejdsomrader/Integration/integrationskontrakt-og-integrationserklaering og åbnes ved klik i en ny fane. Hint: Skulle link ændre sig, har UIM jf aftale med PO påtaget sig pligt at lave redirect.
  • Linket vises kun hvis mindst et af følgende felter har data, og dermed vises.

• Særligt for container "Supplerende kompetencer og kvalifikationer" gælder at teksten:

"Øvrige CV-oplysninger fremgår af CV'et på Jobnet.dk. På PDF-versionen af 'Min plan - Integrationskontrakt' vises CV-oplysningerne desuden til sidst i dokumentet."
skal fremgå af grønt element, der vises efter klik på I-ikon.

• Linket "Gå til CV", der placeres jf. wireframe, fører til borgers "Mit CV", dvs. stien "CV/Jobseeking/CV", vist i samme tab og uden returlink.

• For hvert sprog i collection laves en "dividerlinje" under hvilken elementerne om borgers sproglige færdigheder udfyldes:

• Særligt omkring container "Fritagelser/særlige hensyn": Borger kan have mange typer fravær, men kun følgende to skal – såfremt borger har det ene eller begge - kunne slå igennem i integrationsoverblikket:
  • 68: Fritaget for danskuddannelse
  • 69: Fritaget for tilbud under integrationsprogrammet (helt/delvist)
  • Disse to fravær skal kun optræde, hvis fraværets slutdato er lig med eller større end dags dato for visningen af siden
• Ved klik på link "Se alle fravær" ledes borger i samme vindue/tab over til oversigten over borgers aktuelle fravær.

Spike omkring faneblade (US 1914)

"Som FA ønsker jeg en spike på tværs af Skynet og Cyberdyne, som POC for, at fanebladene anvendt i relation til 'Kvalifikationer' under CV, kan anvendes i kontekst af Min Plan/Integrationskontrakt (desktop og responsivt)"
Formål:
Med udgangspunkt i det eksisterende fanebladselement anvendt i "Kvalifikationer" på CV, oprettes på Min Plan to fanebladselementer, i hvilke containerne fra Min Plan smides ind. Det afklares hvorvidt fanebladene kan anvendes fra Desktop til small breakpoint og det dokumenteres til brug for PO's godkendelse, hvorledes det vil se ud i de forskellige breakpoints.
Konklusion efter spike: Faneblade kan anvendes og screenshots er fremsendt til Helle Kirkegaard, der har godkendt.

Løft til PSS version 19 (US 1966)

"Som Jobnet ønsker jeg løft til PSS v. 19 og GetVariablePersonStatusCV erstattet med GetVariablePersonStatus, for at kunne få adgang til felter der kræves jf. Integrationskontrakt."
Acceptkriterier:

• PSS løftes fra version 18 til version 19
• I jobnetkoden erstattes GetVariablePersonStatusCV med GetVariablePersonStatus
  • Dog bevares kald til GetVariablePersonStatusCV med kald af core ved logon, for at få adgang til borgers cpr-nummer.
• Felterne der skal bruges jf. integrationskontrakten mappes igennem til anvendelse, konkret:
  • Variablen TASS, der giver os abscense, hvor vi skal bruge Absence 68 og 69 i relation til borgers fravær, konkret "Fritaget for danskuddannelse:" og "Fritaget for tilbud under integrationsprogrammet (helt/delvist)"
  • Variablen CORE, der rummer oplysninger om "nationalitet" og "civilstand"
  • Visitationskategori
  • ID for integrationskontrakt Hint: Vi har talt om, at vi ved at se om der er et ID for integrationskontrakt kan se, om borger HAR en kontrakt – og dette kan derved være det styrende element for, om vi skal vise/skjule faneblad.

Til udviklere:
Bemærk: Carsten Olsen står til rådighed for os ved dette løft. På det dokumentationsgrundlag jeg har kunne finde, har jeg ikke kunne specificere det bedre. Men Carsten kan redegøre for hvilke felter der præcis skal hentes…
Som nævnt på møde om service med Neeraj og Carsten:

• I skal være opmærksomme på, at det er en CodeFirst service – det er v. 18 ikke.
• Omkring collectioner var der et issue omkring navngivning.
• Og så var der kodelister der nedarves.

Mapping af services mod viewmodel (US 2070)

"Som PO vil jeg have bundet JobnetMyPlanService og PSS op mod viewmodel, så Integrationsfaneblad viser virkelige data".
Acceptkriterier:

• Integrationsfaneblad, udarbejdet i US 1888, viser virkelige data.

Bemærkninger til udviklere:
Denne US forudsætter, at services er løftet jf. US 1966 (PSS) og US 2020 (JobnetMyPlanService) samt at US 1888 (Integrationsfaneblad i GUI) er implementeret.

Løft til PSS version 20 (US 2235)

"Som Jobnet ønsker jeg løft til PSS v. 20 for at kunne udfase brug af GetVariablePersonStatusCV."
Acceptkriterier:

• Jobnet kører på version 20 af PSS, hvor felterne:
  • MissedConfirmationWarning
  • MissedConfirmationWarningRemovalDate
  • HoursNeededToRegradeTypeIdentifier
  • HoursNeededMaxProlongationTypeIdentifier
  • HoursToPreventQualifyingTypeIdentifier

hentes fra metoden GetPersonStatus

• Kald til metoden GetPersonStatusCV sker ikke længere fra Jobnet.
• CPRnummer på jobnet fås fra den nye PSS metode: GetPersonCivilRegistrationIdentifier.
• Jobnet bærer CPRnummer i securitytoken til genbrug hvor CPR skal bruges, således at GetPersonCivilRegistrationIdentifier kun kaldes minimalt.
  • I det omfang jobnet har borgers CPRnummer via NEMid login, gemmes CPR i securitytoken og opslag til GetPersonCivilRegistrationIdentifier undgås.

Kommentar til udviklere: PSS version 19 rummer ikke alle felter i metoden GetPersonStatus som vi bruger i metoden GetPersonStatusCV. Jobnet gik ellers over på version 19, da den netop skulle være let at gå til, i det alle relevante felter skulle være tilgængelige for os der, på nær CPR, som vi fortsat skulle hente via GetPersonStatusCV.
For at sikre, at GetPersonStatusCV kan fases ud blev aftalt, at Dataservice beriger GetPersonStatus med de manglende felter og at de giver os særskilt metode på PSS, via hvilket jobnet på baggrund af medsendt CV nummer kan få borgers CPR.