Last modified: 2013-12-14 20:57:24 UTC
It would be nice if the API could supply user IDs anywhere that user names are currently an option, e.g. prop=revisions. This would allow clients to use the ID rather than the name as an identifier for the user, as can be done currently with page IDs, an advantage when dealing with large numbers of items. Revisions by anonymous users would I believe end up with 0 as the user ID this way, which may render it unsuitable for some purposes but would certainly be OK for mine.
Per: http://toolserver.org/~amidaniel/chanlogs/%23mediawiki/20090501.txt > <brion-meeting> user ids are an internal implementation detail which should never be needed externally, but they're not actively hidden This has been discussed before but nobody gets around to it.
Suggestions for implementation of almost full User<->ID abstraction in API (per Roan@IRC): Queries ApiQueryRevisions.php * rvprop=user -> userid="12345" or userid="0" * rvuserid=12345 * rvexcludeuserid=12345 ApiQueryImageInfo.php * iiprop=user -> userid="12345" or userid="0" ApiQueryAllimages.php * aiprop=user -> userid="12345" or userid="0" ApiQueryAllUsers.php * list=allusers -> name="" id="12345" or userid="0" * austartid=12345 <- if given a userid, possible to return sequenial users by id? ApiQueryBlocks.php <- note, non-trivial to reference a blocked user from user ID, skip ApiQueryDeletedrevs.php * drprop=user -> userid="12345" or userid="0" * druserid=12345 ApiQueryLogEvents.php * leprop=user -> userid="12345" or userid="0" * leuserid=12345 ApiQueryRecentChanges.php * rcprop=user -> userid="12345" or userid="0" ApiQueryUserContributions.php * (any) -> userid="12345" or userid="0" * ucuserid=12345 ApiQueryWatchlist.php * wlprop=user -> userid="12345" or userid="0" ApiQueryUsers.php * list=users -> userid="12345" or skip for missing="" * ususerids=12345 ApiQueryProtectedTitles.php * ptprop=user -> userid="12345" or userid="0" Actions - should also output ID on success where applicable. ApiRollback.php * userid=12345 ApiBlock.php * userid=12345 ApiUnblock.php * userid=12345 ApiEmailUser.php * targetid=12345 <- this might be weird. ApiUserrights.php * userid=12345
(In reply to comment #1) > Per: http://toolserver.org/~amidaniel/chanlogs/%23mediawiki/20090501.txt > > <brion-meeting> user ids are an internal implementation detail which should never be needed externally True, but only in the sense that page IDs and revision IDs are internal implementation details, and they're available.
(In reply to comment #3) > > <brion-meeting> user ids are an internal implementation detail which should never be needed externally, > True, but only in the sense that page IDs and revision IDs are internal > implementation details, and they're available. Not the same sense at all. Page IDs are extensively used in the UI as &curid in most recent changes links (to allow the correct page to be shown even if the page has moved since). And of course, revision IDs are used anywhere a diff or permanent link is shown. User IDs however are not used in the UI anywhere... except in some extensions, which usually involve direct requests from the user (who is generally the only one with access to this number, excluding the Special:Export trick). So, they've just never been exposed as they are never used. There are cases where they would have been handy in the API though, such as the unfortunate case of bug 17878 (usernames that could log in, and edit, but not be blocked). For this same reason, things like move and delete can be done in the API via page IDs now (where invalid titles could not be referred to otherwise). So giving them a use, like the ability to block retroactively invalid usernames, is a good excuse to expose them.
Started doing some props in r71831 ApiQueryAllUsers, ApiQueryImageInfo and ApiQueryRevisions
r71834 ApiQueryDeletedrevs, ApiQueryLogEvents r71837 ApiQueryRecentChanges.php, ApiQueryUserContributions.php, ApiQueryWatchlist.php
r71838 ApiQueryAllImages, ApiQueryProtectedTitles Leaves: Queries ApiQueryRevisions.php * rvuserid=12345 * rvexcludeuserid=12345 ApiQueryAllUsers.php * austartid=12345 <- if given a userid, possible to return sequenial users by id? ApiQueryDeletedrevs.php * druserid=12345 ApiQueryLogEvents.php * leuserid=12345 ApiQueryUserContributions.php * ucuserid=12345 ApiQueryUsers.php * list=users -> userid="12345" or skip for missing="" * ususerids=12345 Actions - should also output ID on success where applicable. ApiRollback.php * userid=12345 ApiBlock.php * userid=12345 ApiUnblock.php * userid=12345 ApiEmailUser.php * targetid=12345 <- this might be weird. ApiUserrights.php * userid=12345
ApiQueryFilearchive.php is missing.
bug 27616 (In reply to comment #8) > ApiQueryFilearchive.php is missing. bug 27617
QueryBlocks (Both blocking and blocked id) in r82570 / bug 27616
list=users&usprop=blockinfo and list=allusers&auprop=blockinfo gives the username of the blocker. What about adding the user id of the blocker?
(In reply to comment #11) > list=users&usprop=blockinfo and list=allusers&auprop=blockinfo gives the > username of the blocker. What about adding the user id of the blocker? meta=userinfo&uiprop=blockinfo also
reedy spamming my inbox
(In reply to comment #11) > list=users&usprop=blockinfo and list=allusers&auprop=blockinfo gives the > username of the blocker. What about adding the user id of the blocker? (In reply to comment #12) > (In reply to comment #11) > > list=users&usprop=blockinfo and list=allusers&auprop=blockinfo gives the > > username of the blocker. What about adding the user id of the blocker? > meta=userinfo&uiprop=blockinfo also I add some user ids to output with Gerrit change #5546
