778.1 CV for flygtninge og familiesammenførte
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
4.1.1 Model a
4.1.2 Model b (Pt ikke mere i spil)
4.1.3 Model d
4.1.4 Generelle regler for opdatering af asyl data
4.2 778.1.1 CV data fra Let Asyl skal overføres til DFDG og CV på Jobnet
4.2.1 Overordnet løsningsmodel
4.2.2 CVService (Version 6)
4.3 778.1.2 Borgers kontaktgrupper samt tillægsdata i form af overgivelsesdato og frist for CV opdateringer, der er relevante for sagsbehandler i Jobcenter, skal gemmes i DFDG
4.3.1 Overordnet løsningsmodel
4.3.2 CVService (Version 6)
4.3.3 PersonStatusService (Version 18)
4.3.4 LSS udstilling
4.4 778.1.3 Borger skal oprettes på Jobnet såfremt borger ikke findes på Jobnet
4.4.1 Overordnet løsningsmodel
4.5 778.1.4 Borger har et låst CV og må ikke kunne opdatere sit CV på Jobnet før fristen, sat af jobcentret, er nået
4.5.1 Overordnet løsningsmodel
4.5.2 JobnetCitizenStatusService (Version 7)
4.5.3 Jobnet implementering af Låst CV
4.6 778.1.5 Når borgers frist for CV opdateringer nås, skal brugeren have adgang til Jobnet, hvis borger ikke allerede har dette
4.6.1 Overordnet løsningsmodel
5 Særlige krav til test
6 Kendte udeståender fra udviklingsfasen
7 User stories
7.1 US-113: Spike: Analyser og blotlæg nødvendige valideringer ved oprettelse af CV.
7.2 US-114: Spike: Analyser problemstilling omkring oprettelse af CV, når borger ikke er oprettet
7.3 US 115: Som DFDG ønsker jeg afklaring om WSDL for metode til oprettelse af CV, med valideringer, og med afsæt i navngivning fra GetCV.
7.4 US 158: Som Jobnet vil jeg oprette valideringer i WSDL jf. US 113 og 115.
7.5 US 157: Som Jobnet vil jeg implementere metoden 'Opret CV' vertikalt, startende med collectionen 'Erhvervserfaring'
7.6 Løft af JCSS til version 8 (US 277)
7.7 Afblænding af CV på Jobnet, når CvEditingPossible er false (US 276)
7.8 QualificationCollection i UpdateJobnetProfile (US-391)
7.9 ProfessionalSummaryText i UpdateJobnetProfile (US-549)
7.10 PersonalData i UpdateJobnetProfile (US-550)

Ændringslog

Afgrænsning af epic

Oversigt over berørte web services

Beskrivelse af epic

Når asylansøgere kommer til Danmark bliver de modtaget af en asyloperatør, fx Røde Kors. I perioden, hvor asylansøgerens ansøgning om ophold i Danmark behandles, foretager asyloperatørerne en tidlig og foreløbig kompetenceafdækning af asylansøgerne. Hvis en asylansøger tildeles asyl overføres de til den kommune, de skal flytte til, som skal foretage den egentlige kompetenceafklaring.
Den tidlige kompetenceafdækning foretaget af asyloperatøren har ikke tidligere været garanteret at lande i modtager kommunen. Det har ført til dobbeltarbejde, da kommunen således er startet forfra med afklaring af asylanternes kompetencer.
Det er besluttet, at informationerne om den tidlige kompetenceafdækning skal ensrettes og digitaliseres, så informationer automatisk tilgår modtagerkommunen, så de ikke går tabt.
Asyloperatørerne indtaster kompetenceafdækningen i systemet Let Asyl, der så vidt muligt er blevet ensrettet med CV på Jobnet.
For løsningsmodeller se ISB 778 CV for flygtninge og familiesammenførte.
Bemærk at løsningsmodeller er flytte fra denne epic til ISB da de ikke er relevant for 17-1 leverancen.

778.1.1 CV data fra Let Asyl skal overføres til DFDG og CV på Jobnet

Dette acceptkriterie er flytte ud af denne epic og til 778.2 CV for flygtninge.

Overordnet løsningsmodel

• DFDG udstiller ny CV metode hvor Jobcenter kan gemme et CV på Jobnet
• Jobcenter (KSS) kan benytte denne nye metode til at overfører CV data til DFDG/Jobnet
• DFDG sikre Jobcenter kun kan gemme asyl CV data i den korrekte periode i forhold til overgivelsesdato

CVService (Version 6)

