About Building Menus

The My Desk menu object contains an additional menu object that represents the submenu for each installed application. Each of these submenu menu objects is in turn assigned a command or menu (to define another level of submenus) object for each link in the submenu.

The My Desk menu displays as on the global toolbar. This graphic shows a sample administrative object structure needed for an installation that has Engineering Central and Library Central.

You can use Business Modeler to build the menus. Submenus and commands are created first, then added to a higher-level menu on the Items tab (in Business Modeler), or by using the equivalent MQL code. See the Business Modeler Guide for details on defining menus and commands.

Similarly, the definition for the Actions menu object should include a menu object that represents the submenu for each application. Each submenu should be assigned a command object for each link in the menu. In this example from Engineering Central, the ENCActions menu is connected to the Actions menu on the global toolbar. It has 4 menus connected to it as children (it could also have commands connected if appropriate), and then each of those 4 submenus has several commands connected to them.

You can define user access to menu commands.

You can use the Access Expression, Accesss Mask, and Access Program/Access Function settings to determine whether the context user has access to an object. In this case, the object is a menu command.

The above settings return a true or false value. When true, the context user has access to the command. When false, you can use the Access Behavior setting to define whether the ENOVIA application hides the command (the command does not show in the menu), or disables the command (the command shows in gray in the menu and cannot be selected). The default setting is hide.

If a command that has child commands or submenus is disabled, the command shows in gray and cannot be expanded to access those children/submenus.

For some commands, such as Delete, if the user does not have delete access, you may want to hide the Delete command. For other commands, such as a Demote command that is not available for an object in its current state, you may want to disable the command. The user cannot access it when disabled, but knows that the functionality is there.

If a user does not have access to a command based on their Role instead of the above listed settings, then the Access Behavior setting is ignored and the command is always hidden.