Add ability to exclude arbitrary permissions

A seconding of this and a concrete example. Ubercart defines an "act as seller" permission which, when enabled on a site running Paypal payment gateway, requires the user with that permission to provide a Paypal email address on their account.

Thirded. There are often permissions I want to exclude from my administrators. Perhaps the most flexible feature would be for admin role to provide an inverse of the standard Drupal permissions system, whereby multiple roles would be admin roles, and each one could have specific permissions switched off.

fourthed?

this patch creates a textarea in the adminrole settings page. permissions listed there, one per line, are ignored when adminrole does its updates.

This is an a new patch for this feature; providing a friendlier UI and currently in production over at Prometheus Labor. Sponsored by Prometheus Labor.

+1 Reviewed and test. Works great!

I've tested this as well, works fine for me. +1 for the functionality.

I'm attaching a slightly cleaned up version of the patch in #5 that should apply cleanly with drush_make.

New patch needs new review. Change status.

@#8: fwiw, the patch is the same code as #5 - only the format of the diff is changed, so I believe it's justified to change the status to 'reviewed and tested', as it's the same code that #6 and I have both tested.

I'm not sure this is the right approach. I'd like to get the original maintainer's (Jacob Signh) thoughts on this first.

Would you care to share why you aren't sure?

Changing status to "review and tested." It works and until someone can flag a genuine reason as to why it "needs work," it should stay "reviewed and tested."

Well...patch does not apply to the current code. I'm also working on a test suite for the module and I'd prefer to have this patch include tests once I can get those committed, probably tomorrow.

Not to be a stinker, Dave, but tomorrow has come and gone. Any chance you can apply this patch, please?

Well, the current version of adminrole doesn't have any hook_menu() or hook_help() implementation, so it does look like the patch was created against an older version. Maybe updating it for the current version might help?

I understand the desire for this functionality. My reservations is that I could see it being pretty confusing. The whole point of adminrole was that it was really simple to make a role like user1. I'm afraid this dilutes that goal a little.

However, from looking at the patch, it appears to be on a different tab. So as long as the current flow is not interrupted in any way, I'm in favor. btw, my opinion doesn't matter that much, I haven't committed to adminrole in a long time and now work 99% on D7 which has adminrole as part of core. (btw, I don't think this functionality will transfer well)

I would only recommend some more help text explaining what the exceptions page is about. It may also be a good idea to print the list of exceptions on the main page if there are any. So the user sees the description as "User gets all permissions, except the following: ...."

Might help people from getting massively confused and filing bug reports.

I've been looking for this functionality! I realize, as you say, @JacobSingh, that the purpose of Admin Role, is to functionally replicate User #1 status. There are actually some permissions I wish I could revoke even for User #1! For example, I like Admin 1.x, but I don't want the inline editing overlays. Unfortunately, the only mechanism the module provides for turning it off is through the permission, with the effect that it's impossible to turn off for User #1... or adminrole-d users. I think it's poor practice to make permissions the only way to turn a feature off, for that very reason, and I think we need a solution to the problem of modules whose maintainers give no other mechanism; but in the meantime, being able to exclude permissions in Admin Role would get the job done.

Hello

Yet another solution for this issue.

For now I have committed simple support for an 'adminrole_exclude_permisisons' variable that must be an array of excluded variables.

Which patch from this issue did you commit? I just updated to 1.3, and according to the release notes at http://drupal.org/node/883222 there should be a page, a tab, or some form field somewhere that would let me define a series of permissions to be excluded. Alas, I don't see this functionality after the 1.2 > 1.3 upgrade ...

???

The release notes say exactly what the comment before yours says - there's just a variable, no UI. I see no mention (or implication) of a page, tab, or form field in those release notes.

So here's an adjusted patch.

- took the basic code structure from patch #19
- but made a 'theme implementation' so that the admin screen looks like patch #7 & the normal permissions screen. (The theme_adminrole_perms() function from #19 probably still works as a drop-in replacement if you like it better.)
- and adjusted to the variable that's used in v1.2

I moved the settings screen to admin/user/ just like it -apparently- was in #7. Moved the admin_role selector onto the same screen. I don't see the use for them being on different screens, and it also gets rid of the need to make help texts, solely to explain the effects of 'the setting on the other screen'.

Oh crikey.

Ignore patch in previous comment, please.

And suddenly all patches in this thread are marked in a red color. Apparently Dave has turned on testing. (And apparently all historic patches in this thread were tested yesterday :) )

So the time had finally come, when this lowly contrib developer needed to write a little shell script to adjust the output of his 'bzr diff' commands.

(Since I can't find definitive docs, I'll just assume that this is the correct way, and let the test bot give a verdict...)

(Every new fancy thing needs getting used to... Changing status.)

We could use this feature as well, and the last patch seems to be working well. Will there be another 6.x release?

If a maintainer can confirm that they'll apply the patch once it's RTBC I'm happy to review it :)

Oh, that's nice. Works great. Nice work, @roderik!