removing items from the manager menu bar

OK I have managed to remove the elements and files tab from the left of the interface using access policys.

I can make unwanted fields on the resource creation and update not visable using custom forms.

All I need now is to remove some of the top level menu items from the top menu, mainly tools, reports and system for a given user group.

I can not find anything in the wiki to do this i know the topic has come up a few times but with no answers.

Is this doable and if so where do I need to be looking.

Quote from: peteedley at Feb 16, 2010, 10:52 AM

OK I have managed to remove the elements and files tab from the left of the interface using access policys.

I can make unwanted fields on the resource creation and update not visable using custom forms.

All I need now is to remove some of the top level menu items from the top menu, mainly tools, reports and system for a given user group.

I can not find anything in the wiki to do this i know the topic has come up a few times but with no answers.

Is this doable and if so where do I need to be looking.

This can be done in the SVN/rc1 versions by using the ’permissions’ field (where you can specify a comma-delimited list of permissions to restrict by). It is not available in beta5.

At the moment, Security is the only top-level menu that has a Policy Permission associated with it in the default data installed with the core. For the moment, you can add a Policy Permission to the Administrator Policy (a Context ACL Policy) and then use that Permission to specify in the permissions field (this can be a single permission key or a comma-delimited list of them) for the menu item when you right-click and Update Menu from System -> Actions in the Top Menu tree.

I’ll add a ticket in JIRA to add default policy permissions for all the menu items that do not currently have them, but let’s discuss here what those permissions should be called...

OK thanks guys got that working, just loving the whole flexibility of the security in revo, really confused me at first but thanks to bobs guide at http://bobsguides.com/revolution-permissions.html I am now begging to get. But back to topic if by naming you mean like you have with the security one access_permissions. Then this is what I have just added to mine.

site_menu_access
components_menu_access
tools_menu_access
reports_menu_access
system_menu_access, etc

This works for removing top level menus, but I am assuming that the same is doable for individual items on a menu so say I want to remove system settings from the system menu but leave the rest i would apply a permission to the system settings menu, I would then for this use

system_menu_settings_access
system_menu_actions_access , etc

this could end up with long permission names but seems to follow some sort of logic.

If i’m completly wrong on the naming issue then can you please explain more as to what you mean.

Quote from: peteedley at Feb 16, 2010, 12:08 PM

OK thanks guys got that working, just loving the whole flexibility of the security in revo, really confused me at first but thanks to bobs guide at http://bobsguides.com/revolution-permissions.html I am now begging to get. But back to topic if by naming you mean like you have with the security one access_permissions. Then this is what I have just added to mine.

site_menu_access
components_menu_access
tools_menu_access
reports_menu_access
system_menu_access, etc

This works for removing top level menus, but I am assuming that the same is doable for individual items on a menu so say I want to remove system settings from the system menu but leave the rest i would apply a permission to the system settings menu, I would then for this use

system_menu_settings_access
system_menu_actions_access , etc

this could end up with long permission names but seems to follow some sort of logic.

If i’m completly wrong on the naming issue then can you please explain more as to what you mean.

Well, that’s what needs to be determined; currently, many menu items use the existing permissions that relate to that action, i.e. access_permissions is used, not access_permissions_menu_access. Some just didn’t have any defined that made sense to use to hide that menu item. I think it would be better to use permissions without the menu_access suffix, that can be tied to some action that might occur from other trigger points (i.e. a front-end editing component, or a custom manager page) besides the top menu item.

But that’s why I wanted to discuss.

I’ve hidden them by just adding a custom permission to whatever is there in System | Actions (in the current SVN version) and not giving it to people you want to hide the menu items from. For menu items with an existing permission, just add a comma and the custom permission.

I think it’s a better method because removing any built-in permissions from policies could theoretically have side effects if those permissions are used elsewhere.