Note MSSQL support is planned to be removed in 1.34, and you are strongly adviced against using it.

CC subscribers of T14251: Read restriction support

Not a task.

An alternative solution is make blobs of each abusefilter page encrypted with a specific per-filter key (stored in abuse filter table), so that any mechanisms (including extensions) that reads content objects directly can not expose private filters, and decryption of AbuseFilter content are handled in AbuseFilter extension with a permission check. As abuse filter rules are also stored in the table, Decryption will not be done in each edits.

Yes this is used to map sysop=>editprotected and autoconfirmed=>editsemiprotected. But in my opinion this should not be kept indefinitely.

This may be a combination of T224845: Write Wikibase page props for MediaInfo entities and T200860: Possible to search page property via search box.

Yes we can just modify the page_restrictions table. But the log may be broken once the old message key are removed.

By the way, are there any maintenance script to rename a protection level? We may need a task if no such script exists

See also T217005: Fix wgRestrictionLevels for all Serbian projects to fully work for another disparity (in its extreme)

I think we should consider T169626: Deprecate 'autoconfirmed' and 'sysop' value from $wgRestrictionLevels and related settings, though this will be a huge breaking change.

Archive: https://archive.is/iHkXH

Did you find the issue while logged out?

It refers to https://www.wikidata.org/wiki/Special:EntityData/E10, and Special:EntityData is served by Wikibase, but EntitySchema is not based on Wikibase.

In T214884#5394245, @Jheald wrote:

wd:Q5  wdt:Pxxxxx  wd:E10

EntitySchema is not relies on Wikibase so it should not use Special:EntityData in Wikibase. Probably we should use www.wikidata.org/entityschema/Exxx

See https://wikitech.wikimedia.org/wiki/Help:Toolforge/Pywikibot

Probably we can override it in WIkimediaMessages?

Make sure the error message of Special:UrlShortener in other wikis does not break.

Probably related to T228886: Wikidata main page can't be accessed using non-English language

I don't think LDF request is a proper way to get the full result. Currently one page requires 27 seconds to load, so we need 53 days (if the request not run in parallel) to get all results, and the result set will change significantly in the interval.

This may be moved to a seperate endpoint, probably in Toolforge.

Toolforge is an alternative for long tasks.

@wmr You should use Toolforge instead. Suggest to decline.

It's already in Wikistats, though not displayed normally.

In T229064#5367266, @Legoktm wrote:

This was considered during https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener and intentionally not implemented.

I'm proposing the project in requesters' perspective only. They should find the correct project easily. A form may be preferred so that it takes no efforts to categorize these things once there's adequate instruction.

This can be created as a milestone of Trust-and-Safety project so it is both displayed as an column of parent project and a board of itself with columns.