Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
My apologies if this has been reported already (or I'm reporting this in the wrong place (or it's been fixed in the latest dev release)) but I couldn't assign permissions to administer the module to users. I took a look in site_verify.module and noticed that site_verify_perm hadn't been implemented, so I've added the following to the bottom of the file:
function site_verify_perm() {
return array('administer site configuration');
}
I hope this helps someone,
David
Comments
Comment #1
Dave ReidThat permission is already provided by system.module (since being able to upload any arbitrary file to the website is dangerous, or change meta tag content), so we don't need to define it in site_verify.module.
Comment #2
bwinett CreditAttribution: bwinett commentedI don't understand that answer. Modules normally provide the ability to allow specified roles to take specified actions using permissions. DaveyM provided code for implementing this extremely easily. It would be great to have this added, and I can't think of any reason not to.
Comment #3
z3cka CreditAttribution: z3cka commentedSo which permission allows other roles to be able to use the site_verify module?
Comment #4
apadernoA module doesn't declare a permission already declared from another module. If a module uses, for example, the access content permission, it doesn't declare it using
hook_perm()
, as that permission is already declared from a Drupal core module.The code provided by DaveyM (which is not a patch, though) is not correct. If you are asking why the module doesn't implement its own permission, the answer is probably that it is useless to create a custom permission for a single setting page, when it is possible to use a permission Drupal already has.
Comment #5
DaveyM CreditAttribution: DaveyM commentedI see now: I didn't realise that modules could use other module's permissions. Sorry, I guess I've still got a bit to learn!
The hook_perm() that I added causes the 'administer site configuration' permission to dissapear from the listing underneath 'system' on the page at admin/user/permissions, so clearly I took the wrong approach there.
Ticking the system module's 'administer site configuration' permission for the required role does cause the settings menu to appear, along with menus for a bunch of other modules I have on the site.
It would be handy if there was scope for more granularity in the module's permissions (so that all the other menu items didn't have to be shown as well), but as I've only just got my head around what I was doing wrong I've no idea if that's even possible :-)
Thanks for your help,
David
Comment #6
DaveyM CreditAttribution: DaveyM commentedHi,
I thought I'd come back to this issue just so I could get a little practice with coding for Drupal, and I came up with the following workaround. Note: This is based around the code in 6.x-1.0 rather than the latest dev release
Add a new access callback, which is really a wrapper for the default user_access() function:
Add a new permission:
Extend the implementation of hook_menu (notice the use of 'access callback' and the extension of the 'access arguments' arrays):
This seems to work when I tested it, but I haven't looked too deeply into it as I did it more out of curiosity and because bwinett seemed interested - it's totally up to you if you want to look into adding it to the module!
Thanks,
David
Comment #7
joachim CreditAttribution: joachim commentedI'm going to close this as a duplicate of #1898908: Its own permission, which has a patch for D7 which I've just committed, and which can be used as a starting point for backporting. The code posted here looks ok in part, though I am REALLY confused as to why site_verify_user_access() needs so much jumping through hoops -- or is even needed at all!! Surely it's just a matter of user_access()?