In T358076#9565154, @Umherirrender wrote:

Maybe a captcha was shown and abuse filter already logged the first try, but the account was not created (captcha not filled). But I have not tested that.

As abuse filter is working very early for the checks, it may have some logs even the action does not happen.

In T357757#9552941, @taavi wrote:

Which problem is this trying to solve?

In T355063#9460635, @Vikipolimer wrote:

Which log type do you want to control, e.g. only "protect" or all log entries?

All, I would say, if I’m asked to think about the fundamental spirit of this task. But I’m guessing a step-by-step implementation would make a good starting point if it’s going to be too time-consuming.

@Vikipolimer Thank you, and yes, something like that. If I were an anonymous user and the log #65 had been action-deleted, then the response array in the 2nd example should be empty because the object in it is the only log that matches the current protection settings of the page Hello.

Or, leave action-hidden logs in the response and only show what can be shown, e.g. logid and timestamp. This may be another workaround.

(Just adding a mention) T307827

The same kind of reports can be found on ja:WP:VILLAGE and ja:WP:HELPDESK as well.

And what I wrote above was inaccurate, the issue persists in the links below section headings as well when enclosing the comparison operator with nowiki.

In T336142#8833256, @Ladsgroup wrote:

It's not as simple as it looks, watchlist_expiry holds an extra column as the timestamp that's binary(14), in enough size can undo the benefits by being bigger than of holding them unconditionally in watchlist.

I see. Thank you all for your help.

In T336142#8833194, @kostajh wrote:

Ah, OK. Cc'ing DBA -- the code comments for the Watchlist expiry feature mention that 1 year exists as an upper limit due to concerns about database table size for watchlist_expiry.

Alright, that makes sense. Permanently having 10k+ pages in the watchlist or some of them getting removed periodically, I wonder which is parsimonious for the database. Thanks, Community-Tech.

I appreciate your help. I guess the dropdown options can be the same and don't have to have an option like " 3 years". For my purposes, the API is the only one that I want to be modified.

@kostajh That's an option but not the best one, as far as I'm concerned, because any time we protect a page for more than 1 year, it'll be necessary to watch the page indefinitely. This will take up too much "space" in the watchlist.
The thing is, older users have so many pages in the watchlist, and probably the situation is even worse for sysops who surveil pages that have previously been targeted for vandalism. The more pages the watchlist has, the slower it is loaded.

Weird. When I tried to identify the cause of the issue illustrated by the first picture in Op, I didn't see any error message in console but now I get one for the deprecated p-namespaces, and also it's now impossible to reproduce the misaligned portlet link as in the image and in fact no portlet link is added to the position if I use p-namespaces (although this behaviour is normal because it just means p-namespaces is missing. Maybe there was p-namespaces when I initially filed this task but now there isn't? I don't know.) This task can be closed now, it would be a waste of time to try to "fix a bug" for the deprecated feature. I appreciate your help.

@Jdlrobson
That script isn't quite a gadget actually. It's just an experimental script made only for demo purposes for a discussion in village pump.
The following code replicates the misalignment issue, so I believe this is an issue of the vector-2022 skin.

mw.loader.using('mediawiki.util', function() {
    mw.util.addPortletLink('p-namespaces', '#', 'MISALIGNED');
});

I'd like to "bump" this task because it appears that the issue is still present in 2023.
Try the following link (the server domain, ja.wikipedia.org, should be modified if needed):
https://ja.wikipedia.org/w/api.php?action=query&list=globalallusers&agulimit=max&agugroup=founder%7Csteward%7Combuds%7Cstaff%7Csysadmin%7Cglobal-sysop%7Cabusefilter-maintainer%7Cabusefilter-helper%7Cglobal-interface-editor%7Cglobal-bot%7Cglobal-deleter%7Cglobal-rollbacker%7Cvrt-permissions%7Coathauth-tester&aguprop=groups&formatversion=2
Notice that agulimit is set to max. I have an admin right on jawp (hence have apihighlimits), then get 1467 responses, but when I open this link on an incognito window (meaning not logged in), I only get 500 responses (which is normal) and there's no continue property (which is abnormal).

