What this is about
Auditing keeps every change, with the content of the object and with details about the person who made the change. Both can be personal data, meaning information that can be linked to a human being. The rules of data protection apply to it, for example the GDPR.
CDMS provides the recording. How long the data may stay and who may see it is up to your project.
Where personal data lives
flowchart LR
subgraph DB["Tenant database"]
R[("revinfo<br/>user_id · username<br/>ip_address · user_agent<br/>acting_user_id · acting_username")]
A[("person_AUD<br/>every old state:<br/>name, email, address …")]
T[("person<br/>only the current state")]
end
subgraph FS["File storage"]
V["<fileId>.<identifier><br/>old file contents"]
end
R --- A
| What | Where | Visible through the API? |
|---|---|---|
| user name | revinfo.username | yes, revisionMeta.username |
| IP address | revinfo.ip_address | yes, revisionMeta.ip |
| browser or program | revinfo.user_agent | yes, revisionMeta.useragent |
| user ID | revinfo.user_id | no, only in the database |
| acting person after a user switch | revinfo.acting_username, revinfo.acting_user_id | name yes, revisionMeta.actingUsername; ID only in the database |
| every old state of the object | <table>_AUD | yes, revision in the history |
| old file contents | versions in the file storage | only through a rollback |
Where the values come from is explained in What a revision records.
Two kinds of data
- name and ID from the token
- IP address and user agent of the request
- created for every audited model, even for purely technical data
- shows who worked when
- everything that is in the object, for example name, email, address, notes
- including values that were changed or emptied later
- including file contents for file models
- depends on what you model
How long revisions stay
CDMS deletes no revision. There is no endpoint that deletes, shortens or anonymizes revisions, and no built-in retention period.
When: PUT, PATCH, upload, rollback
The old state stays as a revision. So emptying a field does not remove the old value from CDMS, it is still in the older revision.
When: DELETE, directly or through a cascade
The row disappears, the history stays complete. The DEL revision itself is empty except the id, but every revision before it contains the content.
Result: See What remains after a delete.
When: audited file model
Old contents stay as long as the record exists. When the record is deleted, the content and all versions are removed, the history of the record stays.
Result: See File versions.
When: The model is set to not audited.
New changes are no longer recorded. The existing revisions stay in the database.
Deleting or anonymizing revisions is therefore a task at database level, outside the CDMS API. Because every tenant has its own database with its own revinfo, such an intervention always affects only one tenant.
Who may read the history
The history of an object can be read by whoever has the read role and the history role of the model – and who would have been allowed to read the object itself. The row filters that run along when reading and searching, for example the owner filter, apply here too. For a deleted object, its last state before the deletion counts. See Reading the history.
That limits who sees the personal data in the history, but it does not lift the warning above: whoever may read an object sees all its old states as well, with the history role.
What your project has to watch out for
| Proof or rollback needed? | contains personal data? | Recommendation |
|---|---|---|
| no | – | do not audit |
| yes | no | audit. Personal data is still created through name and IP address of the acting person. |
| yes | yes | audit, but decide on retention, read permissions and how to handle deletion requests first |
Pitfalls
What comes next
- What a revision contains: What a revision records
- Roles for the history: Model roles
- What remains after deleting: What remains after a delete