nl-portal / nl-portal-backend-libraries Goto Github PK

Als gebruiker van het NL Portal
Wil ik mijn lopende zaken zien op de overzichtpagina
Zodat ik direct kan doorklikken nadat ik ben ingelogd

Please use G translate...

Er moet een refinement gedaan worden over hoe ontwikkelaars lokaal kunnen werken.

Meerdere opties zoals;

• Docker compose
• Aan test omgeving connecten
• BFF mocken
• APIs achter BFF mocken
• etc

Aditional questions:

• Meer test data?
• Moeten we ook wat met e2e testing om te zorgen dat de koppeling met GraphQL etc. blijft werken? In elk geval een paar smoke-tests?

Issue komt voort uit brainstorm sessie tussen Yolijn en Youri

Doel

Het opslaan van bestanden in een omgeving zonder Documenten API.

Context / achtergrond

NL Portal kan worden ingezet buiten het ZGW landschap. In dat geval is er geen Documenten API beschikbaar om bestanden in op te slaan en is er een alternatief nodig.
De meest logische optie daarvoor is het gebruik maken van een service van de Cloudprovider. Voor AWS is dat Amazon S3 (simple storage service).

Wat moet er gebeuren - wat is er nog niet en hebben we wel nodig?

Een directe koppeling tussen het Portaal en AWS S3. Daarvoor zijn twee opties:

• NL Portal frontend stuurt het bestand naar de backend. De backend stuurt het bestand naar AWS S3.
• NL Portal frontend vraagt een tijdelijke access key aan bij de backend en stuurt het bestand daarmee naar AWS S3.

Wat is het eindresultaat?

Eindgebruikers van het Portaal kunnen bestanden uploaden in verzoek- of taakformulieren.

Wat valt er buiten scope?

Impact - hoeveel inspanning kost dit?

Inschatting door PO: M
Inschatting door SA: S/M/L/XL

Besluiten roadmap overleg

To be refined

Update pipelines with:
• Unit tests en linting stap in GitHub workflow in de nieuwe nl-portal/nl-portal-frontend-libraries

Op dit moment wordt er enkel 1 configuratie ondersteund voor de Documenten-API.
De wens is om meerdere configuraties te ondersteunen, en dat de juiste configuratie wordt geselecteerd obv de document-URL.

Het plugin framework wat al beschikbaar is in Valtimo, is mogelijk bruikbaar binnen de portal. Dit framework ondersteund al meerdere configuraties per plugin.

Via een spike willen we erachter komen:

• of de gewenste oplossing werkbaar is
• of er aanpassingen nodig zijn in het framework
• hoeveel tijd dit gaat kosten
• hoe de authenticatie in zijn werk gaat binnen de portal

To be refined...

• Hoe start ik de boel op?
• Hoe link ik de portal-libraries aan de portal-implementatie
• Wat als ik een nieuw component wil toevoegen waar ik data voor nodig heb, maar die specifiek is voor mijn omgeving (implementation) zoals een header/breadcrumb/footer menu?
• Welke configuraties zijn al voor mij beschikbaar om mijn implementatie er net anders uit te laten zien dan die van iemand anders? (Storybook ofzo)
• Documentatie hoe ik testdata toe kan voegen om te testen of mijn implementatie de verschillende soorten data goed toont
• Contribution documentatie: wanneer moet ik een test toevoegen, waaraan moet mijn PR voldoen voordat hij gereviewed wordt etc.
• Documentatie in de frontend-libraries (of een verwijzing naar de backend-libraries) hoe de data precies werkt, waar komt die vandaan, hoe werkt GraphQL, is daar versioning van?
• Is er documentatie over welke data er beschikbaar is en op de planning staat? (GitHub issues?)
• Is er een manier om zelf een nieuwe databron aan te sluiten? Bijvoorbeeld koppeling met de huidige MijnDenHaag

Als NL Portal gebruiker
Wil ik dat de 'lopende zaken' pagina een vriendelijkere melding geeft
Zodat ik niet alleen de botte tekst 'Er zijn geen lopende zaken.' zie

To be refined by @ThomasRitense
https://central.sonatype.com/search?smo=true&q=nl.nl-portal

Bug report from a DenHaag customer

A customer in klantportaal had a part of their last name translated (xxx of xxx werd xxx van xxx) and nationality was set to english (Where NL shouldve been shown)

Furthermore (Maybe create a 2nd ticket for this after analysis), her maiden name was displayed while in BRP the aanschrijfnaam/displayname(?) is the her Husbands last name...

Related pictures are anonimized but wont post them here. They are available via Jan and Thomas (RE: Verkeerde naam en Nationaliteit in het Klantportaal)

Doel

Als NL Portal implementatie team
Wil ik een Github-template hebben voor de NL Portal Backend
Zodat ik snel kan starten met ontwikkelen

Context / achtergrond

• Het project NL Portal-libraries staat in de NL Portal-organisatie in Github: nl-portal-backend-libraries.
• In deze repository is een 'app'-module beschikbaar die twee Spring Boot-applicatiemodules bevat ('gzac' en 'portal')
• Deze libraries repository wordt gebruikt om de NL Portal-libraries te publiceren naar Maven Central
• De libraries en implementatie moeten gescheiden zijn: de implementatie (Spring Boot-applicatie) moet in een aparte repository staan
• Ondersteunende diensten kunnen gestart worden met Docker Compose: https://github.com/generiekzaakafhandelcomponent/gzac-docker-compose/blob/main/zgw-platform.yaml

Wat moet er gebeuren - wat is er nog niet en hebben we wel nodig?

Wat is het eindresultaat?

