When a self-destructing message expires, its files have always been moved
to deleted-attachments for the retention window, so a moderator can
recover something abusive that was posted on a short timer. That is the
right default for community servers, but small servers where everyone
trusts each other may want those files gone for good when the timer
runs out.
A new "Keep self-destructed attachments" toggle sits under "Keep deleted
files for (days)" in Admin settings, Cleanup. It is on by default, so
nothing changes for existing servers. When it is on, the files are held
for the same retention period as other deleted attachments. When it is
off, the sweep deletes them directly instead of holding them.
Only an explicit off deletes for good. If the setting can't be read (for
example, a busy database), the files are still held, so a read failure
never destroys evidence. The server only accepts true or false for the
setting.
This commit also fixes a loophole that let anyone stop a self-destructing
message's attachments from being removed, just by quoting the message or
linking its attachments before the timer ran out. The message went away,
but its attachments stayed in uploads for good.
Self-destructing messages can no longer be replied to or quoted by
anyone, mods included, so the sender can't accidentally undo their own
self-destruct either. The server also drops a reply to one. Mods can
still keep a message by pinning or protecting it, which removes the
timer as before and allows replies and quotes again. When the timer
runs out, a link to the attachments posted in any other message no
longer keeps them. The link text stays, but it stops working.
Co-authored-by: bo0sted <mc526+github@proton.me>
Expired attachments were unlinked at once, so something abusive posted on
a 30 second timer left moderators nothing to recover. They now go the way
a deleted message's files do: only the sender's own, kept while a quote or
a profile still uses them, and into deleted-attachments for the retention
window. The send dialog says so.
A member denied delete_own_messages could still make messages delete
themselves; the send is now refused for them (and refused if the check
fails). Pinning or protecting a self-destructing message keeps it, as a pin
or protection keeps one from auto-cleanup, so its timer is dropped. Also: a
busy database no longer puts the timer to sleep with messages waiting, and
the test closes its database before removing its folder on Windows.
* Self-destructing messages
A flame toggle next to the mic in channel composers. Sending with it on
asks how long the message lives (1 minute to 24 hours, in minutes or
hours), then the message and the attachments sent with it are deleted
when the time runs out. The sender's own files are removed for good,
skipping deleted-attachments. Each message shows "Self-destructing in
..." under its content until then.
On the server one timer waits for the soonest deadline instead of
polling: it catches up at startup, sleeps when nothing is left, wakes
when a new self-destructing message is sent, and moves on when the
message it waits for is deleted early.
* Self-destruct modal: show how long until it deletes as you type
Updates on every keystroke and when switching between minutes and hours. Spelled out exactly ("1 hour, 30 minutes") rather than rounded, and in the reader's language.
* Self-destruct: allow timers as short as 30 seconds
* Self-destruct: voice messages too
With the flame on, clicking the mic asks how long first and only starts
recording once a time is confirmed; backing out records nothing and keeps
the flame on. The timer counts from when the recording is sent, and
turning the flame off while recording sends it as a normal message.
* Self-destruct: GIFs follow the flame too
In a channel a GIF used to go straight to the server, so it ignored the
self-destruct toggle. With the flame on it now goes through the
composer's send, the way DM GIFs already do, so it asks how long first.
---------
Co-authored-by: bo0sted <mc526+github@proton.me>
ancsemi