if you give a given role the 'admin signups' permission, but not the 'administer site configuration' (and 'access administration pages', for that matter) permissions, the main navigation menu gets weird. the user now has permissions to admin/signup and admin/settings/signup, but not admin nor admin/settings. so, the use just sees 2 links labeled "signup" in their main navigation menu. if they have 'access administration pages' but not 'administer site configuration', the same thing happens, but under the 'administer' menu item.

a few possible solutions:

  1. require 'administer site configuration' permission to create the admin/settings/signup menu callback. this is a little bit too bad, since those settings aren't really as critical to lock down as the rest of the site configuration, and yet a "signup administrator" might want/need to change them
  2. rename these links "signup overview" and "signup settings", but leave them in the same URL. this way, for users who just have 'admin signups', they see the 2 links but they have reasonable names. unfortunately, this would make things worse in the common case, since we'd already see these under admin and admin/settings, and in this case the extra words would be annoying. ;)
  3. try to play tricks with url aliasing, and conditionally rename the URLs for users in this situation.

none of these are very satisfactory. :( this is a weird case, and not all that important, but i'd like to fix it. i'll think about it a little more before i do anything, but just wanted to record my thoughts somewhere, in case someone else has any bright ideas.

CommentFileSizeAuthor
#1 signup_conditional_admin_links.patch1.33 KBdww

Comments

dww’s picture

Assigned: Unassigned » dww
Status: Active » Needs review
StatusFileSize
new1.33 KB

eureka! option 2a: just conditionally rename the titles of these links depending on if the user has 'administer site configuration' permissions or not. ;) i think this is the best possible solution. unless there are any strong objections, i'll commit this to all branches.

hunmonk’s picture

i'm pretty sure this is a bad idea since those menu items are cached. moving them to non-cachable to accomodate this change also seems a little extreme to me...

dww’s picture

according to http://api.drupal.org/api/HEAD/function/hook_menu:

may_cache -- A boolean indicating whether cacheable menu items should be returned. The menu cache is per-user, so items can be cached so long as they are not dependent on the user's current location.

i think it's pretty reasonable to assume that a given user's roles aren't going to be changing so fast that this is really a problem if it's cached. i mean, this is a rare case in the first place, and i don't believe it really matters that if a) they just have admin signups and they cache the link titles as "signup settings" b) they get added as site admins and c) they go to admin/settings and see "signup settings" before the cache is refreshed. seems like an insanely rare situation for a problem that really isn't a big deal (so they see the extra word?). in fact, consider it a feature, since if they're used to the old (verbose) links when they first get added as full site admins, it'll help them find the old links in the new locations. ;)

anyway, given that the menu cache is per-user, i don't see that as a good reason not to go ahead and commit. am i missing something?

dww’s picture

argh, damn ':' got included in that URL. here's the docs on hook_menu:
http://api.drupal.org/api/HEAD/function/hook_menu

hunmonk’s picture

hm, i wonder if the menu cache gets cleared when new perms are saved? i'm not familiar with all situations that the cache is cleared, but if it's cleared in this case, then i don't see an issue at all with this approach.

dww’s picture

according to merlinofchaos in IRC, whenever a user's profile is edited (e.g. to change roles), once the submit happens, the menu cache is cleared. see user.module:

function user_edit_submit($form_id, $form_values) {
...
  user_save($account, $form_values, $category);
  // Delete that user's menu cache.
  cache_clear_all('menu:'. $account->uid, TRUE);
  drupal_set_message(t('The changes have been saved.'));
  return 'user/'. $account->uid;
}

also, if roles are modified to change what permissions are in a given role, *all* cached menus are cleared, and the entire menu rebuilt:

function user_admin_perm_submit($form_id, $edit) {
...
  drupal_set_message(t('The changes have been saved.'));

  // Clear the cached pages and menus:
  menu_rebuild();

}

so, i think we're safe. agree?

hunmonk’s picture

Status: Needs review » Reviewed & tested by the community

yep, go for it

dww’s picture

Status: Reviewed & tested by the community » Fixed

applied to HEAD, 4.7 and 4.6.

Anonymous’s picture

Status: Fixed » Closed (fixed)