search

GPP-Woo / GPP-app

1 stars 0 forks source link

ODPC: Publicatie intrekken #39

Closed MarcoKlerks closed 1 month ago

MarcoKlerks commented 2 months ago

Als gebruiker wil ik een publicatie in kunnen trekken, zodat ik een foutieve publicatie kan herstellen.

Acceptatie criteria

Notities Voor het intrekken van een publicatie gebruiken we in ODPC de bestaande PUT methode. Het registratie component handelt verdere intrekking van publicatie en documenten af wanneer publicatie wordt ingetrokken: https://github.com/GeneriekPublicatiePlatformWoo/registratie-component/issues/64

Taken

felixcicatt commented 2 months ago

@MarcoKlerks we moeten een besluit nemen over hoe dit precies gaat werken. Doet de ODPC een enkel verzoek naar de ODRC en zorgt de ODRC er automatisch voor dat ook de documenten ingetrokken worden of worden dit losse calls vanuit ODCP? In het laatste geval zou je rare situaties kunnen krijgen als de publicatie succesvol ingetrokken wordt maar er bij de documenten iets mis gaat.

Ben je het er daarnaast mee eens dat je wel nog kan doorklikken op een ingetrokken publicatie, maar dat de detailpagina dan een read only weergave geeft?

MarcoKlerks commented 2 months ago

Goede vraag! :-) Ook even afstemmen met @sergei-maertens ...

Ik heb een lichte voorkeur om de procedure in het ODPC te regelen, maar ik twijfel.

In de procedure zou ik dan sowieso eerst de documenten intrekken om als laatste de publicatie in te trekken. Mocht een document-intrekking mislukken, dan kan de procedure afgebroken worden en aan de gebruiker een foutmelding getoond worden. Daarmee voorkomen we "zwevende" documenten en ervaart de gebruiker (die de publicatie wil intrekken) druk om contact op te nemen met de beheerder.

Mijn lichte voorkeur voor het ODPC is omdat ik rekening houd met een mogelijke toekomstige wens om een intrekking terug te draaien. Moeten dan alle "ingetrokken" documenten weer gepubliceerd worden of moet hier een selectie in gemaakt kunnen worden? Moet de gebruiker dan de mogelijkheid krijgen om ook direct metadata te wijzigen? Deze mogelijke wens ga ik overigens pas als story opnemen als daar om gevraagd wordt. Desalniettemin neig ik hierom dat procedures zo veel mogelijk op CommonGround-laag 4 (processen) worden gerealiseerd worden i.p.v. laag 2 (API).

Daarentegen zie ik ook wel en argument om de intrek-procedure in de API te regelen. Dit heeft voordelen wanneer ooit vanuit een gekoppeld (zaak-)systeem een publicatie ingetrokken moet worden.

Ik sta uiteraard open voor andere argumenten en afwegingen.

sergei-maertens commented 2 months ago

ik zou dit in het registratiecomponent regelen puur omdat je dan de atomiciteit van database transacties hebt. alles of niets. je kan nog steeds een dergelijke actie ook per-document inregelen mocht de functionele behoefte daarvoor zijn.

het is ook het meest efficient - meerdere network calls duren langer dan 1 enkele call, en het maakt het component makkelijker uitwisselbaar denk ik.

ook zou je de call voor het intrekken/terugdraaien kunnen parametriseren zodat je kan aan/afvinken wat er wel/niet meegaat. voor mij is de data-integriteit hier de doorslaggevende factor om dit in de ODRC te leggen.

MarcoKlerks commented 1 month ago

Besproken dd 07-10-2024 : Busienss rules realiseren in ODRC ipv ODPC. User story omzetten door Marco

MarcoKlerks commented 1 month ago

ODRC #64 geschreven t.b.v. vorige opmerking.

nijmra commented 1 month ago

@MarcoKlerks deze story gister ready gemaakt, wil jij nog check doen?

MarcoKlerks commented 1 month ago

Testresultaten: Ik heb de koppeling met het ODRC niet kunnen testen, omdat ODRC #64 nog niet opgeleverd is. Die zorgt er ook voor dat ik de consequenties van een intrekking voor de documenten niet heb kunnen testen. Het een en ander zal opgepakt moeten worden bij #68 .

Voor nu akkoord. Ik verwacht wel input wanneer we gebruikers laten testen, maar laten we eerst even afwachten hoe zij gaan reageren voordat ik onnodige verbeteringetjes in de opmaak ga vragen e.d..