We should meet with Andrew and Lydia to discuss whether this makes sense in the context of the ecosystem

Probably just needs to be added to the bot group @ https://github.com/wbstack/mediawiki/blob/46340710040565b951875808e7e727a2d6a4d8f2/dist-persist/wbstack/src/Internal/WbStackPlatformReservedUser.php#L48

Hey @dang; I just wanted to make sure it was clear what I think @Addshore was suggesting so I popped up a change that I think represents that https://github.com/wbstack/mediawiki/pull/479 . Perhaps you could test something like this?

https://github.com/wbstack/mediawiki/pull/480

Do you think we need to go through and adjust any existing PlatformReservedUsers so that they also get the bot flag? Or do you think https://github.com/wbstack/mediawiki/pull/480 is all that's necessary?

Did you already start thinking about this?

Update existing actions from PlatformReservedUser in recentchanges as rc_bot =1 in all Cloud's MediaWiki dbs.

Now I'm thinking about it I'm wondering a bit about what's the best way to do it safely? I noticed this:

Also, users with the 'rollback' and 'markbotedits' permissions may retroactively mark their rollbacks and the edits being rolled back as bot edits by including the parameter "bot=1" in the rollback link.

from https://www.mediawiki.org/wiki/Manual:Recentchanges_table/ro and wondered if that seemed like it might be part of a relevant solution

PlatformReservedUser will be marked as bot when you created new wiki, but PlatformReservedUsers from old ones before I skaffolded the patch are not.
I'm working on a patch for it now

What sort of conclusions did you come to about what needs to be done here in terms of changes to data persisted in the database?

I can see it might be important to ensure that any future edits from the PlatformReservedUser are marked as bot edits (e.g. for entity imports).

Would it be worth checking with @Anton.Kokh if it really makes sense to go in and manually manipulate the RecentChanges table to fix old "Main Page" edits? To me it seems like this wouldn't bring us that much value; since these are mostly very historic data anyway.

I had a quick chat with @dang on Mattermost. We talked about how it was annoying to need to get an account and use the actionapi to edit user groups and grant the PlatformReservedUser the bot group.

Instead I suggested running a maintenance script to do this. For example createAndPromote

In the past we've added some of these scripts to the deploy repo like https://github.com/wmde/wbaas-deploy/pull/546 so that there is an opportunity for a second pair of eyes to look at them before we blindly run code on prod.

We've actually run this exact maintenance script before to grant rights on alpha wikis. For example kubectl exec -it deployment/mediawiki-139-app-alpha -- bash -c "WBS_DOMAIN='anton2.wikibase.dev' php w/maintenance/createAndPromote.php Anton --custom-groups interface-admin --force"

I also suggested on https://github.com/wbstack/mediawiki/pull/480#pullrequestreview-2853985495 that we might want to get on with merging this patch too so at least future Wikis are correctly giving bot to the PlatformReservedUser

You could also consider using https://www.mediawiki.org/wiki/Manual:Hooks/UserEffectiveGroups

Implementing a simple hook in https://github.com/wbstack/mediawiki/blob/main/dist-persist/wbstack/src/Settings/Hooks.php

https://github.com/wbstack/mediawiki/pull/480 was merged and deployed. From now on, new wikis will have PlatformReservedUser as bot and platfrom.

here is the draft of the k8s job to turn PRU into bot
https://github.com/wmde/wbaas-deploy/pull/2138

in this PR I tried to create a k8s job and used createAndPromote. If I run the command (WBS_DOMAIN=test1.wbaas.dev MW_INSTALL_PATH=/var/www/html/w/ php /var/www/html/w/maintenance/createAndPromote.php PlatformReservedUser --bot --force) one wiki at a time it seems to work fine. Running the job always takes forever and fails.

NAME                         STATUS    COMPLETIONS   DURATION  
add-pru-to-bot-group-28bzq   Failed    0/1           10h  
add-pru-to-bot-group-7bf86   Failed    0/1           6h53m  
add-pru-to-bot-group-chfjq   Failed    0/1           7h4m    
add-pru-to-bot-group-pqnmh   Running   0/1           9m22s

I and @dena has fixed the script, ran it on staging and production. Some wikis on production failed because they don't have PlatformReservedUser anymore or never have. So from now on PlatformReservedUser on all wikis are in bot group and their actions will be recorded as bot.
I have a chat with @Anton on Mattermost and we decided to not pursuit (2) in acceptance criteria because it's not worth the pain to poke the database for 7 days worth of data.

we probably won't need it but just for the record here are the 18 wikis where the user seems to be missing:

federation.wikibase.cloud
private.wikibase.cloud
hercules.wikibase.cloud
wikidocs.wikibase.cloud
cursoslabra.wikibase.cloud
plants.wikibase.cloud
wmnyc.wikibase.cloud
public.wikibase.cloud
womenwriters.wikibase.cloud
database.wikibase.cloud
scholia.wikibase.cloud
faclab.wikibase.cloud
ticha1920.wikibase.cloud
maurizio.wikibase.cloud
gilliane.wikibase.cloud
preprints.wikibase.cloud
wikishape.wikibase.cloud
wiki-journals.wikibase.cloud

(the oneliner I used to get this list was for i in $(kubectl get jobs -n adhoc-jobs | grep Failed); do if [[ "$i" =~ ^add-.*$ ]]; then kubectl describe -n adhoc-jobs jobs.batch/$i | grep WBS_DOMAIN | sed s/WBS_DOMAIN:// | xargs; fi; done)

It seems all the patches for this ticket have been merged. We may want to move it out of the review column

I tested the ticket, and the recent changes are not marked as bot edits, despite the user being in the bot group.

Adding the EDIT_FORCE_BOT flag worked:

https://github.com/wbstack/mediawiki/pull/482

Perfect; approved and merged.

In order to ship this look at the instructions (that I just added a short update to) at: https://github.com/wmde/wbaas-deploy/pull/2158

These docs might needs a little more love to express how simple this situation is but it should be as simple as:

• push a tag to the mediawiki repo this is done per commit now; so you could have skipped the changelog
• merge the auto made staging PR
• run make apply
• check all is well (nothing erroring; feature is now fixed)
• move me to "Deploy to Production Column"
• merge the auto made production PR
• check all is well
• move to done
• tell @Anton.Kokh when he's back