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

sun’s picture

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

sun’s picture

The 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?"

catch’s picture

This isn't limited to the toolbar, it affects menu module too.

sun’s picture

@catch: Can you clarify what you want to do/achieve here? Obviously, it seems I got the original post wrong.

catch’s picture

I 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 :(

yoroy’s picture

So, with this marked a critical bug, what's next now that other issue got in?

sun.core’s picture

Priority: Critical » Normal

No idea either ;)

catch’s picture

Status: Active » Closed (won't fix)

It's probably still broken but I'm sure there's another issue somewhere.

eigentor’s picture

Status: Closed (won't fix) » Active

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

  • Has fewer items - less confusing
  • Has shortcut bar - can be nicely configured per role
  • is bigger and easier to click on

So someone please send me to the issue where this is discussed.
Setting to active until someone does :)

jessebeach’s picture

Priority: Normal » Major

This really should be a major.

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.