Servicen udvides med en ekstra metode, version 6 beholdes, da det er en non breaking change.

CreateCV

Metode der kan oprette og genindberette et CV udefra. Metoden er rette mod at Jobcenter (KSS) kan oprette og genindberette et asyl CV i forbindelse med at en asylansøger får asyl og overføres de til den kommune, de skal flytte til.
Forretningsregler:

• Når jobcentret benytte CreateCV overskrives et evt. eksisterende CV, dog tages hensyn til nedenstående forretningsregler/valideringer i DFDG/Jobnet
• CV skal overholde Jobnet minimumskrav til et CV for de data der angives
• Borger skal være oprettet på Jobnet. Bemærk, dette gør DFDG i forbindelse med Jobcentrets oprettelsen af kontaktgruppen for borgeren. Det betyder at Jobcentret skal have lavet en kontaktgruppe og sat en overgangsdato samt en frist for CV opdateringer inden Jobcentret kan gemme et CV
• CV kan kun overskrides af sagsbehandler hvis (DFDG validering):
  • Kontaktgruppen er:
    • d 27) Integrationsydelsesmodtager omfattet af integrationsprogrammet
  • Og dato frist for CV opdateringer (CVEditEndDate) er ikke overskredetFindes der ikke en frist for CV opdateringer (CVEditEndDate) betragtes den som overskredet
• Stillingsbetegnelser / 10 hvordan skal vi lige fikse dette issueVi har jo det kendte problem med det der er koder på tværs af niveauer der ikke er unikke
• Hvad med WSRM?

Tekniske forhold:

• I den eksisterende løsning med CV service er i GetCV benytte enumererings frem for traditionelle DFDG kodelister. Denne model forsættes der med i denne nye metode, da det giver mest ensartethed i forhold mellem create og get metoder.

Jobnets, til DFDG, udstillede metode: UpdateJobnetProfile

Jobnet udstiller en WSDL med metoden UpdateJobnetProfile, til opdatering af CV i Jobnet.
Bemærk: Selv om metodenavnet lægger op til opdatering, er det i praksis en overskrivning der sker. Dette betyder, at hele CV'et skal sendes med ved hvert kald af metoden. Heraf følger, at en collection, der er oprettet ved et tidligere kald, i praksis slettes, hvis collection /data ikke sendes med i det nye kald.
Bemærk endvidere, at opdatering af CV, der indtil nu er sket via Jobnets GUI, har medført synkronisering af data med DFDG. Eksempler herpå er Fx personens kontakt data, stillingsbetegnelser og CVAvailability. Ved kald af metoden UpdateJobnetProfile gøres intet andet end at overskrive eksisterende CV oplysninger. Har DFDG brug for denne opdatering, må DFDG selv opdatere systemerne. Alternativt vil det ske når der åbnes op for borgers adgang til CV'et på Jobnet og borger selv interagerer hermed jf. afsnit 4.4 og acceptkriterie 778.1.4 "Borger har et låst CV og må ikke kunne opdatere sit CV på Jobnet før fristen, sat af jobcentret, er nået".
Metode og skemabeskrivelse for valideringer kan ses af denne URL hvortil der henvises.
https://jobtX.jobnettest.dk/ServicesForDFDG/4/WSDL/CVServiceForDFDG.wsdl
WSDL og skema dokumenteres tillige på Stars WIKI, når DFDG har tilrettet tool for indlæsning af Jobnet WSDL'er.
Synkrone metoder fordrer, at DFDG udstiller kodelister Ved oprettelse af metoden UpdateJobnetProfile er der taget udgangspunkt i en vendt udgave af GetCV. Det er jo borgers udstillede data, der skal kunne indsættes. Det er aftalt, at der i Jobnet ikke skal laves snitfladeændringer og jf. aftale med Rune Gram skal metoderne til output og input på CV være synkrone hvad collectioner datafelter angår.
På GetCV metoden er følgende felter blot referencer til Taksonomiservicen:

• QualificationTaxonomyReference i collection QualificationCollection (Kvalifikationer)
• EducationLevel i collectionen EducationCollection (Uddannelsesniveau)

