gemma-zaken
gemma-zaken copied to clipboard
VNG-Realisatie
Als developer verwacht ik meer filter opties
Als developer verwacht ik dat ik op de zaak API's een lijst kan samenstellen van zaken waarop een gebruiker vanuit een rol actie moet ondernemen (bijvoorbeeld een medewerker die beheerder is) t.b.v een werkvooraad.
Daarvoor zou ik op het zaken endpoint moeten kunnen filteren op rollen_betrokkene en rollen_betrokkeneType. Maar dat kan nu niet. Andersom (vanuit rollen) zou an zich ook kunnen maar is denk ik minder net, al was het maar omdat dan bijna alle zaak proporties filterbaar zouden moeten worden gemaakt op het rollen endpoint.
Dit lijkt mij voor een verdere implementatie overigens brekend, het weergeven van een werkvoorraad lijkt mij persoonlijk minimale eis voor zaaksystemen. De enige methode die ik daar als developer nu voor (lijk) te hebben is om beide lijsten (alle zaken met een bepaald status en alle rollen met bepaalde betrokkene en type) op te halen en onderling te vergelijken.
Maar dat wordt in een productie status natuurlijk snel gek, het zou betekenen dat ik een loop in een loop moet gaan doen om data te vergelijken. Das serieuze systeem belasting en laadtijd. Daarnaast zou ik dan de data die ik niet wil hebben (zaken van een andere behandelaar bijvoorbeeld) wel hebben opgehaald maar niet gebruiken. Wat vanuit loging, privacy by design en last op broncomponenten en dataverkeer natuurlijk weer onwenselijk is.
Neem voor de gedachte een een situatie waarin een een ambtenaar in een middelgroote gemeente een jaartje op openzaak heeft gewerkt. 10 zaken per dag? Hebben we het over 3500 ish rollen waar hij als betrokkene in hangt versus alle openstaande zaken in de gemeente na een jaar? 30.000? Krijgen we 30.000 *3500 vergelijkingen. Das 3.675.000.000.000 berekeningen die je even door je cluster heen trekt. Succes met dat laadscherm. Nog even los van de logs die je crieërd en dataverkeer en het geheugen gebruik van al deze objecten onderwijl je ze aan het vergelijken bent.
Overigens staat in aanvulling hierop #1586 ook nog steeds open.
+1 van mij.
En eigenlijk zie ik dit zelfs breder binnen de context van een krachtige (document) search API, waar je veel flexiber kan omgaan met zoekdimensies. Achterliggende tech voor dat zou dan Elastic Search of Solr o.i.d. kunnen zijn.
Middels #1625 wordt de filtering uitgebreid.
Echter met deze uitbreiding kun je nog steeds niet gecombineerd filteren op een betrokkene en een status van een zaak omdat de status van een zaak in een ander endpoint zit, te weten /statussen. Dus ik weet niet of de vraag van @rubenvdlinde hiermee volledig beantwoord is.
De oplossingsrichting is vergelijkbaar met die om te filteren op betrokkene en zaaktype.
Ik ben bang dat ik de oplossing echt niet zie, dit moet wachten tot @HenriKorver weer terug is.
Wij zijn op dit moment bezig met de implementatie van de zaken endpoint in ons KCS. Ik heb hieromtrent eerder issue #1268 voor aangemaakt maar heb toch nog steeds niet het idee dat het echte pijnpunt is opgelost. Wij willen zaken kunnen filteren op basis van een betrokkene (bijvoorbeeld o.b.v. bsn) en een status. Volgens mij is dit vergelijkbaar hetgeen @rubenvdlinde hierboven beschrijft in dit issue. Zoals het zaken endpoint nu gedefinieerd is lijkt het nog steeds niet mogelijk om te filteren op een betrokkene en moet je op een zeer omslachtige manier via /rollen dit voor elkaar krijgen. Dit zal zoals hierboven beschreven zeker leiden tot performance issues.
#1625 gaat ook over hetzelfde issue. De oplossing zoals daar beschreven zal niet leiden tot efficiency mijns inziens. Aangezien er nu al zoveel issues over gemeld zijn, lijkt mij dat dit z.s.m. verduidelijkt en/of opgelost moet worden.
+1 van mijn kant, en ik heb ook ideetjes over hoe dit er moet/kan gaan uitzien.
Je kan op de /zaken endpoint nu wel direct filteren op rollen/betrokkenen (dus je hoeft niet via /rollen endpoint te gaan eerst), maar het is gewoon nog niet flexibel genoeg voor verschillende combinaties.
En op gebied van status is er inderdaad nog niets voorzien. Ik ben zelf wel benieuwd wat je precies bedoelt met het filteren op status, kan je daar een voorbeeld van geven?
binnen de context van Utrecht zijn we nu eigenlijk client-side een Elastic Search index aan het onderzoeken om te kijken of dat haalbaar is als tussenoplossing.
@sergei-maertens Je geeft aan dat dit al kan op de /zaken eindpoint. Hoe dan???
In ons geval wil ik in eerste instantie alleen openstaande zaken van een betrokkene in het KCS zien. Ik zou dus of op status willen filteren waarbij de laatste status van de zaak nog niet is bereikt of misschien nog handiger kunnen filteren op een gevulde einddatum ja/nee. Dit laatste is volgens mij nog niet mogelijk, toch?
Oh, zo te zien loopt de referentie-implementatie achter, dat is niet handig. Echter, bijvoorbeeld op de API spec van Open Zaak zie je de querystring parameters:
-
rol__betrokkene(indien je een BRP API url hebt, bijvoorbeeld) -
rol__betrokkeneIdentificatie__natuurlijkPersoon__inpBsnindien je gebruik maakt vanbetrokkeneIdentificatie.inpBsnin deRolresource -
rol__betrokkeneIdentificatie__medewerker__identificatiegelijkaardig aan bovenstaand, maar dan voor medewerker.
Deze waren onderdeel van #1625
Met #1686 komt daar ook rol__betrokkeneIdentificatie__organisatorischeEenheid__identificatie bij.
@basretera
In ons geval wil ik in eerste instantie alleen openstaande zaken van een betrokkene in het KCS zien. Ik zou dus of op status willen filteren waarbij de laatste status van de zaak nog niet is bereikt of misschien nog handiger kunnen filteren op een gevulde einddatum ja/nee. Dit laatste is volgens mij nog niet mogelijk, toch?
Ja, laatste status wel/niet bereikt hangt 1-op-1 samen met einddatum wel/niet gezet. Dus dat lijkt me een prima suggestie om hierop te kunnen filteren. Technisch makkelijk te implementeren en toe te voegen aan de standaard. Ik vermoed dat dit makkelijker behandeld wordt als dit z'n eigen issue wordt. Ik ben zelf geen onderdeel van dit team meer, maar zit nu aan de vragende kant :)
Oh, zo te zien loopt de referentie-implementatie achter, dat is niet handig. Echter, bijvoorbeeld op de API spec van Open Zaak zie je de querystring parameters:
rol__betrokkene(indien je een BRP API url hebt, bijvoorbeeld)rol__betrokkeneIdentificatie__natuurlijkPersoon__inpBsnindien je gebruik maakt vanbetrokkeneIdentificatie.inpBsnin deRolresourcerol__betrokkeneIdentificatie__medewerker__identificatiegelijkaardig aan bovenstaand, maar dan voor medewerker.
Dat is inderdaad niet zo handig. Wat is nu leidend?? De specificatie https://zaken-api.vng.cloud/api/v1/schema/ moet toch leidend zijn, of heb ik iets gemist? Hierin is bovenstaande niet te vinden.
Daarnaast erg jammer dat de rest van de betrokkene filters t.b.v. NPS, NNP en vestiging niet zijn meegenomen. Als ik nu dus zaken van een vestiging moet ophalen, moet ik nog steeds via het /rollen endpoint. Om dit even concreet te maken zou ik graag van de volgende filters gebruik maken:
- betrokkeneIdentificatie__natuurlijkPersoon__inpBsn
- betrokkeneIdentificatie__natuurlijkPersoon__anpIdentificatie (lagere prioriteit)
- betrokkeneIdentificatie__natuurlijkPersoon__inpA_nummer (lagere prioriteit)
- betrokkeneIdentificatie__nietNatuurlijkPersoon__innNnpId
- betrokkeneIdentificatie__nietNatuurlijkPersoon__annIdentificatie (lagere prioriteit)
- betrokkeneIdentificatie__vestiging__vestigingsNummer
- betrokkeneIdentificatie__organisatorischeEenheid__identificatie
- betrokkeneIdentificatie__medewerker__identificatie
Waarom is ervoor gekozen om alleen de vetgedrukte mee te nemen?
Ja, laatste status wel/niet bereikt hangt 1-op-1 samen met einddatum wel/niet gezet. Dus dat lijkt me een prima suggestie om hierop te kunnen filteren. Technisch makkelijk te implementeren en toe te voegen aan de standaard. Ik vermoed dat dit makkelijker behandeld wordt als dit z'n eigen issue wordt. Ik ben zelf geen onderdeel van dit team meer, maar zit nu aan de vragende kant :)
Ik heb nieuw issue hiervoor aangemaakt namelijk #1700.
Oh, zo te zien loopt de referentie-implementatie achter, dat is niet handig.
@joeribekker Hoe kan het dat de referentie-implementatie achterloopt?
Waarom is ervoor gekozen om alleen de vetgedrukte mee te nemen?
Simpelweg om de change zo klein mogelijk te houden en te voldoen aan de noden die we op dat moment bij Utrecht hadden.
Waarom is ervoor gekozen om alleen de vetgedrukte mee te nemen?
Deze repository is leidend! Met Open Zaak hebben we referentie-implementatie, en we kijken naar wat er gebeurt in deze repo. Als we zien dat een voorstel goedgekeurd wordt, dan beginnen we alvast aan implementatie in Open Zaak. Deze changes zijn ook nog geen onderdeel van een officiële Open Zaak versie, we draaien een nightly build in Utrecht hiervan.