Last modified: 2009-01-20 23:05:55 UTC
There is currently no way to reliably determine through the API whether or not a given user is autoconfirmed, for wikis that use autoconfirmation. Autoconfirmed is a user right, so it can be determined for the user you are logged in as using 'meta=userinfo', but for arbitrary users, 'list=ususers' must be used, for which only groups, and not rights, can be returned. Since the autoconfirmed user right is not associated with any group, this doesn't help. 'list=ususers' can be used to retrieve the user's edit count and creation date, which can be used to determine autoconfirmed status if the requirements are already known. However, the requirements aren't available through the API either, which means hardcoding them, and consequent breakage when they change. Even knowing the thresholds themselves doesn't help if the method used to determine autoconfirmation changes; there are several methods, and new ones are added from time to time (see r45365). The simplest way to implement this would be to extend 'list=ususers' to either make user rights available or, if that is impractical, a boolean value indicating whether or not the user is autoconfirmed.
You can determine the rights associated with groups as returned by list=users with meta=siteinfo&siprop=usergroups.
(In reply to comment #1) > You can determine the rights associated with groups as returned by list=users > with meta=siteinfo&siprop=usergroups. Indeed you can. But this does not help any. Running that query tells me the rights that an autoconfirmed user gets. That much is fine. But it provides no way of determining whether a given user is autoconfirmed or not. Here is a query asking for the groups that two randomly selected en.wikipedia users are in. One of them is autoconfirmed, the other (as of this post) is not: http://en.wikipedia.org/w/api.php?action=query&list=users&ususers=Billy222|Hshelton&usprop=groups <?xml version="1.0"?> <api> <query> <users> <user name="Billy222" /> <user name="Hshelton" /> </users> </query> </api> It (correctly) tells me that neither user is in any groups. Thus regardless of what the query you mention tells me, I am none the wiser as to which is autoconfirmed. That is the information I need.
(In reply to comment #2) > Running that query tells me the rights that an autoconfirmed user gets. That > much is fine. But it provides no way of determining whether a given user is > autoconfirmed or not. That is because this is an implicit group, that is determined by the software at each access. It is sometimes predictable but sometimes not. A user may pass $wgAutoConfirmAge between you viewing their information and them performing an action. A user may pass $wgAutoConfirmCount in either direction, via editing or having edits deleted. Even more confounding to the potential prediction, when using the TorBlock extension (as WMF does) there are two more variables: $wgTorAutoConfirmAge and $wgTorAutoConfirmCount. These allow separate settings for IPs coming from TOR nods. This means that a user could bounce in and out of autoconfirmed status depending on which IPs they're using. The software would then basically have to 'cache' the implict groups at the last action or access (like, a page view), and return that, but this would be inaccurate. Suggest re-close INVALID.
Beside that TorBlock appears to be basing its autopromote criteria on the current user, which will make the output very broken. In general it can be said that implicit groups can only be accurately determined when requested about the current user.
> The software would then basically have to 'cache' the implict groups at the > last action or access (like, a page view), and return that, but this would be > inaccurate. Suggest re-close INVALID. OK, that makes sense. At least now I have something to point people to when they ask why it can't be done.
r45810 makes the autoconfirmation thresholds available through the API, so while it's not possible for the reasons outlined above to pin down autoconfirmation status exactly, this is good enough for approximation, which is all I need. Therefore marking this fixed.
aaaaand reverted. (r45940)
