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:
- 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
- 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. ;)
- 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.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | signup_conditional_admin_links.patch | 1.33 KB | dww |
Comments
Comment #1
dwweureka! 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.
Comment #2
hunmonk commentedi'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...
Comment #3
dwwaccording to http://api.drupal.org/api/HEAD/function/hook_menu:
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?
Comment #4
dwwargh, damn ':' got included in that URL. here's the docs on hook_menu:
http://api.drupal.org/api/HEAD/function/hook_menu
Comment #5
hunmonk commentedhm, 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.
Comment #6
dwwaccording 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:
also, if roles are modified to change what permissions are in a given role, *all* cached menus are cleared, and the entire menu rebuilt:
so, i think we're safe. agree?
Comment #7
hunmonk commentedyep, go for it
Comment #8
dwwapplied to HEAD, 4.7 and 4.6.
Comment #9
(not verified) commented