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

Status:Patch (to be ported)» Closed (works as designed)

That 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.

I 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.

So which permission allows other roles to be able to use the site_verify module?

A 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.

I 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

Title:hook_perm() not implementedImplementation of hook_perm()
Version:6.x-1.0-rc2» 6.x-1.0
Category:bug» feature
Status:Closed (works as designed)» Needs review

Hi,

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:

/*
* Custom access callback function. Acts as a wrapper for the default user_access()
* function, allowing us to pass from inside hook_menu either the standard array
* of access arguments (string, user object, boolean), an array of permission
* names for multiple ways to access the module, or, extending that, an array of
* arrays containing (string, user object, boolean) arguments
*/
function site_verify_user_access () {
    /* Get all of the arguments passed to our function */
    $numArgs = func_num_args();
     $args = func_get_args();
     /* Loop over all of the arguments */
     for ($i=0; $i<$numArgs; $i++) {
         $account = null;
         $reset = false;
         /* Check the format that the arguments have been passed in:
          * an array of (string, user object, boolean), an array of strings or
          * an array of (string, user object, boolean) arrays
          */
         if(is_array($args[$i])) {
             /* Check first parameter */
             if(!isset($args[$i][0]) || !is_string($args[$i][0])) {
                 break;
             }
             /* Check second */
             if (isset($args[$i][1]) && is_object($args[$i][1])) {
                 $account = $args[$i][1];
             }
             /* Check third */
             if(isset($args[$i][2]) && is_bool($args[$i][2])) {
                 $reset = $args[$i][2];
             }
             $allowed = user_access($args[$i][0],$account,$reset);
         } elseif(is_string($args[$i])) {
             // Have arguments been passed in the format (string, object, boolean)?
             if ($i == 0) {
                 if (isset($args[1]) && is_object($args[1])) {
                     $account = $args[1];
                 }
                 if(isset($args[2]) && is_bool($args[2])) {
                     $reset = $args[2];
                 }
             }
             $allowed = user_access($args[$i],$account,$reset);
         } else {
             /* Get out of the loop if we are receiving inappropriate arguments
              * (for instance, we may now be on the object argument of arguments
              * passed in the format (string,object,boolean))
              */
             break;
         }
         if($allowed) {
             return true;
         }
     }
    return false;
}

Add a new permission:

/*
* Implementation of hook_perm().
*/
function site_verify_perm () {
    return array('administer site verify');
}

Extend the implementation of hook_menu (notice the use of 'access callback' and the extension of the 'access arguments' arrays):

/**
* Implements hook_menu().
*/
function site_verify_menu() {
  $items['admin/build/site-verify'] = array(
    'title' => 'Site verifications',
    'description' => 'Add, change or remove verifications for your site.',
    'page callback' => 'site_verify_list',
    'access callback' => 'site_verify_user_access',
    'access arguments' => array('administer site configuration', 'administer site verify'),
    'file' => 'site_verify.admin.inc',
  );
  $items['admin/build/site-verify/list'] = array(
    'title' => 'List',
    'type' => MENU_DEFAULT_LOCAL_TASK,
    'weight' => -10,
  );
  $items['admin/build/site-verify/add'] = array(
    'title' => 'Add verification',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('site_verify_edit_form'),
    'access callback' => 'site_verify_user_access',
    'access arguments' => array('administer site configuration', 'administer site verify'),
    'file' => 'site_verify.admin.inc',
    'type' => MENU_LOCAL_TASK,
  );
  $items['admin/build/site-verify/add/%site_verify_engine'] = array(
    'title' => 'Add',
    'page callback' => 'drupal_get_form',
    'page arguments' => array('site_verify_edit_form', array(), 4),
    'access callback' => 'site_verify_user_access',
    'access arguments' => array('administer site configuration', 'administer site verify'),
    'file' => 'site_verify.admin.inc',
    'type' => MENU_CALLBACK,
  );
  $items['admin/build/site-verify/%site_verify/edit'] = array(
    'page callback' => 'drupal_get_form',
    'page arguments' => array('site_verify_edit_form', 3),
    'access callback' => 'site_verify_user_access',
    'access arguments' => array('administer site configuration', 'administer site verify'),
    'file' => 'site_verify.admin.inc',
    'type' => MENU_CALLBACK,
  );
  $items['admin/build/site-verify/%site_verify/delete'] = array(
    'page callback' => 'drupal_get_form',
    'page arguments' => array('site_verify_delete_form', 3),
    'access callback' => 'site_verify_user_access',
    'access arguments' => array('administer site configuration', 'administer site verify'),
    'file' => 'site_verify.admin.inc',
    'type' => MENU_CALLBACK,
  );
  // Add the verification paths.
  $query = db_query("SELECT svid, file FROM {site_verify} WHERE file <> ''");
  while ($engine = db_fetch_object($query)) {
    $items[$engine->file] = array(
      'page callback' => 'site_verify_output',
      'page arguments' => array((string) $engine->svid),
      'access callback' => TRUE,
      'type' => MENU_CALLBACK,
    );
  }
  return $items;
}

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

Issue summary:View changes
Status:Needs review» Closed (duplicate)

I'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()?