OccupationTaxonomyReference, der anvendes i collectionerne JobTargetCollection/PreviousJobExperienceCollection (dvs. ved Jobønsker/Joberfaring)
Da metoderne GetCV og UpdateJobnetProfile skal holdes synkrone og der ikke må forekomme snitfladeændringer, er det det aftalt, at DFDG i deres videreudstilling af UpdateJobnetProfile, via deres metode CreateCV, skal berige med kodelister for ovennævnte værdier. Kodelisterne skal holdes synkrone mod Jobnets værdier herfor i Taxonomiservicen og sikre, at aftagere kan kode op mod værdierne. Et eksempel til illustration af problemet:
I feltet educationlevel udstilles via GetCV (og modtages fremadrettet via UpdateJobnetProfile) alene en integer for Educationlevel. Men af den integer kan ikke udledes om uddannelsesniveauet bag et givet tale er "Videregående uddannelse","Grund-/folkeskole indtil 9. klasse" osv.
Hvad med Sprog i languageskillcollection: Code, Name og Level? Er det DFDG eller taksonomibaseret?!!!
Nyt felt "Andet" samt rettelse af tekstlig repræsentation af eksisterende værdi
I relation til Taksonomiservicen omkring uddannelsesniveau fremhæves i øvrigt at:
En ny værdi "Andet" skal oprettes.
At den tekstlige repræsentation af integeren for "Gymnasium, FH, HH, HTC" rettes til "Gymnasiale uddannelser"

Særligt for værdien "Andet" gælder, at den skal kunne sættes ved kald af UpdateJobnetProfile. Integer værdien for "Andet" kan naturligvis også udlæses via kald til GetCV.For beskrivelse af Borgers egen mulighed for opdatering af uddannelser hvor "Andet" måtte være valgt, henvises til afsnit xxxxxTekst til pågældende afsnit, som skal være Jobnet specifikt: På Jobnet må uddannelser, hvor "Andet" allerede er sat som uddannelsesniveau, kunne opdateres af borger selv. Opdateres uddannelsen dog med andet uddannelsesniveau end "Andet", vil borger ikke kunne vælge "Andet" igen. Når borger selv opretter en uddannelse via Jobnet, vil "Andet" aldrig kunne vælges.

Response ved kald af UpdateJobnetProfile
Når DFDG kalder UpdateJobnetProfile, svarer Jobnet med et response indeholdende en fejlbeskrivelse eller en kvittering for succes. Opdateringen af CV'et er så at sige transaktionel. Enten oprettes/overskrives CV samlet set eller også ændres intet.
Ved succes returneres XXXXXDFDG ønsker simpelt response – ikke at får returneret request.
Ved fejl returneres
300 Opdatering fejlet
301 Skema validering fejler
200 CV nummer mangler
203 CV nummer ukendt

Input (Kopieret fra GetCV og skal QA med Jobnet når de kommer med deres CreateCV men den vil være tæt på denne*Linda retter løbende til på denne liste over input til Jobnet CV)*

Response

Error Codes Inkl. mapning af Jobnet fejlkoder

778.1.2 Borgers kontaktgrupper samt tillægsdata i form af overgivelsesdato og frist for CV opdateringer, der er relevante for sagsbehandler i Jobcenter, skal gemmes i DFDG

Overordnet løsningsmodel

• Jobcenter (KSS) vil i forbindelse med DFDG oprettelsen af sagen i jobcentret og herefter sætte
  • Jobcenter tilknytning, hvis denne ikke finde eller er hos andet Jobcenter (Med PersonRegistrationService.UpdateJobcenter
  • Den relevante kontaktgruppe i DFDG (alm. proces med PersonRegistrationService.CreateContactGroup)
• Jobcenter (KSS) indberetter overgivelsesdato og frist for CV opdateringer til DFDG
• Data er tilgængelig fra DFDG via personopslag (PSS) inkl. udstilling til landssupporten.

CVService (Version 6)

Servicen udvides med en ekstra metode, version 6 beholdes, da det er en non breaking change.
Kun eget jobcenter må tilgå de nye metoder nedenfor. Valideringsfejl: 6005.

CreateAsylumTransition

Metode til at oprette overgangsdatoOvergivelsesdato og frist for CV opdateringer for borger der har opnået asyl.
Forretningsregler:

• Frist for CV opdateringer (CVEditEndDate) skal være >= OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate), både ved oprettelser og opdateringer ellers fejl 9196
• Frist for CV opdateringer (CVEditEndDate) må ikke være >= OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate) med mere 60 dage, både ved oprettelser og opdateringer ellers fejl 9197Bemærk: perioden skal være konfigurerbar
• OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate) og frist for CV opdateringer (CVEditEndDate) må kun oprettesnår kontaktgruppen er:
  • (Id 8) Uden ydelse
  • (Id 17) Selvforsørgede, ikke i beskæftigelse
  • (Id 18) Selvforsørgede udlændinge omfattet af integrationsprogrammet
  • (Id 19) Indvandrere omfattet af introduktionsforløbet
  • (Id 20) Beskæftigede
  • (Id 27) Integrationsydelsesmodtager omfattet af integrationsprogrammet

