Page MenuHomePhabricator

Implement user generators into the API
Open, MediumPublic

Description

We should have user generators, with an ApiUserSet class and all the fancy stuff. With it, we can probably obsolete list=users.

Details

Reference
bz14027

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:10 PM
bzimport set Reference to bz14027.
bzimport added a subscriber: Unknown Object (MLST).

Bumping this. OP requested that nobody else touch this bug; it's been over a year now....

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

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.