I’ve recently launched a discourse with the default notification settings to include a number of categories as “watch first post.”
At the same time, this forum has a backlog of posts that we intend to move to those categories.
The problem I discovered is that moving a post into a category where that category is set as “watch first post” triggers an email notification, even if that post is old.
Is there a best practice for overriding this email-sending action when categorizing posts? Thanks!
We had that problem, too. If I remember correctly, that best practice you’re looking for is to use the bulk actions for changing the category:
In a list of topics, click the “toggle bulk selection of topics” button in the left top corner of the topics table. Checkboxes will appear for each topic.
Select some topics.
Click the wrench icon in the top right.
Choose “Set Category” to change the category of these topics.
Please test yourself if that results in e-mail notifications or not. Pretty sure it won’t trigger e-mails, though.
Changing the category with bulk selection will trigger notifications/emails to users that are watching the destination category. There are a couple options to prevent this:
Gather the topic ids and use the rails console to change the category. If there are a lot of topics, you can use the Data Explorer to track down a set of topic ids, otherwise you can get them manually. This method bypasses all notifications/emails.
You can bulk unlist the topics in their current category, then move them to the destination category. If the destination category is already well populated, you can append
?status=unlisted to the url to find all the topics you just moved. Just make note that any existing unlisted topics will be in that list as well. Finally, bulk select those topics and relist them. This will also avoid notifications/emails
Choose a slow time on your forum and temporarily disable emails via the disable_emails site setting. When you move the topics, users that are watching the destination category will receive on-site notifications, but not emails. Make sure to turn emails back on when your are done!
Hope that helps!
This is SUPER helpful, thank you!
Option 2 seems to be the best option for me - we’re dealing with several thousand topics migrated from another system, so I have lots of help going through and categorizing them.
Two follow up questions:
The “unlisted” state seems to be fairly free from side effects - the topics are still visible, just not in “latest” lists. Do they become effectively hidden from non-moderator/admin accounts until they are re-listed? It’s not 100% clear to me what to expect when a post is unlisted (I read this and I’m still unsure)
Currently, all of the posts are in a single category. Is there a way you recommend that I could unlist EVERYTHING in that category, e.g. a sql command?
Once all of those unlisted topics have been moved into their respective categories, is there a way to find everything sitewide that is unlisted and relist it (again, a sql command would be ideal)? We aren’t unlisting topics for any other reason (unless it happens unknowingly because of other actions on the site, but I have manually touched over 1000 topics in the last few weeks during recategorizing and haven’t once used the unlisted state before this).
Thanks so much for your help with this!
Exactly, the topics can be accessed by anyone that has a link, but are hidden from all non-staff when viewing topic lists until they are re-listed.
If you click the bulk select button 
within the category that has all the topics, you should see a select all button. From there, a square button with a wrench icon should appear in the upper right of the topic list. Clicking that will open up the bulk actions modal where you should see an option to unlist.
I believe users have reported an error message if attempted with too many topics at a time, so if this happens you can use a rails command to update it. Let me know if you end up needing this. I have what should be the command, but I will want to test it first before I give it to you.
Sure, this URL (with your forum address used) should list all the unlisted topics site-wide: https://my.forum.org/?status=unlisted. You can then bulk select, select all, and hit the relist button.
Once again if this doesn’t work due to too many topics, you can do it from the rails console.
This is sounding great!
When I go to the Select All option, it only selects the topics on the page. I’d have to scroll for a VERY long time to get them all on the page (it’s ~5000 topics).
So, unless I’m missing something, I’d appreciate the help doing this from the rails console!
Ah ok, that is definitely way too many topics for the bulk select! I will test out the rails commands and get back to you in a bit when I get back to my computer.
Edit:
@alexknowshtml here are the commands. While I have tested these and they work, please be sure to backup your forum before running them just in case™!
Unlist all topics in a category
Topic.where(category_id: <category_id>, visible:true).update_all(visible:false)
Relist all topics across the entire site (run after all moves have taken place)
Topic.where(visible:false).update_all(visible:true)
Hey Taylor,
This SQL seemed to work (all posts in the category are now unlisted) but…
Moving the category of an unlisted post still fired an email to everyone who is set up to “watch first post” on the new category. That is the ONLY action I took too. The topic was still unlisted, and the email was still sent. 
did I miss a step to avoid sending that notification?
I’m very sorry. I just checked and you’re right. Here’s what it looks like I failed to catch:
If a user has already received a notification for the topic/post at some point, they will not be notified again after the topic is moved. The topics I tested with must have met that criteria and so all seemed well. With that said, I feel strongly that the expected behavior should be when a topic is unlisted it should not notify a user if it is moved to a new category in any scenario. It doesn’t seem right for my non-staff test account that was watching the destination category to get a notification for a topic that doesn’t even appear in the topic list. It brings attention and a direct link to something that is supposed to be hidden.
Anyway, it looks like the only way to avoid both notifications/emails is by changing the category from the command line. You would need to gather a list of topic ids and use the command I mentioned above:
topic_ids = [<topic_id_1>, <topic_id_2>, ...]
Topic.where(id: topic_ids).update_all(category_id: <to_category_id>)
I’m not sure what your intended workflow is, but if you were going into each topic to see the content and judge it’s destination category, you can get the topic ID at the end of the URL (just make sure to exclude any reply number) and compile a comma separated list in a notepad then run the above command.
There’s also the data explorer plugin where you could get a list of topic IDs based on a keyword in the title. That could cut down some of the work potentially.
In any case, I sincerely apologize that I failed to pick up on how the unlisted topic moves currently work. I hope it didn’t cause too much inconvenience for you.
Sure, @zogstrip can you add that to the to-do list? Probably just a boolean check in that part of the logic would suffice.
dang i’m relying on a small army of non-technical people to help with categorizing, so the command line isn’t really an option.
the change that @codinghorror mentions in the next comment sounds like exactly what I’m looking for, so I might just pause the categorizing project until that is in place.
I don’t expect a committed ETA, but I am curious if there’s a good way to keep track of that feature in the releases?
You can watch our GitHub commits and release-notes. I’ll also keep a reminder going about this topic and will let you know once I’ve spotted it committed.
@maja can you ensure that changing the category/tags of an unlisted (ie. visible = false) topic never generates a notification (and thus an email)?
Fix has been merged, notifications will not be triggered anymore when changing category or tags of unlisted topics
https://github.com/discourse/discourse/commit/ca33d091b39cd01a00b24f2e0b13f3e57b194354