Customizing the Workspace Menu

The Workspace Menu is the menu accessed by clicking and holding the right mouse (Menu) button on the background of the workspace. Using the Customize Menu and Add Item to Menu options on the Workspace Menu is the same as in the base CDE window system, with some Trusted Solaris protections.

The following apply when a user is allowed to work at multiple labels:

• The user must use the Customize Menu and Add Item to Menu options in a workspace labeled at the session clearance. Changes made at other labels than the session clearance are not recognized by the window system.

  If a user is able to log in at multiple labels, the user has the potential for multiple session clearances during different login sessions. Therefore, make any changes at each of the potential session clearances if you want the changes to apply to all potential login sessions.

• The user makes the changes in a normal user workspace.

• When the user assumes a role, changes to the Workspace Menu persist.

• Changes made to the Workspace Menu are stored in the user's home directory in the single-level directory (SLD) created at the working label. The label should be the same as the session clearance. The items in the Workspace Menu are stored in the .dt/wsmenu directory within the user's multilevel (MLD) home directory in the SLD that corresponds to the working label.

  For example, to change the Workspace Menu when the user's only possible session clearance is NEED_TO_KNOW ENG, the user would go to a workspace labeled NEED_TO_KNOW ENG. If the user adds an item to the Applications menu using the Add Item to Menu option, the item would be stored in /home/username/.dt/wsmenu/Applications.

  The pathname above corresponds to the real MLD path shown below, where .SLD.3 in the example is the SLD that corresponds to the NEED_TO_KNOW ENG label for user barbar.

  /home/.MLD.barbar/.SLD.3/.dt/wsmenu/Applications

• The profile mechanism must enble the user to run the action.

  Any option added to the Workspace Menu must be handled by one of the user's rights profiles or the option will fail when invoked and an error message will display.

  For example, anyone with the Run action can double-click the icon for any executable and run it, even if the action or any commands it invokes are not in one of the account's rights profiles. By default, roles do not have the Run action, and all executable actions require the Run action, and therefore, any item that requires the Run action fails when executed by a role.