After #520364: system_admin_menu_block_access() makes no sense and #296693: Restrict access to empty top level administration pages we're back to a situation where top level menu items on /admin don't show up individual in menus unless you have access to /admin, and when they do show up, they show any link which depends on 'access administration pages' even if they're empty.
There are several issues here, some with horrible API and performance implications, but I think we can get around it by changing the permissions around a bit.
Quick summary, see http://drupal.org/node/301902#comment-2114750 for the gory details with pictures.
'Access toolbar' by itself, with any permission like 'administer users' or 'administer nodes' gives you only an empty toolbar unless you add 'access site configuration' - this is because the menu system checks access to 'admin' as well as 'admin/foo'. before showing any second-tier links We'll need to make the permission for /admin 'access dashboard' when the dashboard patch gets in - and then hope that sites which give users access to the toolbar also give them access to the dashboard. Can't think of any workarounds for this which aren't horrible, same problem exists in D6 by the way.
I suggest we do the following - just like admin/content, admin/people and /admin content have their own permissions, we add these for 'config' and 'appearance' too.
admin/content -> 'administer nodes' or 'access content overview' (see #301902: Allow more users to see the node admin page) - no change
admin/people -> 'administer users' - no change
admin/config -> 'access site configuration pages' (rename 'access administration pages' since that's no longer accurate once dashboard gets in)
admin/reports -> 'access site reports' - no change
admin/appearance -> leave as 'administer site configuration'.
admin/help -> 'access help index' (or similar, to separate it from 'access administration pages'.
/admin - 'access dashboard' (in the hope the dashboard will be accessible to all users.)
That's a total of one new permission, and one renamed, and then you get a working toolbar.
Comments
Comment #1
sunMany people will already know what comes now.
Accessing the Toolbar must be a separate permission than accessing administrative pages. These are different use-cases.
You can setup custom administrative pages not located below admin/ that will be accessible in the toolbar.
Comment #2
sunThe only way out for the UX issue I can currently see would be a "dependency" or better "recommendation" system for permissions. "You just enabled the toolbar for role Foo. Do you want to grant them access to administrative pages, too?"
Comment #3
catchThis isn't limited to the toolbar, it affects menu module too.
Comment #4
sun@catch: Can you clarify what you want to do/achieve here? Obviously, it seems I got the original post wrong.
Comment #5
catchI want to get #301902: Allow more users to see the node admin page in without it being held up on stupid toolbar bugs which have nothing to do with it :(
Comment #6
yoroy commentedSo, with this marked a critical bug, what's next now that other issue got in?
Comment #7
sun.core commentedNo idea either ;)
Comment #8
catchIt's probably still broken but I'm sure there's another issue somewhere.
Comment #9
eigentor commentedHm I wonder where this other issue is.
The single reason why we never ever can use toolbar for clients is the problem catch describes: If the user has no sufficient admin privileges, it is completely useless because they do not see any links on it. One has to turn it off, since we as admins are better suited by admin menu, and the two do not live together really nicely.
This is an even bigger shame as it is much more useful for beginners than admin menu.
So someone please send me to the issue where this is discussed.
Setting to active until someone does :)
Comment #10
jessebeach commentedThis really should be a major.