2

TLDR; I'd like to export the permissions I've added to the authenticated role, and have them appear on a different server when installing the custom module. However, when I install the module on a fresh server, the permissions for the authenticated user remain as default, but I can see in admin/config/development/features that there are pending changes, and once I import them the settings are correctly applied. Why aren't they applied on loading the module?

Steps to reproduce

First I log into a blank dev site, navigate to admin/people/permissions and add the Article: Create new content permission for the authenticated user (which I know is create article content from looking at the page source in my browser).

I now navigate to admin/config/development/features/edit and select Roles->Authenticate user (authenticated), pick a module name, enable Mark all config as required and click Download Archive.

The result is a module that contains 3 files:

my_module.features.yml

required: true

my_module.info.yml

name: 'my module'
type: module
core: 8.x
dependencies:
  - user

Since I'm using 9.0.7 I changed this to;

name: 'my module'
type: module
core_version_requirement: '^8 || ^9'
dependencies:
  - user

config/install/user.role.authenticated.yml

langcode: en
status: true
dependencies: {  }
id: authenticated
label: 'Authenticated user'
weight: 1
is_admin: false

For some reason Features didn't pick up my permission changes, so I changed this manually to;

langcode: en
status: true
dependencies: {  }
id: authenticated
label: 'Authenticated user'
weight: 1
is_admin: false
permissions:
  - 'create article content'

Now I tried to install the module by copying it to /modules/custom/my_module and running drush en my_module on a completely clean site. However, when I navigate to admin/people/permissions I see this:

enter image description here

When I go to admin/config/development/features/diff/my_module I can see that my features were correctly interpreted, just not applied:

enter image description here

If I now select Import Changes the permissions apply correctly. But why aren't they already applied, when the my_module module is clearly enabled?

I tried playing around with the weight value in user.role.authenticated.yml to no avail (I changed it to 9999 and -9999 but it didn't seem to have any impact).

The fact that I had to modify my user.role.authenticated.yml indicates that something has perhaps gone wrong at the export step, but I don't know enough about the features module to know if these events are related.

3 Answers 3

2

You need to un-exclude user permissions first.

Go to /admin/config/development/features > Select your bundle > (Tab) Configure Bundles > Alter (Configure) > Uncheck "Strip out user permissions."

Then recreate the feature.


I've also already been there. 😁

4
  • This causes the permissions to be exported. It's helpful to know because it means I don't have to manually add the permissions to my user.role.authenticated.yml file anymore, but doesn't change the undesirable behaviour that enabling the module doesn't import the permissions. Note that I still have to manually add the core_version_requirement: '^8 || ^9' line as well so I'm wondering if this is a drupal 9.x issue. I noticed that you removed the 9 tag from the post. Do you mind if I revert it?
    – quant
    Oct 21, 2020 at 0:00
  • @quant – No problem, it's just you need to choose only one. Seems 9 is a better fit. And it also seems more of a bug. Though I'm not sure if it's Features or core. What happens when before you enable the Feature on the other site you remove the authenticated user role from this site? Does the role get recreated AND the permissions get set then?
    – leymannx
    Oct 21, 2020 at 5:49
  • I tried changing my drupal version to 8.9.7 and had the same problem, so it's not a version 9 issue after all. I don't know how to delete the authenticated role but when I created a test role and applied the same module (with authenticated replaced with test) the permissions import correctly. So now we've narrowed this down to being an issue to do with the authenticated user somehow..
    – quant
    Oct 21, 2020 at 10:20
  • Well, I've got a workaround, but I'm not proud of it: drupal.stackexchange.com/a/297557/59466
    – quant
    Oct 21, 2020 at 10:31
2

This is only a workaround. If leymannx or someone else come up with a better solution I'll mark it as the answer, but in the meantime I thought I'd provide my hack-around to get this working:

my_module.install

<?php

/**
 * @file
 *
 * Install functions for my_module
 */

use Drupal\user\Entity\Role;

/**
 * Implements hook_install().
 *
 * Perform actions to set up the site for this profile.
 *
 * @see system_install()
 */
function my_module_install() {
  $role_object = Role::load('authenticated');
  $role_object->grantPermission('create article content');
  $role_object->save();
}

This causes the permission to be correctly applied.

0

I would highly suggest you to stop using features and use drush instead You can easily export your config using drush cex -y (cex = config export) and import it using drush cim -y (cim = config import).

8
  • When syncing config from one multi-site instance to another, that simple Drush config routine you described isn't much of a help. It's also not what OP was asking for.
    – leymannx
    Oct 20, 2020 at 23:14
  • Syncing from one multi-site instance to another one is pretty simple since you just need to erase the old yml files, put the new files in the same directory and run the command. And as I already met problems like he described with features but never with drush the suggestion still makes sense ;)
    – MacSim
    Oct 20, 2020 at 23:19
  • This is good to know, but I don't think it helps with my issue.
    – quant
    Oct 21, 2020 at 0:02
  • If you choose not to use drush and keep using features, you're right it won't help you. But if you choose starting using drush it will help you as you won't have your issue anymore.
    – MacSim
    Oct 21, 2020 at 0:13
  • 100 multi-site instances and manually copying 100 of config around. No way.
    – leymannx
    Oct 21, 2020 at 5:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.