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.
========