Our collective bad - it should've been in the acceptance criteria.

@dom_walden Ah, nasty - looks like it's is a new bug introduced by: T208510, merged not long before this. The JavaScript unchecks the checkbox because it's a partial block (with JavaScript disabled, it is checked). Filed as T216845.

@TBolliger They're not actually opposite, though I can see how it sounds that way...

Here's what we discussed in estimation:

The approach of making the ipb_allow_usertalk flag match the behaviour was abandoned (https://gerrit.wikimedia.org/r/488533) in favour of decoupling the block flags/logs/form on the one hand from the block's behaviour on the other hand (https://gerrit.wikimedia.org/r/489662).

The patch seems to resolve all the acceptance criteria.

The only supported hook appears to be in LiquidThreads and returns straight away if there is no block.

@Mooeypoo I think it makes sense to change to item.getLabel() in MenuTagMultiselectWidget because the label is what is exposed in the menu, so most users of this widget are probably more used to interacting with labels than data. (Incidentally the bug was reported for the NamespacesMultiselectWidget, so we'd want to change it there if not in the MenuTagMultiselectWidget.)

This also explains why a block's entries in the logs at Special:Block/<BlockedUser> and Special:BlockList are sometimes different. The former is created at the time when the block is originally submitted, so it reflects the block flags in the database. But the latter is dynamically generated, meaning that it has to represent how the block behaves, because of the lack of a mechanism for getting the block properties without Block::prevents modifying them first. The form at Special:Block/<BlockedUser> is also dynamically generated, so it also has to reflect the block's behaviour, and contradicts the block log at the bottom of the page.

The problems outlined in the task description have been separated into subtasks:

Just looking at a couple of other examples where special pages ask for feedback, which are both inline.

@Prtksxna That looks good to me!

@TBolliger @dbarratt Thanks, have updated the URL to Special:BlockList. The patch passes in the block ID param rather than the target, since the user attempting to edit might not be the target - e.g. if it's an autoblock or an IP range block.

...An additional concern might be that someone who is using English but isn't that confident in English might not understand "Got it"?

In T210273#4938269, @Amire80 wrote:

In T210273#4938231, @Tchanders wrote:

I wasn't sure about lengthening the "OK" message on the blue button, given the narrow width of the screen and possible longer translations in other languages. Perhaps @Amire80 has a opinion?

Thanks a lot for asking!

No, I don't see a problem here at the moment. OK is a common button on all platforms and it has standard translations in many languages, e.g. here.

If there will be a problem, the translators will complain ;)

@TBolliger Ok, that makes sense! The block details are present in the desktop version, but they still don't seem to be there in mobile frontend:

Destop	Mobile frontend

@TBolliger Is the user's talk page the best page to link to? As far as I can see, it doesn't contain block information in mobile frontend, and it only contains block information on desktop if you go to the edit tab... Unless I'm missing something!

We can gather any user account, block ID, or IP addresses of interest in User::getBlockedStatus, respecting the existing rules. We could then query for all relevant blocks at once - we could rename and modify Block::getBlocksForIPList for this purpose, since it's not used elsewhere (https://codesearch.wmflabs.org/search/?q=getBlocksForIPList&i=nope&files=&repos=).

The logic to determine whether a partial block allows a user to edit their own user talk page is currently executed in User::isBlockedFrom, at the point when the user attempts to edit their talk page. In order to make the block list correct, we'd either have to duplicate that logic when parsing the blocks for the block list, or move it to when the block is saved, and store it in the ipb_allow_usertalk flag rather than ignoring the flag for partial blocks, as discussed in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/477447/. I'm in favour of the second way, since it's more universal.

If it helps, we also discussed some implementation details...

Here's a summary of what we've discussed so far.

It is indeed being called with the default $rigor='secure' from Skin::getUndeleteLink: https://gerrit.wikimedia.org/g/mediawiki/core/+/refs/changes/80/484780/1/includes/skins/Skin.php#722 (That patch made this problem happen less often, by changing the order in which conditions are checked.)

The call to User::getBlock from Title::checkUserBlock was introduced in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/478056/

Thanks @TBolliger. Just to (probably over-) clarify, if we're ever in that situation and the admins do decide that any partially blocked users should be sitewide blocked, they'll have to make sure they unblock them first before setting a new sitewide block... Simply editing their partial block into a sitewide one won't work.

@Prtksxna Tooltips/inline text can currently be added to an OO.ui.FieldLayout or an OO.ui.FieldsetLayout, by setting a config option. There whole radio list is within one OO.ui.FieldLayout, and the options do not have their own, so it is not possible to add tooltips for each option in this way. We can implement this, but it didn't seem worth it for the demo on my previous comment.

@TBolliger I have replicated the timing problem on The Good Place, you just have to type very fast.

By default, the Main namespace appears as "(Main)" in the dropdown list. Is this correct, or should it be "Main"?

@dbarratt @TBolliger There's already a patch up for this - it might be better to merge that fix to ensure no partial-block suppressions accidentally get made, and then get to work on T213972.

• If the person changes a suppressed sitewide block to a partial block, it should become unsuppressed.

In order to do this, we need to uncheck the "hide user" checkbox whenever it is hidden. Otherwise, on reblocking the suppressed user with a partial block, the form will have the "hide user" checkbox checked and hidden, making it impossible to uncheck (without playing around with the parameters of the block).

On Test Wiki this is limited to only indefinite blocks, but it may be different across our various wikis.

The "hide user" checkbox is hidden from the UI if the expiration is not set to "indefinite" - do we need to worry about this? (That said, I can't imagine a use case for a non-indefinite suppression.)

@Amorymeltzer It looks like the appearing/disappearing behaviour of the "hide user" option was introduced and discussed in T133036. When the page got broken, the option became always visible again; then when the page was fixed (T212808), the appearing/disappearing behaviour resumed. (The fix didn't touch the "hide user" option logic, it just unbroke the page.)

This behaviour started after the fix for T212808 was merged. (In that sense it is indeed related to T209664.)

@aezell Good idea to keep track of all this properly - filed as T213451, so this can stay closed.

I agree with @Volker_E

@Prtksxna The "Confirm block" checkbox does only appear for re-blocks. I've separated considering what to do about this into T213292 - I imagine it's low priority, since the checkbox has been in place for some time.

I can confirm that this is fixed by the fix for T212808 - after this, the checkbox no longer reappears.

Discussions about the behaviour of the checkbox for a partially blocked user editing their own user talk page can be found on T211073 and T210475.

Link removed:

@TBolliger Great, so I think that means that the following two acceptance criteria are the only ones still not met:

@TBolliger With the messages to match the mockup, and the changes mentioned in T212964, it looks like this:

Disabling the checkbox and using a link instead of a tooltip looks like this: