Unread topics in query-link-lists tracking/watching

We use latest-lists together with the query links ?state=watching, and ?state=tracking. (We added them with javascript as links in the navigation bar). Those lists however don’t include the topics that haven’t been klicked at least once, so people overlook new topics and new answers on old unread topics in the categories which are important to them.

However, people do get a notification on the unread topics, when they watch them. They don’t get a counter when they track them, but that doesn’t matter, cause it would be identical with the number of answers. But they also don’t see them in “unread”.

If this is easy to fix, it would be awesome. The querylinks would be really helpful, if it wouldn’t be so misleading regarding unread topics.

2 Likes

Is that true? @sam can you elaborate here?

state=tracking / watching does not make any purposeful omissions. I was super slow to reply here cause I am just confused at what the problem is.

2 Likes

I think the problem is:

Topics in Categories set to tracking only become tracked themselves when they’re clicked on.

To demonstrate, here’s my current New tab:

You can see the “Discourse Narrative Bot Beta Feedback” topic is listed, in the feature Category, which I track.

Then if I go to latest, with ?state=tracking we can’t see that topic:

And to really drive the point home, if I go back to new, with ?state=tracking I see nothing:

I think the request is for topics in Tracked categories to work like topics in Watched categories - they become Tracked as soon as the category-level notification setting is changed, so they appear in Unread as soon as posted.

I would also like to see this change, but haven’t until now (and even then I’m not sure) found the right words to clearly explain what I think is intuitive.

3 Likes

Hi,

Cool that you come back to this @sam. So the problem is:

Never clicked topics in watched and tracked categories. They don’t behave like watched and tracked topics. Except one thing: you get notifications for those topics nevertheless (only if they are in a watched category of course, not in a tracked one). So the notifications seem to use some other information than the rest of discourse, what a watched topic is. I would prefer every functionality, that relies on watched topics, to use the same information as the notifications. And that the tracked functionality behaves in an analog way.

It burns down to this. The rest what I write, is just for making it more understandable:

Everything what Leo writes is correct except this:

It’s actually the same problem for watched categories. So I also make some pictures, if that helps:

  1. I watch the category features, but only the topics I clicked once in my user-history are listed in latest?state=watching:

I would want to see the complete feature latest list here.

2. And this is how my unread list looks like:

So I would want to see the complete feature latest list also here.

Since there are of course loads an loads of new posts and topics in the feature category that I haven’t read. I got notifications for them though, and that’s good. I want them!

For example these two notifications

from these two topics from the normal latest list, which are not in my unread and not in my ?state=watching list:

3. You can also see here, that there is no blue counter on new posts (these are two new topics, but it’s the same for not new). For our users it would be best if the posts since they first registrated would be counted, because they want to read everything that gets talked about in their category since they joined our community, also if it’s answers on old topics. It’s like they come in a room and start listening - they are part of everything that happens from now on. It seems to make very much sense to me, that a counter in interesting categories should behave like this, but maybe that’s debatable and depends on the use case. The important thing to us is anyhow the lists.

1 Like

This has been assigned to me and I am going to now unassign it now cause its very complicated to change anything here without severe side effect.

One big problem here is that we don’t want to be inserting millions of rows into the topic_users table when a user “tracks” a category or “watches” a category. There is huge risk of creating massive perf issues.

The current implementation just balances stuff so you need to opt a bit harder to track things and watch thing. Under usual usage this is fine, if you are customizing the home page it is not ideal. I guess if you have the resources I would recommend you write a plugin here to allow you to insert tons of rows into topic user, but you are talking pretty advanced plugin here.

3 Likes

The recent filter=tracked feature is somewhat related to this.

https://github.com/discourse/discourse/commit/88dcdf776bf1ea0f4cc9a4245a123ffdc2a4abb0

However, the commit message explains that in this filter we:

do not include explicitly tracked and watched topics outside of
the tracked categories and tags.

We can consider a filter=all_tracked to cover this edge case.

So filter=all_tracked is what would satisfy the use case discussed here.

1 Like