Because a user can override a specific topic
Watch #bug but mute a particular bug
7 Likes
I see. I guess there’s have to be a nil or default topic tracking state to know when to fall back on the category or tag preference.
It’s a bit hard to tell without the migration you mention, but so far this seems to be just right.
I look forward to a migration that will set the new style tracking state, so I can finish testing this out.
2 Likes
This sounds terrific, @sam! It sounds like this change is what the mailing list crowd was asking for.
What Discourse version is this change on?
I’m not sure how to transition, though. Would we need a script that removes and re-adds all users’ watched categories?
Edit: do these changes impact the watching/tracking states of Group PMs?
A migration is quite risky here, I am worried about adding it and its just for an edge case.
The edge case we are not handling now is:
- User visits topic X in category Y
- User watches category Y
- Topic X is not watched
- Admin upgrades Discourse
- topic X is still not watched
However this works just fine
- User never visited topic X in category Y
- User watches category Y
- Admin upgrades Discourse
- topic X is watched
@alehandrof this is in latest beta, I would not worry about transition edge cases you can deal with them on a case by case basis imo. This has no impact on group PMs
1 Like
What if:
- User watches category Y (because I have that as the site default for users)
- User visits topic X in category Y
- Topic X is not watched (in other words, they took no action while viewing it)
- Admin upgrades Discourse
Would topic X still be watched [by way of the category watch]?
Unfortunately the edge case you mention is exactly my situation.
I have specific groups watching specific categories (automated via a plugin). I need to know that everyone in that group is receiving notifications from every topic in that category.
2 Likes
@sam In my primary forum, about 1/2 the users are in the edge case you describe, the other are in the one I describe.
Like Alex, the goal is to know that users are Watching specific categories. Perhaps removing them & reading them to a Group could reset the Watching state, via this Group-watch feature request?
2 Likes
encountered this bug recently:
- Start by clicking the Category dropdown menu, and choose any category.
- While in the selected category space, click on the watch/track button next to + New Topic
- Choose to watch the category
- Refresh page, then try to unwatch the category by setting it to other option (like Normal or Watching First Post)
- Refresh page, the category is still being watched (Watching is still selected).
- Only way to unwatch the category is through the account preference page.
Shouldn’t user be able to unwatch any category the same way they use to watch one?
1 Like
Not following, this has been implemented for ages.
2 Likes
@sam That’s what I thought, which is why I’m a bit confused.
The way I understand it, if I am watching a category, a new topic in this category would result in a record being created for this topic where the initial state would be watching.
Is that correct?
Because the way I am experiencing it now is that you will for example get a notification about the new topic, but if you vist /latest?state=watching, the new topic will not show up. It is not until you go visit the topic that the watching state will be set.
@sniepoort In trying to track down the source of issues I’m having here, I found the commit you’re after
3 Likes
Also see:
1 Like
Is the following also true when opting to just Track a whole category?
Any old topics tracking state records that are in “regular” in that category become “tracked” (with “you are tracking this category” reason).
I think so, but you got to test it.