Bemærk at der ikke må sættes disse datoer for nogen andre kontaktgrupper (således heller ikke Id 26). Fejlbesked: 9198 nedenfor.

Response:
Der returneres et standard ServiceReceipt, hvor MessageIdentifier er id på den netop oprettede række i databasen.

UpdateAsylumTransition

Metode til at opdatere overgangsdatoOvergivelsesdato og frist for CV opdateringer for borger der har opnået asyl.
Forretningsregler:

• Frist for CV opdateringer (CVEditEndDate) skal være >= OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate), både ved oprettelser og opdateringer ellers fejl 9196
• Frist for CV opdateringer (CVEditEndDate) må ikke være >= OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate) med mere 60 dage, både ved oprettelser og opdateringer ellers fejl bbbb
• Ønskes at ændre en OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate) f.eks. pga. fejlindberetning skal der sættes en kommentar (CorrectionComment) ellers fejl 9202Bemærk: OvergangsdatoOvergivelsesdato er for den første kommunes overtagelses af integrationsansvaret. Kommune 2 må ikke efter en flytning sætte en ny dato. Dette laves der ikke DFDG validering på.
• Når Frist for CV opdateringer (CVEditEndDate) er < dags dato må frist for CV opdateringer (CVEditEndDate) og overgangsdatoOvergivelsesdato (AsylumCVTransitionDate) ikke længere ændres ellers fejl 9200. Dette er pga. borger nu kan have rettet i sit CV via Jobnet.
• Frist for CV opdateringer (CVEditEndDate) og overgangsdatoOvergivelsesdato (AsylumCVTransitionDate) kan kun opdateres hvis de tidligere er oprettet - 9201
• OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate) og frist for CV opdateringer (CVEditEndDate) må kun ændres når kontaktgruppen er:
  • (Id 8) Uden ydelse
  • (Id 17) Selvforsørgede, ikke i beskæftigelse
  • (Id 18) Selvforsørgede udlændinge omfattet af integrationsprogrammet
  • (Id 19) Indvandrere omfattet af introduktionsforløbet
  • (Id 20) Beskæftigede
  • (Id 27) Integrationsydelsesmodtager omfattet af integrationsprogrammet

Bemærk at der ikke må sættes disse datoer for nogen andre kontaktgrupper (således heller ikke Id 26). Fejlbesked: 9198 nedenfor.

Response:
Der returneres et standard ServiceReceipt, hvor MessageIdentifier er id på den netop oprettede række i databasen.

GetAsylumDates

Metode til at hente overgangsdato og frist for CV opdateringer for en borger.
Element ikke vist, samme element som under .

PersonStatusService (Version 18)

Forretningsregler:

• AsylumTransitionInfoType må ikke vises for a-kasser, der skal typen være tom.
• Kun de aktuelle data medtages, historik udstilles ikke i PSS

GetVariablePersonStatus

Kun ændret collection vises.
CVInfo

CVType-3 (udvidelse til CVType-2)

AsylumTransitionInfoType

LSS udstilling

De nye data omkring frist for CV opdateringer (CVEditEndDate) og OvergangsdatoOvergivelsesdato (AsylumCVTransitionDate) udstille via PSS på LSS.

778.1.3 Borger skal oprettes på Jobnet såfremt borger ikke findes på Jobnet

Overordnet løsningsmodel

• Når Jobcenter (KSS) i forbindelse med oprettelsen af sagen i jobcentret sætte den relevante kontaktgruppe i DFDG kontrollerer DFDG om borger er oprette som bruger på Jobnet.
• Er borgeren ikke på Jobnet oprette DFDG borgeren som brugeren på Jobnet. Jobnet skaber borgerens konti og giver mulighed for at kunne oprette CV

DFDG's kontrol om bruger er oprettet på Jobnet og borger oprettes hvis nødvendigt

• Ved oprettelse af en ny kontaktgruppeindberetning af overgivelsesdato (CVService (version 6).CreateAsylumTransitionPersonRegistrationService (Version 9).CreateContactGroup):,hvor kontaktgruppen er:
  • (Id 8) Uden ydelse
  • (Id 17) Selvforsørgede, ikke i beskæftigelse
  • (Id 18) Selvforsørgede udlændinge omfattet af integrationsprogrammet
  • (Id 19) Indvandrere omfattet af introduktionsforløbet
  • (Id 20) Beskæftigede
  • (Id 27) Integrationsydelsesmodtager omfattet af integrationsprogrammet

