Last modified: 2009-01-20 23:05:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 16867 - API: Autoconfirmation
API: Autoconfirmation
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-03 16:09 UTC by Gurch
Modified: 2009-01-20 23:05 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Gurch 2009-01-03 16:09:46 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.
Comment 1 Bryan Tong Minh 2009-01-03 17:53:24 UTC
You can determine the rights associated with groups as returned by list=users with meta=siteinfo&siprop=usergroups.
Comment 2 Gurch 2009-01-03 20:13:44 UTC
(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.
Comment 3 Splarka 2009-01-03 21:42:46 UTC
(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.
Comment 4 Bryan Tong Minh 2009-01-03 21:56:07 UTC
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.
Comment 5 Gurch 2009-01-03 22:01:22 UTC
> 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.
Comment 6 Gurch 2009-01-16 21:37:31 UTC
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.
Comment 7 Gurch 2009-01-20 23:05:55 UTC
aaaaand reverted. (r45940)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links