As discussed in #1153072: New content types (and other dynamic) permissions are not auto-selected for admin role—always give it all perms and a number of other issues core does not implement the feature of a role with all permissions. I find that feature very useful and would like to see a 7.x port.

CommentFileSizeAuthor
#22 Admin role configuration.png123.54 KBAnonymous (not verified)
#8 adminrole.zip9.66 KBliquidcms
#7 adminrole.zip9.53 KBliquidcms
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

coderintherye’s picture

Hate to do more than just add a +1, but yes I would also request this feature.

Like boombatower I found the behavior in core to be a big WTF, because it does not actually do what the code comment says it will do. I'd love to see that in Drupal 7 core, but doubt that will happen at this point, so next best thing is seeing a 7.x port of this module.

liquidcms’s picture

+1.. nice idea but yup, core missed the boat.

liquidcms’s picture

i re-opened this post #480660: Add an 'administrator' role to core - i am sure i will get flamed royally for doing so.. lol

Leeteq’s picture

A major annoyance with the core implementation is that when changing the admin role, it does not automatically set full permissions for that role across all modules.

boombatower’s picture

Due to the silly way it was implemented...it only add permissions enabled after it was setup.

okokokok’s picture

+1

liquidcms’s picture

FileSize
9.53 KB

here is a first cut at a D7 version of this module.

right now it doesn't update when a new type or field is created. i have this code:

/**
 *
 * Respond to fields/entities being created, updated, deleted   - NOTE - this is the wrong code fore this!!
 */
function adminrole_field_update() {
  adminrole_update_permissions();
}
function adminrole_field_create() {
  adminrole_update_permissions();
}
function adminrole_field_delete() {
  adminrole_update_permissions();
}       
function adminrole_entity_update() {
  adminrole_update_permissions();
}
function adminrole_entity_create() {
  adminrole_update_permissions();
}
function adminrole_entity_delete() {
  adminrole_update_permissions();
}

seemed like it should work; but is never hit.

it does do the right thing when admin role is set (user admin settings) and when module admin is submitted.

if someone can tell me what code is run on node/field create/delete (D6 module ran on node/field update as well but not sure thats needed)

not sure if other triggers should be included; but easy enough to add.

liquidcms’s picture

Status: Active » Needs review
FileSize
9.66 KB

this one is a bit better, it updates on node type create/delete, field add/delete, perms being set, admin role being set, modules enabled/disabled

it also spits out a message when ever the admin role perms have been set

i think this now covers all the functionality of the D6 module (and slightly more).

i see in the D6 code there was the start of code to allow setting a set of perms which were not affected by the admin role. would be easy enough to add this but seems contradictory to the concept of the module so i didnt bother.

mgifford’s picture

Thanks Peter. This hasn't been something that's bothered me, but it makes sense.

Would be good to see if perhaps it can't be cleaned up in Drupal 8. You should submit a patch to core!

liquidcms’s picture

i think there is a plan to fix this in D8; might be in already.

doublejosh’s picture

@liquidcms, thank you! This is a BIG help when dealing with automated upgrades.
Was mid-way through writing the same thing until I found this.

Anonymous’s picture

@liquidcms

The 7.x-1.x-dev version of Admin Role in #8 was working when my site had a modest number of modules. Now it is not. At present, my site has 486 modules and sub-modules available. Of these, 219 are installed.

Its been several days now since I have not seen confirmation of adminrole's granting all permissions to the administrator role when running 'drush cc all'.

I experimented with disabling/re-enabling the module, and with uninstalling and reinstalling it. This made no difference.

I was a happy camper, but now I am sad, since this feature really is close-to-essential during site building.

Bob

Leeteq’s picture

Time for a 7.x-dev release for the project page?
Or at least point to this issue from the D7 note on the project page, which is quite misleading.

@liquidcms:
"allow setting a set of perms which were not affected by the admin role" - would be *VERY* useful for lots of sites... (in fact quite critical for some)

liquidcms’s picture

i've been given commit rights by the project maintainer but GiT (as usual) is not letting me add a new branch.

i'll try again later tonight.

re #12: not sur ewhat you are saying; with more modules my module doesn't work; i guess that it would be possible that php times out; would be helpful if you said what the actual issue was.

re #13: "allow setting a set of perms which were not affected by the admin role"; not entirely sure what this refers to; is it something like select specific perms which don't get set for the admin role? that wasn't the original use of this module in d6, not what core was trying to do and i have no use in adding that. i suppose if the project maintainers are interested in this and you provide a patch; they might commit it (of course once we actually have a D7 rel). what i could be convinced to add would be a hook so that other modules (like this other module you are referring to) could alter which perms this module sets.

Anonymous’s picture

@liquidcms

Re #12, the actual problem is that whenever a new module is enabled, its permissions are NOT automatically granted to the site's administrator role. I have to do it manually.

liquidcms’s picture

it works for me :) on numerous sites that the module is running on now. perhaps some other module is interfering with this?

Anonymous’s picture

IMO, and at the risk of going off topic, this is exactly why the Drupal developer community needs to adopt the discipline of incorporating basic tests for each-and-every module into an automated continuous integration test suite. This is the only way an engineering community's members can know that their work has just screwed up someone else's, or vice versa.

The majority of issues I have run into thus far using D7 are incompatibilities, always of an unknown kind, between (contributed) modules, but no one seems to know which ones are the candidate offenders.

Arrrg!

To boil it down, Drupal needs to raise the bar for its core and community development practices.

Ok, EOR (end of rant) :)

NikLP’s picture

I'm about as disillusioned with Drupal as I have been in many a month. We have an adminrole module which is "incorporated into core" but actually has totally different functionality? What was the freaking point of that, exactly?

So... */rant* is this module going to do what adminrole 6.x did, or are we abandoning it...? I loved the original (with its expected behaviour, SHOCK!) where we just enabled it and off we went, no checkboxen, just blammo!

boombatower’s picture

The folks in core in the linked to issue are disillusioned with reality, but good luck convincing them of that. Should rightly be considered a bug fix and dealt with 8 versions ago, but...this module really should be ported since they won't figure that out, perhaps with my new side-project I will get some time to work on it.

liquidcms’s picture

ran through Git again to see if i could create a D7 branch and commit my D7 port. either it works better this time around or i do (likely me) as i think the D7 branch is now committed.

at the moment i have only created D7 branch with -dev and there is nothing showing up yet (likely later today or tomorrow); but as i am using this module on all of our D7 sites with no issues; perhaps i should go ahead and create a stable tag.

Anonymous’s picture

FileSize
123.54 KB

My previous frustration with Adminrole (see #18 above) was actually due to its poor D7 documentation. The included README.txt is actually about the D6 version, which has a different admin paths structure.

Once I stumbled upon Adminrole's configuration pane, which is incorporated with others at admin/config/people/accounts, the module has performed flawlessly.

See the attached configuration screenshot, specifically the "Administrator role" pane.

It should be noted that Adminrole-7.x-1.0 still contains the outdated README.txt file.

liquidcms’s picture

Assigned: Unassigned » liquidcms
Status: Needs review » Closed (fixed)

yes, i started my port with what was most recent from D6 -dev. The README likely needs updating (feel free to add a patch for this.. :) ). Also, i think there is a drush file there as well which i have not touched.

also, i see my git attempt did work and we do now have a 7.x-1.0 release on the project page - so closing this issue. please raise any issues related to the D7 port as new issues tagged as D7.

boombatower’s picture

great work. thanks.

NikLP’s picture

Bravo liquidcms! :)

coderintherye’s picture

see #1830608: Update README for 7.x for the readme issue