1. - (Id 27) Integrationsydelsesmodtager omfattet af integrationsprogrammet- (Id28) Integrationsydelsesmodtager med uddannelsespålæg kontrolleres om borger findes som bruger på Jobnet allerede (JobnetAccountService (Version 43). GetAuthenticationStateCVserviceForDFDG.GetJobnetProfile kaldes med det CVnummer borger er registreret med i DFDG) CitizenAccountService
2. Hvis:
   1. Borger findes på Jobnet gøres ikke mere
3. Borger ikke findes ikke på Jobnet så oprettes borger. DFDGD kalder "UnemploymentEnrollmentService (Version 6).CreateJobnetAccount" CitizenAccountServiceForDFDG.CreateEnrolmentCV og linker CV-nummer med CPR-nr i DFDG for implementeringsdetaljer se den relevante US) CitizenAccountService.. CreateEnrollmentCV. DFDG sørger for, at borgers loginbrev ikke afsendes til borger.Der sker i praksis ikke noget ved at borger logger ind, sålænge CVeditingPossible er false. Men på et tidligt møde aftalte vi, at DFDG skulle holde password brev tilbage.
4. SPØRGSMÅL TIL FLOWDIAGRAMHej DGDF.Jobnet er ved at undersøge det med "aktivering" af cv. JEg tror det er irrelevant, da det må være for CV'er (altså jobnetprofiler) der er så gamle at de er inaktiveret. Vender tilbage… Og det skulle nødig ske her, at et CV er mere end 15 måneder om at behandles…
   1. 

778.1.4 Borger har et låst CV og må ikke kunne opdatere sit CV på Jobnet før fristen, sat af jobcentret, er nået

Overordnet løsningsmodel

• Hvis en borger har en frist for CV opdateringer (CVEditEndDate) der IKKE er overskredet vil DFDG fortælle Jobnet dette (via JobnetCitizenStatusService (Version 8).GetCitizenStatus))
• Jobnet vil når borger er markeret med at de ikke må ændre i deres CV låse CV'et for ændringer og give/vise en besked om dette for borger (Se Jobnet user stories).
• BEMÆRK: På Jobnet er GUI og dynamik kodet via US 276. JCCS v. 8 er dog ikke løftet og løftes først i US 277 i Epic 778.2. GUI er derfor blændet af, så det i 2017-1 er tilladt for alle at editere deres CV.

JobnetCitizenStatusService (Version 7)

GetCitizenStatus

Kun det nye "element" i GetCitizenStatusResponse.CitizenStatus er beskrevet.
Forretningsregler:

• Vedr. CVEditingPossible Hvis der ikke er en CVEditEndDate (den er NULL/tom)

Request
Uændret.
Response
Kun det nye "element" i GetCitizenStatusResponse.CitizenStatus er beskrevet.

Jobnet implementering af Låst CV

Når Jobnet, ved borgers login, af JobnetCitizenStatusService kan se, at CVEditingPossible er false, så tilrettes GUI som følger:

På "Min side" fremgår af feltet "Din status" følgende status for CV:

Af menupunktet "Mit CV" fremgår den herunder viste informative grønne boks og CV-status er følgende: "Status: Hos jobcenter"

Ved klik på "Vis, udskriv eller eksporter CV" vises de CV oplysninger der er registreret på borgers profil. De kan således printes ud og tage med på sprogcenter etc. Men linket til redigering af oplysningerne er fjernet.

Er CVEditingPossible true, null eller fraværende vil CV blive vist for borger, med den status for .

778.1.5 Når borgers frist for CV opdateringer nås, skal brugeren have adgang til Jobnet, hvis borger ikke allerede har dette

Overordnet løsningsmodelAlex: Hvad hvis en borger flytter til anden kommune midt i alt det her?

• Når frist for CV opdateringer er overskredet, skaber Jobcentret et nyt username / password til borgeren.
• Jobcenter sender/give username/password til borger
• Borger kan logge ind på Jobnet og XXXXXX

Info til KSS JobnetAccountDetailsService (Version 3).SendUsernameAndPassword

Særlige krav til test

Kendte udeståender fra udviklingsfasen

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

User stories

User stories er kun til interne brug for STAR's leverandører.

US-113: Spike: Analyser og blotlæg nødvendige valideringer ved oprettelse af CV.

