The discussion revolves around a bug with auto-delete topic timers in Discourse, specifically involving TL4 users. mentalstring reports that TL4s can edit auto-delete timers on stub topics, but the changes don’t take effect—topics aren’t deleted even when the timer expires. The visible countdown updates, but the actual deletion doesn’t occur. itsbhanusharma initially couldn’t reproduce the issue, but later confirmed it with TL4s. JammyDodger corroborates the bug, noting that TL4s can edit timers but the changes are ignored. mentalstring clarifies that TL4s shouldn’t be able to edit such timers at all, as they lack permission to create them. The issue also occurs on regular topics, not just stubs. The consensus is that TL4s should not have edit permissions for auto-delete timers, and the UI incorrectly shows the timer as deleted when it’s not. IAmGav suggests a workaround of canceling and re-adding the timer, but this isn’t feasible for TL4s who can’t create timers. The bug appears to be related to permissions and timer synchronization, with the UI showing incorrect state information.
However, if that timer is edited, it doesn’t behave as one expects.
Lowering that timer doesn’t seem to have any effect on the actual auto-deletion of the topic which still follows the original delete merged stub topics after days setting: once that (visible) timer expires on the new date, the stub topic still remains. Only after the, eg, 7 days there’s an actual deletion.
There seems to be two separate timers here that don’t seem to agree. Perhaps the visible timer shouldn’t be editable? Or, if it is, the auto-delete should follow it’s new value but that doesn’t seem to be happening for some reason.
There seems to be more to this, perhaps related with TL4 permissions.
– As an admin: I created a new topic, then moved that single post elsewhere. Went back to the stub topic, changed the 7d timer to a minute from there. After some minutes the background job marked the topic as deleted. This is the intended behavior.
– As a moderator: repeating the steps above works just like with an admin account.
– As a TL4: I repeated the same steps. But, after the (reduced) timer expired, the topic remained there (not deleted) and the timer disappears from view.
I believe a TL4 normally can’t create an auto-delete timer, although they seem to be able to edit it in this case (the countdown does change!), even though it ends up not deleting the topic. So perhaps the bug is that TL4s shouldn’t be able to edit topic auto-delete timers?
As evidence that there seems to be something amiss with auto-delete timers and TL4 accounts, I noticed this oddity: once the stub topic (reduced) auto-delete timer expires, if they go to the Set topic timer..., this shows:
In short: the issue seems specific to TL4’s editing stub topic auto-delete timers. They seem able to edit the timer, the countdown appears to change, but the topic is not deleted on the new date.
As this seems related to TL4 only (see above), they can’t create auto-delete timers (although they seem to be able to edit this one), so this workaround doesn’t apply.
Some more context to this: it’s actually not specific to stub topics and can be reproduced even on a regular topic that has a auto-delete timer set (eg: by an admin/moderator).
So: TL4’s appear to be able to edit an auto-delete timer down (probably they shouldn’t?), the countdown does change, but when the (now reduced) timer expires, the topic is not deleted and the timer disappears from view.
I can replicate this with the new TL4 information.
TL4 appear to have the ability to edit pre-existing auto-delete timers through the UI, however these changes do not take effect, and visually wipe the ‘real’ timer countdown.
edited, it doesn’t behave as one expects.
