New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sql:sanitize option to ignore admins in users_field_data #4725
Conversation
I'm a little torn on this. I do see its utility. The PR as it stands might be incomplete as it still sanitizes the User fields and Sessions for admins. Sometimes that’s desired and sometimes it it isn't. And even if we made that consistent, would all sanitize plugins be expected to skip processing for admins? I'm thinking of TFA sanitizing, for example. |
If we had a uid whitelist, then your feature would be as as imple as making a script that grabbed all admins and passing it it to sql:sanitize. See #4213 |
Just made a change to allow multiple user roles to be ignored in sanitization, not just administrators. A cursory glance at #4213 suggests that the option added in that PR would meet the same need however: |
FWIW, I think this is still useful even with the other issue merged. Our use case is that client admins (which aren't using our mail domain obviously for their users) can still log in on test environments. dropping session seems fine, I don't think there are many valid scenarios where you could actually still use them. Also fine to keep user field values, all we care about is that clients can still log in with their e-mail and password. |
#5808 has merged. |
This change adds a sql:sanitize option to ignore admins in users_field_data table when sanitizing. This is useful, for example, if sanitizing a database of customer data and importing to a QA environment where multiple Drupal administrators need to test.
In the particular use case where this requirement came about, the site uses a third-party auth system which matches to Drupal users on email address, so if the emails are wiped, admins can't get in.