• De implementatierepository is een Github-template met de naam 'nl-portal-backend-template'
• De inhoud van nl-portal-backend-libraries -> app/gzac zou onderdeel moeten zijn van deze template
  • README-bestand is up-to-date met informatie over het opstarten van de applicatie
• Een Docker-compose template wordt gebruikt om een postgres-database te starten bij het opstarten van de applicatie

Wat valt er buiten scope?

Impact - hoeveel inspanning kost dit?

Inschatting door PO: S
Inschatting door SA: S/M/L/XL

Besluiten roadmap overleg

Doel

Het virus-scannen van alle bestanden die in het Portaal worden geupload.

Context / achtergrond

In het Portaal kunnen gebruikers bestanden uploaden, bijvoorbeeld bij het invullen van een taakformulier.
Die bestanden moeten op virussen worden gecontroleerd om te voorkomen dat schadelijke bestanden worden opgeslagen op de schijf van het DMS.

Wat moet er gebeuren - wat is er nog niet en hebben we wel nodig?

Optionele integratie tussen de Portal backend en een ClamAV service die als Docker container draait. Terugkoppeling van het scanresultaat naar de Portal frontend.

Wat is het eindresultaat?

Alle bestanden worden gescand voordat ze worden opgeslagen in de Documenten API. Gebruikers krijgen feedback als een bestand niet geaccepteerd wordt.

Wat valt er buiten scope?

• Het configureren van een ClamAV instantie/service in de infrastructuur. Deze bestaat als het goed is al.

Besluiten roadmap overleg

Acceptatie criteria

• Alle bestanden worden gescand voordat ze worden opgeslagen in de Documenten API
• De ClamAV implementatie wordt via een interface geïmplementeerd zodat er later andere implementaties kunnen worden toegevoegd.
• Standaard wordt geen virusscanning uitgevoerd. Om deze feature aan te zetten moet dit geconfigureerd worden in de applicatie instellingen (application.yaml of ENV).
• De licentie van de gebruikte ClamAV library is compatible met EUPL
• De implementatie gebruikt de clamd service van de host

Dev note

• De DataBuffer / InputStream kan je maar 1 keer uitlezen, dus de inhoud moet worden gekopieerd BufferedInputstream of vergelijkbaar.
• Unit tests: waar mogelijk
• Integration tests: happy flow (geen virus), via Docker

Impact - hoeveel inspanning kost dit?

Inschatting door PO: M
Inschatting door SA: M (3-4 dagen)

Doel

Als inwoner van de gemeente Den Haag wil ik graag meer zaakdetails in het klantportaal kunnen zien dan die nu gepresenteerd worden.
Ik zou bijvoorbeeld graag de inhoudelijke gegevens van een vergunning of een erfpachtcontract willen zien.

Context / achtergrond

De omgevingswet omvat een groot aantal verschillende vergunningen die allemaal verschillende relevante zaakdetails met zich mee brengen.
Deze zaakdetails worden door GZAC opgeslagen in het Zaakdetails Object in de Objecten API.
Per Zaaktype is het mogelijk om een 'eigen' Objecttype te maken voor de Zaakdetails, omdat de details voor elk Zaaktype anders zijn.

Een deel van deze Zaakdetails moet ook gepresenteerd worden aan de inwoner in het Klantportaal. Hiervoor moet een nieuw Zaakdetails (Klantportaal) Objecttype voor gemaakt worden.
Dit Objecttype is niet perse hetzelfde als het Zaakdetails Objecttype dat GZAC gebruikt, omdat wellicht niet alle Zaakdetails in het Klantportaal gepresenteerd moeten worden.

Wat moet er gebeuren - wat is er nog niet en hebben we wel nodig?

• Vaststellen van een structuur/standaard voor het Zaakdetails Objecttype voor het Klantportaal.
• Aanmaken van het Zaakdetails (Klantportaal) Object door GZAC bij het aanmaken van de Zaak
• Bijwerken van het Zaakdetails (Klantportaal) Object door GZAC op relevante momenten
• Koppelen van het Zaakdetails (Klantportaal) Object aan de Zaak door GZAC
• Tonen van de inhoud van het Zaakdetails (Klantportaal) Object op de Zaak details pagina

Wat is het eindresultaat?

• De inwoner kan in het Klantportaal de Zaak inzien, en ziet daarbij de inhoudelijke informatie uit het Zaakdetails (Klantportaal) Object

Wat valt er buiten scope?

Impact - hoeveel inspanning kost dit?

Inschatting door PO: M/L
Inschatting door SA: S/M/L/XL

Besluiten roadmap overleg

Spring 2 will be end of support on 18 october for open source(?)

Both Backend-libraries & -libraries need to be updated to Spring 3.

• Spring security must be carefully checked as it has some breaking changes
• GraphQl also has some compatibility issues

GraphQL now:
query { GetTasks { getTasks { content { id objectId formId title status date data } } }

Should be:
query { getTaken { content { date formulier { type //id of url value //https://objectenapi.nl/uuid } id objectId status identificatie { type value } } } }

Include type in request to get form definition. Based on type, BFF should either serve form definition from database (type = id) or retrieve form definition from the Objecten API (type = url)

Als NL Portal gebruiker
Wil ik graag dat mijn roepnaam zichtbaar is in de titel van de overzichtspagina
Zodat de pagina er persoonlijker uit ziet

The real fix is planned via #24
This bugfix should only ensure no backend error when trying to retrieve a zaak where the document is not in OpenZaak.
Its ok for now (Until #24 is fixed), to just not display the documents.
Note that the documents which are in openzaak of course need to be displayed!

Fix can probably be done in OpenZaakClient.kt

Bill of Materials samenstellen en gebruiken in backend / backend-template

youri kan dit aanvullen vanuit zijn word document