Til kundesupport og test: Dette er vidensafklaring til kommende US. Der er intet at forholde sig til for jer.
Spike Formål:
Vi skal have kortlagt viden omkring hvilke valideringer der gøres i Jobnet i dag, med henblik på at afdække hvilke valideringer der kan lægges i kommende WSDL og hvilke der skal ske længere nede.Sigtet er dels viden til etablering af den kommende WSDL, men også skæring af kommende US. Interessante oplysninger er (men I kan sikkert komme på mere):

• Hvilke valideringer gøres i dag på highlevel niveau, dvs. I GUI?
• Hvilke valideringer sker på low level niveau – som ikke vil kunne lægges i WSDL – eksempelvis om den medsendte discoamskode eksisterer?
• Hvilke constraints er der? På Gui niveau og/eller databaseniveau som skal forceres for at jobnetdata fortsat er valide og Jobnet virker? Når Collection påbegyndes udfyldt, så er der i nogle tilfælde krævede data der skal suppleres med, hvor vi kaster en fejl hvis det ikke sker.
• Hvilke fejl kan returneres fra GUI?
• Hvilke fejl bør returneres fra lavere lag, hvis ikke constraints overholdes?
• De fejl der kan opstå i de højere lag er ligeledes relevante at kortlægge, da de er input til valideringer WSDL skal gøre.
• Hvad er minimum set af data man kan slippe i gennem med at angive?
• Hvilke datatyper er der for de enkelte værdier?
• Hvilke feltlængder?

US-114: Spike: Analyser problemstilling omkring oprettelse af CV, når borger ikke er oprettet

Til kundesupport og test: Dette er vidensafklaring til kommende US. Der er intet at forholde sig til for jer.
Spike Formål:
Den normale måde hvorpå et CV oprettes er, at borger opretter sig på Jobnet og derefter selv opretter CV. Den nye situation der skal adresseres er, at CV skal kunne oprettes gennem skal af Service, som JN udstiller via DFDG og at borger, på tidspunktet hvor kald sker, med stor sandsynlighed ikke har en oprettet profil. På Jobnet er det formentlig et krav, at CV knyttes på en borger. Cv kan således ikke bare oprettes, da der mangler en profil at knytte det på. Muligvis vi kan remote oprette en borger, gennem en service DFDG kan kalde hvor borger tildeles brugernavn og password, men borger får ikke disse oplysninger. Og kan derved ikke, når vedkommende logger ind første gang, knytte denne profil sammen med sit NemID og lave en verificeret bruger.
Vi ved, at DFDG ved oprettelsen ved, om borger er oprettet. Er det tilfældet, vil de have et CVnummer på borgeren. Men det vil være for et fåtal.
Hovedparten af de nye borgere har ikke et CVnummer, men alle har dog et CPR nummer, når de når så langt, at de får asyl og visiteres til kommunen.
Vi har i Jobnet nu tilladelse til at gemme og bruge CPR. CPR returneres ved NemID login. Kan vi få DFDG til at supplere med CPR ved oprettelse af CV'er på dummy brugere og så bruge det som nøgle til at merge stærk borger med en evt. dummy profil, når de første gang logger ind? Dog kan en del af disse borgere faktisk skifte CPR NR eftefølgende.CPR er ikke relevant på JN. Vi fortsætter med CVnr. Men muligvis relevant på DFDG siden?
Eller er der en bedre måde at sikre, at vi ikke risikerer at have CV'er blafrende, fordi vi ikke kan merge CV og borger, når borger skal remoteoprettes for at CV kan oprettes?
Kan PID evt. være nøglen? Tror ikke DFDG nødvendigvis ligger inde med dette, men træk gerne på DFDG i design af løsning.

US 115: Som DFDG ønsker jeg afklaring om WSDL for metode til oprettelse af CV, med valideringer, og med afsæt i navngivning fra GetCV.

På denne opgave, der reelt definerer kontrakten mellem DFDG og Jobnet, er aftalt et tværgående team, hvor DFDG ser på opgaven sammen med Jobnet. Jobnet går, for hurtig leverance, efter en verifikation af den eksisterende WSDL. Aftal nærmere med DFDG, der stiller Nynne til rådighed i løbet af sprintet.
Acceptkriterier:

• Kontrakt mellem Jobnet og DFDG er dokumenteret, samt verificeret med DFDG, herunder:
  • Fejlkoder der returneres
  • Data (krævede felter, feltlængder, datatyper)
  • Valideringsregler
  • Status for Completed
  • Søgbarhed
  • Eksisterende synkroniseringer med DFDG.

