In T408726#11325986, @Zache wrote:

Other data which would be useful

• protection levels ( ie. wgFlaggedRevsRestrictionLevels values ) which is need for API:stabilize to set which user groups can automatically review revision

Note 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.

• is wiki stable by default or latest by default: (ie. wgFlaggedRevsOverride value)

I agree, except that I wouldn’t return $wgFlaggedRevsOverride itself, but rather FlaggedRevs::isStableShownByDefault(), which resolves to $wgFlaggedRevsOverride && !$wgFlaggedRevsProtection, because it’s what actually matters (the raw value of $wgFlaggedRevsOverride is never used by FlaggedRevs code, only through FlaggedRevs::isStableShownByDefault()).

The name of the (only) tag; currently returned in name of the first tag if not in protection mode, but it would be needed in protection mode as well (it’s used as a parameter name when reviewing).

It would be nice if tag name requirement would be removed from reviewing API too so it would be just flag=3 instead of flag_accuracy=3. In pywikibot side i think that code can handle this.

I agree that the review API should finally get rid of this dynamic variable name. I’d still return the tag name, though, in case it’s needed elsewhere (e.g. to get the MediaWiki message name for the human-readable tag name – unlikely to be useful in Pywikibot, but gadgets or user-facing Toolforge tools may need it).

I’d also bikeshed a bit, and call the review API parameter level instead of flag, as it better describes the meaning of the parameter. I’d also drop (deprecate) the unapprove parameter, as it’s synonymous to level=0 (except that it isn’t, because it doesn’t work: using level=0 without unapprove= gives the nonsense error message Either all or none of the flags have to be set to zero.).

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.

I think that available levels which can be used in API call is what we want, not the raw config value.

• is wiki stable by default or latest by default: (ie. wgFlaggedRevsOverride value)

I agree, except that I wouldn’t return $wgFlaggedRevsOverride itself, but rather FlaggedRevs::isStableShownByDefault(), which resolves to $wgFlaggedRevsOverride && !$wgFlaggedRevsProtection, because it’s what actually matters (the raw value of $wgFlaggedRevsOverride is never used by FlaggedRevs code, only through FlaggedRevs::isStableShownByDefault()).

Sure

I’d also bikeshed a bit, and call the review API parameter level instead of flag, as it better describes the meaning of the parameter. I’d also drop (deprecate) the unapprove parameter, as it’s synonymous to level=0 (except that it isn’t, because it doesn’t work: using level=0 without unapprove= gives the nonsense error message Either all or none of the flags have to be set to zero.).

There is also a difference that at the database level, unapprove deletes the row from the flaggedrevs table instead of setting level to "0"

In T408995#11333598, @Zache wrote:

I think that available levels which can be used in API call is what we want, not the raw config value.

In that case, you can already get the value. Acceptable inputs for a given API module are the concern of that module, not another module.

There is also a difference that at the database level, unapprove deletes the row from the flaggedrevs table instead of setting level to "0"

Sure, the backend should continue to behave like that, but that’s an implementation detail.

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#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.)

It is OK for me to use level=0 as unapproved. The only reason why I would use the separate unapproved action is that it would be the same at the API level as what it does in the code, but in this case there is not that much difference.

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

In any case, as there is update to pywikibot in gerrit for review() then lets decide if we want to use level=0 or unapprove=True for removing reviews.

• https://gerrit.wikimedia.org/r/c/pywikibot/core/+/1203490