Change 855018 had a related patch set uploaded (by AGueyte; author: AGueyte):

[mediawiki/extensions/Thanks@master] Remove GlobalBlock calls from Thanks

https://gerrit.wikimedia.org/r/855018

Testing notes:

This can be tested on Beta.

I tested as a logged-in user, since only registered users can thank. I globally blocked the user's IP address. I did not check "Globally block anonymous users only" on the global block form, to ensure my user would be blocked by the global block.

I tested locally with the Thanks extension installed. Also the Echo extension, which Thanks depends on.

I tested in these places:

• On a history page (click on the history tab at the top right of any article page), "thank" links appeared next to the lines when there was no global block. They did not appear when the global block was applied.
• On Special:Log, "thank" links appeared next to log lines when there was no global block. They did not appear when the global block was applied.
• Using Special:APISandbox, I chose "thank" from the action dropdown, clicked on "action=thank", and entered a revision ID[1] in the "rev" input. I got a blocked error when there was a global block; success with no global block.

[1] One way to find a revision ID: go to a history page and click on the timestamp for any revision in the list. The revision ID appears in the URL as the value for the oldid parameter.

Notes:

• Thank links do not appear next to all log items. One example where they do appear is next to the log for when someone creates a page.
• On a history page, thank links do not appear next to all revisions. E.g. they don't appear next to revisions made by the user doing the thanking, or revisions where the user has already thanked.

Change 855018 merged by jenkins-bot:

[mediawiki/extensions/Thanks@master] Remove GlobalBlock calls from Thanks

https://gerrit.wikimedia.org/r/855018

On Special:Thanks/<revid>, the respective block messages for each type of global block:

• Global blocked IP: globalblocking-blockedtext-ip
• Global blocked range: globalblocking-blockedtext-range
• Global blocked IP/range in XFF header: globalblocking-blockedtext-xff

On API:Thank you always appear to get the same response, such as:

{
    "error": {
        "code": "blocked",
        "info": "You have been blocked from editing.",
        "blockinfo": {
            "blockid": 963,
            "blockedby": "Dom walden",
            "blockedbyid": 16150,
            "blockreason": "Crosswiki spamming: {{Click}}",
            "blockedtimestamp": "2022-11-11T13:01:21Z",
            "blockexpiry": "2022-11-11T16:01:21Z",
            "blockpartial": false,
            "blocknocreate": true,
            "blockanononly": false,
            "blockedtimestampformatted": "13:01, 11 (november) 2022",
            "blockexpiryformatted": "16:01, 11 (november) 2022",
            "blockexpiryrelative": "in 2 hours"
        },
        "docref": "See https://en.wikipedia.beta.wmflabs.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": "deployment-mediawiki11"
}

With always "code": "blocked" regardless of type of Global block.

You don't see the "Thank" link on revision history or Special:Log.

If you open revision history/Special:Log before being blocked, when you click the "Thank" link you see a popup: Thank action failed (error code: blocked). Please try again.

The Special:Thanks/Flow/<flow id>, API:flowthank and thanking on Structured Discussion (Flow) pages behave the same way as their non-Flow counterparts.

Test environment: https://en.wikipedia.beta.wmflabs.org MediaWiki 1.40.0-alpha (f53279b) 12:06, 11 November 2022. GlobalBlocking – (bea7a07) 07:12, 10 November 2022. Thanks 1.2.0 (d287af1) 19:01, 9 November 2022.

In T318891#8389466, @dom_walden wrote:

On API:Thank you always appear to get the same response, such as:

{
    "error": {
        "code": "blocked",
        "info": "You have been blocked from editing.",
        "blockinfo": {
            "blockid": 963,
            "blockedby": "Dom walden",
            "blockedbyid": 16150,
            "blockreason": "Crosswiki spamming: {{Click}}",
            "blockedtimestamp": "2022-11-11T13:01:21Z",
            "blockexpiry": "2022-11-11T16:01:21Z",
            "blockpartial": false,
            "blocknocreate": true,
            "blockanononly": false,
            "blockedtimestampformatted": "13:01, 11 (november) 2022",
            "blockexpiryformatted": "16:01, 11 (november) 2022",
            "blockexpiryrelative": "in 2 hours"
        },
...
}

I can see two problems here (not really specific to this task, it just made think of them).

One is that for global blocks, $block->getBlocker() might return a user that does not exist locally (if the person who issued the global block never visited that wiki). This is not incorrect behavior, I'm just wondering if it might trip up some code somewhere which doesn't expect it. Also I think it would be good to warn about this in the interface documentation.

(Also also, handling of potentially-locally-nonexistent users in MediaWiki is a mess, where sometimes we use a UserIdentity with the SUL name and ID 0, sometimes a UserIdentity with the SUL name with an interwiki prefix and ID 0, sometimes a UserIdentity with the SUL name with a wiki ID prefix and ID 0, and sometimes numeric IDs given by CentralIdLookup. More specifically, GlovalBlocking returns an external user with a different prefix syntax from what ExternalUserNames expects. We should really clear that up somehow, but that's a larger thing; filed T322953: Standardize handling of remote / external users in MediaWiki about that.)

The other thing is that this blockinfo array is indistinguishable from the blockinfo array for a local block; since it contains a database ID, there should be some way to tell which database it refers to. Filed as T322954: ApiBlockInfoTrait should indicate the type of the block.

In T318891#8390187, @Tgr wrote:

One is that for global blocks, $block->getBlocker() might return a user that does not exist locally (if the person who issued the global block never visited that wiki). This is not incorrect behavior, I'm just wondering if it might trip up some code somewhere which doesn't expect it. Also I think it would be good to warn about this in the interface documentation.

Good point.

I tested this on beta by creating a global block on enwiki with a user (Drwpb1) who does not exist on dewiki. I then attempted a few different actions on dewiki.

The API response I get when I try API:Thanks and API:Upload:

{
    "error": {
        "code": "blocked",
        "info": "You have been blocked from editing.",
        "blockinfo": {
            "blockid": 976,
            "blockedby": "Enwiki>Drwpb1",
            "blockedbyid": 0,
            "blockreason": "",
            "blockedtimestamp": "2022-11-14T13:21:49Z",
            "blockexpiry": "2022-11-14T16:21:49Z",
            "blockpartial": false,
            "blocknocreate": true,
            "blockanononly": false,
            "blockedtimestampformatted": "14:21, 14. Nov. 2022",
            "blockexpiryformatted": "17:21, 14. Nov. 2022",
            "blockexpiryrelative": "in 2 Stunden"
        },
        "docref": "See https://de.wikipedia.beta.wmflabs.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": "deployment-mediawiki11"
}

When attempting to delete, edit or move a page:

The first message is coming from GlobalBlockingHooks::onGetUserPermissionsErrorsExpensive (apparently) and the "Drwpb" is a link to https://en.wikipedia.beta.wmflabs.org/wiki/User:Drwpb1 (the wiki the global block was made on).

The second message is coming from GlobalBlockingHooks::onGetUserBlock.