Hi all,

what's the plans for an upgrade to drupal 6?

Thanks!

Comments

Jonathan.Cochran’s picture

I am also interested in this. Let me know if I can help test at all!

Thanks

physiotek’s picture

subscribe

fago’s picture

Probably there will be a 6.x version, but I don't know when. I hope that it's possible to remove the patch with 6.x, but I had no look at it yet. If someone wants to lend me hand, just do it - I'd appreciate it.

chiddicks’s picture

I'm interested in doing this. Please see my comment here: http://drupal.org/node/196582.

hutch’s picture

I have had quick look at your comments on http://drupal.org/node/196582 and I'll have a bit of a think about it. 8-)
The module should write to it's own table, and only that table plus any variables in the variable table. That way when it is removed the hooks are gone and everything slides back to where it was.
The existing table maps mid to rid or menu_id to role_id and I reckon that is what we need.
I have converted several small modules recently so I can help with that.
The existing code, just at a quick glance looks easily convertible, the patch actually enforces the rules and that is the hard part.

Anyway it's late, more later

chiddicks’s picture

I agree - it would be ideal not to interfere with other DB tables. However, I just don't see how that would be done without the patch to menu.inc. There's no other hook we can take advantage of to modify which menu items are drawn and which are not, at least as far as I can see.

I'm not a theme expert - could we accomplish this through a theme hack of some kind?

Yes, the module itself would be pretty simple to convert to D6, but core patch would have to change, since the architecture of the menu.inc file has changed. I'm hoping to kill two birds with one stone in terms of the D6 update and the core patch.

hutch’s picture

Assigned:Unassigned» hutch
StatusFileSize
new1.43 KB

I have attached a tarball that installs menu per role on D6.
It inserts the fieldset into the menu item edit form and writes the settings to db
It DOES NOT WORK otherwise.
I am trying to fathom the new menu system, any input welcome!

fago’s picture

thanks!

I had no look at your code yet, just wanted to let you know that I appreciate your work. Unfortunately I have no time for it right now, but I'll comeback to this probably on Wednesday.

@approach: using hook_menu_alter is definitely the way to go. If possible we should keep the original access and only grant access if we grant access *too*.

Some first thoughts about how we could tackle this for 6.x:

Perhaps we can make a new callback function, and add the original callback function as well as its arguments to our function - then use that to invoke it and only when it grants access, we do our own checks. Ideally we do db access only when writing the menu item definition so that on runtime no db call is needed.

->
our_function ( granted roles, original callback function, originial arg1, originial arg2 ,..)

hutch’s picture

@approach: using hook_menu_alter is definitely the way to go.
I'm not sure that it is, it is used by the module it's in to manipulate it's own menu items.

The old code patched the _menu_build() function. The D6 version of menu.inc has a candidate function, _menu_router_build()
As far as I can see it saves the callbacks and access arguments to the router table. The old menu effectively saved one menu per user online. The new one does the lookups for access permissions and page callbacks dynamically.
We may need to look at how the menu is fetched, after it has been cached and alter things on the way out.

more later

fago’s picture

@hook_menu_alter:
Why should it be only for manipulating own items?
I think its intended for alter items of other modules. Anyway, to avoid we should set the module weight of menu_per_role to a high value.

So why should we patch _menu_router_build() when we can have a clean version without patch? Furthermore we should make use of caching - a db lookup for each page view is not ideal. This can be also done by using hook_menu_alter.

fago’s picture

Status:Active» Fixed

So I've done some work on this and ported it like I described it. Seems to work well. You can find the code in the newly created 6.x branch.

What's still missing is a check for external URLs, as the module won't work with them and a README update. When I've done this, I'll create a first dev release.

Please test it.

fago’s picture

hm, this doesn't really suffice - as it would allow configuring access just per router item. e.g. node/4 would configure access for all node view callbacks - not really intuitive.

To fix this, I'd tried to create additional menu items if necessary. However when this should work, we need to get the original menu item. I tried to do so, but my first approach failed as the menu_router table is empty when menu_alter is run.
So we need to save the item in a new own table so we can get it when menu_alter is run from that table. The admin interface needs also be adapted to reflect the changes. (settings per link_path, not per router_path).

I've no time left for this right now, so I've just committed my first not working approach - so you can proceed if you want. I probably won't have time for this for a week or so.

hutch’s picture

Well you have got further than I did.
I agree that no patch is best, but I'm not sure how.
The menu rebuild functions write the menu to cache, but the decisions about wether or not to display are made on the fly on the basis of the current user's access permissions and roles. This is the point at which we need to butt in and add our filter. Where that is in the code I don't know yet, I will have a look as soon as I can but that might be a few days.