A bit more information.
I tried erasing the relevant conditions that prevent account creations BEFORE forcible account creation, then that wasn't barred by the filter (note: I didn't either DISABLE or DELETE the filter). Maybe this is a workaround.
Anyway, when I forcibly created the relevant local account and blocked it for sockpuppetry with autoblock turned on, my IP was autoblocked. Is this normal? It's ridiculous that the IP of the sysop that took the admin action is autoblocked. Also, my IP will probably show up when the blocked user is CU-ed.

@Daimona Thank you so much for your detailed inspection, and

@Daimona It's fine, this would be time-consuming.
Our filters include both added_lines and removed_lines if they need to detect content addition/removal, so the false positives we came across are likely to be attributed to this bug.
Anyway, as I said above, we'd appreciate it if anyone could take care of this matter.

@Daimona Thanks for the quick response. I'm pretty sure this can make false positives (and in fact it did), so we'd appreciate it if anyone could fix it.

In T313661#8099586, @Dragoniez wrote:

But the blockID doesn't change even if the relevant user is reblocked

Sorry forget about what I said in the quoted part. This probably isn't the case because the logIDs of the blocks are different (6055924 (initial block), 6055931 (reblock)).

But the blockID doesn't change even if the relevant user is reblocked, so the alternative is perhaps not a very good idea. I'm just wondering whether that the timestamp doesn't get updated is a bug or intended.... and it seems like there's no way to get the reblock timestamp at present, using the action API.

@Umherirrender Just as I explained, but let's look at this:

Sorry I did something wrong.

@Xaosflux Yes, that's right. Just like "action=query&pageids=" and "action=query&revids=", this is what I'm looking for.

@Trizek-WMF, thank you for your reply again! And I'm sorry, I didn't know new accounts don't get notifications for reverts on jawiki and enwiki. Before I filed this (actually long ago), I took a look at ja:Wikipedia:通知, en:Help:Notifications, and mw:Help:Notifications/Types, but I only found "Received when your edits are undone or rolled back", and for this reason I had been thinking any account gets revert notifications when their edits are rolled back.

@Trizek-WMF, I think that that would involve some serious drawbacks, unfortunately. This is because new users and IP users would then need to do a manual revert any time when they want to revert others' edits, and the problem is that manual revert is way more complex than undo revert. Undo revert is very simple and straightforward because users just need to hit the undo link, but when you need to do a manual revert, you need to either first open a diff page and then do action=edit, or make exactly the same edit as the relevant previous revision. (And I'm pretty sure that even some extended-confirmed users don't know how to restore a previous revision from a diff.) Plus, the number of bad-faith edits is limited, and overall, undo reverts by new users are good-faith edits (like reverting vandalism edits). Disallowing undo reverts for new users would be easy because it can be achieved just by hiding the undo link for them via the CSS, but this is unlikely to be a solution for this matter, unfortunately.

Hi @Trizek-WMF, thank you for your reply. I have rollback rights on the Japanese Wikipedia and revert vandal edits on a daily basis, and I frequently face situations in which vandal users revert my (and others') rollback edits just in a minute or so (e.g. 1, 2, 3, 4, 5) (the last 2 are instances on enwiki; you might want to search for '巻き戻し' on the Japanese links to find rollback edits). Currently, rollbacking sends a notification to the user whose edit's been rollbacked, and I think this notification is unnecessary because it makes it easier for vandal users to find pages to re-vandalize. Please note that I'm talking about the rollback revert only, not about the undo revert. I think the notification function for the undo revert should be as it is now because it's a very useful function and also because it's used to revert good-faith and non-vandalism edits. My idea is particularly important to rollbackers, who don't have block rights unlike sysops. Sysop can settle vandalism by blocking the relevant users or protecting the affected page, but we rollbackers need to always be careful not to do any harm on the revision history of the page before sysops take some countermeasures, because we want to keep it clean and prevent further vandalism and edit wars. One way to do this is do a manual revert, because this doesn't send notifications. But since manual revert can't be done automatically, it's nowhere near efficient than rollback. For this reason, I have always wanted rollback to not send notifications, and these are the reasons why I think notifications should be disabled for the rollback revert (across all wikiprojects). Thank you.

@kostajh Oh I'm sorry, I'm new here and I thought we can post some random ideas directly on phabricator and discuss them here. Should I go make a thread on e.g. enwiki for discussion to build a consensus?