New content types (and other dynamic) permissions are not auto-selected for admin role—always give it all perms

I think the current behavior is mostly by design. If I uncheck a permission checkbox, I don't want Drupal to magically assign it again at some random time.

See also #787152: Dynamic permissions cannot be automatically assigned to or removed from roles which is a related issue (not quite a duplicate) that has some discussion, in particular by @catch, about the motivation for the current behavior.

If we did want to change the behavior in Drupal 8 to make it a "superadmin" role, then I think we wouldn't want to have the code deal with assigning permissions at all (nor show this role on the Permissions page); instead it would make sense to extend the current "user 1" code in user_access() to look for this role also.

#9: 1153072-admin-role.patch queued for re-testing.

Looks like a solid bug fix. Here is a reroll.

This is actually more of a feature request - see discussion in #787152: Dynamic permissions cannot be automatically assigned to or removed from roles.

I'm not a huge fan of this personally, but there are legitimate arguments on both sides. That said, the patch is not complete.... The checkboxes for this role on the Permissions page (and elsewhere) become meaningless with this patch, so they'd either need to be removed or disabled.

Also, per my comment in #6, if the goal of this issue is really to have a role that behaves like user 1, I'm not sure why it needs to deal with permissions at all; instead couldn't user_access() check for this role and always grant access, just like it checks for user 1 now?

Hmmm. Good points. I'll let others make a case that we need a new sort of admin role, and if we do it should be a user_access() improvement as David suggests. The existing patch doesn't make much sense.

not exactly sure what the intent of this patch was; but doesn't do what it needs to do.

with patch:
- add a new content type
- check Node perms: these are not set for admin role

flushing all caches though does set these - so i guess its close.

without patch, flushing caches does not fix new node types perms

pretty sad that D7 has gotten this so messed up.. and comments like Dave's and others on the other big post re: this issue just muddy the waters..

If I uncheck a permission checkbox, I don't want Drupal to magically assign it again at some random time.

uhhh.. yea.. you sure the hell do want it to be assigned back for the admin role which was set to be ALL perms by definition.. that is the point.. just like uid = 1.. if you need some other "admin like" role that you want to pick custom perms for.. then why not make a new role for this... i.e. this is not the point of D6 admin role module and should not have been the point of the new feature poorly added in D7.

Retitling to disambiguate from #787152: Dynamic permissions cannot be automatically assigned to or removed from roles. Also, I agree with David that this change would not be backportable.

Edit: However, I think if we set the expectation properly that there's a super-user admin role that always has all permissions, it would be reasonable for the admin role to be such a role in D8. And, as David has stated, that would require either removing or disabling the admin role's permissions at admin/people/permissions -- probably removing, because why bother with permissions at all then? :)

Edit: See also #1454686: When a new module is installed, the admin role doesn't get all new permissions.

Could this current feature be used to create a superuser role?

In Home » Administration » Configuration » People >> Account Settings
exists a section called ADMINISTRATOR ROLE where you can select: disabled, Administrator, or one of the custom roles.

The description says, "This role will be automatically assigned new permissions whenever a module is enabled. Changing this setting will not affect existing permissions."

@lokapujya, yes, that is part of the bug here:

The description says, "This role will be automatically assigned new permissions whenever a module is enabled. Changing this setting will not affect existing permissions."

