Yes. I wanted to get the schema reviewed first in case there were any big changes from that which would affect the other patches

We can likely parse the wikitext on the server and send it back to the client in the API response for display

Thanks, I'll close this as a duplicate of T405612: Suggested investigations: Provide a link to the contributions page of users in a case then

In T405612: Suggested investigations: Provide a link to the contributions page of users in a case, we are proposing a 'contribs' link which is coloured red when the user has no edits. @Izno would that functionality address this ticket in your eyes?

Looks fine to me

It seems there is nothing to review here. Tentatively moving to Done for not knowing where else this should go

(patch is currently in work in progress, so moving back to in progress)

Having looked into this further with @kostajh it seems that the return value of performance.measure was not in place until Firefox 103. Using performance.getEntriesByName has better backwards compatibility.

For clarity we do not use the https://developer.mozilla.org/en-US/docs/Web/API/Performance/measure feature so AFAICS it should be supported in Firefox 102. The error that was reported was that the entire performance.measure method is removed

Proposed format that has been implemented in the patch:

https://caniuse.com/?search=performance.measure says support exists for it in Firefox 102

This has nothing to do with CheckUser-SuggestedInvestigations from what I can see. Removing that tag.

For context, in T410640: Suggested investigations: Order accounts in accounts list by their user ID we are proposing to add an order for these accounts such that the newest accounts are shown first. Before this there was no explicit order defined and so in theory it could be random (though likely the SQL optimiser chose some order based on how the queries were executed)

We need to work out how to format the notes column when the user has edited the notes column using the status dialog. This likely means implementing the wikitext parsing on the client side, which AFAIK has some drawbacks and limitations.

In T341553#11423316, @Tgr wrote:

In T341553#11422966, @Dreamy_Jazz wrote:

Not sure if it has already been mentioned, but mwscript-k8s doesn't seem to support running maintenance scripts that are not defined in public code.

Last time I tried, you could do it with --file.

--file has the following documentation which to me implied I could not use it to define the script but only input files:

--file FILE           Copy a text file into the MediaWiki container (in the script's working directory) to be used as script input. Format:
                       path/to/local-file.txt[:remote-file.txt] -- omit colon section to use the same filename (with any leading path stripped).
                       Pass --file again to copy multiple files.

QA will be verifying that the warnings no longer appear on production when this gets deployed everywhere

Not sure if it has already been mentioned, but mwscript-k8s doesn't seem to support running maintenance scripts that are not defined in public code. Specifically I have the need to run a private maintenance script (see T410303). mwscript works when using an absolute path to the file but mwscript-k8s doesn't work

Might this be the cause of the mwext-phpunit-coverage-patch jobs now failing consistently in CheckUser? https://integration.wikimedia.org/ci/job/mwext-phpunit-coverage-patch/54162/console#console-section-6

composer update for mediawiki/core
14:08:11 INFO:quibble.commands:>>> Start: composer update for mediawiki/core
14:08:11 INFO:quibble.commands:Running "composer update" for mediawiki/core
14:08:11 [13.0MiB/0.16s] > pre-update-cmd: MediaWiki\Composer\VersionChecker::onEvent
14:08:11 [13.0MiB/0.16s] Loading composer repositories with package information
14:08:12 [20.4MiB/1.18s] Updating dependencies
14:08:12 [22.6MiB/1.20s] Dependency resolution completed in 0.002 seconds
14:08:12 [22.6MiB/1.20s] Your requirements could not be resolved to an installable set of packages.
14:08:12 [22.6MiB/1.20s] 
14:08:12   Problem 1
14:08:12     - Root composer.json requires php >=8.2.0 but your php version (8.1.33) does not satisfy that requirement.
14:08:12 
14:08:12 [17.8MiB/1.20s] Memory usage: 17.83MiB (peak: 28.79MiB), time: 1.2s
14:08:12 INFO:quibble.commands:<<< Finish: composer update for mediawiki/core, in 1.319 s

After looking over this ticket, it seems to be a much larger ticket than previously expected.

@dom_walden have you tried testing on a wiki where the content language is not English? The options in that dropdown are configured to only be shown in the content language (though that may need to be changed)

In T411223#11415277, @Novem_Linguae wrote:

Not sure how either of these things could be fixed without making changes to Codex components which would have knock-on effects elsewhere.

Please see my patch above. Can you give an example of a "knock on effect" it would have?

I think this comment was made from a design point of view, with the idea that the fix would have been made to the Codex component. While adding CSS overrides would add CSS that could break if Codex was to change how the icons work, I think it wouldn't have the issues about applying the styling more widely

Tentatively ready for review

I've not created a custom schema before, so definitely work in progress but created https://gitlab.wikimedia.org/repos/data-engineering/schemas-event-secondary/-/commits/T409260?ref_type=heads as branch for the WIP changes. Will create a PR when it's closer to being ready

In T409318#11413544, @hashar wrote:

Thank you very much for your assistance @Dreamy_Jazz 🎉

No problem. Thanks for fixing the issue