We should have user generators, with an ApiUserSet class and all the fancy stuff. With it, we can probably obsolete list=users.
Description
Description
Details
Details
- Reference
- bz14027
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T16746 Request editcount for rvprop in prop=revisions | ||
| Open | Feature | None | T21314 allow list=usercontribs to be a generator in certain circumstances | ||
| Open | None | T16027 Implement user generators into the API |
Event Timeline
Comment Actions
Bumping this. OP requested that nobody else touch this bug; it's been over a year now....
Comment Actions
(In reply to comment #1)
Bumping this. OP requested that nobody else touch this bug; it's been over a
year now....
Yeah, this is probably a nice feature to have and it seems I don't have time to do it. Anyone taking up this bug should probably run their implementation ideas by me first, though.
Comment Actions
This is a thought that may or may not make sense. Feedback is welcome.
We may not want this to work exactly like the existing title generators. The use case for the title generators is that it's fairly common to use one module just to get a list of titles, without caring about any other data that module might generate, just so the list of titles can be fed to other prop modules. I suspect the use case for user generators is more likely to be wanting the user data (e.g. gender) in addition to (rather than instead of) the data from the generating module.
So, perhaps, instead of a "usergenerator=foo" parameter we'd have each module capable of generating users have a boolean "xxgenerateusers" parameter to instruct it to do so, and ApiQuery (or maybe even ApiMain) would output the data based on the ApiUserSet if anything fetched the set to populate it.