This is for updating the old one. I think that I (or @Yupik) mentioned about that it was added in 2025 (we are both working with Finto people things related to Wikidata).

In T420702#11732605, @Anton.Kokh wrote:

Could you please reformat your request using this template?

In T420705#11732602, @Anton.Kokh wrote:

Could you please reformat your request using this template?

Just FYI, we have outreachy project going on related to FlaggedRevs automatic reviews and we have statsgraph for it. It just needs to be polished and deployed to toolforge if the third party tools is enough.

Apertus is under OSI-compatible licence (Apache 2.0), multilingual and training process should be reproducible. It should be also reasonable good.

@Tacsipacsi One solution could be also that level and unapprove are mutually exclusive as parameters and user could not define them at same time.

Thank you very much !

I triaged this high as this is still going on and impacts to multiple tools.

It seems that toolsdb is generally down. Here is ticket for montage db connection [https://github.com/hatnote/montage/issues/353#issuecomment-3488646411 timeouting].

In T408995#11333670, @Tacsipacsi wrote:

When using binary flagging, the level is already automatically set to zero when unapproving. So why not extend this and avoid conflicting parameter values by simply dropping one of the parameters? Another solution would be no longer accepting level=0, but that’d leave the question what the difference between level=1&unapprove= and level=2&unapprove= is. (Nothing.)

In T408995#11333487, @Tacsipacsi wrote:

that stabilize doesn’t take exactly these levels, as it also accepts none, which is not in the array; if you want to get the exact values accepted by an API module, you can use data.api.ParamInfo in Pywikibot (and the underlying API endpoint elsewhere):

>>> import pywikibot
>>> pi = pywikibot.data.api.ParamInfo(pywikibot.Site('wikipedia:fi'))
>>> params = {p['name']: p for p in pi['stabilize']['parameters']}
>>> params['autoreview']
{'index': 2, 'name': 'autoreview', 'type': ['none', 'sysop'], 'default': 'none'}

However, if you still think the raw value of the configuration variable is useful, it can be included.

Following wikis are running FlaggedRevs extension without Wikiwho. I think that WikiWho data could be used in pending reviewing so it could be nice to have these enabled at some point.

Thank you! Also, follow-up question: how much disk space does one language version take? (for example enwiki, dewiki, huwiki) Note: I don't really need this information but would like to get some understanding of the sizes.

@MusikAnimal is there documentation on how wikiwho imports are done and would it help if someone would preprocess data locally for adding them? (I suppose that processing dumps take some time)

In T408726#11325245, @Tacsipacsi wrote:

6. _apisite.flagconfig()
   • Shows information about review flag configuration.
   • API: https://www.mediawiki.org/wiki/Extension:FlaggedRevs#action=flagconfig

I think this API endpoint should be deprecated:

In T57081#11325259, @Tacsipacsi wrote:

In T57081#11324752, @Zache wrote:

The ticket T57081 is place where you can comment about Pywikibot part.

T57081: Implement support for Flagged Revisions in Pywikibot is the present task. You mean T408726: Add FlaggedRevs support to Pywikibot (Outreachy 31), don’t you?

Just FYI, I am planning that we are adding the FlaggedRevs support to Pywikibot and using it as API instead of coding these directly to PendingChangesBot. Please comment about the functions and places where they would be added. The ticket T57081 is place where you can comment about Pywikibot part.

Question: Is there in mainline FlaggedRevs currently a possibility in protection-like configurations to make some edits pending afterwards, or will the stabilization affect only future edits in protection mode?

@Tacsipacsi : I think that DeferredChanges branch never got mainlined and all the related code are for version before T277883 so they branches are deprecated as well. So it is unlikely that it would be implemented any more and it would be ok to close the ticket.

@taavi Adding Superset support to Pywikibot was pretty one of the first use cases for Superset when it published the replica access, and the point of it is that it doesn't require a Toolforge account as because managing the new Toolforge accounts doesn't scale. For example, there are security reasons not to create Toolforge accounts for random workshop participants or, in our current case, for Outreachy contribution period volunteers, if nothing else. Using OAuth login and HTTP API will scale to that usecase.

@Xqt Is the pywikibot/site/_apisite.py correct place for adding flaggedrevs review() and stabilize() functons?

Pull request successfully merged and closed in github

Pull request successfully merged and closed in github

In T408286#11311161, @Xqt wrote:

@Zache: I have checked the cookie files. I think BotPassword accounts may not work for web or OAuth logins because they do not receive a central OAuth session (centralauth_Session). Can you (or someone) confirm?

successfully merged and closed in github

• https://github.com/Wikimedia-Suomi/PendingChangesBot-ng/pull/27

• https://github.com/Wikimedia-Suomi/PendingChangesBot-ng/pull/29

Succesfully merged and closed in github

Succesfully merged and closed in github

Succesfully merged and closed in github

We moved most Outreachy tasks to using PendingChangesBot-ng/issues to reduce duplicate work on tickets. So, most, if not all, microtasks are in GitHub, and I think that I could start to close these. However, there are still tickets which I will keep on Phabricator as they are related to other projects which are using Phab. Most notably, Pywikibot + Gerrit, which will require Phab tickets.

@Xqt If you have time i would you like to write step-by-step guide how you got the Oauth working? ( I am trying to figure out what i am doing differently )

Yes, it is afaik same. Do you have any idea if it would be possible to get the Oauth/Botpassword working for third part oauth logins?