Hello- I realize that this module accomplishes things that others can. I have a site that has items restricted by taxonomy and based on various roles I have created- there is also not a menu item for certain roles. Not only can they not see it- they also cannot access it with the combination of taxonomy and this module, using only the "primary links" menu- this has worked flawlessly for me for some time. I recently updated to 6.x-1.8 and then after checking the new permission box, my primary links menu (all of it) was seen by all roles. I double checked the permissions that had worked right before the update but they have not changed. I have had to revert back to make it work. I did not try to recreate the entire menu as it did not make sense that I would need to. What is so different about 6.x-1.8 that it would update and work as is? This has not been a problem with updates before. I have been using this module successfully for some time.

Comments

Hi rkbreneman,

First, I'm sorry that it broke something on your site. Not the intend!

As for what has changed, I generally try to include the changes in the notes. http://drupal.org/node/945832

It is generally a copy of the CVS log messages. http://drupal.org/project/cvs/107330

Just for the record there are the changes I made. The two things I could think of are the optimization (1st entry) or the administrator permission (last entry) although that last one is very unlikely since you probably don't have all the users defined as a menu per role administrator. The problem with the INSERT and the DELETE would not have any effect until you edit a menu and since you said you did not do any of that, I would assume that's not the problem.

* Optimization #831760: Excessive database queries: Excessive database queries
* Added a test before the INSERT to make 100% sure that the row does not already exist (only for MySQL, in version 5.1.x it fails returning the matched count and returns the affected rows only, so if nothing changed it looks the same as if the row did not exist...)
* Enhanced the menu_per_role table management by deleting the rows that are empty (since empty is the default, we do not need to save those.)
* Fix for #769518: Error: duplicate entry 414 (INSERT INTO menu_per_role ...) -- dropping the default on the mlid field.
* Menu per role administrator are viewed as User UID 1 and thus see all the hidden menus.

So... first checking that the roles you are testing are not menu per role administrators would be a good thing.

As for the database queries, if it is not working right, then we need to debug them. That would be the only thing that could create a problem, although it looks like it works for me just fine... that doesn't mean it would work for everyone. As a test, you can search for the "Top Secret" menu entry on this page:

http://linux.m2osw.com/

You won't see it as an anonymous user.

Thank you.
Alexis

Alexis-

Thanks for your quick reply. This is strange. There may be a conflict with something else I have installed.

Steps I took:
1. Updated the module- Updated Database.
2. Checked "admin menu per role" for the administrator. (after this- no role saw any menu)
3. Checked "admin menu per role" for everyone- then everyone saw every menu.
(Keep in mind I have not changed any settings on my primary links menu that I had in place beforehand that worked).

I do have the Taxonomy Access Control Lite module installed to prevent roles from seeing content. Could that be a possible conflict? It has not been until now- but this is the only other thing other than core modules competing for roles.

I also rebuilt permissions but I think that is only concerning articles not menus?

I have also cleared site cache thinking that it would need that but I did not reset the database. Should I need to do that?

Just a note (not sure if it matters) I have 16 roles plus authenticated and administrator.

Sorry to trouble shoot this on this forum but not sure what else to do. I hope that this helps someone else or if anyone else has seen this error- please jump in!

Hi rkbreneman,

Just in case, I tested Tacle & Menu per Role and it works. So that's probably not it.

Tacle uses the Grant system of D6, indeed. Menu per Role just goes through the menu and remove items that are chosen as hidden via an Alter hook.

If somehow that hook doesn't get called then the Menu per Role would not be effective. Or if it's called at the wrong time? Hmmm...

First I mark all the links as alterable with this hook:

<?php
function menu_per_role_menu_link_alter(&$item, $menu)
{
 
$item['options']['alter'] = TRUE;
}
?>

Second you have the function that checks whether a menu item is enabled or not:

<?php
function menu_per_role_translated_menu_link_alter(&$item, $map)
{
 
// avoid checking the role if the item access is already false
 
if ($item['access'] && _menu_per_role_access($item['mlid']) === FALSE) {
   
$item['access'] = FALSE;
  }
}
?>

If the _menu_per_role_access() function always returns FALSE, then the entire menu would disappear. If you look at the function, I check UID = 1 first and if you are the all almighty god then you will see the menu item (return is not FALSE.) If not, then there is another problem. Same thing with the 'administer menu_per_role' permission test.

Are you a programmer? If so, you can test by adding code or messages to try to see what's happening.

<?php
  drupal_set_message
('Some message here', 'error');
?>

Thank you.
Alexis

Alexis-

I am a wanna be programmer. I have dabbled but not excellent at PHP and know my way around by goggling and finding specific cut and paste solutions.

rkbreneman,

Well... Wannabes are nice creatures 8-)

First of all, we could check to make sure that the menu link alter function is being called.

