Our collective bad - it should've been in the acceptance criteria.
@TBolliger They're not actually opposite, though I can see how it sounds that way...
Here's what we discussed in estimation:
Thu, Feb 21
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.
Tue, Feb 19
Mon, Feb 18
@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.)
Fri, Feb 15
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.
Thu, Feb 14
Wed, Feb 13
The problems outlined in the task description have been separated into subtasks:
Tue, Feb 12
Mon, Feb 11
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.
Fri, Feb 8
...An additional concern might be that someone who is using English but isn't that confident in English might not understand "Got it"?
@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:
Thu, Feb 7
@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=).
Tue, Feb 5
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...
Sun, Feb 3
Here's a summary of what we've discussed so far.
Wed, Jan 30
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.)
Tue, Jan 29
The call to User::getBlock from Title::checkUserBlock was introduced in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/478056/
Fri, Jan 25
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.
Jan 23 2019
@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.
Jan 22 2019
@TBolliger I have replicated the timing problem on The Good Place, you just have to type very fast.
Jan 18 2019
By default, the Main namespace appears as "(Main)" in the dropdown list. Is this correct, or should it be "Main"?
Jan 17 2019
Jan 15 2019
- 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).
Jan 14 2019
Jan 11 2019
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.)
Jan 10 2019
Jan 9 2019
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.
Jan 8 2019
Jan 7 2019
@TBolliger Great, so I think that means that the following two acceptance criteria are the only ones still not met:
Disabling the checkbox and using a link instead of a tooltip looks like this:
(Labels have also been updated in accordance with the discussion on T202773)