Sorry if I'm jumping ahead a bit. I just think it'd be beneficial to have a clearer picture of the intended functionality and UI before settling on the schema design.

In T424269#11975006, @Rajveer42 wrote:

Quick follow-up on the schema before,

• I draft the patch the task asks for "wikitext section headings" and structured multi-paragraph documentation (purpose, false-positive guidance, maintenance notes), which won't fit af_public_comments's blob(255).

• I'm planning to use blob(65530) for af_summary and afh_summary, matching af_pattern / af_comments. Does that match what you had in mind, or do you want a different length?

cc @Dragoniez

Sorry I missed the mention.

In mark-locked.js#L-92, there's an issue with how the locked property is evaluated. With gusprop=locked, the property is a boolean value and may be false. The current implementation probably mismarks unlocked users.

Ah, never mind about the second point. I didn't realize the input users is already batched into groups of 50 or 500.

In mark-locked.js#L-92, there's an issue with how the locked property is evaluated. With gusprop=locked, the property is a boolean value and may be false. The current implementation probably mismarks unlocked users.

The issue will probably resolve itself once we deep-purge Template:ابهام‌زدایی.

I purged the page’s cache and it’s gone now. This may be just a rendering remnant of what T425056 has already fixed.

In T424425#11940230, @thiemowmde wrote:

As I wrote on the patch I'm struggling a bit with this. Do we seriously expect people to call this special page manually and then manually enter two page names, without visiting the original page first?

In T424425#11939818, @VadymTS1 wrote:

@Dragoniez @Bugreporter2 If you don't mind I can create a patch only with 'move' alias

It sounds like you mean the TA massblock SHOULD overwrite existing blocks? If so, we will probably need to require user interaction when the target TAs already have multiple blocks, since there would otherwise be no way for the system to decide which block to overwrite. This could interrupt the administrative workflow to some extent, so this likely requires a deeper discussion.

@matmarex Thanks for the patch and the update to the help doc.

Got it :)

In T426033#11917179, @matmarex wrote:

I added a backport for wmf.1, since that version is still live (see https://versions.toolforge.org/).

@BBlack Your input would be appreciated on:

Removing the tags, as this doesn’t seem to be a CSP issue after all.

I have finished updating MarkBLocked.

For those who are planning to update scripts/gadgets using list=globalusers with gusprop=locked, followed by cross-origin list=logevents requests to fetch lock details, T425972: POST by mw.ForeignApi is CORS-blocked when a Promise-Non-Write-API-Action header is provided may be of interest.

@matmarex Thanks for the backport!

Thank you for spotting this. This occurs with gusprop=rights when the queried users don't belong to any global groups.

Sorry, it looks like the tag is used only for wishes that are from 2024 and later.

I just noticed that this is listed on the Community Wishlist.

Declining this for now, as there hasn't been any effort to address the concerns raised. As I commented in the patch, one option may be to limit the scope of the change to the relevant project rather than applying it globally.

I have a draft patch for this that's about 60% complete and has been sitting in my local repo for months. Now that this task has become more important because of the recent update to rate limits, I'll prioritize working on it (hopefully this weekend).

In T424846#11871633, @matmarex wrote:

These scripts often end up with "centralauthtoken is invalid" warnings in our logs. I'm not sure why this happens.

This looks to me like a local gadget issue. Try replacing 'oojs' with 'oojs-ui-windows'.

In T424425#11858740, @Bugreporter2 wrote:

Yes, I considered this. However:

1. Renaming a page is much more common than renaming a user.
2. Renaming pages is generally done by autoconfirmed users, whereas renaming users can only be done by those in the bureaucrat group. The former are much lower in their responsibility level, and hence the level of required technical expertise is also much lower.

I think [[Special:Rename]] would be ambiguous with [[Special:RenameUser]] and should be avoided. I have no objection to introducing [[Special:Move]] though

This reminds me of T406952#11547903, where I suggested separating the description into private and public labels. Either way, we’d need a new database column.

In T424217#11852012, @Bhsd wrote:

Okay, I get it now. I can work on this tomorrow.

In T424217#11851696, @Bhsd wrote:

May I know what is the use case for inserting a tab character?

@Bhsd Thank you for the patch!

@Bhsd Thank you for the patch!

In T423808#11836682, @Dragoniez wrote:

This can be reproduced when the filter code is sufficiently long. The likely cause is that the editor focuses on the end of the content when the page is loaded.

In T423808#11836681, @Bhsd wrote:

Sorry, I cannot understand this task. Could you add a reproducible link (e.g., a public abusefilter) and maybe also a screenshot with annotations?

Fixing the status that was likely mistakenly chosen

Not sure if I can push this forward.

In T401823#11763094, @Dreamy_Jazz wrote:

In T401823#11763040, @Dragoniez wrote:

Should we limit the use of ipbreason-indef-dropdown to when the radio option is explicitly selected, and consistently use ipbreason-dropdown when a value is chosen from the "Preset duration" dropdown?

IMO no, because then you would see the non indefinite block reasons for an indefinite expiry option and so wikis which have updated their reason selection would now see the temporary block reasons for an indefinite block which would likely be confusing in the other direction

I think the confusion partly originates in the UI behaviour that ipbreason-indef-dropdown is used even when "indefinite" is selected in the "Preset duration" dropdown, rather than only when the "Indefinite" radio option is selected.

In T420404#11721541, @aaron wrote:

Was there a specific use case in mind or is the idea that this would just be generally useful?

I presume this would be better re-submitted with the Temporary accounts and MediaWiki-Special-pages tags, since the intent seems to be improving the general user interface of Special:Block(?), as far as I understand. Unfortunately, the task description is largely incomprehensible from an AbuseFilter perspective.

If possible, I'd like to request that localhost:* also be allowed. Without this, web servers would need to run on port 443 only (for https), which usually requires admin privileges and is a bit too inconvenient.

I don't really get the issue reported here.

In T411507#11639042, @Samwilson wrote:

These actions (delete, edit, move, etc.) are all operating on only a single page. I'm guessing this is for when you've somehow got a list of pages and you don't know their watched status and will send separate API calls to watch each of them, and it'd be more convenient to be able to send e.g. watchlist=watch&watchlistexpiry=1+month to all and not have it clobber the permanent expiries

In T411507#11638597, @Samwilson wrote:

Would it make sense to change the default behaviour to not modify an existing watchlist item? The annoyance of losing the item's data is only going to become more annoying now we've also got watchlist labels.

Now I've taken a closer look, this does look like an Upstream issue but we may simply want to ensure that ApiResult::META_TYPE => 'assoc' is used for result datasets that may be returned as empty JSON objects.

It may be good to do the same thing as what BlockLogFormatter does.

I’ll merge this into the existing task for now. Feel free to reopen if it turns out to be a separate issue.

Thanks for filing this! This appears to be a known bug (T395168: Duplicate log-events sometimes created for page moves), although the root cause hasn't been fully understood yet.
Based on the description here, this may be related to a race condition when multiple move requests are processed at around the same time.

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.