In my Discourse forum I’d like to refactor the set of tags we use (we’re using discourse-tagging). Early on I allowed our project staff free reign in creating new tags since there’s no way to pre-populate a fixed tag vocabulary. Now a few months in, there’s a lot of inconsistency in tags, and I’d like to edit the tags on virtually every topic to bring useful consistency.
The problem is that editing tags is just like any other activity on a topic and it bumps that topic up in the Latest category view.
So if I undertake the tag vocabulary refactoring, it’ll create a huge amount of churn in the Latest view, which is what my users see by default.
Could we make it so that editing tags (and similar metadata) don’t change the post’s timestamp?
Hmmmm, I just now removed a Tag from a topic (at StePoint) with several replies and it didn’t get “bumped” up the list.
AFAIK it is only happens when the last post gets edited that causes a bump. Are these no-reply topics?
I feel so silly. Yes, I got the idea that tag editing bumped a topic in general because I was doing it to posts that had no reply yet. Trying it now on older posts with replies, I see you’re absolutely right! Thanks.
I’ve also noticed that bulk tag edits don’t seem to cause a revision, which makes the topic not get bumped even if it’s the only post.
Yep, any last post edit will bring it to the top. It can be confusing when a minor edit makes a post resurface from months past. Thankfully, they don’t generate notifications.
On a related note, resurrected threads can’t be dismissed by deleting the last post - the previous ancient post stays at the top of the list.
Speaking of ressurection. I just came upon this situation again. I created a new category and have been moving topics into it, and in the process also updating some tags. Some of these are 2 years old and have had no reply.
I honestly don’t see why these get bumped. It makes no sense.
This was raised before in other contexts, mods wanting a way to do “non bumping” edits.
Technically its not too hard to build, but the UX is a nightmare. And additional discussion here really should have some UI mockups about how you would see a “non-bumping” edit work.
Thanks, Sam. Hmm… not so sure UI mockups are needed, unless you are talking about having an option that shows up everywhere to prevent bumps on a case by case basis.
For me, I would be mostly satisfied if the following never bumped topics. If this disrupts others, maybe this could be an admin site setting?
- changing the title or category/tag via the edit pencil next to the topic title
- any topic admin wrench actions
- editing old posts that are no longer editable by users themselves
- assigning and whisper replies (not sure if this already bumps topics)
In addition, it would be helpful for admins and moderators to be able to see a “Do not update timestamp” option when editing posts. It could sit to the right of the
cancel buttons below the composer. I realize this is sensitive so enabling this feature for moderators could also be enabled/disabled via an admin setting.
What you are asking here is for a “bucket” of special cases, I don’t even know how to define this as a site setting.
“Avoid bumping user topics when edited by staff”
Where this gets particularly complicated is:
Why are you suppressing a bump by a moderator when they fix typo in a title, but not suppressing it when they fix a typo in a post?
You’re right - I thought about this afterwards as well. I would be fine with suppressing all staff edits including when they fix a typo in a post.
I see how this is difficult to implement UX wise. So given that this non-bumping should be limited to a diverse set of rare cases, here are two thoughts:
One way could be a temporary no-bump mode that staff could enter. Perhaps it should even have an automatic time out of a minute or so, preventing people from forgetting to turn it off.
Another one might be to not actually prevent the bump itself but make it possible to revert it via the post history modal. There could be an additional button there to Revert last timestamp change or
Revert timestamp to this revision