ODCR: Organisatie datamodel + API resource

[sergei-maertens]

Split off from #8

Description (why)

uit PSA: Deelnemende gemeenten willen ook namens organisaties waar zij aan deelnemen, bijvoorbeeld gemeenschappelijke regelingen, documenten kunnen publiceren.

Dit vraagt erom dat organisaties en organisatieonderdelen in de ODRC vastgelegd kunnen worden. Dit vraagt om aanpassingen in o.a. de data-opslag en de gebruikersinterface “Modelbeheer”. Organisaties moeten door beheerders gecreëerd, geraadpleegd, gemuteerd en ge(de)activeerd kunnen worden. Via de ODRC API moeten zij geraadpleegd kunnen worden.

Acceptance criteria

• Organisation model is defined and can be managed in the admin interface
• /api/v1/organisaties and /api/v1/organisaties/:id API resources exist, with CRUD capabilities
• Valuelists are imported:
  • Register gemeenten compleet
  • Register overige overheidsorganisaties compleet
  • Register samenwerkingsorganisaties compleet
• Documentation is updated (readthedocs).

Implementation tasks

• Implement data model for Organisatie and OrganisatieOnderdeel and wire up to the admin interface

  • Model fields: identifier, naam, oorsprong (enum as usual), actief (boolean, default=False)
  • identifier must be unique
  • Search through identifier and name fields
  • List filter on origin, actief
  • Bulk admin actions to publish/unpublish organisations
  • Tabular Inline for organisatieonderdelen

• Add API endpoint for CRU operations /api/v1/organisaties

  • READ
    • Paginated list (there will be a lot of records)
    • List endpoint must support filter parameters for actief, origin. Search options for identifier and name (so that UIs can implemented autocomplete on name). By default, use actief=true if unspecified. Other options are false and alle (similar to ZGW API's Catalogi API, for zaaktypen/informatieobjecttypen)
    • Detail endpoint: as usual - a record being active/not active has no impact
  • CREATE
    • Create implies origin == 'zelf_toegevoegd'
    • identifier is generated server-side
    • user can only provide name and actief
  • UPDATE
    • name can be updated only if origin is zelf_toegevoegd
    • actief can always be updated
    • identifier and origin can never be updated

• Add management command to populate the Organisaties from the waardelijsten

  • Management command will be run periodically and must result in django fixtures (using natural keys)
  • The fixtures will be included in the docker image and need to be automatically loaded on container/application start up (post migrate hook)
  • The fixture must be post-process to exclude the actief field, otherwise a container restart would undo the activations performed by a functional admin

Draft API resource definition here: #8 (comment)

[sergei-maertens]

TODO: finish refining/technical specs for Bart

[sergei-maertens]

Burgerportaal: volgt uit geïndexeerde data - out of scope voor dit ticket.

Publicatiecomponent:

• Bij inlezen organisaties: alles deactiveren
• Functioneel beheer activeert in ODRC wat nodig is
• ODPC krijgt beperkte set

[sergei-maertens]

Re-opening because the fixture post-processing to make sure organisations are deactivated by default/initially is not picked up yet.

The functional requirement here is:

• When a fresh instance is set up/deployed, all the organisations are present, but not active
• An administrator activates in the admin the organisations that are relevant to them
• If the fixture gets updated (extra organisations are added), then the new organisations are added and deactivated by default. Existing activated organisations are not deactivated.

[MarcoKlerks]

Testresultaten:

1. De lijst aan gemeenten (filter: Municipality list) is leeg. Inlezen is niet gebeurd of mislukt.
2. Alle organisaties staan op "actief". In de vorige opmerking hierboven is afgesproken dat ze standaard op "niet actief" gezet zouden worden, zodat de gewenste organisaties handmatig op "actief" gezet kunnen worden.
3. In de admin-interface heet dit onderdeel "Organisations". In het Engels dus. De andere onderdelen onder "Metadata" hebben een Nederlandse naam gekregen ("Informatiecategorieën" en "Thema's"). Graag dit onderdeel hernoemen naar "Organisaties" t.b.v. consistentie.
4. Graag de oorsprong en dus ook de filters in het Nederlands.

Ik zie overigens dat de API-documentatie (ReDoc) ook afwisselend in het Engels dan wel in het Nederlands geschreven is. Ik voeg een user story toe om dit te verbeteren.

[sergei-maertens]

#110 will address some of these remarks! I'll put the ticket back in testing once that's tackled.

Re 3. and 4.: translations will follow soon, I typically do these in batches.

[MarcoKlerks]

Hertest: alle punten zijn opgelost