Error: Call to a member function grantPermission() on null in userprotect_install()

Adding a plain patch from the first merge request.

Hm, so if I understand correctly, it is possible that the authenticated user role does not exist?

I'm happy to merge the patch, but isn't this also a bug in the drush site install script? User Protect depends on the User module - which upon install - should install the role "authenticated". Or not? Can a Drupal site technically work without that role?

Side note: I see that tests are failing on Drupal 10.1. Something must have changed in Drupal 10.1 lately because about a month ago tests were still passing on that version.

It may be a core issue since I get this for several projects that use the same code on hook_install(). The "AUTHENTICATED" role simply does not exist for some reason dut to wrong order of execution.

See:

- https://www.drupal.org/project/drupal/issues/2906107 🐛 hook_install() is invoked before the module's default config is installed during config import Needs work
- https://www.drupal.org/project/drupal/issues/793660 🐛 Check for failure of hook_install Needs work

Spent a long morning digging into this.

I don't think it has anything to do with the listed issues in #6 though. I did a big bisect of core and the problem is actually caused by 📌 Remove special case of User module install Fixed . The impact is that user module can be installed later. This is a pretty small change for most things, it just allows user to be installed a bit later in the installer. What this means for this module is it can now be installed in the same install task instead of a previous one which installing from config.

Best I've been able to sort out this breaking this use case because Drupal installs all the modules, then imports the config. Because user.module is not being installed in the same step as userprotect.module, the user module config hasn't been imported yet and the role load fails.

The solution proposed should actually work because the changes will already be in config so the fact we don't change the role doesn't maatter. Turns out there's actually a cleaner solution used by some other modules like commerce_checkout which does the same thing with slightly less code using the helper user_role_grant_permissions.

Attached is a patch that uses that helper.

I'm using different patch, no reason to change role when installing from config

Since this only seems to happen on a site install from existing config, I guess the most logical solution is checking for the $is_syncing flag like the patch in #8.

However, the approach using user_role_grant_permissions() like done in #7 seems more robust and is also used in core by media_install() and node_install(). I would vote to use user_role_grant_permissions(). Since the user module is already a module dependency, we don't have to check for the user module existence like media_install() and node_install().

We have tried the path in #7 and now installation works for us.

Agree with @andypost. If we install from an existing config, we want the exact config to be imported and we want no changes. Voting for #8.

#8 works correctly and I think it is the correct way.

I'm not sure that the sync is required but i don't see a problem with it so here's a combined version with the sync and also the more robust helper method.

Thanks for the patches! Since it is likely that user_role_grant_permissions() gets deprecated in the nearby future (see 📌 Deprecate user_role_grant_permissions() and user_role_revoke_permissions() Needs work ), I would rather avoid using it if not absolutely necessary. So I've based my approach on what is used in node_install() on the MR of 📌 Deprecate user_role_grant_permissions() and user_role_revoke_permissions() Needs work .

Let's see if that makes the tests still pass. (I've just fixed the tests for PHP 8.1 + Drupal 10.2, which I wanted to get done first before addressing this issue).

Tested the MR and confirm it works as expected.

Thanks for the review! I merged the code.

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