Normally the title, the bit between the /t/ and /topicId at the end, does not matter, so I could change it to anything and it would still redirect to the same topic so long as the topicId is correct:
This is great behavior because if the topic’s name is changed, old links to it still work. However, this behavior is broken with unlisted threads. Unlisted threads can only be accessed with the current title, and all other links are broken – they do not redirect.
Use Case:
Our forum has community mentors that PM users to suggest how they can improve their posts. We link the threads that warrant the PMs on a spreadsheet so other mentors don’t send duplicate PMs and moderators can occasionally review us. If our site moderators unlist a thread that has had its name changed since the link was entered into the spreadsheet, the link in the spreadsheet is now broken, and the site moderators have to search all topics by the user to find the thread.
If a mod doesn’t want a thread to be visible at all, shouldn’t they just delete it? From what I understand (rather, at least what we use it for in our forum), unlisting is more for just clearing up clutter.
For instance, when we merge two threads we unlist the duplicate so we don’t have topics that pop up in the search and 5/6 of them are locked. We also unlist topics like “Look what I had for breakfast!”. If someone finds these by Id scraping, then cheers to them.
At the very least, it would be nice for links to redirect for unlisted topics if the name was ever valid. The server’s logic might look something like:
This user gave me a link. What thread does it go to?
I found the thread, but it’s unlisted
Has the title in the link the user gave me ever been the title for this topic (in edit history perhaps)?
I am fine with the staff improvement here, that you don’t need to know the slug of an unlisted topic if you are staff. But if that does not address Drew’s issue and Sam’s performance issue then maybe best to leave this “as designed”.
Yeah, we are technically not staff (volunteers closer to the Regular role). A permission for trust levels or groups would cover our use case since name history isn’t performant.
erlend_sh
(Erlend Sogge Heggen)
Split this topic
15