Als API-consumer wil ik dat de Zaak.einddatum een datetime wordt

sergei-maertens commented 5 years ago

...zodat ik op een convenient manier dit kan afleiden, in plaats van de datumGezet van de laatste status uit te lezen.

Dit kwam voort uit feedback van leveranciers van Demo 6.

Definition of ready

[ ] Iedereen in het team begrijpt de user story
[ ] de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
[ ] Is klein genoeg (maximaal 1/5 van sprint)
[ ] Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
[ ] Idee hebben van hoe deze user story kan worden gedemonstreerd.
[ ] Userstory is ingevuld op template architectuurschets
[ ] Userstory is voorzien van veldmapping naar RGBZ2 (mag alleen afgevinkt worden door Arjan)
[ ] Userstory past op wenselijk gebruik ZGW volgens GEMMA 2 (mag alleen afgevinkt worden door Jeffrey)
[ ] Vastgelegd in Github en geplaatst in kolom ready

Definition of done

[ ] Er is een OAS 3.0 specificatie
[ ] Er is een referentieimplementatie
[ ] Er zijn tests aanwezig die de wijziging aantonen
[ ] De technische specificatie (standaard.md) is gepubliceerd leesbaar

Acceptatiecriteria

[ ] De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
[ ] Eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
[ ] Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.
[ ] Er zijn geen bekende RGBZ tegenstrijdigheden of afwijkingen zijn vastgelegd

Taken

[ ] Implementeren in referentie-implementatie [verantwoordelijke]
[ ] Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
[ ] Genereren/opstellen van OAS 3.0 [verantwoordelijke]
[ ] Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

TCIMEddy commented 5 years ago

@Hugo-ter-Doest Prio?

Hugo-ter-Doest commented 5 years ago

Laag omdat er een work-around is.

ArjanKloosterboer commented 5 years ago

Waarom zou een consumer iets dat semantisch niet nauwkeuriger kan dan een datum toch tot op de seconde willen hebben? is er een user-story waaruit de noodzaak van een einddatum van een zaak tot op de minuut of seconde blijkt?

michielverhoef commented 5 years ago

@ArjanKloosterboer Dat was ook mijn eerste reactie maar volgens mij gaat het er in dit issue om dat de einddatum van de zaak nu een afgeleid gegeven (want gelijk aan de datum van de laatste status gezet die ook een eindstatus is). Om de einddatum van een zaak te vinden moet je dus eerst de laatste (eind)status van de zaak opvragen en daar de datumtijd van de status gezet van opvragen. Het is voor het gebruik makkelijker om dit als een attribuut bij de zaak mee te krijgen.

Overigens kan dit ook heel mooi (in ieder geval eleganter en misschien wel beter) opgelost worden in een experience API waarbij de einddatum door de experience API verwerkt (opgevraagd/afgeleid/gezet) wordt en niet als gegeven opgeslagen wordt. Dan heb je meteen #660 opgelost/voorkomen.

Maar wat weet ik nou van API's ontwerpen.

ArjanKloosterboer commented 5 years ago

In de designkeuzes meen ik onder 'Zaak afsluiten' te lezen dat de resource Zaken het element 'einddatum' als een alleen-lezen-attribuut zou krijgen, een afgeleid gegeven dus. Dan hoeft een consumer die einddatum niet zelf af te leiden uit de Statussen. Ik zie 'm ook in de resource-specificatie staan.

michielverhoef commented 5 years ago

Dan zou dit dus eigenlijk al moeten werken?

ArjanKloosterboer commented 5 years ago

Met dien verstande dat de Zaak.Einddatum een datum-veld is en de Status.Datum_status_gezet een datum-tijd-veld. Het lijkt er op dat de discussie over een Einddatum incl. tijd gaat.

michielverhoef commented 5 years ago

Als ik de reden waarom lees gaat het er juist om dat de einddatum nu uit de laatste status gezet afgeleid moet worden, niet over het formaat:

zodat ik op een convenient manier dit kan afleiden, in plaats van de datumGezet van de laatste status uit te lezen.

Ik verwacht (hoop) niet dat een leverancier niet in staat is om een datumtijd-veld om te zetten naar een datumveld... :-)

ArjanKloosterboer commented 5 years ago

Je slaat het eerste deel van de user-story-omschrijving over:

Als API-consumer wil ik dat de Zaak.einddatum een datetime wordt

michielverhoef commented 5 years ago

Oh wacht, nu snap ik hem... De einddatum uit de resource Zaak is alleen een datum en geen datumTijd. Duh.

Op zich is het wel logisch dat de einddatum van een zaak identiek is aan de datumTijd van de laatste status. Bijvoorbeeld wanneer die einddatum als zoeksleutel gebruikt wordt oid. (al weet ik niet in welke gevallen je dat zou doen).

sergei-maertens commented 5 years ago

Het gaat wel om het formaat. Dit was feedback uit de demo. De argumentatie was dat er zaaktypen zijn die in een tijdsbestek van uren opgelost wordt, niet dagen of weken. De startdatum van de zaak is dan precies hetzelfde als de einddatum, en via de statusprogressie is er wel nauwkeurigere informatie over wanneer de zaak precies beeindigd is.

sergei-maertens commented 5 years ago

Bijvoorbeeld wanneer die einddatum als zoeksleutel gebruikt wordt oid. (al weet ik niet in welke gevallen je dat zou doen).

Dit was inderdaad ook een argument. Blijkbaar is er een use-case waarbij zaken gezocht worden waarbij de eindgebruiker weet dat die afgesloten was 'tussen 12.00 en 14.00' bijvoorbeeld. Enkel op datum kunnen zoeken geeft te veel zoekresultaten als je nauwkeuriger weet wanneer iets afgesloten was.

ArjanKloosterboer commented 5 years ago

Ik ben benieuwd naar die use-case ...

TCIMEddy commented 5 years ago

@sergei-maertens was dit niet al gerealiseerd?

michielverhoef commented 5 years ago

In de huidige OAS 3 is het nog een datum, geen datumTijd. https://ref.tst.vng.cloud/zrc/api/v1/schema/#operation/zaak_read

VNG-Realisatie / gemma-zaken

Als API-consumer wil ik dat de Zaak.einddatum een datetime wordt #659