Role-dependent authorizations (OP)From a user point of view, a role represents a functionality in a company. In LN ’s Authorization Management System (AMS), a role represents a set of authorizations for a functionality in a company. User authorizations that are defined by role instead of by user significantly reduce the redundant data. The authorizations for normal users are, therefore, defined in roles to which the authorizations can be linked. The role concept provides you with a user-friendly method to quickly add new users or to update user authorizations. Because an employee can have more than one functionality in a company, you can assign the user to more than one role. A role can also contain more than one sub-role, which itself can also have sub-roles. All these roles and sub-roles form a role tree, which you can view with the role browser. The role browser shows the role tree in a graphical user interface. Ultimately, the employee’s role is a combination of all the authorizations defined in the user’s roles and sub roles. Recursive role structures are not allowed. For example, a junior software engineer cannot have the authorizations of a senior software engineer in a sub role. This diagram shows an example of the combined authorizations of two different roles:  Example of combined authorizations for more than one role
For example, a department manager has more responsibilities than the employees in the department and therefore has more database authorizations. Consequently, the manager has two roles:
The restrictions on the table authorizations of the two roles are combined for the department manager. If the table authorizations are restricted for one role but not for the other role, the department manager will ultimately have permission to carry out the database actions. Role-dependent authorization types in LN You can define the role-dependent authorizations at the following component levels in LN: If the role-dependent authorizations change, conversion indicators are automatically set. Changes to the session authorizations, table authorizations, and the library authorizations are only converted to the run-time data dictionary when the conversion indicator is set to avoid unnecessary conversion of the authorization data to the run-time data dictionary. Session authorizations The session authorizations define which sessions the users can start and what the users can do with these sessions in LN. You can specify the session authorizations and on several levels for either a specific company or for all companies. For example, you can give the users authorizations for only specified sessions in a module or only the sessions in a specified package. The session authorization priorities in the following table show that the session authorization with the highest priority (1) is stated at the most specific level and the lowest priority (8) is stated at the most global level. The session authorizations that you define for a specific company have a higher priority than those defined for all companies:
You can define the session authorizations with these sessions in LN ’s AMS:
Enhanced AMS (the ‘classic sessions’ ttams3xxx are replaced)
Table authorizations The table authorizations define the actions the users can perform on specified database tables and the associated fields in the database table. You can specify the table authorizations for a specific company, or for all companies, and on several levels. You can give the users authorizations for specified tables in a module or only some table fields in a database table and so on. The table authorizations that you define in LN ’s AMS are applicable to the databases for which the user is authorized. You can define the databases for which the user must be authorized in the RDBMS Administration module. For more information about the LN ’s table authorization, see the “RDBMS administration” section. The table authorization priorities in the table show that the table authorization with the highest priority (1) is stated at the most specific level and the lowest priority (14) are stated at the most global level. The table authorizations that you define for a specific company have a higher priority than those defined for all companies.
You can define the database-table authorizations and the database-table-field authorizations with these sessions in LN ’s AMS:
Note Table field authorizations and Table Field Data Authorizations have no effect on reports. If a user has no authorization at all for a table field, the field is still printed. The database table field authorizations (1 – 4) only relate to the fields on the form and have no effect on the database table authorizations (5 – 14) and are handled by 4GL. Library authorizations LN uses the Business Object Layer (BOL) integration technology, and OLE, DDE, OCX, and ORB interfaces to integrate programs with the LN environment. These programs communicate with LN through the Dynamic Link Libraries (DLLs). The Library authorizations define whether the users who are linked to the role can access the functions that are defined in DLLs. Note For details on the Business Object Layer (BOL), refer to To Model a Business Object in the Infor Enterprise Server Web Help You can specify the library authorizations at several levels. For example, you can give the users authorizations only for specified libraries in a module or only the libraries in a specific package and so on. The library authorization priorities in the following table show that the library authorization with the highest priority (1) is stated at the most specific level, and the lowest priority (3) is stated at the most global level:
You can define the library authorizations at the various levels with these sessions:
| ||||||||||||||||||||||||||||||||||||||||||||||||