Done, the UI patch is up as 1324358. It adds the wikitext Summary field between the description and the conditions, saves it, and has a test that submits the form and reads the value back from the database.

Thanks, that makes sense. I will go with the configurable option since you flagged the PermissionStatus approach as possibly infeasible, and I would rather not guess at whether AbuseFilter denials surface as permission errors.

I'd like to take this one. AuthManager::autoCreateUser already logs every failure itself, debug level for expected denials like blocks and provider denials, error level for real failures, so the detail is in Logstash already.

Thanks for the reviews!

This looks already fixed. The 'Get users' block fieldset is gated on an empty result set in CheckUserGetUsersPager::shouldShowBlockFieldset(), added in e8818383 ("Hide 'Get users' block buttons if there are no results", November 2024). Can this be closed?

Duplicate of T433200, filed twice by mistake.

NguoiDungKhongDinhDanh is right. SpecialGlobalContributions extends ContributionsSpecialPage and calls parent::execute(), which fires SpecialContributionsBeforeMainOutput, and the CentralAuth handler has no page specific check. So the lock notice does show there. 1317483 adds the class in that handler, so it applies on both pages.

I'd like to take this one, unless someone is already on it.

I'd like to take this one. The search path in AbuseFilterPager::reallyDoQuery keys results by filter ID and then ksorts them, so the selected sort column gets discarded.

Thanks, that makes sense for prevention. Does the AbuseFilter variable still help as a signal the community can write rules on, like temp-account bursts from one IP that get past hCaptcha? If the team feels this is already handled I'm happy to pick up something else.

I'd be interested in implementing this. One clarification before I start: is "last hour" the right window, or should it be configurable? Happy to follow the team's preference, T374522 (edits) looks like a natural follow-up with the same plumbing.

I'd like to take this one. The GlobalBlocking notice here is built in GlobalBlockingHooks::onSpecialContributionsBeforeMainOutput, which I recently worked on for T381236, so I'll mirror the existing mw-contributions-blocked-notice wrapper pattern for the global block notice and do the same for the lock notice in CentralAuth. Any objection?

@Daimona, No worries, thanks for taking a look! I'll leave it parked unless someone with current context wants to drive the design." closes it gracefully without committing you to a risky blind refactor

Thanks for the steer earlier, @Dreamy_Jazz, I implemented this as discussed (counting gblblock entries on the central wiki the link points to) and put it up as 1303462. I see the task is now resolved + you've claimed it; did it get handled separately, or would the patch still be useful to review? Happy to get CI green and finish it, or abandon if it's already covered.

Thanks for the context, that makes complete sense. I'll hold off; better to wait for Product Safety and Integrity to learn what filters checkusers actually need than build speculatively. Appreciate the steer!

Hi, I'd like to take this on. On Special:Contributions, the global-block notice (GlobalBlockingHooks::onSpecialContributionsBeforeMainOutput) renders a custom "active block" line via getMockLogLineFromActiveGlobalBlock() and then always appends the "View full logs" link, rather than using LogEventsList::showLogExtract() the way local blocks do, so there's no entry count to gate the link on.

Thanks for the review! Good to know the tables are small enough not to be a concern, and noted on the DB-side search complexity; we're planning to match in PHP for exactly that reason.

Thanks! That makes sense, I'll stack the implementation patches on top of the schema change (1296257) so the new columns have visible consumers. Starting with the data-model patch (read/write + history tracking) now; the editor-UI patch, where the wikitext-vs-plaintext question lives, will sit higher in the stack once that part's settled.

Here's how I'd sequence T424269: [the 5-patch series above]. The data-model/storage/history piece (Patch 2) is independent of the wikitext-vs-plaintext UI question, so I can start there now while we settle the editor design. Sound good?

I'd store the summary as wikitext and render it when viewing the filter (and in history), since that's where links are useful. For editing, I wouldn't add live preview in v1, matching Description/Notes today: save, then view. That also avoids the dedicated preview pane concern; a "Show preview" button could always be added later.

First attempt (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1296523) abandoned. Reusing MediaWiki core's inline-diff toggle widget (TextSlotDiffRenderer + setInlineToggleEnabled + getTablePrefix) didn't work in the AbuseLog context: setInlineToggleEnabled pulls in VisualEditor's diff-loader JavaScript, which requires wgDiffOldId / wgDiffNewId. On Special:AbuseLog the "diff" is between two raw wikitext strings (the pre-save edit content), not between two revisions, so those config variables don't exist and the JS throws.

Thanks @Daimona, understood. I'll focus on smaller AbuseFilter patches first to get more familiar with the codebase and review tempo, then come back to this once I have a better sense of who'd be the right reviewer for a larger series. Will keep the task open and not start coding until that's settled.

Patch up: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1296523

Patch up: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1296554

Preview UI

1. Patch Summary

First patch is up: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1296257

Quick follow-up on the schema before,

Thanks @Dragoniez, that clears everything up.

Hi @Izno , I'd like to work on this.

Hi @dom_walden , I'd like to work on this.

Thanks @Dragoniez. So the summary visibility follows af_hidden, that makes sense.

Thanks @Daimona, that's very clear. So the plan is:

Hi @Dragoniez , @Tgr & @Reedy
I'd like to work on this task.

I’d like to work on this, but before I start, I want to make sure I understand the expected design correctly.