Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Als gebruiker van het DRC weet ik soms het IO-type niet van te voren #930

Closed
23 tasks
joeribekker opened this issue Apr 18, 2019 · 1 comment
Closed
23 tasks

Comments

@joeribekker
Copy link
Collaborator

...dus kan ik geen IO aanmaken want IO-type is verplicht.

Concrete case kwam van Circle Software die aangaf dat (naast dat het anders werkt in hun eigen implementatie) dat als je een document in scant, het document wel gemaakt moet worden maar je weet niet wat je hebt gescant. Zij hebben hun software hierop aangepast zodat IO-type niet meer verplicht is, maar pas gezet wordt bij het relateren aan een Zaak.

Technisch valt dit prima op te lossen: Relatie met Zaak (of Object) mag alleen als IO-type bekend is.

Vraag is vooral of er argumenten zijn om dit NIET te doen.

Bepaling prioriteit door PO

  • verbreding of verdieping API's
  • stimuleert gebruik door gemeenten
  • stimuleert gebruik door leveranciers

... eventueel nog toelichting door PO

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.
  • Globale oplossingsrichting bekend
  • 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 en waarmee de user story getest kan worden.
  • De technische specificatie (standaard.md) is gepubliceerd leesbaar
  • Gebruikte gegevensmodel is na iedere iedere sprint bijgewerkt.

Acceptatiecriteria

  • De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
  • Er zijn geen bekende GEMMA 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]
  • Documentatie bijwerken
  • Gegevensmodel bijwerken
@TCIMEddy TCIMEddy added this to Backlog (nog) geen Prio in 2. Scrum ZGW Voorbereiding via automation Apr 19, 2019
@Hugo-ter-Doest
Copy link
Contributor

Vooralsnog denk ik dat je dit niet moet toestaan. Je moet een soort invariant hanteren voor registratiecomponenten dat een minimale set metadata beschikbaar is voor alle geregistreerde informatieobjecten. IO-type hoort daarbij. Documenten waarvan het type nog niet bekend, leven nog even in de client van de registratiecomponent. Deze moeten nog door een soort intake voordat ze in de DRC kunnen worden geregistreerd.

@TCIMEddy TCIMEddy removed this from Backlog (nog) geen Prio in 2. Scrum ZGW Voorbereiding Apr 22, 2019
@TCIMEddy TCIMEddy added this to Done - Sprint 5 in 3. Gereed en Archief Apr 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3. Gereed en Archief
  
Done - Sprint 5
Development

No branches or pull requests

2 participants