[go: up one dir, main page]

Page MenuHomePhabricator

Action API: list=blocks doesn't show reblock timestamps properly
Open, Needs TriagePublicBUG REPORT

Description

I'm not sure if this is a bug or an intended bahaviour, but list=blocks returns inconsistent values if the queried user is reblocked. Let's say some user is blocked by Sysop1, and then reblocked by Sysop2 as below:

{
    "by": "Sysop1",
    "byid": "Sysop1's userid",
    "timestamp": "2022-07-01T00:00:00Z", // the time at which the user was initially blocked
    "expiry": "infinity",
    "reason": "block reason"
}

{
    "by": "Sysop2",
    "byid": "Sysop2's userid",
    "timestamp": "2022-08-01T00:00:00Z", // the time at which the user was reblocked
    "expiry": "infinity",
    "reason": "updated block reason" // reason modified
}

Then, the API returns the following response:

{
    "by": "Sysop2",                       // updated
    "byid": "Sysop2's userid",            // updated
    "timestamp": "2022-07-01T00:00:00Z",  // not updated
    "expiry": "infinity",
    "reason": "updated block reason"  // updated
}

My question is, is this intended? If it's not, I'd appreciate it if anyone could fix it.

Event Timeline

Dragoniez renamed this task from Action API: list=block doesn't show reblock timestamps properly to Action API: list=blocks doesn't show reblock timestamps properly.Jul 23 2022, 2:33 PM

What is shown on Special:ListBlocks? The api should show the same result, because both using the same data.

From my testing the timestamp is also not updated there.
Why you expect the reblock timestamp to be found in the result? It is not a fresh block, just a reblock with some new parameters set.

@Umherirrender Just as I explained, but let's look at this:

2022-07-23T09:11:45 さかおり (talk | contribs) changed block settings for 페어 아가스 (talk | contribs) with an expiration time of indefinite (account creation blocked, cannot edit own talk page) (LTA:ASPE)
2022-07-23T09:11:07 Nnh (talk | contribs) blocked 페어 아가스 (talk | contribs) with an expiration time of indefinite (account creation blocked, email disabled, cannot edit own talk page) (sockpuppet)
// Code
new mw.Api().get({
    'action': 'query',
    'list': 'blocks',
    'bklimit': 'max',
    'bkusers': '페어 아가스',
    'bkprop': 'id|user|userid|by|byid|timestamp|expiry|reason|range|flags|restrictions',
    'formatversion': '2'
}).then(function(res) {

});
URL (couldn't paste a proper link because of the pipes):
https://ja.wikipedia.org/w/api.php?action=query&list=blocks&bklimit=max&bkusers=페어 아가스&bkprop=id|user|userid|by|byid|timestamp|expiry|reason|range|flags|restrictions&formatversion=2

This returns:

{
    "batchcomplete": true,
    "limits": {
        "blocks": 500
    },
    "query": {
        "blocks": [
            {
                "id": 1234332,
                "user": "페어 아가스",
                "userid": 1971465,
                "by": "さかおり",      // sysop who applied the reblock
                "byid": 368127,      // sysop who applied the reblock
                "timestamp": "2022-07-23T09:11:07Z", // timestamp of the first block
                "expiry": "infinity",
                "reason": "[[LTA:ASPE]]",     // reblock reason
                "rangestart": "0.0.0.0",
                "rangeend": "0.0.0.0",
                "automatic": false,
                "anononly": false,
                "nocreate": true,
                "autoblock": true,
                "noemail": false,     // reblock criteria
                "hidden": false,
                "allowusertalk": false,
                "partial": false,
                "restrictions": []
            }
        ]
    }
}

The thing is, I'm running a bot that marks up block requests on the admin's noticeboard, and there're sometimes requests like "This user has already been blocked but his/her talk page needs to be disabled", but since we can't get the timestamps of reblocks, the bot can't update markups in accordance with reblocks. This is because it compares the time at which the request was submitted with the time at which the block was applied, and it runs only if the request timestamp is prior to the block timestamp. As far as I'm concerned, the timestamp property of the response object should be "2022-07-23T09:11:45Z" (reblock timestamp) because all other info shows the criteria for the reblock. Or, as an alternative, it'd be great if the API listed all blocks and reblocks one by one, for instance:

{
    "query": {
        "blocks": [
            {
                "id": 1234332,
                "user": "페어 아가스",
                "userid": 1971465,
                "by": "さかおり",
                "byid": 368127,
                "timestamp": "2022-07-23T09:11:45Z",
                "expiry": "infinity",
                "reason": "[[LTA:ASPE]]",
                "nocreate": true,
                "noemail": false,
                "allowusertalk": false
            },
            {
                "id": 1234332,
                "user": "페어 아가스",
                "userid": 1971465,
                "by": "Nnh",
                "byid": 474,
                "timestamp": "2022-07-23T09:11:07Z",
                "expiry": "infinity",
                "reason": "sockpuppet",
                "nocreate": true,
                "noemail": true,
                "allowusertalk": false
            }
        ]
    }
}

But as I mentioned above, I'm not sure whether the current behaviour is intended or not.

But the blockID doesn't change even if the relevant user is reblocked, so the alternative is perhaps not a very good idea. I'm just wondering whether that the timestamp doesn't get updated is a bug or intended.... and it seems like there's no way to get the reblock timestamp at present, using the action API.

But the blockID doesn't change even if the relevant user is reblocked

Sorry forget about what I said in the quoted part. This probably isn't the case because the logIDs of the blocks are different (6055924 (initial block), 6055931 (reblock)).