ODRC: Set up foundation for logging/audit trails

[sergei-maertens]

Als informatiebeveiliger / beheerder wil ik dat wijzigingen gelogd worden, zodat ik later kan reconstrueren wie wanneer wat heeft gedaan met de gegevens (bijvoorbeeld omdat er iets niet klopt).

** Description (why)**

Acceptance criteria (what)

• De creatie, mutatie of verwijdering van een data-object wordt gelogd (m.u.v. de log-records zelf)
• Optioneel: de raadpleging van een data-object wordt gelogd. Graag laten weten of dit wordt meegenomen!
• Uit de logging blijkt:
  • welke handeling is uitgevoerd,
  • op welke data-objecten de handeling is uitgevoerd,
  • welke gebruiker de handeling heeft uitgevoerd,
  • wanneer (datum en tijd) de handeling is uitgevoerd,
  • op welke wijze de handeling is uitgevoerd (welk component sprak de API aan?)
  • met welk resultaat (gelukt/mislukt, liefst met meer info, zoals wat gewijzigd is).
• De logging is niet muteerbaar.
• De documentatie is bijgewerkt (Read the Docs)
• Een grafisch datamodel van de database is beschikbaar / bijgewerkt (op GitHub of Read the Docs of elders)

Specific details (how)

Test plan

Tasks

• Add django-timeline-logger dependency
• Set up admin integration for django-timeline-logger so that log records can only be read, even for superusers (proxy model)
• Set up admin-index configuration to put the audit trail in the "Logging" category in admin-index
• Add a logging package/module that wraps the ORM actions
• Each log record needs at minimum:
  • User identifier (taken from API call request headers, and/or django admin overrides). These will contain users that don't exist in accounts.User!
  • User representation/display name, e.g. the name / initials + last name
  • Reference to the object that was acted upon (use the GFK)
  • Type of action, this may be taken from audit trail request headers. E.g. create, update, publish, unpublish/retract
  • Any additional metadata relevant to the action being logged
• Ensure that log records can be searched in the admin, based on user (ID + representation), date hierarchy, type of action
• API endpoints must support (and require!) custom request headers for audit trails: Audit-User-Representation, Audit-User-ID, Audit-Remarks. ODPC/ODBP are responsible for populating these.

[MarcoKlerks]

@sergei-maertens Ik heb hier net zoals bij #2 ook alvast acceptatie-criteria toegevoegd, omdat deze story randvoorwaardelijk is voor die story.

Ik vermoed dat mijn criteria verschillen van jullie standaard-oplossing. Laat even weten wat de verschillen zijn, dan kan ik daar wat van vinden (= schrappen of aparte story van maken).

Ik wil nog een aparte story maken om de logging in de beheerinterface te tonen.

[sergei-maertens]

@MarcoKlerks is het ook voldoende als de logs/audit trails via de beheeromgeving van de registratiecomponent inzichtelijk (en te exporteren zijn) ipv deze ook via de API te onsluiten? Dat is namelijk een stuk minder werk :)

[MarcoKlerks]

@sergei-maertens
Voor nu, ja. API erbij kan altijd nog.
Ik pas de AC aan.

[sergei-maertens]

@MarcoKlerks feedback processed and deployed, you can re-test!

[MarcoKlerks]

Testresultaten:

• Bij o.a. publicaties en documenten is een knop "Show logs" toegevoegd. deze toont alle log-regels.
• Bij de logging kan nu ook gezocht worden in de titel
• In de logging is een kolom "Kind" toegevoegd die laat zien of het data-object een publicatie, of een document, of een gebruiker, of een ... is.

Top!

[MarcoKlerks]

Helaas, ik heb nog een issue gevonden...

Als ik in de beheer-interface een publicatie raadpleeg, dan staan daar (terecht) de documenten bij. Rechtsboven ieder document staat een vinkje 'verwijderen'. Als ik dat aanvink en opsla, dan wordt het document inderdaad verwijderd. Deze verwijdering wordt echter niet gelogd. Wel wordt er een mutatie van de publicatie gelogd.

Óf deze wijze van verwijderen wordt ook gelogd óf het vinkje wordt weggehaald.