Drush user list command

A preliminary review:

+++ b/commands/user/user.drush.inc
@@ -159,6 +159,23 @@ function user_drush_command() {
+    'callback' => 'drush_user_list',

There's no need to define this. Drush will infer that same function name from the command name.

+++ b/commands/user/user.drush.inc
@@ -159,6 +159,23 @@ function user_drush_command() {
+    'aliases' => array('ulis'),

the alias for user-login is 'uli'. Perhaps it results confusing.

+++ b/commands/user/user.drush.inc
@@ -159,6 +159,23 @@ function user_drush_command() {
+      'names' => 'A comma separated list of names to filter by',
+      'emails' => 'A comma separated list of emails to filter by',
+      'roles' => 'A comma sepparated list of roles to filter by',
+      'status' => 'Filter by status of the account. Can be active or blocked',

roles and status seems useful but I don't see the utility for names and emails given that they fit the exact match. You can use user-information command to get all the info for a user based on uid, name or mail. Also it is useful to filter users that had never login (spam accounts).

+++ b/commands/user/user.drush.inc
@@ -481,6 +498,104 @@ function drush_user_login($name = NULL) {
+  $names = (!empty($names)) ? explode(',', $names) : $names;

you can use this function to explode csv:
http://api.drush.ws/api/function/_convert_csv_to_array/master

+++ b/commands/user/user.drush.inc
@@ -481,6 +498,104 @@ function drush_user_login($name = NULL) {
+    $uid_query = db_query("SELECT uid FROM {users} AS users $query_mod");

This raises a warning if $query_mod was not defined. Also you may use
http://api.drush.ws/api/function/drush_db_select/master

+++ b/commands/user/user.drush.inc
@@ -481,6 +498,104 @@ function drush_user_login($name = NULL) {
+  $header = array('UID', 'Name', 'Email', 'Roles', 'Status');

dt('Name') etc

+++ b/commands/user/user.drush.inc
@@ -481,6 +498,104 @@ function drush_user_login($name = NULL) {
+    $user = user_load(array('uid' => $uid));

IMO this is killer. In general you can build a complex query from the given options. See watchdog command for reference.

Also may be of interest to implement --pipe support.

Haven't tried it yet, but I like this idea. I might suggest uls (like "ls" for users) as the command alias.

Nice work, I've tested and seems to works fine, although not tested with a Drupal with a huge ammount of users.

Initially I thought that could be useful to query users based on email but not with exact match but with partial match. However main use for this feature would be to detect test users (finding test*@* users or *@devserver*) but I guess this can be accomplished better with a simple query using sql-query so it's no worth to pollute drush comand list and options ;)

For pipe you have to use drush_print_pip function. It seems that you have to always put pipe info using that function and drush will only show if --pipe param is added. Well, manuee and me we have figured out talking on IRC but I leave here for reference purposes.

Just wanted to toss out that it failed for my PgSQL8.3/Drupal 7.4 site after applying drush-user-list-1199080-6.patch to Drush 4.4.

WD php: PDOException: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at [error]
or near "%" at character 75: SELECT users_roles.rid AS rid
FROM
{users_roles} users_roles
WHERE (uid = %d) ; Array
(
[0] => 6
)
in drush_db_select() (line 1858 of /data/drush44/includes/drush.inc).

I'll try posting an update if I get something working too.

db_placeholder() is only available for D6. See #508756: RIP db_placeholders(). Please fix and test for D7.

I'm kind of thinking that this should be a query mechanism for the other user commands. What I imagine is that the results table gets fed into drush_choice and you can operate on any row from there. This is probably hard to implement, but sounds cool :)

Not totally sure this belongs in core. Thinking about it.

If the other user commands use (or in the future might use) the user-list command, then user-list needs to be in core if the other user commands are in core.

I am a little unhappy about the scattering of the site-admin commands, with some in core, some in extras, and some, like drush role off by themselves in small extensions.

I think that we should accept all site configuration commands that deal with configuration options for Drupal core in drush core, and put them all in a 'site-admin' folder. Failing that, I think we should move them all to extras, or make a new project, drush_site_admin to hold them. Configuration options for contrib modules belong with the contrib modules themselves, but we should not allow all of the Drupal core config commands to continue to be scattered.

I can sympathize with this frustration. I experience it too. But I can think of no other way. Consider some niche commands that deal with forum module (i.e. drupal core) that let you move comments from one thread to another. Thats vital when you need it, but very few drupal sites need it. You want that in Drush core? I can think of commands that are too obscure for drush_site_admin admin as well (poll vote management).

The point is, not everyone needs the same stuff and mainstream maintainers don't want to manage niche code. Creating another bucket but that does not completely solve the problem.

It is quite possible that the frustration stems from a disgreement about whether role and user-list commands are broadly useful or not. Again, these sorts of disagreements are inevitable when a maintainer highly values code that he does not have to maintain :)

Having said all that, I do have a dream to split all drupal code out of drush. All the drupal code would live in a drupal extension. Others might make a wordpress extension, and so on. Patches welcome. It would be the most awesome patch since #335360: Drush does NOT have to be a module!.

-moshe

I actually use drush sql-sync to copy my bugzilla database, so I can see the utility of #16. If I ever used wordpress or joomla, I might consider it. :)

I do see your point about commands that are core but obscure; my metric of 'if it's core, it must be common' is not accurate. If we could convince the Drupal core maintainers that they should maintain drush commands for everything... c.f. above comment about highly valued code that one does not have to maintain ;). And so the controversy lives on. Maybe all I really need is a section on drush.ws/resources that lists all of the drush extensions that do site management for Drupal core.

Depends on #1364808: Proposal for an output formats engine.

I'd also like to see a drush_drupal extension (and drush_wp) being drush the core of all of this.

In the meantime I think user-list worth core.

remove tag

This command definitely needs work, but I think it should go in.

There's a big difference between supporting everything that ships with core and supporting the required core modules. This command especially could be a very useful utility command.

Here's what I'd like to see changed:

- Break out the fetching of the users from the command callback. It's pretty long and hard to follow as it is.
- Support D7. Maybe use EntityFieldQuery for that part.
- Support the typical "format" options found in cache-get.

I'd like to see this added as well; it would be very useful.

I applied this as a custom command and it works great although I got these errors:

array_flip(): Can only flip STRING and INTEGER values! entity.inc:355  [warning]
array_flip(): Can only flip STRING and INTEGER values! entity.inc:355  [warning]
array_flip(): Can only flip STRING and INTEGER values! entity.inc:355  [warning]
array_flip(): Can only flip STRING and INTEGER values! entity.inc:355  [warning]
array_flip(): Can only flip STRING and INTEGER values! entity.inc:355  [warning]

To clear these warnings I had to change u

$user = user_load(array('uid' => $uid)); //Brings back error

to

$users = user_load_multiple(array(), array('uid' => $uid));
$user = reset($users);

I'd like to add the ability to use drush user-list to see who's online.

I'll most likely have some time next week to work on it.

Help here is greatly appreciated. Future patches should utilize the new output formatters in Drush 6. See the drush topic documentation, and #1862950: drush site-alias should indicate the current alias set by drush use.

I'll add that we have views-execute in Drush core now. Thats a way to get listings of users and loads of other stuff. It handles paging, querying, etc. I think this is Won't Fix but willing to discuss more.

Maybe user-list could just be a thin wrapper around views-execute, then?

Side comment: views-execute is currently only implemented for D8.

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.

Follow-up: https://github.com/drush-ops/drush/issues/149