Role-Based Menus

Topics: Administration, Announcements, Core, General
Feb 1, 2012 at 3:16 PM

Why is it that I cannot associate a Role to a menu option?  It seems like this should of been a basic feature of the Orchard CMS framework from the beginning.  Doesn't it seem to you all that we are complicating things doing it any other way??

In most every CMS I have ever looked at (or written), you create a navigation menu with some menu options that are available to the general public and others that are available to an Admin role.  The "protected" menu options would have a role of "Admin" assigned and would only appear once the authenticated user ID with the Admin role logs in.

I cannot believe that I am the first one to notice or complain about this.

There are always lots of ways of doing things and I am sure I will hear from plenty of folks who have implemented Orchard sites with Layer Rules, etc, but this seems like a basic thing when it comes to CMS functionality.  Nearly every CMS I have looked at provides role-based security at the menu level.  Why would you want to have to dig through layer rules to figure out who/how someone has rights to a specific menu option?

 

Feb 1, 2012 at 5:26 PM

Technically you can assign permissions to menu items via INavigationProvider. But the default front-end menu UI doesn't support this. However the back-end admin menu does use permissions and you'll notice that users with different roles get a different set of menu items depending on what they can do.

The thing is, it's not so good from a design perspective to have an interface where you can assign roles to menu items. Orchard works on a complex set of permissions, and roles are just groupings of those permissions, really you always want to target the permissions rather than the named roles directly. That way if you ever change the roles, everything will still work based on the underlying permisisons. But you don't want to display the entire list of permissions in the menu UI, it's really quite a big list.

It'd be much better to have an automated solution where Orchard checks the content that's actually linked to and whether the current user has view permission for it. Actually, this is one of the things my Quanta module was meant to support, but I never quite did it properly ... will be fixed and in my next release after 1.4. So even if core doesn't change, you'll be able to do this with a module. But also, I'm pretty sure "improving the default menu" is at least one of the things being considered for 1.5 (hopefully someone will correct me if I'm wrong!)

Coordinator
Feb 1, 2012 at 5:41 PM

"It seems like this should of been a basic feature of the Orchard CMS framework from the beginning": you have no idea how many different things this exact sentence gets applied to by different people. Almost everyone has a different idea of what should come out of the box. This is why CMS matters: it lets you add exactly what you need and nothing more to a core that is only there to enable new features to be added.

"I cannot believe that I am the first one to notice or complain about this": no you're not. The way this works is that if someone needs a feature badly enough, they build it and make it available for others. But until that happens, well, tough, it's not there. If you need it, build it. That's pretty much open source: there is no entitlement. Sorry :)

Aug 10, 2012 at 6:08 PM

Hi,

first of all, I can't say it enough but Orchard is fantastic - great work everybody!!

I just wanted to ask if the new Content Item Permissions in 1.5 support role based menu items?

Thank you!

Best regards,
Johann

Aug 10, 2012 at 6:10 PM
Edited Aug 12, 2012 at 7:59 PM
codepunkt wrote:

Hi,

first of all, I can't say it enough but Orchard is fantastic - great work everybody!!

I just wanted to ask if the new Content Item Permissions in 1.5 support role based menu items?

Thank you!

Best regards,
Johann

Sorry, forgot to mention: I am talking about front end.

BR,
Johann

Aug 18, 2012 at 10:39 PM

I don't think so...unless I'm doing something wrong.

I added the ContentPermissions part to the CustomLink content type (since the items I want to secure are all custom links). I then went to Navigation and checked off Anonymous and Authenticated so that they weren't authorized to View on the menu items that I wanted to secure.

Looking at the front-end of the site while not logged in, I still see those menu items. So, my guess is that the ContentPermissions don't apply to menu items at this point...unless of course I didn't apply it properly, which is entirely possible.

Is this something that is possibly planned for a future release so we can use ContentPermissions to secure Menu items on the front end?

Coordinator
Aug 20, 2012 at 5:29 PM

Yes, it works, but there is a bug for Content Item links. The bug is already filed and a patch has been provided.

Aug 20, 2012 at 7:12 PM

Sebastien...did the bug apply for CustomLinks as well?

Aug 24, 2012 at 7:44 PM

Hi Sebastien,

are we talking about the following work item http://orchard.codeplex.com/workitem/18861 or some other bug?

BR,
Johann