• På educationlevel dokumenteres aftale om oprettelse af nyt uddannelsesniveau "Andet" og "Gymnasiale uddannelser, FH, HH og HTC" rettes til "Gymnasiale uddannelser"

• • Disse ændringer verificeres med DFDG i forhold til evt. ændring i kodelister/taksonomiservice/jobnetdatabase.
  • Det klarlægges om de ændrede værdier afstedkommer arbejder i PDF-udgaverne af CV.

Til udviklere:
Der ligger regler i GUI, i form af constraints og i difogram – flest mulig af disse, skal (tillige) flyttes i top på wsdl, således at aftager se hvad der skal leveres.... Der skal dog fortsat valideres i dybet også, af hensyn til måden det er implementeret ind på i dag. Bemærk omkring "Educationlevel": I dag udstiller vi alene et tal for educationlevel. Det skal afklares hvorfra dette tal kommer – om det er database, taksonomi eller DFDG kodeliste. Årsag: Når vi kun udstiller et tal, skal vi være sikre på, at aftagere af service er afstemt med det nye tal. Ellers kan de ikke tolke "Andet" og tekstrettelsen til Gymnasiale Uddannelser, vil alen være på Jobnet. DFDG har en lignede kodeliste: https://starwiki.atlassian.net/wiki/display/UDV/EducationAttainmentIdentifierType
Vi skal verificere om den er synkroniseret med os. Ellers vil ny værdi kunne give uheldigt udfald!

US 158: Som Jobnet vil jeg oprette valideringer i WSDL jf. US 113 og 115.

Acceptkriterier:

• WSDL oprettes, med fundne valideringer jf. US 113 og under hensyntagen til resultat af ønsker for kontrakt mellem DFDG og Jobnet jf. US 115

• WDSL udstilles til DFDG

US 157: Som Jobnet vil jeg implementere metoden 'Opret CV' vertikalt, startende med collectionen 'Erhvervserfaring'

Det er aftalt, at oprettelse af selve metoden sker vertikalt collection for collection, startende med Erhvervserfaring. Rammerne etableret ved første collection, vil komme værdifuldt tilbage, ved efterfølgende collectioner.
Acceptkriterier:

• Logikken i service, valideringsfejl, mapning, overskrivning af CV samt logning er implementeret.

• Ved kald af service med ikke fyldestgørende, forkerte eller for lange parametre for collectionen "Erhvervserfaring", reageres med response indeholdende fejlkoder jf. valideringsregler i US 115. Den eksisterende collection overskrives ikke.

• Ved kald af service med valide værdier for collection "Erhvervserfaring", overskrives den eksisterende "erhvervserfaring".

• • Særligt ved kald med tom collection for "Erhvervserfaring", slettes den eksisterende collection for "Erhvervserfaring".

• Det skal ikke være muligt at oprette datea via webservice, der ikke også kan oprettes via Korrektionen af dette acceptkriterie til mere generelle termer ændrer ikke på hvad der valideres. Det er alene ordlyden på feedback der ændres, derfor kan vi ikke sige "identisk med". GUI fanger alt på Jobnet. Når service går uden om GUI valideres på samme, men nogle fejl fanges af skema, andre af dybereliggende lag – og der kan formuleringen være anderledes…..GUI. Undtaget herfra er dog årstal, hvor GUI restriktivt holder på, at de ikke må ligge mere end 100 år tilbage. Samme restriktion er ikke indbygget i Webservice. .Response fra service og status på data ved kald af servicemetoden med valide/ikke valide data, er identisk med response og status på data opdateret via Jobnet GUI.
• 
  

Løft af JCSS til version 8 (US 277)

US 277 er flyttet til Epic 778.2 i 2017-2.

"Som Jobnet ønsker jeg nye værdier i den eksisterende JCCS v.8 implementeret, til fremtidig anvendelse"
Beskrivelse:
JCSS har fået tilføjet nye værdier, uden den er løftet versionsmæssigt. Det er således stadig version 8. Skynet skal bruge nogle af værdierne i relation til dagpengetællere. Det skal aftales med dem, til hvilket lag de skal mappes. Cyberdyne skal bruge resten af felterne i relation til kommende userstory, hvor det via disse skal styres om en asylmodtagers CV må vises eller ej. Disse værdier skal altså bruges i GUI, til styring af at CV skal skjules, links skal skjules, grøn boks vises med informationstekst mv. Se evt. US 276
Acceptkriterier:

• Feltværdierne under følgende to elementer mappes ind i Jobnet:

        AsylumTransition
