1

In the process of wrapping my head around Drupal 8's configuration system (which is awesome, by the way), I came across this:

YAML file (from core/modules/user/config/install/user.role.authenticated.yml)

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

Now of course I understand module dependencies, but what might be set here as a dependency for a user role configurable and what would it mean?

Thanks!

Improve this question
8
  • 1
    Nothing. This is a config entity and each config receives dependencies array. But user role has none since it's just the id and label basically.
    – user21641
    Sep 1, 2015 at 16:51
  • Hi, Ivan. That was my assumption until I saw the (apparently unnecessary) entry in the user module file and thought perhaps something interesting might be going on. Guess not. :) Thanks!
    – othermachines
    Sep 2, 2015 at 7:08
  • But that does not mean you cannot provide dependencies as you please. You can have some specific user role that should depend on some content type for example.
    – user21641
    Sep 2, 2015 at 9:28
  • @IvanJaros OK, now it's interesting again. Can you expand on that a bit? If I were to specify a content type as a dependency of a role, is it also up to my module to handle that dependency (to make it mean something), or are there built-in effects?
    – othermachines
    Sep 2, 2015 at 14:26
  • The content type(node type) is a config entity so you would export it into config file too, the same as the user role, and you would provide the content type config entity as a dependency in your user role so the content type would be imported before the role. The content type(or dependency to be more precise) has to be defined by some module. The user role can be put into config/optional directory which would mean it would be installed only if the content entity was already present.
    – user21641
    Sep 2, 2015 at 14:45

1 Answer 1

Reset to default
4

As Ivan Jaros said, all config entities can have dependencies on modules and other config entities, both automatically derived based on code (e.g, a field depends on its field storage and entity bundle it is added) and manually set (in an enforced sub-array with the same structure)

Dependencies ensure that the required dependencies are installed and they are installed in the right order. Which is important if you import a new node type with fields, display configurations, views that list them and so on.

User roles currently don't have automatically derived dependencies, but they actually should have. They should depend on the modules that provide the used permissions, which is a bit tricky since permissions don't give you that information especially not for dynamic ones that depend on node types, filter formats and so on. That's why the key is always empty for them.

We should open a core issue to try and track this better, that would allow roles to clean up permissions when e.g. a node type is deleted or a module is installed. But it's not a major problem since nothing happens if those permissions don't exist anymore.. it's just a string and if nothing asks for it, then nothing happens with it. The only problematic thing is that you a) end up with cruft in those config objects and b) the permissions could get active again when you e.g. delete a node type and add again with the same name. You might not expect your permissions configurations to survive that.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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