Your description says

Administration Menu is only displayed if a user has the privilege 'access administration pages'.

This is good, but it's only part of the picture. Most Site configuration items are only accessible when the user has the administer site configuration permission. You do remove some of them, but I still get Clean URLs, Date and Time, and a bunch of others, even though clicking them goes to an "Access denied" page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

keesje’s picture

I have the same "problem", where the default Drupal admin menu nicely hides all options not accessible, Admin menu shows some of them located under Site-configuration.

sun’s picture

Status: Active » Closed (duplicate)

Marking as duplicate of http://drupal.org/node/155589

sun’s picture

FYI: Some menu items below admin/settings do not have required access restrictions. See http://drupal.org/node/170567 for further information.

joep.hendrix’s picture

Status: Closed (duplicate) » Active

This was marked as duplicate of http://drupal.org/node/155589.
However, that patch did not fix it. There are still items visible in the Site configuration menu where the user does not have access to.

Like mentioned in the initial issue content:

Most Site configuration items are only accessible when the user has the administer site configuration permission. You do remove some of them, but I still get Clean URLs, Date and Time, and a bunch of others, even though clicking them goes to an "Access denied" page.

sun’s picture

Title: Inaccessible menu items » Inaccessible site configuration menu items are displayed

This is caused by missing access permission definitions in system.module in Drupal core.
Here is the flow:

- Site configuration (admin/settings) is displayed if user has access permission 'administer site configuration'.
- F.e. Clean URLs (admin/settings/clean-urls) has no access permission set, inherits permission from Site configuration.
- To display sub-menu items that have a different access permission than 'administer site configuration' below Site configuration, admin_menu iterates over all children of Site configuration and grants access to Site configuration if there is at least one item that is accessible for the current user.
- As a consequence, items like Clean URLs are displayed, because Site configuration is accessible now.

joep.hendrix’s picture

Thanks sun for updating me on this.
I can see that this is a missing access permission in core. However, in the regular admin interface, these inaccessible menu items are not visible.

So maybe the _menu_item_is_accessible function can be used here (http://api.drupal.org/api/function/_menu_item_is_accessible/5) like suggested by http://drupal.org/node/170567#comment-597950.

matt@antinomia’s picture

Invoking _menu_item_is_accessible() in theme_admin_menu_tree() fixes the issue for me, effectively hiding all menu items the user does not have access to. However, it also hides the "Drupal" menu as well as the User and Devel menus. I'm not rolling a patch as I noticed sun is actively working in CVS...

If we use _menu_item_is_accessible() how do we slip the Drupal, User, and Devel menus through when necessary?

sun’s picture

It would be great, if you could provide a patch against DRUPAL-5--2, so I'm able to understand what you are talking about. Thanks.

btw: 99% of all modules are *always* evolving ;)

matt@antinomia’s picture

Version: 5.x-1.x-dev » 5.x-2.x-dev
Status: Active » Needs work

Sure thing Daniel, here's a patch against DRUPAL-5--2.

matt@antinomia’s picture

Patch attached this time...

Sutharsan’s picture

With this patch applied a non user/1 user looses the admin menu bar altogether.
This user has 'access administration menu' and 'display drupal links' permission. Without the patch the admin menu works as described above.

sun’s picture

Well, we might need to fork _menu_item_is_accessible(), because admin_menu forks the Drupal's complete menu tree and alters it afterwards. The core function might not work correctly, because admin_menu's menu tree also contains items that do not exist in the regular menu tree.

marcoBauli’s picture

the patch at #10 does not apply cleanly anymore. Tryed applying it manually, but still the Site configuration menu appears to unauthorized users (cleared cache_menu). thx

sun’s picture

Version: 5.x-2.x-dev » 5.x-2.6
Status: Needs work » Needs review
FileSize
1.37 KB

Well, I think I finally found a fix for this. Only applies to items below Site configuration, but AFAIK, that's the only location where I have ever seen menu items in DAM that are actually not accessible.

Please test.

marcoBauli’s picture

patch applies, and seems to work just fine.

@sun: here applies to items under every main administration menu, not just Site configuration. Thank you for this, very much needed!

sun’s picture

Thanks. It would be great to have another confirmation though, just to be sure this patch does not remove too many items it should not remove. Set to RTBC then, please.

matt@antinomia’s picture

@sun The patch removes the menu items for me.

...but, in my case it still does not work properly. I've done quite a bit of menu customizing, including moving the 'Comments' out of 'Content' so that it's a parent menu item rather than a child of admin/content. For users that can administer comments, the admin/content menu item still appears, generates a 403, and has no children. It's not critical and it's a special use case. Most people should not encounter this.

sun’s picture

@matt: Was that a confirmation that it works, or a report that it removes too many?

And, yes, edge-cases cannot be properly handled with D5's menu system. Consider upgrading.

matt@antinomia’s picture

@sun: I thought it was working properly but now realize that it is removing too many menu items, although I cannot determine a pattern. Perhaps this is also being caused by my re-organization of menu items?

sun’s picture

The provided information is a bit too vague. Can you please elaborate on some examples of items that you moved and are now removed?

travelerto’s picture

Version: 5.x-2.6 » 6.x-1.3
Category: bug » support
Priority: Normal » Critical
Issue tags: +inaccessible

same problem
my site is http://theological.asia/
i installed the module dfgallery but latter i did not liked it so i removed it following the normal procedure, modules>uncheck> etc and then i erased the directory dfgallery from the sites/all/modules. in modules it is ok, does not show up. BUT IN THE SITE CONFIGURATION MENU , STILL I SEE THE DFGALLERY MENU , when i press does not show anything.
(because i use the module boost, which runs fine, i copy the directory /sites/all/modules/dfgallery to /modules/boost/dfgallery as instructed by boost, during installation, )
i reinstalled it but using devel>reinstall modules, it worked but then the problem remains in uninstalling.
i did devel>menu rebuild , the same result, the entry dfgallery remains in site configuration menu.
i try to erase in the database but there is no entry, no table under this name.
i tried to erase by devel>variables, at the begining it show dggallery but no way to delete, so change the variable it had, now does not show up any more, but still exists in the site conf. menu!!!!!
i did empty cash ,repair and optimize database, same result
cron runs normally , every 6 hours.
please help me , what to do
thanks

sun’s picture

Version: 6.x-1.3 » 5.x-2.6
Category: support » bug
Priority: Critical » Normal

Please do not hi-jack existing issues. admin_menu 5.x works completely differently than 6.x.

sun’s picture

Version: 5.x-2.6 » 5.x-3.x-dev
FileSize
3.5 KB

Finally.

I am pretty sure that attached patch will kill this issue.

sun’s picture

Status: Needs review » Fixed

Committed to 5.x-3.x. Please re-open this issue if you still encounter this bug or anomalies related to this issue.

sun’s picture

Status: Fixed » Active

Meh. Core "reports" items below admin/logs/* are no longer displayed.

sun’s picture

Status: Active » Fixed
FileSize
1.38 KB

Committed attached follow-up patch.

Thanks for reading. :P

Status: Fixed » Closed (fixed)
Issue tags: -inaccessible

Automatically closed -- issue fixed for 2 weeks with no activity.