as this is not actually what happens; but also it should cover more cases than simply when a module is enabled; any time anything adds new perms (which isn't only when a module is enabled; for example it also occurs when a new node type is created)

but the UI is in the correct place and is the setting you refer to; it just doesn't work.

i added a first cut at a D7 port of the Admin Role module here: #1153626: 7.x port since core does not implement the same feature

Can someone explain in plain English to a mere site builder...how can I make sure that the admin role has full permissions on everything that is installed, ever? I would be happy to install a seperate module for this.

I have just spent another 10 minutes of my life going through and clicking the little boxes to give the admin full permissions on newly installed apps. At this rate Drupal will make me 5 years older in only 1 year. WTF and HELP. TY.

see my post directly above yours?

Also, per my comment in #6, if the goal of this issue is really to have a role that behaves like user 1, I'm not sure why it needs to deal with permissions at all; instead couldn't user_access() check for this role and always grant access, just like it checks for user 1 now?

There are many ways this could be implemented in D8.

However, for D7, I imagine that baking this into user_access() would be too much of a change.
On the other hand, the current behavior on D7 is quite useless.
The only reasonable solution in D7 would be to tick the checkboxes as soon as possible. If we have to wait for a cache clear, or until someone visits the permissions page, so be it.

The reason for not backporting this to Drupal 7 is that it's a huge behavior change; I don't think it matters how it's implemented.

On the other hand, the current behavior on D7 is quite useless.

To each his own, I guess; I think it's useful, and so do a lot of other people I've talked to. On an already-launched site, it's rarely a good idea to give administrators all permissions, even if you trust them in theory. Removing a few dangerous ones to prevent people from easily shooting themselves in the foot while exploring is not a bad idea at all. In addition, there's the other use cases people have mentioned elsewhere (e.g., you want high level admins to use Admin Menu but lower level admins to use core Toolbar, so you need to remove the Toolbar permission from high level admins to prevent both from appearing).

Where I've seen the "true" admin role most useful is on a site that's still under development; if you have six developers building a site then you want them all to have all permissions always so they can build it efficiently. But even then, the core admin role mostly works well (except for the bugs that are covered in other issues).

Anyway, it looks like http://drupal.org/project/adminrole has a Drupal 7 release now, so hopefully that means everyone can get what they want :) It still has the comment on its project page about not needing a Drupal 7 release because it's already in Drupal core, though; I'll file an issue with the module now to remove that.

#26
My comment was mostly from my own experience.
On various projects with different co-developers we ran into those stupid issues like "I don't see the admin menu" or "I cannot configure the blocks", or "that link that you gave me doesn't work". This is exactly the type of problem that I thought the admin role setting is supposed to solve.

And even when everyone on the team learned why this happens, someone still needs to go to the permissions page and check all the checkboxes, whenever a new module is installed, a content type created, etc.

In my personal experience, this person will usually *not* carefully read through all the permissions and make an informed decision.
Even if one developer did carefully leave some permissions unchecked, the next one might just go through the list and tick everything on the way.

-----

Personally I am going to try the contrib adminrole D7, hopefully soon with this nice addition, #447940: Add ability to exclude arbitrary permissions. This should also cover the toolbar thing.

Whether we need to do anything on D7 core, I leave to others to decide. Maybe just some string changes to make it more clear what the current solution does.

-----

On D8, if we really want to solve this, one useful thing might be a "pending" state on permissions in addition to checked and unchecked, meaning that those permissions have just been created and are waiting for a decision. There could be a work flow where Drupal would present all the pending permissions for a given role.

This really is a WTF that I hope we can fix before D8 ships. Re-marking as a bug, rather than a feature request because this continues to bite me all the time. I understand and agree with David's resistance to backporting it to D7, though.

The rationale in #26 doesn't make a lot of sense to me for defending its current behaviour; if that's the kind of role you want, just make your own role and call it whatever you want, set admin role to none; it's the default way Drupal roles work. Admin role should be special, and should not require manual futzing every time you add a content type, change a setting here or there, etc.

Also, the natural consequence to admin role not behaving this way is everyone sharing the same uid1 password, and that seems like a far greater evil.

Also, per my comment in #6, if the goal of this issue is really to have a role that behaves like user 1, I'm not sure why it needs to deal with permissions at all; instead couldn't user_access() check for this role and always grant access, just like it checks for user 1 now?

Exactly, that does not only make much more sense but is also much cleaner implementation-wise.

Patch incoming.

#31: 1153072-30.patch queued for re-testing.

rerolling

Seems to me fixed in #2435075: Implement admin role as a flag on the role storage, simplify permissions page, remove user_modules_installed. Please reopen this if I'm wrong.