Automated OCR operations are attributed to the impersonated file owner (audit-trail / accountability concern)

[fgrosswig]

Summary

When workflow_ocr processes a file, the resulting version author and the
file activity are attributed to the file owner ("You"), not to an automated
system actor. As a result an automated OCR operation is indistinguishable
from a manual user edit in the audit trail.

Root cause (as I understand it)

lib/Service/OcrService.php calls userSession->setUser($owner) before
writing the OCR'd file back and creating the version (and setUser(null)
afterwards). The impersonation is technically necessary for filesystem access,
but it means the version metadata + activity inherit the owner as author.

Why this matters (compliance / ISMS)

In a compliance / ISMS context, accountability & non-repudiation require
that automated system actions are clearly distinguishable from manual user
actions. Attributing an automated OCR to a real user weakens the audit trail
("who actually did this?").

Current mitigations (helpful, but not sufficient)

• The Before OCR version label signals an OCR result.
• The configurable "assign tag after OCR" marks processed files.
  These document that OCR happened, but not that it was automated vs. manual.

Request

Please consider an option to attribute OCR operations (version author + activity)
to a configurable system/service actor (or Nextcloud's system actor),
instead of the impersonated file owner — at minimum as an opt-in setting.

Environment

• workflow_ocr: 1.33.1
• Nextcloud: 33.0.5
• Mode: local backend (ocrmypdf), Flow trigger on file create + PDF

[R0Wi]

Thanks for the suggestion. Indeed this app was never used to be audit-trail ready, but your request makes sense from an admin perspective.

To give you some background first: we have been struggeling quite a lot with different approaches of "which user to take to create the OCR version of a file". We've been running into several permission issues until we decided to use the user account, which last created/updated the file. This way we're 100% sure that we have proper permissions to create a new file version.

If we would allow an admin to set a service user instead of using the impersonation, the admin would need to make sure that this user has write access to basically all files in your Nextcloud instance, effectively making it an admin user which somehow goes against the RBAC principle.

Also I'm not sure if this approach would be audit ready? I mean the Nextcloud admin could pick any arbitrary user from the instance making it the "OCR user". This way the history could show for example that user A uploaded the files, whereas a real user B created a new version (OCR version) - which in my opinion is even worse than claiming that user A created a new file version. So do you really know that letting the Nextcloud admin choose a user for the OCR processing would be audit compliant in your case?