Page MenuHomePhabricator

Getting topic notification on page with same section heading as a topic notification I did sign up for
Closed, DuplicatePublic

Description

I signed up for topic notifications for the administrators newsletter on enwp's Admin noticeboard by manually clicking [subscribe]: https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Administrators'_newsletter_%E2%80%93_September_2022

Screenshot 2022-09-01 at 17-48-46 Topic subscriptions - Wikipedia.png (335×1 px, 58 KB)

I just got a notification for someone replying to a thread with the same title, yet on a totally different page:

Screenshot 2022-09-01 at 17-49-36 Topic subscriptions - Wikipedia.png (139×500 px, 16 KB)

which is for https://en.wikipedia.org/w/index.php?title=User_talk:Tone&oldid=prev&diff=1107979257. When I look at that section, it does say [unsubscribe], though I never subscribed to it. If I look at some other admin's user talk page, e.g. https://en.wikipedia.org/wiki/User_talk:The_Earwig#Administrators'_newsletter_%E2%80%93_September_2022 it also says [unsubscribe].

My expectation is that when I subscribe to the thread on WP:AN, I'm just subscribing to that thread and not any same-named thread on any talk page.

Event Timeline

It works this way because that's how we keep the subscription working when a topic you subscribed to is moved to another page. Note that it tracks by the author and time of the first comment, rather than the section heading text (to keep the subscription when it's renamed, too).

Thinking about it, now we've got the permalink-tracking spinning up, maybe we could improve this? My thought is that we can:

  1. Store the page that the subscription initially occurred on.
  2. After a comment is left, check whether the subscribed section actually exists on that page via examining the permalink tables. (I didn't verify that we can definitely do this.)
  3. If yes: only notify if the edit happened on that same page.
  4. If no: go ahead and fall back to the current behavior.

It'd make building the initial list of people to notify more expensive because we'd need to do some joining or extra queries, but it'd avoid the issues that "newsletter"-type talk page usage incurs.

MassMessage could potentially add some random token to each delivery to allow DiscussionTools to differentiate them. That would probably fix the majority of instances but not all of them given that not everyone uses MM.