One more code review on this ticket which pulls out the useFetchActivity composable to a new common module.

How long did the backfill script take you to run? Did you run the backfill script immediately after enabling ORES on the wikis?

@Ladsgroup this is scheduled for a late backport deploy this afternoon, just a heads up.

Thank you!

Stalling pending engineering weekly discussion around potential workarounds.

I cannot seem to reproduce this, do you mind adding more detailed reproducible steps?

In T409438#11435118, @Ladsgroup wrote:

@Kgraessle do you need the ores tables? like ores_models and ores_classification?

Hi,
I realized we need to create the tables before enabling the extension per the docs here.
I noticed that the docs say:

In T409438#11428377, @gkyziridis wrote:

In T409438#11428348, @Kgraessle wrote:

Model configuration and threshold configuration have been deployed.
The next step is to backport adding thwiki to the ORES dblist: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1207923.
Let's discuss in engineering weekly when we would like to go ahead and do that along with the backfill script.

Hey @Kgraessle, thank you for splitting into two different patches the deployment of thwiki.
This is the correct way to do it, and I suggest to follow this "2-step" patches also for the rest of the wikis in batches of 4-5.
I have more info in this phabricator task: https://phabricator.wikimedia.org/T408607#11412332

In T410670#11432795, @Samwalton9-WMF wrote:

In T410670#11432781, @Kgraessle wrote:

Upon closer inspection of the code, the issue is happening because the ORES hook is not firing at all therefore our code would never fire because the hook isn't firing.
I filed a bug with the ML team here: T411786: ORES is not working on testwiki.

We could rework the AutoModerator code to not rely on the ORES hook, though I'm not sure I recommend that.
It would be quite a large refactor that I'm not sure we'd like to spend the time on right now, so @Samwalton9-WMF let me know how you'd like me to proceed with that.

Thanks for uncovering this and filing the ticket!

Can you elaborate a bit on the situation & refactor proposal? I thought we were only using ORES if it was available, and otherwise using LiftWing directly?
In general though, I think I agree, we should expect ORES to work and if it doesn't ORES needs fixing, rather than refactoring for an edge case.

Upon closer inspection of the code, the issue is happening because the ORES hook is not firing at all therefore our code would never fire because the hook isn't firing.
I filed a bug with the ML team here: T411786: ORES is not working on testwiki.

Stalled waiting on: T410670: Fix AutoModerator on testwiki

Noting that the tests are skipped, but we will need to fix the actual issue, so moving this back to ready.

One more patch with a translation that was missed if you could review whenever you get a chance.

Model configuration and threshold configuration have been deployed.
The next step is to backport adding thwiki to the ORES dblist: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1207923.
Let's discuss in engineering weekly when we would like to go ahead and do that along with the backfill script.

There are two small patches ready for review:

Hi, I can update the byte size red and green colors, I just had one comment about the colors in dark mode:

In T402297#11396292, @A_smart_kitten wrote:

Hey all! A few notes on the new mobile-diff footer design (speaking as an end-user);

1. For editors with (relatively) short usernames, although the username doesn't take up the full width of the screen, the <a> HTML element does. This means that tapping to the right of the link's text will still result in your browser taking you away from the diff page & to the editor's userpage. IMO, this behaviour seems like it'd be unexpected. (Speaking personally, I encountered this behaviour when I was attempting to tap the 'expand' icon at the right of the footer, and obviously mistapped ever-so-slightly.)
   
2. When viewing the expanded footer, after tapping on the 'info' icon next to the 'X user groups' label, the box slightly overlaps the right-hand edge of the screen.
   
   While testing, I viewed a random diff on zhwiki while logged-out, and this problem seems even worse on the edit I looked at there:
   
3. In the 'user groups' box, it seems like the technical names of the user-groups are displayed (in my case, autopatrolled), rather than the 'human' version of the group names (in my case, 'Autopatrollers'). This feels like it's a change from the previous version of the mobile diff footer, and feels like it might cause problems/confusion on e.g. non-English wikis (and on wikis which have overridden a group's human/social names to be quite different to their technical names).
4. It seems like there's a brief flash-of-unstyled-content after loading a diff-page, during which (if you expand the footer in that time) the e.g. 'undo' button appears as a link, rather than a button.

Let me know if you'd like me to split any of these out into their own tasks :)

Patch Demo here

In T405152#11387398, @Superpes15 wrote:

@Samwalton9-WMF @Kgraessle Are you planning to deploy this today too? Thanks!

Hi, this is looking great so far!
I just noticed a few messages that are a bit different from the designs so I've left comments in gerrit.

Just curious if you had any reservations about us proceeding with deploying the revert risk filters to thwiki since it's a larger wiki?
Thanks!

Here's a list of FlaggedRevs enabled wikis.
After going through it, it looks like the following wikis on our list have FlaggedRevs enabled:

@OTichonova

I have uncovered another snag while implementing the FlaggedRevs "review" filter using the RecentChanges API. I naively assumed in my spike that this was another filter like unpatrolled .
However, the logic for the filters is being added server side in the Flagged Revs extension. There's currently no API that exposes this data for us on the client side and we'd have to introduce it.

Latest patch demo for testing available here.