I looked at the code a while back, so I'll try to explain my recollection of how things work (although I may have some details wrong).jelo77 wrote:I did look at the table. My board has 2884 posts in 447 topics. In the table topic_watch I have 395 entries, most of them have a notify_status=0. I was under the impression that each user that posts will get an entry with the correct notification status of 0 or 1 for that user id and topic id, but apparently that is not the case. I will check if I can run an SQL command to select all users in one topic to then set the notification for those users only for each of my topics.No. Once again, the topics_watch table stores topic subscription information. Why is this hard to believe? You need to track each topic that a user has subscribed to, which requires storing both a user ID and a topic ID. Look at the definition of topics_watch.
When somebody subscribes to a topic, that topic and user ID get inserted into the topics_watch table with notify_stat indicating that the person should be notified when a new post is made. When somebody posts to that topic, the notify_stat value is changed to indicate that no more notifications should be sent until the user visits again. When the user does visit, notify_stat is reset to indicate that the person should be notified again when a new post is made. Notifications are only sent to people in that state. If the user unsubscribes from a topic, his entry for that topic is deleted from topics_watch.
As I said, the details may be off a bit, but that's the gist. That's why a simple UPDATE query won't work; if people posted in a topic but aren't subscribed, you need to insert those people/topic pairs into topics_watch.