Change 596690 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/core@master] SpecialBlock: Fix flag set on block if $wgBlockAllowsUTEdit is false

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

What happens if the config value changes (or worse, is not consistently one or the other?) Should the existing values in the database be updated or should they remain as-is?

(Assuming this task is about the MediaWiki-Blocks code project, hence adding that project tag so other people who don't know or don't care about team tags can also find this task when searching via projects. Please set appropriate project tags when possible. Thanks! :)

@dbarratt It's a good question - I think it's worth discussing what should happen if the flag changes, since it doesn't seem to have been discussed elsewhere. Here's a task for that: T253051

For this task, we should restore the behaviour that existed in SpecialBlock::processForm before it was accidentally changed, since that will allow extensions to call the new service without changing their behaviour.

Change 596690 merged by jenkins-bot:
[mediawiki/core@master] SpecialBlock: Fix flag set on block if $wgBlockAllowsUTEdit is false

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

• If the UserTalk namespace is not blocked, then ipb_allow_usertalk is always true
• If the UserTalk namespace is blocked and $wgBlockAllowsUTEdit is false, then ipb_allow_usertalk is always false (this is the bug - it's currently always true)
• Otherwise, ipb_allow_usertalk is determined by the form field

I tested the Special:Block form in the cases of:

• $wgBlockAllowsUTEdit = false on local vagrant MediaWiki 1.35.0-alpha (7fc72f3).
• $wgBlockAllowsUTEdit = true on https://en.wikipedia.beta.wmflabs.org MediaWiki 1.35.0-alpha (8a85f2e) 06:18, 21 May 2020.

It behaved consistently with my understanding of the acceptance criteria above (although I still find it a bit confusing at times).

To be more systematic, I wrote a script using the block API (which also uses SpecialBlock::processForm) to create a number of blocks with different combinations of block parameters, with $wgBlockAllowsUTEdit = false and $wgBlockAllowsUTEdit = true.

The script queried the database and API (action=query&list=blocks) to check the correct value of ipb_allow_usertalk, based on the below logic (done as pseudocode):

if partial and namespace restriction not equals User_talk:
    expected ipb_allow_usertalk value = true

else if (sitewide or namespace restriction equals User_talk) and not $wgBlockAllowsUTEdit:
    expected ipb_allow_usertalk value = false

else:
    expected ipb_allow_usertalk value = value of allowusertalk parameter that was POSTed

which I think accurately replicates the acceptance criteria, but perhaps @Tchanders can double check for me.

One interesting thing: If I am partially blocking Eve with only a page restriction on "User_talk:Eve":

• If $wgBlockAllowsUTEdit = false then ipb_allow_usertalk is true but Eve is blocked from "User_talk:Eve"
• If $wgBlockAllowsUTEdit = true then the allowusertalk checkbox is disabled* and ipb_allow_usertalk is true but Eve is blocked from "User_talk:Eve"

I guess this is consistent with the acceptance criteria insofar as the User_talk namespace is not being blocked here. But it still might be a bit confusing.

(* With JS disabled you get a validation error if you submit with the box checked)

[...] which I think accurately replicates the acceptance criteria, but perhaps @Tchanders can double check for me.

That's correct.

One interesting thing: If I am partially blocking Eve with only a page restriction on "User_talk:Eve":

• If $wgBlockAllowsUTEdit = false then ipb_allow_usertalk is true but Eve is blocked from "User_talk:Eve"
• If $wgBlockAllowsUTEdit = true then the allowusertalk checkbox is disabled* and ipb_allow_usertalk is true but Eve is blocked from "User_talk:Eve"

I guess this is consistent with the acceptance criteria insofar as the User_talk namespace is not being blocked here. But it still might be a bit confusing.

That's a good point - have filed a task for it, but is probably low priority: T253382