Role Permissions

Role permissions are defined by assigning a set of application resources to a role using Role Permissions Maintain (36.3.6.5).

• For component-based functions, role permissions control the ability to use the various types of activity—create, modify, view, and delete, for example.

Note: Access control can also be defined for fields, sites, GL account updates, and inventory movement codes using user ID, role, or a combination. For details see Setting Up Additional Types of Security.

The application resources defined in the system display in a tree layout similar to the way the menu looks in the .NET User Interface. To define role permissions, you select the resources to assign to the role. Once role permissions and role membership have been defined, when a user opens a workspace, only the application resources associated with that user role display on the application menu. When a user has more than one relevant role, the application resources that display are essentially the sum of the user roles.

Example: Sophie Woods has been assigned the roles Project Manager and Accountant. The Project Manager role allows her access to the Customer View function. The Accountant role allows her access to the Customer Invoice Create function. Consequently, the following menu choices display when she logs in:

The role-based security that is defined for a function also applies to any associated functions that are available on the Go To menu for which a user has been granted access. For example, if you are modifying data in the Customer Invoice Create function, the Go To menu for that function displays related functions—Daybook Create, for example—for which you have appropriate permissions.

Role-based security also applies to parts of the system that do not have a user interface—for example, Web services and API calls, as well as daemons. For more information on daemons, see QAD System Administration User Guide.