Empty admin categories are not hidden
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | menu system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | Needs Documentation |
Under Drupal 6(.4), even if a role has *no* User-Management related permissions, the "User Management" menu does not hide - it still shows, with no items under it. Selecting the menu takes the user to a page that simply states: "You do not have any administrative items."
It seems to me, that the menu simply should not be present.
To reproduce, using a brand-new D6.4 installation:
1) login as the site's superuser, and create a new role - name it anything you wish
2) In the 'permissions' page for the new role, make sure the role has *no* user management permissions - under "user module", deselect everything.
3) create a new user for the site, and give this user the newly created role
4) log out as the superuser, and login as the new user, with the new role
5) notice that under 'Administer', you still have "User Management" - clicking it will take you to that silly page that states that you have no administrative items...
This is a *very* annoying bug. I do *not* wish the "User Management" menu to be displayed for certain roles - ie., 'site editors', whose function is simply to add and edit content to the site.
#1
The same problem is also reproducible for the "Site Building" menu - ie., even if the role has no permissions for any of the menu items in the menu, the menu itself is still displayed. I suspect the same thing might happen also for the "Site Configuration" menu.
This *is* a serious problem to me, as one of the main tasks I have when setting up a Drupal site is to 'dumb down' the admin interface for newbie users. Not being able to easily hide these menus means that the interface ends up being overly complicated for low-level admin users - like site editors, who have no business managing users, or playing around with the site configuration.
Currently, the only way to overcome this bug is to split the Administer menu into several menus (one for each role needed), and use the BLOCK permissions for each menu block individually. In my case, for instance, I ended up having to split the menu into "RegisteredUser", "SiteEditor" and "SiteAdmin" menus. This is not a proper solution, it is a time-consuming, inelegant hack. I end up with 3 or 4 separate menus, containing totally related functions that had to be split in order for me to be able to control role access to them - when they really should be under just a single menu.
I do not need several different menus. I need just ONE menu, that properly restricts its items' visibility according to the user's permissions.
I hope this will be fixed for D7.
#2
That issue has been identified several months ago. Here is a first patch for it.
#3
Confirmed this problem. Would be nice to back-port fix to 6.x as well.
Steps to reproduce:
- Create a role called "editor" and an "editor" user assigned to that role.
- Give the role both "administer nodes" and "access administration pages" permissions.
- Log in as "editor" and go to "Administration"
You'll see entries for Site building, etc. in the navigation menu even though those result in "Access denied" when you try to go there. See attached screenshot.
Let's get tests with this patch though to make sure this bug doesn't recur.
#4
The code in #2 uses
system_admin_menu_block()which does allot of extra stuff then is necessary to determine if there are children. Plus_system_settings_accessdoesn't seem like the right name for the access callback for two reasons.1) It could be used by contrib, no need for private declaration (_).
2) It relates to other items besides settings.
In my attempt at this in #263616: Move SimpleTest out of "Site building" I used the following code:
<?phpfunction system_admin_menu_block_page_access($path, $string) {
if (user_access($string)) {
$count = db_result(db_query("SELECT COUNT(mlid)
FROM {menu_links}
WHERE plid = (
SELECT mlid
FROM {menu_links}
WHERE link_path
LIKE '%s'
)", $path));
return ($count > 0);
}
return FALSE;
}
?>
Which alleviates the call to the other function.
Should think about the name of the function. The reasoning behind my choice is that the items that only display a list of children use
system_admin_menu_block_pageso it would only seem nature thatsystem_admin_menu_block_page_accesswould be used for them.#5
@boomatower: Ok for the name change, it makes sense and I don't really care :)
The objective of using system_admin_menu_block() was to limit code duplication and database queries as most as possible. Your solution was not enough, because we also need to check for access of each menu item, not just count them.
I turned that issue around over and over, and came to the conclusion there is no better way.
#6
I forgot to add: "... but of course, I only want to be proven wrong!"
#7
Working on writing the test, and a few cleanup items along with it.
#8
Thank you, everyone, for your superhumanly quick response to this!
I was wondering, if we are going to see a back-port of the fix in D6, as mentioned by webchick.
#9
Adds test and changes access callback name per #4 and #5.
@icouto: Depends on what this is considered. If this is considered a bug/or necessary feature then it most likely will be. It would be useful as SimpleTest 6.x-2.x would use this and I'm sure there are others, not to mention default use-cases as per #3.
The test needs assertLink and assertNoLink: #297894: Add assertLink and assertNoLink to SimpleTest
which requires: #297869: Add xpath method to Simpletest and refactor existing tests
Will need those to get in first, but we can still review this patch. (although you will need to apply those.)
After patches applies test passes.
#10
After applying the above patches and then applying this one tests pass.
#11
Ran entire test suite with all passes.
#12
Still applies after dbtng.
#13
There is a bug with the last patch :
1. Give anonymous user these permissions :
access administration pagesandadminister blocksoraccess site reports.2. Clear cache
3. Logout
4. Go to admin page >> Access denied, and no menu link
5. Refresh >> Notice error :
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'system_admin_menu_block_page_access' was given in D:\Serveur\www\drupal\7.x\includes\menu.inc on line 502.
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'system_admin_menu_block_page_access' was given in D:\Serveur\www\drupal\7.x\includes\menu.inc on line 502.
#14
Hmmmm...two interesting things:
It would seem the issue is in the existing code not the new code, but yet it works without the new code....
When I run the site as anonymous I get:
error PHP Fatal error: require_once(): Failed opening required './includes/database/mysql/query.inc' (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in .../drupal-7/includes/bootstrap.inc on line 1399, referer: http://drupal-7.dev.loc/#15
There are three bugs here:
* Drupal don't use absolute paths for loading include files, and the current path can change, especially during the execution of shutdown functions. This is solved in #259623: Broken autoloader: convert includes/requires to use absolute paths. Please try that patch.
* Access control on /admin don't work properly, probably because system_admin_menu_block_page_access() recursively calls itself. For now, I disabled that access control on /admin.
* Hide descriptions/Show descriptions toggles didn't work for anonymous users (it was relying on a $user parameter). I changed this to use session for anonymous users.
#16
Not to be overly picky on code comments, but:
+ * Ensure that menu items that without "visible" children are hidden.An extra "that" or something?
+ * The path of the menu item to ensure has children.Something's not quite right there.
I see this is another good use of compact mode, which I wholeheartedly approve. We don't use setting enough.
These are minor, so I'll leave at CNR and you can take care of them during the next substantive re-roll.
#17
The last submitted patch failed testing.
#18
Subscribing and marking for later review. Administration menu module users are suffering from this.
#19
Here is an updated patch which applies against HEAD and fixes the comments in #16. It's working as expected for me.
#20
- Renamed menu item access callback to system_admin_menu_block_access(), since the additional "page" suggested that it would be used for determining access to a page, but we are just checking admin block/category access here.
- Optimized system_admin_menu_block_access() to check for the user permissions first.
- Removed all changes related to compact mode, as those are unrelated to this issue. (please create a new issue, since the changes make sense)
- Renamed test case.
Also ran tests, tested manually with a test user (and having admin menu module installed) and everything seems to working properly.
#21
This is a annoying bug - better title.
#22
Changes in #20 make sense, but this is an old patch, and its test doesn't comply at all with our (relatively new) Test Writers Guidelines.
<?php
}
}
+class AdminMenuBlockTestCase extends DrupalWebTestCase {
?>
^^ Missing PHPDoc above the class.
<?php+ /**
+ * Implementation of getInfo().
+ */
+ function getInfo() {
?>
^^ We don't PHPDoc overriden functions anymore.
<?php+ return array(
+ 'name' => t('Admin menu categories'),
+ 'description' => t('Confirm that administrative categories, which do not contain any visible child items, are not displayed.'),
+ 'group' => t('System'),
+ );
+ }
?>
<?php+
+ /**
+ * Ensure that administrative menu items without visible children are hidden.
+ */
+ public function testEmptyHide() {
?>
^^ The PHPDoc description should probably better start with test*...
testEmptyHide() is a badly choosen function name.
As an end note: it's quite fun to shoot down one of your own old patches :)
#23
After a BIG support session with Damien in IRC, this should (hopefully) be properly. :) (Thanks again!)
#24
FYI: Damien moved the compact mode fixes to #352734: "Compact mode" switch doesn't work for anonymous users...
#25
The last submitted patch failed testing.
#26
#27
The last submitted patch failed testing.
#28
While working at #362834: Move statistics out of the administration pages and add permissions I noticed that MENU_ITEM_GROUPING has not been added to the new menu system in D7. As a result, we now have several functions that do pretty much the same. node_add_page() and system_admin_menu_block_page(). I think node_add_page() is a good candidate for a new MENU_ITEM_GROUPING. It needs some changes, but then it will do fine (See the patch in #362834).
However, that patch is not complete yet, since it displays a MENU_ITEM_GROUPING parent item even if there are no child items or if the user has no permission to access any of its child items. This is the point where chx told me to check out this issue.
<?php
/**
* List a menu item's children.
*
* @return string
*/
function menu_item_grouping() {
$item = menu_get_item();
$items = system_admin_menu_block($item);
// Bypass the listing if only one child is available.
if (count($items) == 1) {
$item = array_shift($items);
drupal_goto($item['href']);
}
return theme('menu_item_grouping', $items);
}
/**
* Theme a list of menu items.
*
* @param $items
* The items as returned from system_admin_menu_block().
*
* @return string
*/
function theme_menu_item_grouping($items) {
$output = '';
if ($items) {
$output = '<dl class="menu-item-grouping">';
foreach ($items as $item) {
$output .= '<dt>' . l($item['title'], $item['href'], $item['localized_options']) . '</dt>';
$output .= '<dd>' . filter_xss_admin($item['description']) . '</dd>';
}
$output .= '</dl>';
}
return $output;
}
?>
#29
The attached patch reintroduces MENU_ITEM_GROUPING as a menu item type. Such menu items automatically get a page callback that lists all the item's children, or redirects the user if there is only one child.
See this patch in action at /node/add. See anything different? No? Exactly!
By the way: node_add_page() and similar obsolete functions have not yet been removed to keep this initial patch simple.
#30
The attached patch also performs access control and should hide the item if a user has no access to child items. All issues pointed out in #29 are dealt with. I haven't yet tested the patch thoroughly, but it seems to work. Will do more testing as soon as I'm done with my other work here.
To do: display a message if there are no children to list.
The code responsible for the access check:
<?php
/**
* Determine if a user should have access to a menu item.
*
* Users should only have access if all of the following cases are true:
* - The user has access to at least one of this item's children.
* - The custom access callback (if any) returns TRUE.
*
* @param $path string
* The path of the menu item to check access to.
* @param $callback string
* A custom access callback to check as well.
* @param $arguments array
* Arguments to pass on to the access callback.
*
* @return boolean
*/
function menu_item_grouping_access($path, $callback, $arguments) {
if (is_string($callback)) {
$custom_access = call_user_func_array($callback, $arguments);
}
$item = array('path' => $path);
$items = system_admin_menu_block($item);
foreach ($items as $child) {
_menu_check_access($child, array());
if ($child['access']) {
if ($custom_access) {
return TRUE;
}
else {
return FALSE;
}
}
}
return FALSE;
}
?>
#31
Benchmarks?
#32
I have split the patch in two. After #363951: Reintroduction of MENU_ITEM_GROUPING gets submitted I'll post a new patch taking care of access control here. This will make benchmarking easier.
#33
subscribe
#34
Suscribe using Drupal 6.10.
Will drupal fix this to 6 version or will it be a solution for Drupal 7?
#35
Subscribing too, if a Drupal 6 backport is on the cards.
#36
Subscribing.
#37
Subscribing and looking forward for d6 patch
#38
Since #363951: Reintroduction of MENU_ITEM_GROUPING won't be committed (marked as won't fix), does this mean we're back to the patch in #20 above?
#39
Rework of #23 (no longer applied and outdated).
drupal_static().admin/development.admin/development.#40
Patch looks good and works quite well. However there's still one edge case that isn't covered - if the user has the 'access administration pages' permission, but doesn't have access to _any_ of the sub menus, and if the help module is not enabled, then the 'Administer' menu item still appears in the navigation block and the message "You do not have any administrative items." appears when clicked.
It's an edge case (why would anyone give that permission to a user without giving them access to at least one sub-menu?!) and the message displayed is useful, but shouldn't that menu item not appear at all?
#41
Actually this also change also needs to be implemented for the new top level admin menu
admin/internationalin locale.module#42
I am not sure that is an issue since technically there is a menu item under "Administration". When help module is disabled the Administration menu item still displays. I attempted to add the check the the root "admin" item, but it causes an issue, possibly due to excessive looping.
Not sure we want to deal with that issue or perhaps save for follup patch. Either way this patch contains admin/international alteration.
#43
I think it's good to go as is, just to summarise what this patch does:
system_admin_menu_block_pageand gives it the params: path (e.g. 'admin/build') and the access permission.#44
Yes. 'admin' & 'access administration pages' we need to tackle elsewhere.
#45
Kick ass! I'm so happy to finally see this fixed! :D
Committed to HEAD! Marking "needs work" until it's documented in the 6.x => 7.x upgrade page.
Ultimately this is up to Gábor, of course, but given what was required to fix this in 7.x, I'm pretty sure we can't backport this to 6.x. It's an API change that requires module developers to make changes to their menu items' access callbacks. In addition to this being a mean thing to ask people 1.5 years after D6's initial release, it will result in hackish "if function_exists" workarounds in order for this to work for people not using the latest versions of Drupal 6. Granted, it'd only affect the handful of modules that define their own top-level admin blocks like OG, Panels, and Project. But still. Stable means stable.
#46
Documentation added: http://drupal.org/node/224333#system_admin_menu_block_access
#47
The last submitted patch failed testing.
#48
Guess I'll just mark fixed unless anyone says otherwise.
#49
Followup patch: #475348: Move admin/development menu category into system.module
#50
Automatically closed -- issue fixed for 2 weeks with no activity.
#51
should any fix be expected for drupal 6? In a different issue maybe?