Previous Next

In functional terms, a role is a capacity in which a user makes use of a USoft application.

For example, people could "do Sales things" in an application because they have the "SALES" role. Other people could "do Marketing things" in that same application because they have the "MARKETING" role.

It is also possible to allow people to do both "Sales and Marketing things" by giving them both roles. If you have Marketing people, but also a different group of people who should have access to Marketing things only as a reader, you probably want to create some additional role, perhaps named "MARKETING_READER".

In more technical terms, a role is a collection of resources that people have access to if and when they are associated with the role. A role gives them the right to access the resource. A resource may be a data element, a job, or an (RDMI) component.

The only way in which a user (a client) can have access to data, jobs and components is through roles.

A USoft application always runs either with "merged roles" or with "distinct roles". With "merged roles", users who have multiple roles automatically have access to all the corresponding resources at the same time. With "distinct roles", they have access to one role at a time, so they need to be given a means to switch to a different role.

Roles may be associated with specific menus, submenus, or menu options by working with First Menu Pages. Menus are a way of guiding users to whatever resources they have access to. Menus are specific to USoft GUIs.



The only way that USoft clients have access to data, jobs and components is through roles. Menus are a GUI aspect of roles.

NOTE: In earlier versions of USoft, roles (then called "user groups") were associated only with data and menus. Access rights to jobs and components are a new feature in USoft 10.0. In many existing USoft applications, a job's purpose is ultimately to query or manipulate data: the job is a "way in" or access path to the data, and people had the right to execute the job because they had the right to access the data. The two layers are now separate. Because of the versatily of components, which open the door to any coded world, a component right can mean just about anything: its (indirect) goal may or may not be related to application data. It is likely that in the future, there will be more and more job rights and component rights that primarily control access to functionality rather than to data.



collapseOverview of access rights
collapseAccess right dependencies
collapseHow to understand access right dependencies


See also

Table rights

Column rights

Role conditions

Merged roles

Job rights

Component rights

Module rights