o   CVEditingPossible : bool - flag for at borger må editere sit CV
o   CVEditEndDate : Date - dato for hvornår jobcenter ikke længere kan rette i CV
        UnemploymentBenefitAccountInfo
o   HasbenefitAccount : bool - flag for om borgere skal have vist dagpengetællere på jobnet

• • RecalculatePossible : bool - flag for om borger skal have mulighed for at kunne genberegne

• Ved unit test dokumenteres at felterne er implementeret og kan vises på jobnet.

Tips til udviklere:
Værdier skal mappes gennem relevante lag, så værdierne for AsylumTransition collectionens vedkommende er tilgængelige for umiddelbar anvendelse i US 276.
For UnemploymentBenefitAccountInfo aftales med Skynet hvortil det skal mappes.
Det eksisterende felt RecalculateUnemploymentBenefitsAccountPossible, er flyttet ind I elementet UnemploymentBenefitAccountInfo og udgøres nu af RecalculatePossible. Det er ikke et felt der har været i brug før, men for god ordens skyld bør vi lige søge koden igennem for forekomst af dette felt.

Afblænding af CV på Jobnet, når CvEditingPossible er false (US 276)

"Som asylmodtager, vil jeg ikke kunne rette mit CV på Jobnet, når det ikke er frigivet af Jobcenteret"
Når asylmodtager ankommer til sin tildelte kommune, skal Jobcenteret sammen med asylmodtageren, og med udgangspunkt i de data, der undervejs i asylansøgerens ophold i Danmark er blevet indsamlet, have etableret et CV på Jobnet.
Det er i den anledning vigtigt at asylmodtageren skærmes af fra at kunne lave rettelser på selve CV'et på Jobnet, som alternativt efterfølgende ville blive overskrevet, når jobcenter uploader. Og upload vil kunne ske i en periode, til det frigives til borger selv.
Værdien der skal styre hvorvidt borger må redigere sit CV er CVEditingPossible, som bleiver løftet i US 277 i 2017-2. For nu er funktionalitet kodet og testet af, så det vil virke dynamisk, når JCSS løftes. MEN i 2017-1 koden er CVeditingPossible efterfølgende hardkodet til true, så alle funktionalitet effektivt er sat ud af drift, til det reelt skal implementeres..
Links til wireframe Min side Mit CV Vis, udskriv eller eksporter CV

Acceptkriterier:

• For borgerere med CVEditingPossible = false skal af "Din status" på "Min side:

• • Alene fremgå "CV Status: Hos jobcenter".

• • • Der skal således ikke fremgå yderligere CV relaterede oplysninger, eksempelvis link "sådan gør du dit CV søgbart", Cvs søgbarhedsstatus, seneste status for at CV er opdateret.

• For borgerere med CVEditingPossible = false skal ved klik på menupunkt "Mit CV" und "Min jobsøgning" alene fremgå følgende grønne boks, samt link til "Vis, udskriv eller eksporter mit CV":

• • Heraf føgler, at der hverken skal fremgå "motifikationer" eller CV i redigerbart form.

• Af CV Status feltet fremgår "Status: Hos jobcenter"
  • Der skal således ikke fremgå yderligere CV relaterede oplysninger, eksempelvis link "sådan gør du dit CV søgbart", Cvs søgbarhedsstatus, seneste status for at CV er opdateret.

Ved klik på "Vis, udskriv eller eksporter CV" sendes borger allerede i dag til siden, hvor CV kan vises, udskrives eller eksporteres.

• På denne side fjernes dog linket "> Ret mit CV", for borgere med CVEditingPossible = false.

QualificationCollection i UpdateJobnetProfile (US-391)

"Som Jobnet vil jeg tilføje QualificationCollection til UpdateJobnetProfile, så borgers kvalifikationer på CV'et kan opdateres."
Acceptkriterier:

• Ved kald af UpdateCV med parametre i collectionen QualificationCollection, verificeres mod taxonomiservice, at det er gyldige værdier, hvorefter de opdateres.
  • Er værdier ikke gyldige afbrydes hele opdatering af CV og der returneres fejlbesked herom.

Er der ikke angivet værdier for collectionen QualificationCollection, er det analogt at slette collectionen fra det på Jobnet lagrede CV.

• Integrationstest:
  • Der udvides med scenarie, hvor der suppleres med testdata for QualificationCollection.
  • Der udvides med scenarie, hvor der suppleres med tom collection for QualificationCollection

• Supplerede værdier er verificeret i GUI.