Extend sql-sanitize to cover more user fields

[grasmash]

I've put together a small module that extends drush sql-sanitize by providing sanitization on user fields beyond the default "name" and "mail" fields: https://www.drupal.org/sandbox/madmatter23/2829772

I'm wondering whether this should be merged into drush directly. The intended scope is to cover only core field types. E.g., string, string_long, email, telephone, text, text_long, and text_long_with_summary.

This does seem to be within the purview of drush's sql-sanitize command. If it's decided that this is not desirable, I can promote my module to a full project.

Opinions?

[greg-1-anderson]

I am in general in favor of expanding the capabilities of the core sanitize command in useful ways. Your extension looks very useful; my one reservation is that it seems to be a bit overzealous. Perhaps not every field attached to a user contains sensitive information. It could be useful to maintain the original values in some instances.

If this command was configurable in some way -- perhaps defaulting to sanitizing every user field, but allowing fields to be whitelisted (e.g. via an $option value in a drushrc.php) -- then this could be considered for Drush core, presuming that @weitzman concurs.

If you don't want to do that, then you could just publish your project as-is.

[grasmash]

That seems reasonable. Does this format look good to you?

drush sql-sanitize --whitelist-fields=field_example,field_another_example

[grasmash]

Created pull request: #2457

Now, I'm not sure how you like me just adding a class to Drush like this, but I found that the architecture is better suited for the operation. If it would make things more palatable, I could move some of the password and email sanitizing logic into the class.

[weitzman]

Lets discuss in the PR.

[brooke-heaton]

Anyone have any idea why I'm getting this error on
drush sql-sanitize --uri=my_site --no-interaction --ansi

[error] No entity bundle was specified