I have been having a conversation regarding user imports over here: https://www.drupal.org/node/2092895#comment-9828027

The issue is simple, during a user import UID 1 is unprotected. If you conduct a user import and have set the "delete non existing users" option for the importer, there is no way to protect the super admin account. This has the effect of destroying websites since the importer is simply doing what is is asked: if the user doesn't exist within the import CSV, blast it from the site. This is a great option (like the addition of blocking users instead of deleting them) but this feature lacks some basic protections for those using the user importer.

We can't assume that anyone conducting an import is fully knowledgeable about how CSV imported data works -- and should they be learning as they do this, having them kill their super admin in the process is kind of "mean".

Comments

shane birley’s picture

This may have already been proposed or it may already been available but protecting UID 1 and a role of the importers choosing. I suspect this would be asked in the future.

shane birley’s picture

Rolling a new patch for protection of UID 1 and users with certain roles.

shane birley’s picture

StatusFileSize
new3.69 KB

It would help if one attached the file.

shane birley’s picture

This adds a section called PROTECT under the user processor settings page. It allows importers to protect the UID1 account as well as users with a selected role.

megachriz’s picture

Could you provide the changes in a patch? By providing a modified version of a file, it's harder to find out what you actually modified, especially when the same file changes later in dev. See "Creating patches" on https://www.drupal.org/patch.

megachriz’s picture

Status: Active » Needs review
StatusFileSize
new4.01 KB
new5.05 KB

Here is a patch that adds protection for user 1. It prevents user 1 from being deleted via either the "Delete items" form or via the "delete non-existent" feature. Also attached a patch with tests only, to demonstrate that the tests are failing without the fix.

The feature for protecting certain roles is not included.

The last submitted patch, 6: feeds-protect-user-1-2485059-tests-only.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 6: feeds-protect-user-1-2485059.patch, failed testing.

megachriz’s picture

Status: Needs work » Needs review
StatusFileSize
new5.03 KB
new1.86 KB

I think that when trying to delete user 1, while user 1 does not get deleted, the associated feeds item should get deleted. Else there would be no way to get rid of that redundant feeds item. New patch.

Status: Needs review » Needs work

The last submitted patch, 9: feeds-protect-user-1-2485059-9.patch, failed testing.

megachriz’s picture

Status: Needs work » Needs review
StatusFileSize
new4.68 KB
new735 bytes

The feeds item doesn't have to be deleted when deleting non-existing users, I think. Only when really clearing a feed.

Status: Needs review » Needs work

The last submitted patch, 11: feeds-protect-user-1-2485059-11.patch, failed testing.

megachriz’s picture

Status: Needs work » Needs review

All tests are passing, not sure why the testbot moved the status to "Needs work". Back to "Needs review".

twistor’s picture

+++ b/plugins/FeedsUserProcessor.inc
@@ -379,6 +389,19 @@ class FeedsUserProcessor extends FeedsProcessor {
+    if (isset($state->removeList[1])) {
+      unset($state->removeList[1]);
+    }

I don't think this needs to be conditional.

Other than that, looks good!

megachriz’s picture

@twistor
Thanks for reviewing. I see that a variable doesn't have to exist to unset it.

I fixed this and made a few tiny corrections in the tests (mainly text corrections). If this is passes, I'll commit it.

  • MegaChriz committed e280ce2 on 7.x-2.x
    Issue #2485059 by MegaChriz: Added delete protection for user id 1.
    
megachriz’s picture

Status: Needs review » Fixed

Committed #15.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.