Best Practices for New Groups and Menus (Menu Copying?)

[viiiwonder]

I am embarking on setting up some groups for our internal support and engineering staff to be a member of. We have a few experienced PBX admins in our ranks who I don't mind being superadmins, but also want to provide access to engineering for tenant turnups and sysadmins to mostly just view. I believe I have a good understanding of groups and 'protection' of custom groups (not sure that 'protection' is actually required of custom groups?)

I have two areas of inquiry:

1. Is there anything in particular you would consider if doing this yourself in the group permissions for either use case? My plan thus far seems to be:
   1. our SysAdmin (or 'lower') permission group will mostly just have global 'view' rights for most items - restricting the add/edit/delete for the most part. We would like them to assess, and confer with an engineer prior to making changes/having changes made.
   2. our Engineering (or 'higher') permission group will have restrictions on various system-wide items such as global defaults, need to figure out how to restrict permissions to modules such as Provision and Script editor, as well as restrict access to other big-ticket items such as SIP profiles
2. Menus. I'm hoping I'm just 'missing' something here, but this seems very arduous to deal with.
   1. I can create other menus under 'Menu Manager', but I'm not sure how they are actually used. There is the 'Menu' setting under default settings which looks like it's going to change the menu for the whole system. That also implies to me that I could change the menu for a single domain, but that's not really what I want to do.
   2. I have discovered that if I want to have a custom menu Parent and Menu items that it seems best to create a new parent, and menu items, protect them, and restrict them to the group that we want to 'see' that particular parent and items. (use case: we have customer accounts whose only purpose it is to log in is to send and receive faxes, so we have a group for that, as well as custom menu parents/menu items in our default menu restricted to those groups.)
   3. This just seems like it would take a monumental amount of work to set up new menus that would be presented to the two groups above, with the added complexity of them needing to be protected/updated for future releases/features.

Am I thinking about this wrong or am I missing some critical part of menu management?

I browsed through the public and member documentation, even scanning the chapter markers in the admin and advanced training videos. If the documentation for this exists, I would gladly take the link to it, or if you have any thoughts on the subject, your response is appreciated!

 

[markm]

Were you able to figure out how to have a different menu show up on login based on user/group assignment? I am running into same thing.

 

[viiiwonder]

Oh yeah, I think I know how to do it... but it's just tedious - hence my inquiry here. If you want the default menu items to still be eligible for being updated during the update process, you can't 'protect' them, instead, you have to replicate them (the menu items and the parent menu items, not the entire menu definition), and protect your copy. E.g.:


Maybe I'm overreacting and the right way is just to protect the original menus after making changes to their groups, but I'd be unsettled that some update in the future would prevent it from being updated. ("Protected" = prevent the 'update' process from modifying)

I keep hoping the devs will come along and clarify this for me and/or explain a better way. I haven't seen a whole lot of good documentation around the menus.

 

[whut]

Protected menus items and sub-menu items are exempt from updates and restore default in the code behind. But there is some oddness when a menu is protected and a submenu is not protected, and the other way around. Your approach to creating new menu and sub-menu and protecting them is currently the best approach in my experience.

 

[hfoster]

It's so much easier I have found to just create another menu, and assign that to the user/domain in question. That way, you don't have to mess with the default menu.

 

[viiiwonder]

It's so much easier I have found to just create another menu, and assign that to the user/domain in question. That way, you don't have to mess with the default menu.
View attachment 3286

Yeah, this is more graceful for sure. I had made a new menu other than the default, but it didn't occur to me to go assign that menu to either a domain or the user. (heck, I didn't even realize that this 'User Settings' section existed...). I'll give this a shot for my objectives.

Now we just need the ability to copy menus and bulk edit menu items... all my Pull Requests have been about provisioning... might actually have to look at the UI code base and see if I can contribute.

(BTW, the nomenclature around Menus is frustrating: the word 'Menu' can mean 3 different things in Fusion: the Menu SET, the Parent Menu Items, or the Menu Items)

 

[hfoster]

One word of caution, make sure your users stick to US English. I wondered why a few people were getting blank menu bars, and it transpired that people had switched their language to UK English.