3

I have created a role, Admin. Admin has permissions: "Assign roles" (via RoleAssign), "Access administration pages", "View admin theme", and "Administer users".

I export the role with Features (including the permissions one by one, as well as the role itself).

I delete the role in config and clear cache before enabling the feature. I enable the feature. I drush fr adminrole and I get Current state already matches defaults, aborting.

But my new Admin role doesn't have the expected permissions. Sometimes it has "Access administration pages" and "view admin theme" but it does not have "assign roles" or "administer users".

Is this a case where Features requires Strongarm? Or do I have to use Secure Permissions (which would be less than ideal because other administrators would not be able to change permissions in config anymore.)

Improve this question

2 Answers 2

Reset to default
2

I was confusing two different things. Because of the way Features handles permissions and roles, there are three pieces, not just two.

What I thought was happening:

  1. I add Myrole to the Feature.
  2. I add mypermission1, mypermission2, mypermission3, etc. to my Feature.
  3. I save my Feature and user with Myrole will have mypermissions 1, 2, 3, etc.

What actually needs to happen:

  1. I add Myrole to the Feature
  2. I add mypermission1, mypermission2, mypermission3, etc. to my Feature.
  3. I make sure that Myrole's permissions in my current config actually include mypermissions 1, 2, 3, etc.
  4. I save my Feature and user with Myrole will have mypermissions 1, 2, 3, etc.

The first one exports whatever the state of mypermissions 1, 2, 3, etc. is at the moment of the export which means that if the role in your config does not actually have those permissions, your Feature will specify that your role does not have those permissions, explicitly. Backwards from what I was trying to do.

Improve this answer
1

one common problem with featurizing permissions is that the roles in the source and target installs have to be identical not just in name but in ID as well. If not you may be applying permissions to the wrong roles, or to role IDs that don't exist. So the first thing is to check that both sites line up as regards the role table.

Improve this answer
2
  • I considered that but that's not the problem. I'm checking everything on a clean sandbox that does not have different roles than my dev site.
    – beth
    Commented Mar 5, 2013 at 19:18
  • Is the RoleAssign module enabled at the point when the new permissions are installed? Also, check that the Feature files are correct when applied: if the Feature stays as "overridden" after reversion that's a sign there's an inconsistency. It's worth installing the Diff module to help in diagnosing Features issues. Also, you make a good point about Strongarm: does the RoleAssign module require any particular variables to be set in order to create these permissions? If so, you may need to Strongarm them.
    – Alfred Armstrong
    Commented Mar 6, 2013 at 8:43

Your Answer

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

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