Page MenuHomePhabricator

DiscussionTools subscribed me to Steward requests/Permissions#Requests and does not let me to unsubscribe
Closed, ResolvedPublic

Description

Hello,

I was subscribed by DiscussionTools to https://meta.wikimedia.org/wiki/Steward_requests/Permissions#Requests, probably based on my reply via the reply tool.

SRP is a high-frequency noticeboard used by the Wikimedia Stewards. Unlike many other pages, the actual threads use h4 (ie. ==== Headline ====), rather than h2 (==) like normal talk pages. I don't want to be subscribed to it via DT, since it would trigger a lot of notifications. Watchlist is preferred for me to keep track about SRP matters, and to reply to new requests.

Unfortunately, DiscussionTools does not let me to manually unsubscribe: the button "unsubscribe" is there, but clicking it shows "Could not unsubscribe from this topic". See screenshot:

image.png (313×437 px, 16 KB)

This is the API call that is triggered when I hit the "unsubscribe" button:

image.png (558×719 px, 29 KB)

and here is the reply:

{
  "error": {
    "code": "subscription-failed",
    "info": "Could not unsubscribe from this topic.",
    "docref": "See https://meta.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
  },
  "servedby": "mw1379"
}

Even though the unsubscribe button shows up (and notifications are flowing in), I don't see any record about me being subscribed in the discussiontools_subscription table:

wikiadmin@10.64.0.97(metawiki)> select * from discussiontools_subscription where sub_namespace=0 and sub_title='Steward_requests/Permissions' and sub_user=(select user_id from user where user_name='Martin Urbanec');
+--------+------------------------------+---------------+------------------------------+-------------+-----------+----------+----------------+----------------+
| sub_id | sub_item                     | sub_namespace | sub_title                    | sub_section | sub_state | sub_user | sub_created    | sub_notified   |
+--------+------------------------------+---------------+------------------------------+-------------+-----------+----------+----------------+----------------+
|   1531 | h-HitomiAkane-20220813165800 |             0 | Steward_requests/Permissions | Requests    |         2 |  7034294 | 20220911085228 | 20220917114915 |
+--------+------------------------------+---------------+------------------------------+-------------+-----------+----------+----------------+----------------+
1 row in set (0.001 sec)

wikiadmin@10.64.0.97(metawiki)>

Personally, I think DiscussionTools should not autosubscribe on SRP at all, or alternatively, it should subscribe users to the h4-marked thread, not to the whole page, to avoid notification spam. It might be useful for me to quickly learn about replies to requests I responded to, but I don't want to be notified about all SRP request changes, even requests where I did not contribute in any way. In any way, it should let me to unsubscribe if I want to.

Event Timeline

As a workaround while this gets fixed, you may try to unsubscribe via https://meta.wikimedia.org/wiki/Special:TopicSubscriptions I think.

I was able to subscribe to and then unsubscribe from https://meta.wikimedia.org/wiki/Steward_requests/Permissions#Requests, but this produced a subscription with sub_item equal to h-, which is not supposed to be allowed (ref) and which is also different from your subscription.

This may be related to the changes from T298617?

Note: users have reported being able to successfully unsubscribe via Special:TopicSubscriptions

I think the problem is that at the moment when

comment.replies.forEach( threadScan );

runs here for the subheading items of the "Requests" heading item, their replies property is not ready yet – it is populated only for the heading item itself (here), but not for its descendants. Therefore, the properties of the heading item (oldestReply, commentCount, name and so on) are not filled correctly.

@Jack_who_built_the_house if that's the issue (I have done no investigation), there's a strong chance that I fixed it with this patch for T318057 which is going out on the train this week.

Just tested, that patch indeed fixes it for me, and the explanation for why it works makes sense.

EAkinloose subscribed.

I was able to subscribe and unsubscribe without errors

Screenshot 2022-09-29 at 16.11.56.png (200×548 px, 24 KB)

ppelberg claimed this task.