I recently migrated a fairly large (150k posts) phpBB forum to discourse. A lot of our users want to be able to “track” the majority of the forum, so they’ve added all categories to their “Tracked” categories in their user settings. This works perfectly for new threads created in discourse.
However, when someone replies to an old imported topic, it does not become “implicitly tracked” as I would expect from this thread:
Steps taken:
User “David” has the “General” category set to “Tracked” in his user preferences
User “Bob” replies to an old thread that was imported from phpBB
“David” does not see this in his “Unread” tab
However, this works fine:
User “David” has the “General” category set to “Tracked” in his user preferences
User “Bob” creates a new thread under “General”
“David” sees this in his “new” tab
Some investigation on the console reveals that there is no TopicUser row associated with David for either of the topics, so I don’t understand why the implicit tracking is not working.
David’s user_id is 1, old topic_id is 8531, new topic_id is 10708
“Watching” categories works absolutely fine - if someone posts on an old topic and I have the category set to “Watching” then I do indeed receive a notification
(Still no TopicUser row created until I view the topic, so the implicit watching is working)
You can’t have a topic that is both “new” and in “unread”, it is either/or.
My guess… these topics were never visited by these users, so they should show up in “new” however… you have “new” set to last 2 days or something so they end up missing.
If the users visit the topics they will become tracked.
Implicit tracking means there is no row in TopicUser, it is added first time the record is created (topic visited)
The settings on my account are the same as the defaults for all our users - consider new when “haven’t viewed them yet”. I suspect the reason that the topics aren’t all showing up in “new” is because all the users have their “first_seen_at” field set to the date of the import, and therefore after the topic was initially created.
So I think the problem is:
Topic does not show up in “new” because it was created before the user first visited the forum
Topic does not show up in “unread” because the user has never viewed it
I would imagine this logic extends further than imported forums - any new users of a forum who decide to track a category won’t see old topics in new/unread until they’ve viewed the topic at least once. Afraid I don’t know my way around the codebase enough to find the logic for what gets included in the “new” tab, so I could be completely wrong with all of this.
Would it be better change “new” from unviewed topics created since the user first visited
to unviewed topics with posts since the user first visited
or maybe better would be to change “unread” from tracked, viewed topics, with unread posts
to (tracked, viewed topics, with unread posts) + (tracked, unviewed topics, with posts since user first visited, created before user first visited)
I can see the appeal on unconditionally adding “tracked” categories into the “new” filter but technically making this work could end up being quite costly performance wise.
Also, we have to keep a cap on new counts cause they are tracked in memory in the app, if you have 500k “new” topics it can brutally slow (and kind of pointless)
Honestly, I am really unsure what the best course of action is here.
Now that I’ve looked at the code a bit, this would certainly be an awful lot easier!
At the moment, the “new” tab is sorted by “topic.bumped_at”, but filtered by “topic.created_at”. What’s the thinking behind this? It seems a little un-intuitive that topics don’t “drop off the bottom” of the list once they’re no longer declared new. What would be quite nice, at least for my forum, would be to filter them by “topic.bumped_at”.
Would there be any way for me to adapt the new/unread logic on my forum using a plugin, without having to hack around in the code? Or is there a best-practice way for patching the core code so that I can still apply updates?
Edit: I’ve come up with this plugin which works, but doesn’t apply the “new” badge to topics. Is the logic for that badge elsewhere?
# name: filter-new-bumped
# about: A super simple plugin to override the new_filter to use bumped_at instead of created_at
# version: 0.0.1
# authors: David Taylor
after_initialize do
require_dependency 'topic_query'
class ::TopicQuery
def self.new_filter(list, treat_as_new_topic_start_date)
list.where("topics.bumped_at >= :created_at", created_at: treat_as_new_topic_start_date)
.where("tu.last_read_post_number IS NULL")
.where("COALESCE(tu.notification_level, :tracking) >= :tracking", tracking: TopicUser.notification_levels[:tracking])
end
end
end
@sam what do you think about changing the new logic to be bumped_at rather than created_at?
I think if things are left as-is, then some clarification should be added to the “tracked categories” box in the user preferences - should really be called “track viewed topics in categories”