chiddicks’s picture

A module like Node privacy by role might be worth looking at. It allows individual role permissions per node. One of the by-products of this is that menu items will disappear if the user does not have access to the linked content. I'm not sure if this is the module or the menu system at work, but somewhere along the line this module is indicating that the user should or should not have access to the menu item. I'll look further into it and see if I come up with anything interesting.

fago’s picture

yes, drupal uses node access for these menu items - so for this items it's preferred to use node access. This makes me think if there is still a need for menu_per_role to cover other cases?

Lenn-art’s picture

i can imagine some situations where an user with a specific role needs his/her own menu with 'public' links. For example a moderator wants a menu with
* latest users
* track
* newest posts etc
All these links are public. A normal visitor has to digg somewhat in the site to find these links. The moderator wants these links 'immediately'.

chiddicks’s picture

Status:Active» Fixed

Oh yes, there is still a place for this module. As you say, it's not necessarily just about managing access to content. I would say that the most important ability of this module is molding the user interface - from something generic, perhaps confusing, to something that is streamlined and carefully thought out.

fago’s picture

Status:Fixed» Active

hm, I'm not sure about that any more.

@Lenn-art: For this one probably better creates an own menu and restricts access to the block showing it. This module would change permissions for the pages itself, not only for the links.

I think I'll finish the content access port first and test how well it covers this use case. If someone else wants to takeover developing this module - just ping me.

icouto’s picture

Please, please, please, do NOT stop development of this module. This is most certainly needed in D6, and beyond. I will give you a couple of reasons:

1) Drupal does not hide/show its *own* admin menu items properly
Right now, I am configuring a site, where there will be a single "Site Admin" - who manages everything in the site - and a handful of "Site Editors", whose job is simply to add content to the site. The Site Editors are NOT very internet savvy, and Drupal's admin interface, with its tens of options on every page, scared them. I have been trying to 'dumb down' the menus, leaving absolutely *only* the ones required for the editing, for the 'site editor' role. I have, for instance, removed all permissions that have anything to do with User Management for the 'site editor' role. Nevertheless, when a Site Editor logs on, the "User Management" menu IS STILL LISTED! - even though it has nothing in it. The same thing happens with other items in the Administer menu (Site Building, Site Configuration). And it also happens in modules that access the Administer menu (Drupal Admin Menu, Simple Menu, etc.) - see this issue: http://drupal.org/node/296693. So, if this module were able to set 'by role' restrictions on these menu items, that would save us MANY MANY hours of work and headache.

2) Even outside Drupal's built-in admin menus, there are *many* situations in which I would like to create menu items accessible only by certain roles. Let's say, for instance, that I have a 'job searching' site, where employers can post job offers, and registered users can search. I might setup a View page, where anonymous visitors can search, but do NOT see the full contact details for the poster. I would like registered users, however, to have access to a *different* View page - one that lists the full contact details of the job poster. Of course, I need the menu link to look the same, and be in the same menu, but to have different results based on the visitor's role. Trying to do this by using block visibility, as suggested above, is an absolute nightmare, if not downright impossible.

One has to admit that the functionality of the module "Remove Non-Viewable Menu Items" (http://drupal.org/project/remove_nonviewable_menu_items) is very, very helpful, and that some of that functionality *should* be copied over into THIS module. Ideally, in order to overcome Drupal's own shortcomings, and provide the Site Admin with the uttermost flexibility in configuration of the menu, it would be best to give the user an OPTION for menu visibility:

[ ] Show menu for these roles only:
[ ] ...
[ ] ...

[ ] hide menu if not allowed to view target <--- functionality from 'remove non-viewable items'

So, pleeeeeeeease, do NOT stop working on this module! Your work IS very much appreciated and needed! :-)

Babalu’s picture

Status:Fixed» Active

subscribing

mainebob’s picture

#19 icouto: Made an passionate plea back in August for creating "...menu items accessible [Visible] only by certain roles..."

YES! I need this *NOW* for my current projects and want it for Drupal version 6.x

Is this being actively worked on? or is there another way to accomplish this Menu Item/Role function?

I like the theme ROOPLETHEME.com because of their "suckerfish" menus... and the Roopletheme
developer today said:

