-
Bug
-
Resolution: Fixed
-
Blocker
-
4.5
-
MOODLE_405_STABLE
-
MOODLE_405_STABLE
-
MDL-83245-main -
MDL-75850 introduced a new File Redaction system, located in lib/classes/fileredact.
This works by hooking in to the File Storage API using the after_file_created hook. It attempts to redact file content after the file has been persisted to the Moodle File pool and database. If a redaction is possible then it removes the file storage DB record, creates a new one, and then replaces all of the references to the original file.
To support this it requires the addition of a new $notify parameter when adding files to the file pool to disable the after_file_created hook.
The API itself is called in the form:
$manager = new \core\fileredact\manager($storedfile);
|
$manager->execute();
|
There is no return value from the execute call, and the actual redaction service (not the manager) is responsible for the interaction with the file system API internally to remove and replace the file.
There are a number of issues with this approach, including:
- it is in the wrong subsystem (should be core_files)
- the fileredact L2 namespace is not a valid API (or L2 namespace)
- it operates after the file metadata has been persisted, and after the file itself has been added to the storage pool
- the API design is opaque - the actual changes are hidden behind the API and are hard to understanad
- the API will lead to duplicated code beause the service is responsible for file system API interaction
- the execute method is essentially unnecessary
- the manager is single-file
For me, the most concerning is that we are persisting redactable content. Whilst this has been the case since day dot for Moodle, the point of this service is to not do this any longer. Additionally I do know that it is not accessible by users, but it is still PII that we can remove, and are removing, but just not at the right point.
Secondary to that is the limited nature fo the API.
To address this we should:
- move the operation to before the file is persisted to DB or the file pool using a newly converted component/hook
- move the API to the core_files namespace
- define this as a valid L2 AI
- stop taking a stored_file in the constructor to the manager
- provide options to redact content by either file path, or file content
- have the redaction methods return a relevat value so that the caller can handle the result
- allow the API to work on file content, or file paths
- allow for the API to take other formats in the future
- add unit tests