Als developer wil ik het Locatie component common ground proof maken

[matthiasoliveiro]

Voor dit component stellen wij het volgende voor op Schema.org bestaat de standaard Place voor het Locatie object wat de basis is van dit component kan zijn.

Organisatie	Standaard	URL
Schema.org	Place	https://schema.org/Place

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]

Naar aanleiding van wat @CMasselink ook al op slack zei, er is ook een https://schema.org/Accommodation en (om mezelf eens te quoten) https://schema.org/docs/hotels.html norm. Ik voel er zelf veel voor om daar het hotels voorbeeld te volgen. Als ik dat zo lees is het niet mega complex (3 objecten ipv 1) en de gedachten er achter rechtvaardigen dan ook wel echt dat je een apart locatie component gebruikt. Die zou je dan zowel kunnen relateren aan PDC (product) als AgendaComponent (resource) en dan heb je de datazet eigenlijk rond. Zonder dat je dingen echt overhoop trekt

[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 Waar zijn de verplichte velden bij het creëren van een accomodation op gebaseerd? Verplichte velden moeten afgestemd zijn op hetgeen we nu bij een locatie vastleggen, ik weet niet of daar nu een mismatch mee is. Je bent bijvoorbeeld verplicht om een product in te voeren. Dat betekent dat je geen locaties/ruimtes op kan voeren waarbij je nog niet weet wat voor producten je daar wilt aanbieden, dat lijkt me wat onhandig.
NumberofBathrooms lijkt me ook wat overbodig.

Geselecteerde linkjes kloppen niet.

Kloppen deze datatype aanduidingen? Is het datatime of een string geformateerd als datetime?

[rjzondervan]

@CMasselink De totalNumberOfBathrooms-property is een property die vanuit de Schema.org standaard naar voren kwam. Ik kan me voorstellen dat je deze wat overbodig vindt, maar er zijn situaties te bedenken waarin deze property wel nuttig kan zijn, ook wanneer we in de toekomst externe locaties toe willen kunnen voegen.

De string aanduidingen betekenen dat het component een string als datetime geformatteerd verwacht, dit wordt dan intern in een DateTime-object omgezet.

Voor wat betreft de verplichte velden geeft @matthiasoliveiro mij aan dat dit zo is opgehaald bij de specialisten, mocht dit niet meer kloppen dan moet er even worden gekeken wat de consequenties zijn.

[CMasselink]

@rjzondervan als de mensen die de locaties straks moeten beheren, deze velden verplicht willen maken, vind ik het uiteraard prima. Dan ga ik er ook van uit dat deze informatie, zoals de oppervlakte en het aantal toiletten standaard bij deze mensen aanwezig is...
Misschien wel handig om het nog eens te valideren. Met de huidige implementatie moet je wel heel veel informatie van te voren hebben, wil je een locatie op kunnen slaan. Geen idee of de specialisten zich dat gerealiseerd hebben.

[CMasselink]

@DdeBruijn @MichelleDautzenberg Zien jullie kans bovenstaande met de backoffice medewerkers te verifiëren?
Het gaat om alle velden die hier als required staan aangegeven:
https://lc.huwelijksplanner.online/#operation/postAccommodationCollection

[rubenvdlinde]

Nog even over het technische stuk. Hier is inmiddels is boventafel waar dit vandaan komt, er worden een aantal variabelen niet gezet op de kubernetes omgevingen. Omdat de openapi.yaml locaal wordt gemaakt verklaard dat ook met het verschil. Er is inmiddels een fix voor (variale zetten) en die moet over alle deployments worden uitgerold. Zie #438

[MichelleDautzenberg]

Ik heb de vraag uitgezet bij de informatieadviseur van BZ, maar ik verwacht niet heel snel antwoord gezien de werkdruk nu daar.

[matthiasoliveiro]

Deze staat nu ook op demo kan iemand even checken of dat klopt? zo ja dan is even de vraag wat we met dit issue gaan doen.

[MichelleDautzenberg]

Hoe kan ik dit checken @matthiasoliveiro