===copy
Re: Suckerfish Menus based on Roles
« Reply #1 on: October 01, 2008, 08:45:55 PM »
There are a lot of ways to do this, but none of them are out-of-the-box simple. If you use any of the user access modules (TAC, TAC-Lite, etc.) that restrict access to content, and you then use the menu option on the node edit form to add the content to the menu, then you'll get the behavior you describe. This is the best solution. There's also the Menu Per Role module, but it hasn't been upgraded for Drupal 6.
===end copy

Thanks!

hutch’s picture

The reason that Menu Per Role has not been upgraded to D6 is that the 'hooks' that were present in the menu module for D5 are not to be seen in D6.

The advice given by the Suckerfish people is as good as it gets, use one of the access modules.

daniorama’s picture

Hello, I'm not sure that the content access modules are a good solution for everyone. If we need the same content shown in some menus we cannot select all of them on the node edit form. Also putting content access modules and OG together could be a bit messy.
Would a menu item be shown if its linked node is protected by content access module and it was linked by the path field in the menu item edit form and not the menu field in the node edit form? (oh man, that question sounds so confusing...)
As many other people said before, it would be a pity to lose this module in Drupal 6, it's very helpful and needed.

bejam’s picture

subscribing

majortom’s picture

Priority:Normal» Critical

I am not sure the sucker fish solution works for me. I need to have several menu items all with the same name do different things based on role (i.e. an authenticated user gets one page, an anonymous user gets a different one). I do not understand how one would accomplish that with the other suggestion.

I cannot upgrade my site to D6 without that option.

fago’s picture

You can even create several menu items, which will be only shown if you have sufficient access permissions for the underlying node page.

Let me give an example:
Install content access,
enable per content node permissions for your content type, e.g. page,
create a page and add one ore more menu items for it,
then go the the page, click on the access control tab and customize access for it.

That's it, the menu item will only appear if the logged in user has access to the underlying page.

fago’s picture

Update to the port: As noted on the project page I'm not going to port the module as content access already covers altering permission for links to content nodes. If someone else wants to takeover developing this module - just contact me.

majortom’s picture

That's it, the menu item will only appear if the logged in user has access to the underlying page.

That is fine that direction, but it now means that one needs to create different versions of various pages if one wants different menu items to have different permissions.

In other words, if one does not care if the underlying content is visible, only which menu item is visible, this solution does not work. For example, one might choose to post a URL in a message and want everyone to be able to get there, but on the main site, one might want the menu for anonymous users to suggest they register first and then take them to that page. Etc.

Oh well.

Thanks any way for a great D5 module.

momper’s picture

@#28 - excactly this i need .... so +1 for the drupal 6 version ...

thanks for this nice module momper

momper’s picture

Title:Drupal 6?» Menu per Role: Drupal 6?
ramper’s picture

This would be a great feature to have, on a regular basis - for all Drupal versions. So I hope some kind soul(s) steps forward to release a D6 version. Just the ability to show or hide certain menu items for different roles introduces so much flexibility in maintaining a site. So here's one more request!

AlexisWilke’s picture

Fago,

Okay! I got it! 8-)

I thought that it should be doable and that the Drupal people should have done it already. And they have. Now I'm not too sure why it isn't documented (well, never mind, I'd bet it is, simply put: it's so well hidden that pretty much no one knows about it!)

So... the default themes should probably include that feature, and yet they don't. Add a link to login as follow:

user/login

And that's it. It will NOT show up once you are logged in.

So in other words we do not really need yet another module for that one.

Hope this helps a few people...

Fago, I suggest that you put that information in your paragraph under "Drupal 6:" on this module definition. You already explain the other nodes, adding this info (i.e. user/login, user/logout, user/register and user/password all work.)

So... the only one I still have a problem with is "My Account" which requires the user identifier (user/%uid). That is not auto-handled. But that is less of a concern to me since if you are not yet logged in or registered, that page appears instead!

Thank you.
Alexis Wilke

jrowny’s picture

Alexis, I don't really understand what you mean about adding a link to user/login? I guess I'm still kind of a n00b.

What I still need this module for is
#1) an external link. What if you want a link to an external site to show up for only certain roles? Since it's not anything to do with content access, I don't know how to do it.
#2) Cart Links! I've got "pay membership" button that goes to Ubercart's cart-links. I can't seem to get node-access to work here.

It will be my first time developing a Drupal Module, but I might give a port to D6 a shot since this would still be a nice feature to have for easily customizing menus.

AlexisWilke’s picture

jrowny,

When you want to have menu entries named "Log In" and "Log Out", you probably want them to appear/disappear depending on whether you are already logged in or not. If you just use "user", then you will be taken to the login screen when anonymous, but that link will not disappear once you are logged in. Some people have had problems in that regard.

