2

We have several roles. Each user is allocated to one role only.

Each user has a separate menu area - e.g. 

user 1 - Profile
       - Product
       - Press Releases - release 1
                        - release 2


user 2 - Profile
       - Product
       - Press Releases - release 1
                        - release 2

What this question is NOT about:

It is not about restricting access to post by role (that is too blunt an instrument)

It is not about restricting access to view by role or individual user.

What this question IS about:

As the number of members increases, the "pick list" of menu items will become unmanageable. It also, of course, means that it is possible, for whatever reason, for users to post to someone else's area. We therefore need to lock each user's posting access to his own user account (in menu terms [user1] or [user2] and its subtree). Each user should not see, in the select box, menus that he cannot post to.

We need to allocate users to specific menu subtrees, presumably through either restrictions or permissions.

What does not work:

module: Menu subtree (applies to roles only)

module: Menu access (it crashed the site resulting in forced database maintenance)

module: User Permissions (it applies the standard permissions module for individual users, it does not add additional permissions.)

Node/content type: inserting a field - we can't see any way of importing the specific menu subtree that we want and, even if we could, we can't see a way of making the correct menu subtree appear for that specific user.

Any and all ideas are welcome!

Improve this question
4
  • Is there any specific need that forces you to actually use menu system for this? Or you just need menu-like output? And is the structure of that menu identical for all users, or can be changed at will?
    – Mołot
    Commented May 17, 2013 at 8:26
  • Hi, it's a very specific requirement for a site where individual users will manage their own content which is "filed" within their own collapsible menu. If it helps, it's at www.pitchmybook.com. As you can see, users complete their own e.g. book data (with extracts appearing as a further level down), media releases, etc. A nested menu system is, I think, the neatest way of achieving this.
    – Pete Jackson
    Commented May 17, 2013 at 9:05
  • I know some ways to make it look and work as you want, but without default menu implementation. If you decided to expand menu system functionality, I cannot help. That's why I asked in the first place.
    – Mołot
    Commented May 17, 2013 at 9:08
  • Thanks, Molot. I'm open to alternative suggestions. There's always more than one way of solving a problem, especially with something as flexible as Drupal. My reason for following this path is that, when the user posts within his area, he will select exactly where in the structure his entry goes. Basically, the end result I want, is that when we create the user, we set a flag that says he can post only within the structure headed [user1], but he has to be able to choose which sub-section (and below) he can post in.
    – Pete Jackson
    Commented May 17, 2013 at 9:11

1 Answer 1

Reset to default
0

Drupal's menu module is pretty good thing, but written with simple cases in mind.

Solution without using menu system:

  • Create a taxonomy tree representing the part of menu that gets repeated for each user
  • On node creation, omit menu altogether, let user choose taxonomy term from a tree instead
  • Use Views to render it all as one big tree, theming it so it would look like a menu

Added benefit is that you can easily move elements from user to user, allow users to change their names etc and it just works, no need to edit same thing in 2 places. And you can rename "menu element" once, in taxonomy, instead of "once per user".

Improve this answer
4
  • Yes, the menu system is excellent and ironically does exactly what we want - it just does too much of it! With, say, only 250 members each having only four entries, someone posting a new item would have to fish through 1000 member entries, and that's not including all the admin stuff. I'll get the techies to have a look at those ideas. Thanks for your help.
    – Pete Jackson
    Commented May 17, 2013 at 9:19
  • Let us know if this answer worked for you, when they'll finish with it.
    – Mołot
    Commented May 17, 2013 at 9:24
  • Molot - before I give this to the techs who are in a different time zone, I have a couple of what are probably very stupid questions. First: we still need the menu structure (or something that works in an identical way) for visitors to be able to find their way through the information entered by users. The expandable menu is the most convenient way for this within the design parameters of the way people use the site. How does your solution preserve this? (again, if you look at the site, you'll see exactly what I mean). Secondly, how does the user created content become attached to those menus?
    – Pete Jackson
    Commented May 17, 2013 at 11:44
  • You can put literally anything in HTML template looking like a menu, and being a menu from a UX perspective. Users->terms->nodes combination may be templated using .tpl.php files to give you identical html output as a menu you have now, if you want to. It might take some time to get it right, but it most definitely can be done.
    – Mołot
    Commented May 17, 2013 at 11:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.