For the various knowledge base topics we have I would like to have a special timer for:
Replies on this topic are automatically deleted after N days
I think this is a very powerful tool for keeping documentation topics clean. I would have this on most documentation topics on meta.
It means people can reply to them but they know upfront that replies are like tears in the rain. If you want something permanent:
Even though we can do this pruning by hand it is tedious. Plus, on a psychological level, when a computer does something cause “these are the rules of the ball game”, it feels way better than us humans intervening. (oh why are you making up this rule now, not fair)
I think we might also want to retain replies that have a certain threshold of likes, just in case?
Other than that I think there’s clear need for this based on our usage at least, in the “first post wiki” kinda deals. It would have to be a per-topic setting though, right?
I like this. We have a lot of “stickies” (pinned posts) that might get a lot of heavy use now as we transition over to Discourse, but later won’t be as relevant. I don’t want to have to remake the posts every so often.
I am in favor of this feature request for all the reasons cited above plus one more.
Here is some background for my reasoning. I have researched having a ‘chat’ feature in Discourse and understand the position of the Discourse team on people using private multi-recipient messages for chatting.
I know that both Babble and ‘Quick messages’ plugins use the multi-recipient PMs at their core.
I think ‘Quick Messages’ is almost exactly what suits us.
We want to have just a few selected people on our site who are allowed to chat but it seems to me that the feature requested by this topic, if implemented as a feature, would mitigate most of the negative issues with using multi-recipient PMs as a form of chatting.
Actually I hate chat, but it has its purpose for a team of people who are working together on creating a DRAFT of a long helpful general forum topic. The chat sidebar, can be on top while all the good stuff that results from the chatting gets transferred to the DRAFT topic, on the same screen below (preferably beside) the chat sidebar.
Our team is using RocketChat beside a Discourse window right now but I want an All-in-one solution…
Just my 2 cents and I really would like if this feature were added soon
I would like a ‘chat now’ button beside each topic, so that ‘chat’ on the topic could be found easily in the future vs having to wade through a bunch of PM’s to see it there was a chat for a topic
EDIT: I am suggesting that ‘deleting replies after X days’ in these ‘linked to a topic’ multi-recipient PMs that can also show up in a expandable/hide-able chat sidebar (in the chat sidebar, the PM is ‘compressed’ by removing dead space and using image thumbnails), would be the ultimate for us.
Also, I do not think whispers are a close enough solution for our issue.
This could be great feature for special type of topics: e.g. one-time question and answer. I’d love to see this implemented…
Also useful for some announcements that we want let users to react to but at the same time keep topic clean.
This is on our roadmap for the next release!
Now it’s done in the commit below. I did many changes in the “
future-date-input” code. So let me know if there are any new UX issues related to it.
Where do we set this, can you share a screenshot of the user interface? Is it a per-topic setting?
Per topic at the moment in the topic timer UI
If I go to Set Timer dialog, choose “Auto-delete replies” and then exit modal by clicking , following new line appears:
It can’t be deleted and disappears after reload.
I just saw this feature in today’s release notes. It looks great! I have a follow up question.
Did this part of the feature get implemented? It seems like a good idea.
No, it’s not yet implemented.
Alas. Is there any way to manually save a reply from deletion?
Sorry! it doesn’t have that kind of option right now.
Agreed, we kind of missed that Vinoth – we should add protection for replies with >=
x likes. Either hard-coded or as a site setting.
In that case, should we retain only the OP replies? Because if we retain a non-OP reply without its reply-to-post it will create confusion. For example, if we delete post #10 and retain post #11 in this topic then it won’t make any sense.
I’d also like to put in my two cents in favor of manually saving replies. (As long as it’s a manual process, presumably whoever it is that’s saving the replies will have the wit to save replies that make sense out of context.)
It can be arbitrary. Likes is the only metric we need.
I am fine with a site setting here of:
skip_auto_delete_reply_likes (default 5)
It can be somewhat surprising, so I would like us to have this number communicated to admins when they set the timer. Maybe we wait on the redesign of topic timers UI @martin is working on to add this in?
Note, this doe not solve @dfabulich problem, and to be honest I can not think of a clean workaround for manually protecting, here are some things I thought about
skip_auto_delete_reply_on_staff_like (default false) - similar to how we feature comments on BBS using staff likes
Automatically skip on “post notice” … adds noise
Always skip when staff posts, would have to be a setting
Something else … too messy imo.