For external links, yes. I guess it would be useful. On the other hand, I do not see why you would need that for an external link since your users could find those sites by other means. But it is correct that there is otherwise no control (unless you create a page with the actual external link?)

The cart links, I'm not too sure what you are referring because you will usually protect the page and the link will be hidden if the page is protected (i.e. not currently accessible by the user.)

Note that what is presented in #7 is a good start. The setup is done. "All" you would need to add are the necessary tests to know whether the menu is to be shown or not.

Thank you.
Alexis Wilke

jrowny’s picture

I've almost got it... I am an idiot and just did everything that hutch did in post #7 on my own! But I guess it's a good thing because it is my first time writing a module and I learned how to do all this stuff. So, I'm almost there!

jrowny’s picture

StatusFileSize
new8.38 KB

OKAY! I did it, unfortunately, I don't know how to give it to you all... so here's my attempt. Attached is a zip (I don't even know how to make a tar-ball in windows)!

You also need to make this edit:
In includes/menu.inc starting at line 455 in the function _menu_check_access(&$item, $map) , add this:

if (module_exists('menu_per_role') && !is_null($access = menu_per_role_access($item['mlid']))) {
      $item['access'] = isset($item['access']) ? $item['access'] && $access : $access;
   }

Leave everything else how it is. In D6, each item has a callback function to check its access. After that runs, then this goes and checks the menu_per_role system. I'm sure this IS NOT THE BEST WAY! however, this is my first ever module-adaptation... or actually my first contribution of any kind!

Please help me improve it. Thanks!

jrowny’s picture

One final note, I had to modify the module itself because my admin user could no longer see the links I edited! I fixed it below:

function menu_per_role_access($mlid) {
  global $user;
  if($user->uid==1){
return true;
  }else{
$rids = menu_per_role_get_roles($mlid);
//NULL means inherit access from parent item
return count($rids) ? count(array_intersect($rids, array_keys($user->roles))) : NULL;
  }
}

This says "if the user's id is 1, then always return true".

AlexisWilke’s picture

jrowny,

Very cool, I worked a bit with your version and an earlier version. There is now a complete package that works. I did not test extensively but it looks pretty good.

Note: I made many changes, especially, I made optimizations to the code (specifically, I only save ONE row per menu items instead of one per item x role.)

WARNING: I changed the name of the access function because the named used before could interfere with the default access hook.

I will check that in later, it's already very late here! 8-) But I will put a tarball in the next message as an attachment.

Thank you.
Alexis Wilke

AlexisWilke’s picture

Assigned:hutch» AlexisWilke
Status:Active» Needs review
StatusFileSize
new8.64 KB

Note: this is a patch for Drupal 6. At this time, the version is limited to 5.x.

Okay! Created the new release entry. It will be available within the next 12 hours.

AlexisWilke’s picture

Version:5.x-1.x-dev» 6.x-1.x-dev

Marking this entry with Drupal 6 version.

Once the new module is visible in the project, I will close this issue and you can create new issues for whatever problem you get.

Thank you.
Alexis

Salimane Adjao Moustapha’s picture

looks like the patch do not work for drupal 6.7. well the patches are also marked as 6.6.... so any modifications for 6.7 ?

#edit actually it doesn't work for drupal 6.6 too after applying all the patches. any info i should provide ?

AlexisWilke’s picture

unclesamlive,

It could be that I do not create my patches properly. I installed 6.7 just now (in includes security fixes!) and checking the patches (regenerating them) did not make any different other than the dates.

These are very small and you could just edit the files so you get things going.

Otherwise, what do you do to apply the patches? (what command line, tool...)

Thank you.
Alexis

#edit -- I actually just checked the docs and I do it right according to the docs:

diff -up original.php new.php > filename.patch

See here: http://drupal.org/patch/create

AlexisWilke’s picture

Status:Needs review» Fixed

I'm marking this fixed as we have a new entry now.

Thank you.
Alexis Wilke

hobbes_VT’s picture

@#26: It might be to wrong place to post this here, but some developers browse all versions to find answers.
A quick note for those who still work in D5.x: content access does not affect the menu, thus you still have menu items that lead users to an "access denied" page. To make the menu items hidden as well, you also need to install module http://drupal.org/project/remove_nonviewable_menu_items

AlexisWilke’s picture

hobbes_VT,

I have updated the front page so that way people know why they would possibly need this module with D5.

Thank you.
Alexis

Status:Fixed» Closed (fixed)

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