Als developer wil ik het Medewerker component common ground proof maken

[matthiasoliveiro]

Voor dit component stellen wij de Schema.org standaard JobPosting wat het dichtsbij komt van het Employee object.

Organisatie	standaard	URL
Schema.org	JobPosting	https://schema.org/JobPosting

Taken lijst todo:

• Architectuur afstemming
• Ontwerp gegevens model
• Realisatie
• Postman testscripts
• Documentatie Redoc
• Testscripts aan leveren aan testvoorziening
• Voorbeeld implementatie
• Code opleveren in Utrecht repo

Checklist Definition of done

• Oas documentatie
• Postman scripts (test scripts)
• Aangeleveren testscripts aan de api test voorziening
• Containers moeten gepubliceert zijn
• Gereviewd op de design decisions
• Voorbeeld implementatie beschikbaar
• Redoc moet beschikbaar zijn
• Documentatie moet beschikbaar zijn op github-pages
• NLX integratie moet werken

[rubenvdlinde]

Ik ben het er mee eens dat JobPosting hier de quickwin is, dus laten we die zo doen. Maar zou wel graag als uitgangspunt nemen dat we het component de kant op zien gaan van https://hropenstandards.org/. Dat rechtvaardigt in mijn hoofd ook beter waarom dit ene los component is. Dat z’n systeem buiten de scope van huwelijksplanner licht lijkt me echter evident. Dus laten we dat aan andere teams of vrijwilligers laten.

[matthiasoliveiro]

• Test voorziening geeft niet thuis en kunnen we niet afronden.
• Github pages is een strech goal en een nice to have, we hebben het nu ander opgelost via de readme (zie tabel)
• NLX hebben we een andere afspraak voor gemaakt en wordt los opgepakt. Het component is NLX ready maar het staat nog niet aan dat is een andere story

[CMasselink]

@rubenvdlinde zie ConductionNL/medewerkercatalogus#16 voor een wijzigingsvoorstel om het contact attribuut te wijzigen naar person

[CMasselink]

@rubenvdlinde @matthiasoliveiro de documentatie op https://mrc.huwelijksplanner.online/ lijkt kapot, de operaties worden niet meer getoond aan de linker kant in het menu van redoc.

Het wijzigingsverzoek staat ook nog open.

[CMasselink]

@rjzondervan
Ik zie in de query parameters bij get jobposting een aantal attributen die volgens mij bij geen enkel object bestaan:

Ook de documentatie is niet altijd goed ingevuld bij de query parameters.

Het datamodel van dit component klopt niet, staat nu alleen maar een employee object in.

Ik zie ook attributen bij het jobposting object waarvan we volgens mij in de context van de huwelijksplanner hebben afgesproken dat we die niet gaan gebruiken:

We hebben het bij trouwambtenaren wel gehad over het kunnen vastleggen van aantal uren dat iemand beschikbaar is. Waar zouden we dat moeten vastleggen?

Hoe gaan we dit component nu eigenlijk precies gebruiken?
Bij het employee object wordt een referentie gemaakt naar "person".

Waar leggen we in de context van de huwelijksplanner de referentie naar? Dit mag geen referentie zijn naar een persoonsobject uit de BRP. Daar zit een BSN in de URL en een BSN mag niet gebruikt worden voor medewerkersidentificatie.

[rjzondervan]

@CMasselink

Bedankt voor je feedback. Ik zie dat er hier en daar bij het aanmaken van de documentatie iets niet helemaal goed is gegaan, ik duik er even in, maar het kan zijn dat er hier en daar ook nog iets in de parser die de documentatie aanmaakt fout gaat.

Het datamodel moet inderdaad nog even bijgewerkt worden, dat is een beetje achterop komen te liggen. In ieder geval een paar punten waar ik antwoord op kan geven:

• jobStartDate en validThrough zijn vooral in verband met herbruikbaarheid opgenomen
• employmentType gaat nog ergens mis, maar de gedachte hierachter is om aan te kunnen geven of dit een fulltime aanstelling, partttime aanstelling, tijdelijke of seizoensaanstelling is (of een stage)
• standardHours is om het aantal uren per week op te slaan, waarom deze in de redoc niet goed gaat kijk ik even na.

[CMasselink]

We hebben op dit moment geen goede plek om medewerkergegevens (Naam, etc.) vast te leggen. Een verwijzing naar een persoons uit BRP mag niet vanwege eerder aangegeven redenen.

In overleg met Patrick stellen wij de volgende wijziging voor op het employee object:
We voegen de volgende identificerende gegevens toe aan het employee object:

Aangevuld met het attribuut voornaam.

Het attribuut Person is geen verplicht veld meer.

Deze wijziging maakt het mogelijk om zowel by reference naar een medewerker te verwijzen, als op basis van de identificerende gegevens.

[matthiasoliveiro]

Aangezien we personen ook opslaan in het contacten component zit er in het medewerker alleen een verwijzing naar het contacten component. Alle gewenste velden zouden daar in moeten staan.