Created on 2022-12-02 20:10 by rouilj, last changed 2022-12-02 20:10 by rouilj.
|msg7691||Author: [hidden] (rouilj)||Date: 2022-12-02 20:10|
In the thread including https://sourceforge.net/p/roundup/mailman/message/37743155/ Thomas AH provides a use case where a message may have to be purged because of sensitive info. I suggested adding a purge action to the web interface and roundup-tracker. Comment taken from email: ==== Have you thought about adding a "Purge File/Message" button on the msgNN and fileNN pages that calls a purge action. The action does the following (which I think touches all your points above): 1. unlink file/message from all associated issues 2. clean up purged item metadata: * for file: * set the filename to [purged by userNN on date]. This removes the need to remove (1) the journal entry on the issue(s). The filename info comes from the file metadata.) * set contenttype to to text/plain * for msg: * maybe empty the recipients * for either maybe clear the date to 1970-01-01 3. truncate file or use code from something like https://github.com/r3nt0n/wiper/blob/master/r3ntlib/wiper_ops.py or an os.system or subprocess.call(shell=False) to shred(1) to overwrite data on disk file before truncation. (*) 4. purge/clean up journal/history for the file/message. For messages this can probably be skipped. For files, you want to remove the journal entry that records the rename if it is sensitive data. Note this process does leave the link/unlink history references in the issue, but looking at them should show something like: later date user ... files: - [purged by admin on 2021-12-21] date user ... files: + [purged by admin on 2021-12-21] I don't consider that an issue. There is an open issue https://issues.roundup-tracker.org/issue2551133 to enhance roundup-admin pack to include the ability to run pack 0d file200 to purge all journals on file200 starting now (0d) back to (but not including) the original create. I think that would work for your use case. Adding a 'purge' command for file based and user classes to roundup-admin would be useful. With suitable checks (user verifies filename, creating user at minimum) and warnings I think it would work. Adding this as an action to the core accessible by admins, but not exposed in the UI would be reasonable. The UI exposure would be part of customizing the tracker. ========