See also T323088: Global blocks should be displayed below local blocks.

/me pokes the unattached images.

In T344463#9100728, @Izno wrote:

See also T323088: Global blocks should be displayed below local blocks.

Ah, this may be a dupe of that then.

/me pokes the unattached images.

Sorry, I changed "form" so I guess Phab got confused.

The combining/generic block reason is fairly useless as to informing the editor what is going on, displaying all the block messages would be better.

I spoke with @L235 about this and we're wondering if this issue is caused by changes made in T322941. I'll speak to AHT

See also: T342870: Block ID list on the overlapping block message mixes local and global block ids

In T344463#9115305, @jrbs wrote:

I spoke with @L235 about this and we're wondering if this issue is caused by changes made in T322941. I'll speak to AHT

That's correct. Sounds like we could do with some product/design input here - adding @Niharika @KColeman-WMF

One complexity is that there could be more than one type of local block (e.g. blocks targeting some subset of the user, their IP, a range covering their IP, and their IP could also appear on a disallow-list). If there are multiple local blocks with different reasons, is there a best one to show, or should they all be shown?

Has there been any determination if this is a regression? The current message is mostly useless when a user is trying to share it to get help.

Hello everyone. I write to emphasize this is a highly urgent issue and needs prioritization. This issue affects everyone who is using a VPN and editing the English Wikipedia -- including many who may not even know that they are using a VPN (see, e.g., iCloud Private Relay). I am guessing this is at least 10% of the non-established editors who attempt to edit, though I don't have a real basis for this. As I'm sure y'all can empathize with, receiving this message must be infuriating and entirely inconsistent with the Foundation's prioritization of Growth in its planning.

Fixing this also strikes me as low hanging fruit, relative to the large impact.

I'm available for a call or to discuss in more depth why this should be "Unbreak Now" status. A few specific thoughts:

One complexity is that there could be more than one type of local block (e.g. blocks targeting some subset of the user, their IP, a range covering their IP, and their IP could also appear on a disallow-list). If there are multiple local blocks with different reasons, is there a best one to show, or should they all be shown?

Perhaps the one with the longest duration, or the most specific one (local over global; within local, accounts, then individual IP blocks, then IP ranges by CIDR size?). Certainly prefer local to global blocks, because local IPBE can override global blocks, but global IPBE can't override local blocks.

But it is better to choose any of these options, or to show multiple blocks, than to wait.

Has there been any determination if this is a regression? The current message is mostly useless when a user is trying to share it to get help.

In the past both global blocks and local blocks would be shown. I don't know when that was changed.

I'll note that it's not just an enwiki problem, as several other projects make significant amounts of local proxy blocks.

Change 965048 had a related patch set uploaded (by Tchanders; author: Tchanders):

[mediawiki/core@master] Add hack to display the reason from one block in a CompositeBlock

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

This should show one local block message, but not necessarily the preferred one if there are multiple local blocks

With Thalia's patch:

It's an improvement, I guess. It's still very bad. Putting a line break in $2 of blockedtext-composite breaks the list created by the initial colon, so the real reason appears in its own paragraph with no indent. With a template generating a block-level element, the period after the </em> also ends up on its own line.

We are still saying the reason given is blockedtext-composite-reason "There are multiple blocks against your account and/or IP address" which is wrong, that's not the reason given. Maybe it's the reason for the permission denied error, but it's not the reason for the block.

And where is the name of the blocking admin? There is a bunch of useful information in the blockedtext parameters which we throw away when we decide to deliver blockedtext-composite.

I'd rather just loop over all original blocks and show the blockedtext message for each one.

It's definitely an improvement. I'll take it, if that's what we've got. Looping over all the blocks would also be satisfactory. Or, just remove the "There are multiple blocks against your account and/or IP address" part — that's already implied because we're calling blockedtext-composite, not blockedtext. If you remove the "There are multiple blocks against your account and/or IP address" from the block reason, that allows local customization for how to inform the user that there are multiple blocks.

Thanks for the comment @L235. @Xaosflux @AntiCompositeNumber @Izno @taavi as a quick solution for this problem, is the currently implemented solution acceptable?

... show one local block message, but not necessarily the preferred one if there are multiple local blocks

Putting a line break in $2 of blockedtext-composite breaks the list created by the initial colon, so the real reason appears in its own paragraph with no indent. With a template generating a block-level element, the period after the </em> also ends up on its own line.

This needs to be fixed.

We are still saying the reason given is blockedtext-composite-reason "There are multiple blocks against your account and/or IP address" which is wrong, that's not the reason given. Maybe it's the reason for the permission denied error, but it's not the reason for the block.

And where is the name of the blocking admin? There is a bunch of useful information in the blockedtext parameters which we throw away when we decide to deliver blockedtext-composite.

I'd rather just loop over all original blocks and show the blockedtext message for each one.

Agree with all three.

Thanks everyone. Just awaiting confirmation from @Niharika on what we want to do for now, then I'll update the patch.

Based on the feedback, I think we should do the following:

• Adding a line break in $2 of blockedtext-composite breaks the list created by the initial colon, so the real reason appears in its own paragraph with no indent. With a template generating a block-level element, the period after the </em> also ends up on its own line.
• Remove the blockedtext-composite-reason "There are multiple blocks against your account and/or IP address" because that doesn't make sense.
• Loop over all original blocks and show the blockedtext message for each one.

Change 965048 merged by jenkins-bot:

[mediawiki/core@master] Display all error messages for a CompositeBlock

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

In T344463#9287523, @gerritbot wrote:

Change 965048 merged by jenkins-bot:

[mediawiki/core@master] Display all error messages for a CompositeBlock

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

@Tchanders After this change, trying to create an account via the API when I am composite blocked the messagecode in the response is strange.

{
    "createaccount": {
        "status": "FAIL",
        "message": <message>,
        "messagecode": "___1____2____3____4",
        "canpreservestate": false
    }
}

The numbers seem to correspond to how many blocks make up the composite block.

Previously (or now with only a single block), it would return "messagecode": "blocked"

Thanks @dom_walden - looks like an existing problem that is caused by multiple errors in general. Filed as T350248: Api error for account creation has numerical error codes when there are multiple errors

I tested this along with T349826.

@Tchanders can this be marked as resolved?