Yup, topic state is getting set at visit to the topic.
Here is my test:
- As a normal user, set a category to Tracking
- As another user, create a topic in said category
- Using Data Explorer, query the
topic_users table for newly created topic to see what users have a subscription state on it.
- Validate that only user with a subscription is the topic owner
- Visit the topic as the user from step 1
- Immediately re-run Data Explorer query in step 3
- Two users now have a topic state for the topic (the user from step 1 and from step 2) – this is the culprit
- Reply to topic
- Topic state does not change because user has a subscription state for the given topic.
User for step 2 has the following preferences set:
Automatically track topics I enter is set to 4 minutes. I did not wait 4 minutes on the topic when visiting. I waited less than 30 seconds before running the query, the topic state happens immediately
When I post in a topic, set that topic to is set to Watching.
Tracked Categories is appropriately set for the category being used in the test.
auto_notification method to look for a higher subscription state than what is being requested. In this case, the current state would be
tracking, and the request would be
watching so it should permit the change in state. Or in cases of the state being
normal (not sure if this is possible) and the request being
tracking, it should change it.
What should happen if the state is
muted (meaning the user muted a category) and then they replied to a topic in the muted category? Should that topic’s state change?