ODRC: Publicatie resource

[sergei-maertens]

Split of from #2

Als architect wil ik via API's publicaties met documenten kunnen opslaan en ontsluiten, zodat we hierbovenop interactiecomponenten (ODPC en ODBP) kunnen ontwikkelen.

The "publication" resource will act as a container for documents being published. It logically groups related documents. At the time of writing, there's no such container concept in the DiWoo standard, but for GPP-WOO we wish to introduce this.

Acceptance criteria (what)

• Via een API kan een publicatie (data-object) gecreëerd, geraadpleegd, gemuteerd en verwijderd worden.

• Minimaal worden de volgende gegevens vastgelegd: identifier, officieleTitel, verkorteTitel, omschrijving,

  • Attribuutnamen zijn niet heilig, maar voor de herkenbaarheid hanteer ik gemakshalve de DiWoo-termen
  • DiWoo ondersteunt het toekennen van meerdere identifiers, titels en omschrijvingen. Voor nu is het voldoende als we voor deze velden één waarde kunnen opslaan.

• Het is zowel mogelijk om één publicatie te raadplegen (op basis van de identifier) als om een lijst (array) van publicaties op te vragen.

  • Bij het opvragen van een lijst kan sortering en pagination toegepast worden.

• De creatie, mutatie of verwijdering van een publicatie wordt gelogd (zie ODRC: Set up foundation for logging/audit trails #16 )

• Optioneel: de raadpleging van een of meerdere publicaties wordt gelogd (zie ODRC: Set up foundation for logging/audit trails #16 ). Graag laten weten of dit wordt meegenomen!

• De API specificatie is bijgewerkt (ReDoc, Swagger)

• De documentatie is bijgewerkt (Read the Docs)

• Een grafisch datamodel van de database is beschikbaar / bijgewerkt (op GitHub of Read the Docs of elders)

Development tasks

See also GPP-Woo/GPP-app#34 for the UI-side of things.

• Add data model for Publication, with the fields:
  • uuid (server generated, will fullfill the identifier acceptance criterium)
  • official_title (required)
  • short_title (optional)
  • description (optional)
  • created_on (server generated timestamp, for audit logging reasons)
• Register the model in de admin interface
  • It must be possible to search on both of the title fields and the uuid
  • list filter on created_on
  • date hierarchy on created_on
• Mutations in the admin must be logged in the audit trails
• Add the API endpoint /api/v1/publicaties
  • READ (list)
    • Paginated list endpoint
    • Filter parameters can be done later
    • Add ordering GET parameter: possible fields are created_on, official_title, short_title
  • READ (detail)
    • Use the uuid for detail lookups
  • CREATE (HTTP POST call)
    • Client can submit the official_title, short_title and description fields
    • Must receive the request headers Audit-User-Id, Audit-User-Display-Name and Audit-Toelichting and create audit record that publication was made by this user (they are now the owner of this publication)
    • Server generates UUID and created_on timestamp
  • UPDATE (HTTP PUT and PATCH)
    • Client can submit the official_title, short_title and description fields
    • Must receive the request headers Audit-User-Id, Audit-User-Display-Name and Audit-Toelichting and create audit record that publication was modified by this user (they are now the owner of this publication)
  • DELETE
    • Audit log that publication is deleted
    • Hard delete - gone is gone, might become soft delete in the future

Draft API resource exposed in the endpoint (all CRU) operations:

Publicatie:
  type: object
  properties:
    uuid:  # readonly
      type: string
      format: uuid
    officieleTitel:
      type: string
    verkorteTitel:
      type: string
    omschrijving:
      type: string
    registratiedatum:  # exposes the `created_on` field, readonly
      type: string
      format: date-time
    

[sergei-maertens]

@MarcoKlerks I've copied over your acceptance criteria and fixed the markdown for the links, this new specification should capture our Slack discussion outcome but please double check!

If all is well, you can assign it to Bart.

[MarcoKlerks]

@MarcoKlerks I've copied over your acceptance criteria and fixed the markdown for the links, this new specification should capture our Slack discussion outcome but please double check!

If all is well, you can assign it to Bart.

@sergei-maertens @bart-maykin Checked and assigned to Bart! If the tasks are clear, you can change the status to 'ready'.

[MarcoKlerks]

Logging moet eerst af, voordat deze story afgemaakt kan worden. (impediment)

[sergei-maertens]

Logging geregeld via #16, ready for testing