In T189362#8356363, @Oshwah wrote:

Can anyone test? I tested this today on test-wiki and was able to create accounts from a blocked IP when IPBE was applied.

I think it's ready to be deployed on mobile? Just make the IP info box always collapsed and do not touch the mw-ipinfo-infobox-expanded user preference if on mobile frontend.

@Ericliu1912, it has not been deployed on production yet (not sure why @ReleaseTaggerBot did not add a tag). You can verify on beta cluster where it works like a charm: https://zh.wikipedia.beta.wmflabs.org/wiki/Special:活躍使用者

Can confirm this is resolved.

The patch cannot be merged until unit tests are fixed in T309678.

So this seems to be blocked by T180173 (popup widget displays incorrectly on small screens).

Also related to T22208 which reports duplicate page_random. Turns out that there are currently more than 1000 groups of articles on English Wikipedia with duplicate page_random. In other words, the gap is 0 and some of those articles will never be picked. An obvious workaround would be using a maintenance script or something to periodically regenerate page_random. Doing that, the distribution is still skewed within the same period, but in the long run each article has a fair chance to be picked.

Bruh I'm stupid and for some reason was looking at the doc for 1.29.

Looks like the patch was already merged on 25 Apr 2022 and the issue has been resolved.

Only JS and CSS rules are disabled on mobile explicitly by rEIPI5431b44d6b86: Explicitly disable IPInfo for mobile targets, but the infobox is always inserted to page html in src/HookHandler/InfoboxHandler.php. Possible fix: add oo-ui-element-hidden class to new PanelLayout() in php file to make the infobox hidden by default, then remove the class in modules/ext.ipInfo/infobox/init.js.

Thanks @TheresNoTime for testing and code reviewing :) API docs will be automatically updated when this is deployed on MediaWiki.org, then I will edit the Parameter history section.

And we might also want to do the same for Special:Log. For example, block log of User:2600:1700:2070:8500::/64 displays the range blocks as expected, but User:2600:1700:2070:8500:E9EF:1BCA:92B8:77C4/64 shows nothing. This may cause some confusing as well, since it is a common use case (at least for me) to directly append /64 to a single IP and check relative logs from the range.

Updated the patch demo with the current patch set, link to the new demo site. Thanks Bartosz and Volker for code reviewing :) Here are some screenshots from the current design:

A quick summary of what I have dug up:

• Try to create accounts via api causes the same error.
• $this->authManager->beginAccountCreation() called by includes/api/ApiAMCreateAccount.php:105 to create an account
• $provider->testUserForCreation() called by includes/auth/AuthManager.php:1078 to check if we are denied by one of the providers
• We are denied by includes/auth/CheckBlocksSecondaryAuthenticationProvider.php because we have been blocked so $user->isBlockedFromCreateAccount() in L79 got the block.

Not sure why is this only causing issues recently though.

Seems that the issue has been fixed - CA for ɱ and Ɱ both give the results of Ɱ, and global rename log simply shows nothing.

Everything looks OK now (try it out here), except the padding between page and namespace panels seems too small. Feel free to do more tests on the patch demo.

@matmarex sure, I almost finished the patch with parent set to your change, just need a few more local testing. I plan to introduce some css rules in resources/src/mediawiki.special/whatlinkshere.less to position the invert and filter checkboxes. Flexbox for ns selection + invert checkbox to make them in the same line, and display: inline-block for filter checkboxes. I am also going to make the whole box collapsed if target is set which means the user is browsing results. Some screenshots will be posted later.

From the above discussion, here are a few notes I took:

• The Invert selection checkbox should be in the same line with the namespace dropdown list.
• Filter checkboxes should be inline-block so they will be in the same line if possible, and not consume too much space.
• Since OOUI design is still much spaced than current, we should make the form collapsible, and collapsed by default when parameters are set (i.e. user is browsing the results), just like the current behavior of Special:Contributions.

I will try to implement the above design, and any other suggestions are welcomed.

According to the insertable suggester, almost anything is allowed in a variable name including - and $, so the two variables are greedily combined together. Not sure how can we fix this, though. Maybe disable the use of $ in tvar names?

This makes sense to me, just like contains_any vs multiple in statements. And we can create a new function ip_in_ranges and implement it with IPUtils::isInRanges.

In checkPermissions() of SpecialUndelete.php, the parent (SpecialPage class) will be consulted first to check parent::userCanExecute( $user ), and SpecialPage::userCanExecute only checks if the user has deletedhistory right. So we have to grant the global group deletedhistory right without touching mediawiki core.

Just to clarify that I'm still interested in working on this. Sorry for the delay.

The tool is working normally now. It is still under development so feel free to inform me if something breaks again.

1.37.0-wmf.4 has been deployed on meta.

Hi @MusikAnimal, thanks for the quick reply. I would like to help and was wondering if there are any existing test environments on Toolforge (or maybe docker image?) available for development purposes like this, or shall I create a new tool and set up the environment following the doc? Thanks :)

I've been playing around with this recently. A new parameter is needed certainly, say, iprange. Then just fork and modify the $userIter of userprefix parameter (in ApiQueryUserContribs::execute) and that's it, imho. Desired $userIter should yield IP addresses selected from ip_changes, with condition ipc_hex BETWEEN <start> AND <end> and group by ip_hex. The rest is similar to other parameters, so ApiQueryUserContribs::prepareQuery won't be affected.

Based on debugging logs on my local wiki, this is because UserRightsProxy::addGroup is not allowed to update existing user groups (see this line) while User::addGroup can do so, changed in this commit. So just doing the same thing as the aforementioned commit for UserRightsProxy will be a fix. I'll figure out if there are any side effects and submit a patch soon.

Thank you for notifying me. The tool is just a preliminary version and needs a revamp though recently I'm too busy to do so. The webservice is temporarily stopped until I can figure out the issue.

As the description has been elaborated, I'm changing the status back to open.

@Aklapper, I've done some additional tests and revised the task description. Please let me know if there is anything still vague. Sorry for being unclear before.

I've managed to fix both lziad and lziad-cvnbot. Sorry for any trouble caused.

https://www.mediawiki.org/wiki/Special:MyLanguage/API:Tutorial seems to be a better alternative, according to the above.

I prefer the idea to add a link to the actual sandbox query. The message document does not need to be updated so I'm not going to modify qqq.json.

According to @A2093064 's advise I removed both of its subcategories and deleted that category to fix above glitch in database. After restoring again it seems working well so I'm closing it as invalid (if I'm making mistakes fell free to correct me).

@Amorymeltzer Oh yeah I got it. IMHO it would be more appropriate to enable it while do some additional check in skin stuff like SkinTemplate.php.

It turns out to be intentional - see highlighted lines of SpecialContributions.php. However, I cannot figure out why the comments say a 'logs' link (of an IP range) may be irrelevant and am looking forward to a reply from those who know it.

@Ammarpad : sorry to disturb you but two months have past and I'm wondering when could we get that enabled, or are there any stuff we need to provide? Thanks a lot!

@Ammarpad, according to blocking policy on zhwiki, 24 hours should be a reasonable duration for both logged-in and IP users.