It looks like this is actually a duplicate of T403913.

In T410724#11612192, @Dreamy_Jazz wrote:

Feel free to modify what I added to the rules format page. I'd support adding this to the general documentation for count

Unattached accounts on AbuseLog for account creation attempts will be styled with a dotted underline thanks to a newly introduced class attribute, mw-abusefilter-log-missinguserlink. Note that these links may still have the mw-anonuserlink class unless they are for temporary users, but they will now be styled by the backend, making it likely unnecessary for frontend users to prepare their own stylesheets.

It would be ideal if we could backport this, but for now please consider using a temporary (ugly) workaround like this or something similar you might already have, in your global.css until the next WP:ITSTHURSDAY.

BTW, I think the name $wgOnlyUserEditUserPage is a bit off for what the extension does now. Maybe the original idea was to only let registered users edit other people's user pages? I would probably go with something like $wgUserPageEditOwnerOnly instead.

This extension appears to have one real bug in how it restricts edits to user subpages. I'll fix it shortly.

The patch got a +2 and will be merged soon.

Something like the following at least works, although hardcoded width constraints elsewhere need to be handled separately.

It looks like the latest patch introduced a side effect. The interface labels are too wide now.

@Dreamy_Jazz Thanks a lot for moderating this.

In T416914#11598839, @Reedy wrote:

This should be fixed...

I've also encountered this on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1237964

It looks like this doesn't surface on the UI for any of the currently available skins because AbuseFilterSpecialPage::getShortDescription handles everything since this change and AbuseFilterSpecialPage::addNavigationLinks hits the early return code path every time.

Thanks, I wasn't aware that afl_log_id had once existed but was later dropped. My intention was to make it possible to remap abuse log entries associated with saved changes to MW logs, but now that I think about it more carefully I'm not sure how that can be achieved under the current AbuseFilter architecture which doesn't listen to MW log entry insertions. Let me mark this ticket as stalled to make a more concrete plan.

In T293321#7427987, @Daimona wrote:

My guess is that this would happen on any special page; it's just that the AbuseLog is (to my knowledge) the only place where an unattached account can be listed as the actor for a logged action.

I think that is correct. AbuseFilter uses core's Linker::userLink, which always adds the mw-anonuserlink class when there's no user ID.

Closing this as resolved, the patch got a +2 and will soon be merged.

Yeah, we need to reconstruct the container FieldLayout for wpFilterDeleted since the label belongs to that container

Temporarily marking this task as stalled because there's a blocker to address the issue

Unlike count in PHP, count in AbuseFilter is a string function that counts substrings in a haystack. From the doc:

Returns the number of times the needle (first string) appears in the haystack (second string). If only one argument is given, splits it by commas and returns the number of segments.

I haven't debugged this deeply but count probably stringifies the removed_links array first and just does its usual thing. When I tested this using one of those autocreateaccount logs:

!!count(removed_lines) /* true */

!!removed_links[0] /* false */

!!length(removed_links) /* false */

count('[]') === 1) /* true */

So, count(removed_lines) is likely equivalent to count('[]').

Just leaving a note:

I don't think the filter ID should be visible in the API response. Even on the UI, it's only inferable rather than visible.
Some projects give a single generic name to all private filters to make it impossible to infer which filter triggered an action, so the triggering filter being inferable here isn't an issue with AbuseFilter, but with the on-wiki setup.

In T414049#11537692, @codenamenoreste wrote:

I have announced this at the English Wikipedia, see this discussion I started.

This change should probably be announced to the community. Here's my suggestion:

@Dreamy_Jazz Thank you so much for the multiple reviews.

In T345677#11531153, @matej_suchanek wrote:

... not really. The UnblockUser does a lot more, including running hooks. We need to make a change in the core first, otherwise this is a dead end. (The priority isn't very high as Wikimedia now enforces temporary accounts.)

Alright, here's what's happening.

In T414858#11531110, @Bugreporter wrote:

Another example is https://en.wikipedia.org/w/index.php?title=Special%3AAbuseLog&wpSearchUser=Popcountrysucks+Backup+4.0C - this page says 50 entries but only show 44.

In T414858#11531090, @Dragoniez wrote:

There being an empty <ul> element suggests that the early return logic in AbuseLogPager::doFormatRow isn't working properly.

<form method="GET" action="/wiki/Special:AbuseLog/hide">
   <ul class="plainlinks"></ul>
</form>

This doesn't look right to me. There being an empty <ul> element suggests that the early return logic in AbuseLogPager::doFormatRow isn't working properly.
I've confirmed that this happens when the viewing user doesn't have access to revdel'd revisions and the abuse log entry is associated with a revdel’d revision.

This task may be quite important for T413695: AbuseFilter should have a revert API. It's a bit tricky to resolve the merge conflict in Block::revert though, as the method now uses UnblockUserFactory::newRemoveBlock and ManualLogEntry is no longer used there.

This was likely fixed by rMW1e6e758.

In T398673#11506964, @A_smart_kitten wrote:

One edge-case of the new IP block appeal tagging might be to do with partial-blocks. It seems like the current logic in SpecialMytalk.php might react to any blocks on an underlying IP address, not just sitewide blocks. So then, now that we also have the new tag, it seems like we're getting cases where:

• a temp account is created and its account-creation log entry is tagged with IP block appeal;
• ...but that same temp account is then still able to make edits elsewhere on the wiki (that aren't to appeal their IP block).

cc @Dragoniez @Tchanders

In T412532#11487739, @Pikne wrote:

In T412532#11485497, @Dragoniez wrote:

	"checkuser-tempaccount-specialblock-ip-target": "See temporary account contributions at [[Special:IPContributions/$1]].",

Should we localize the special page name in this message on the UI?

[[{{#special:IPContributions/$1}}]] should do I guess?

Let's address this in T414049: Introduce an account_type variable.

	"checkuser-tempaccount-specialblock-ip-target": "See temporary account contributions at [[Special:IPContributions/$1]].",

Should we localize the special page name in this message on the UI?

@DAlangi_WMF @Tgr Thank you both for your input. AFAICT, option 4 appears to be the most suitable overall, and I have no objections to pursuing that direction.

In T396305#11444370, @Umherirrender wrote:

Maybe you can use wgTextModelsToParse for this to include wikitext pages or pages handled like that.
Not sure about the performance impact on the database query, because there is no index on page_content_model.
There is also T230607: stop using page_content_model

@DAlangi_WMF @matmarex I would appreciate your opinions on this matter, as you both often maintain AuthManager and CentralAuth. Thanks.

@Stang I would appreciate your input on the 3rd approach.

@HideonRosie Was your source IP blocked from account creation when you attempted this? If so, the block was correctly bypassed, and we can resolve this task :)

In T411952#11440713, @HideonRosie wrote:

@DAlangi_WMF @Tgr @Dragoniez The issue now is a bit diffrent.

Now it's blocked by local filter (filter is not a problem). The filter 32 logs show that the target account is the one who performed the action. Added a bypass for sysops, but it doesn’t seem to have any effect.

There are two possible approaches to this issue:

Ah, I think I've found the culprit. In CentralAuthForcedLocalCreationService::attemptAutoCreateLocalUserFromName#87, we probably need to pass an explicit performer.

Sounds like T408724 messed up something.