<?php
function menu_per_role_translated_menu_link_alter(&$item, $map)
{
 
drupal_set_message('Menu-Link alter called', 'error');
 
// avoid checking the role if the item access is already false
 
if ($item['access'] && _menu_per_role_access($item['mlid']) === FALSE) {
   
$item['access'] = FALSE;
  }
}
?>

If not, there is a conflict, somehow. For instance, the Simplemenu module does not call the system functions and skips on a certain number of callbacks at this time. That's one example of why this wouldn't work...

Thank you.
Alexis

I have also encountered this problem with update.

Did not realize at first because users with permissions to administer menu_per_role see the menu item.

However, the roles selected all but anonymous (by hiding from specific roles, anonymous) can not see the menu item.

Site does not use taxonomy access but does use organic groups.

This module has worked flawlessly before. Reverting to 6.x-1.7 resolves the problem.

Thanks,

Izzy

Would you please try to remove the user_access('administer menu_per_role') from the following and let me know whether that fixes the problem:

<?php
function _menu_per_role_access($mlid) {
  global
$user;
  if (
$user->uid == 1 || empty($mlid) /*|| user_access('administer menu_per_role')*/ ) {
   
// Admins do not lose access whatever this module would otherwise say
    // Also, if the menu link identifier is not set, ignore the request
   
return NULL;
  }
  [...]
?>

Thank you.
Alexis Wilke

Tested suggestion in #7 but it does not fix the problem.

Izzy

I see there is now another issue Menu's not appearing for roles which is describing the same problem. I am not sure if this or the other should be marked as duplicate.

Izzy,

Do you have problems with any role or the Admin (UID #1)? Because the "fix" in #7 does not prevent the admin from seeing everything still since there is still this test:

<?php
if ($user->uid == 1 ...
?>

Making that part of the test a comment would help...

<?php
function _menu_per_role_access($mlid) {
  global
$user;
  if (
/*$user->uid == 1*/ || empty($mlid) /*|| user_access('administer menu_per_role')*/ ) {
   
// Admins do not lose access whatever this module would otherwise say
    // Also, if the menu link identifier is not set, ignore the request
   
return NULL;
  }
  [...]
?>

My apologies for the lack of clarity in #6.

The test case is a primary menu item that is a link to a group home page that is public (og).
The menu path = node/... for the specific group home page.
The menu_per_role module is used to hide this menu item from anonymous users and one other role.
With version 6.x-1.8 the menu item is still visible to anonymous users, it is not hidden.
Version 6.x-1.7 and earlier worked fine.

I hope this is more helpful.

Thanks,

Izzy

All of you... would you mind to list the modules that you are using on your website? I'm thinking there could be some conflict.

Also, if you could find the time to test 1.8 with a Drupal Core install and see whether that works for you as you'd expect and report your results here, it would be paradise! 8-)

Thank you for your time.
Alexis Wilke

@AlexisWilke, ok I was able to test 6.x-1.8 on a vanilla Drupal 6.19 install and it works.

To test,
User permissions: anonymous users can access content.

Create page or story:
Title "Hello",
Body = whatever text,
Menu title = Hello,
Parent = Primary menu.
Restrict visibility:
either show to only authenticated
or hide from anonymous

Both work. The menu item is hidden from anonymous users.

So, now the big task of finding the conflicting module(s) that is happy with 6.x-1.7 but breaks 6.x-1.8

I'll see if I can test a simple og install and report my findings.

Thanks.

Izzy

I have re-tested the use case described in #11 again and the upgrade from version 6.x-1.7 to 1.8 does indeed work. The site has og and many other modules.

I am now trying to identify if there is another use case that caused the problem and was the basis of the post in #6. I'll report back my findings.

Izzy

Izzy,

So... I'm not going completely crazy here... 8-)

og is often the culprit, but I'm not too surprised that this is not it on this one. This is not a permission problem. It's linked to roles.

The main change comes from someone else although I made it even better (his idea was excellent to start with!). The function is the one used to retrieve the set of role ids before matching them against the user roles. I would think those are what has an impact. It is quite optimized in 1.8 (in comparison to 1.7.)

The database is the same (nothing changed there.)

Alexis

Alexis,

No, you are not going crazy. And I'm sorry to have contributed to the grief. At least you can start the New Year with less stress. Now I have the grief of trying to understand the hiccup I encountered six weeks ago.

Is there any caching that might give an initial temporary failure, not that I have good evidence that is happening?

Izzy,

Note that according to the stats, a little over 3,000 people use 1.8. So if there was a major problem, I think I'd know about it by now... 8-)

Thank you & be well.
Alexis Wilke

ok, call me a yo-yo. There is a bug and it is reproducible.

Using the setup in #13

test 6.x-1.8 on a vanilla Drupal 6.19 install
To test,
User permissions: anonymous users can access content.
Create page or story:
Title "Hello",
Body = whatever text,
Menu title = Hello,
Parent = Primary links.
Restrict visibility:
either show to authenticated
or hide from anonymous
Both work. The menu item is hidden from anonymous users.

The acid test is to remember that the menu should not be hidden from roles other than anonymous.
Login as an authenticated user, or other role but not one with permissions to administer menu_per_role and voila, the menu item is hidden - not visible !

If you login with a role that has permission to administer menu_per_role the menu item is not hidden and you may be misled to thinking things are working as expected.

My apologies for not being on top of this earlier. This is the problem I was attempting to describe in #6. It is easily reproducible.

Izzy

Izzy,

I think I'll just call you Izzy. The problem is that the menu information is not saved on creation of a node. I had not understood another bug report I got, that's what the problem is. If you re-edit the same node and look at the settings, you'll notice that it is not set... Set it then, save and it will work.

The fix might involve a patch to Core... 8-P

Thank you.
Alexis

Assigned:Unassigned» AlexisWilke

Okay. Got it. 8-)

We had to implement a hook_nodeapi() function to properly save the menu per role information on an 'insert'.

Version 6.x-1.x-dev will include the fix. I will do an update to 1.9 once you confirm that this works for you too.

Thank you for your patience!
Alexis

http://drupal.org/cvs?commit=472710

In answer to #19, checking the node again the settings appear correct and even after saving again the problem persists and menu item is not visible to authenticated users, so it is not just a problem on node create but I did notice some issue with settings not taking consistently on node creation during my testing.

I will test the new dev version and report back.

Thanks.

Alexis,

I have tested the new dev version on a vanilla Drupal 6.19 install.

I think there are two separate issues.

#1009944: Changes to visibility aren't being saved which may be fixed by the change.

However, this issue is not fixed.

The crux of this issue is that menu_per_role must both hide the menu item from some roles and allow it to be visible to others. That is not happening. It is hiding the menu items from roles (e.g. anonymous), but also hides the item from all roles expect those that have permission to administer menu_per_role. It works fine in version 1.7

I hope this helps to identify where the logic change is.

Thanks,

Izzy

Izzy,

Let me make sure that we both agree on what is supposed to happen:

Parameters:

* User A is a member of role P
* User B is a member of role Q
* User C is a member of role P and Q

* Menu item X is marked as hidden to role P
* Menu item Y is marked as visible to role Q
* Menu item Z is marked as hidden to role P and visible to role Q

What is visible:

User A sees menu item Y. X and Z are hidden to P and thus from A.

Use B sees X, Y and Z.

Use C sees Y. X and Z are hidden to P and thus from C.

Notice that Z is hidden from C even though it says "visible to role Q". This is because the "hidden to role P" has priority over the "visible to role Q". There is no option to change this priority.

In that regard and as far as I know, version 1.8 is supposed to have the same logic as 1.7.

Thank you.
Alexis

Never mind... 8-)

I posted a new patch on the other issue, but it most certainly (again) is the same problem.

Thank you.
Alexis

I'll check out the new patch.

Meanwhile, the simplest view of the problem might be,

Create a node as a menu item or select a menu item.
Restrict visibility to hide from anonymous users only and save.
All other roles should be able to see menu item when logged in.
Roles with permission to administer menu_per_role do see menu item as expected.
Other less privileged roles, such as simply authenticated, should see the menu item but do not.

Yes. and the following would create an entry with an array including the key [0] which is the anonymous user.

<?php
  $v
= explode(',', '');
?>

Which is a problem when we expect the array to be empty (i.e. array() instead of array(0 => '').)

Thank you.
Alexis

Status:Active» Needs review

Yes, the dev version of Jan 3 works !

Just tested it on the vanilla Drupal testbed and will now do more tests.

Thanks.

Izzy

Status:Needs review» Reviewed & tested by the community

Alexis,

The new dev version also works on complex site with og and much more.
I'm going to be bold and change status to RTBC.
Thanks.

Cool, I'll wait a week or so to see if anyone else says they still have problems similar to this one.

Thank you for your patience and time for testing the changes.
Alexis

Would it help to change the title of the issue to something more descriptive of the problem, maybe something like:

"When updating to 6.x-1.8 Menu per role, menu items also hidden from other roles not selected"

Title:When updating to 6.x-1.8 Menu per Role stops workingUse of "hidden from role" menu items in 6.x-1.8 causes Menu per Role to stop working (fixed)

Well... I think there is a mix between the two bugs I've fixed between this issue and the other one. There seems to really be another problem with that other menu module (menu_access).

Anyway, I went ahead and changed the title. I guess we will soon close this issue and keep the other one open. I may test with a fresh install and menu_access to see if I can reproduce problems with it.

Thank you.
Alexis Wilke

Status:Reviewed & tested by the community» Fixed

Okay, all of that should be in 6.x-1.9

Please, create a new issue if you still have a similar problem as this issue is already quite long and it has been reported as working.

Thank you.
Alexis Wilke

Status:Fixed» Closed (fixed)

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