Closed totten closed 1 week ago
I believe this is related to #6109. The check for whether or not to include a permissions link for a module will trigger dynamic permission generation for that module. The only problem is that the module may also provide dynamic permissions which rely on an entity type definition which is not yet available for use at the time the links are generated.
I should add that you can replicate this with Drupal core's media
module on a standard
profile installation as well.
I can reproduce this. A workaround PR is at https://github.com/drush-ops/drush/pull/6155.
My question is why is that entity type definition not available yet? The module has fully installed. When \Drupal\media\MediaPermissions::mediaTypePermissions runs, it has a stale entityTypeManager. I get that the container gets rebuilt after a module install but it would be nice if that didn't make stale the PermissionHandler's ETM.
I ran into something similar when it came to field definitions going stale during a test on https://www.drupal.org/project/drupal/issues/2232427#comment-15837482 - an explicit cache-clear was required but honestly it feels like it shouldn't be necessary at all.
Yay! Thanks @weitzman
Describe the bug
My project has some autobuild test/demo sites which include drush and https://www.drupal.org/project/userprotect.
Beginning with 13.3.2,
drush en userprotect
fails.To Reproduce
composer.json
:Install Drupal Core via CLI (
drush site-install
)Enable the module (
drush en userprotect
)Expected behavior
Module installs without error.
Actual behavior
Installation fails:
Workaround
userprotect
via web UI, orSystem Configuration
Additional information
When I skimmed the changelog for 13.3.2, I didn't see any obvious reason for this to fail. But in my testing (autobuild sites on server; local site on Linux; local site on MacOS), the results have been consistent.