This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 . It is not the current version, and thus it cannot be edited.

Back to current versionRestore this version

DEFINE ROLES#

The Define Roles (IMRO) form is used to view system supplied roles as well as create and update customer defined roles.

You need to establish the roles that will be used to identify what users who are attached to the role will have access to. You can assign a user to more than one role. The only time that the Default toggle needs to be turned on and the password filled in is if the role will need to have access to utilities external to the application (e.g. SQL).

All roles should have a role type, and you shouldn't try to do anything outside of that type with that role.

Every user requires a business role to make use of the application. It is suggested that you create a base business role that can be assigned to all of your users and then extra roles can be added to meet your additional needs for the application.

There are several types of roles that will be used and each has a separate purpose and use in the application:

Business Role#

A business role must be defined. This role is required and typically will set the web menu that the user will have access to when they log into the application.

We have specific roles for business levels that used for setting the menus and controlling access underneath that business function.

Clerks who are also the HR Clerk and PR clerk can be set to have the two different independent roles which the clerks can switch between via the menu. The security access beneath that is set to point to those business roles so they're only invoked when that role is in focus.

Execution Role#

Roles with Execution type are the only ones with execution rights. The Execution Role type is set up in order to give the user access to various functions within the application.

Database Security Role#

Basically, there are two database roles that are supplied by HLC:

P2k_user

everyone has this

P2k_database

for only those who have database administrator capability

There might also be a role for Discoverer users to be used for access at the database level. The only reason you'd make a Database role type is when the control or functionality for a role is controlled at a database level.

Object Security Role#

The Object Security role defines for the specific users what fields they can see on a function, further defining the function. For example if there is no need to have a field displayed on a screen that field can be removed using Object Security.

This will be explained further during the discussion of Field Security (IMFOS).

SS Role #

This role is obsolete.

The definition data for the Define Roles screen is stored in the P2K_AM_ROLES, P2K_AM_PREFERENCE_VALUES,P2K_AM_USER_ROLES,P2K_AM_EXECUTION_RIGHTS, and P2K_AM_SECURITY_VALUES table.

Role Name

This field holds the actual name of the role.

Role Type

This field allows you to classify the role into a specific category.

Description

This field provides a short description of the role.

Password

This is the password the system will use to access external applications, such as, SQL*Plus or Discoverer. Although this is an optional field, it is required if this role has been marked as a Default Role.

This password has nothing to do with the Personal Identification Number (PIN) that employees will use to access the application.

Changed On

This field will display the date the password was last changed.

Changed By

If the password has been changed, this field will indicate the user who last changed it.

Default Role

If you select Yes in this field, the current role will become your default role. Default roles are used in programs OUTSIDE of the eP world, for example, Oracle, Discoverer and SQLPlus.

This means that if a user who has this as a default role, logs into other programs, they will be given access to information according to the rights and responsibilities of this role.

If this role is not selected, the user will not be a member of that role outside of the application.

Most roles used in the application should not be setup as default roles, however, the 'P2K' user must have all roles assigned to it as default roles.

---

Preferences tab#

Preferences for roles depend on the type of role. Most are set only for a business roles, not database roles, etc. For example on the Employee role, www_employee, you can set the preferences for the web splash, change the colour for the web theme, or allow query.

Preference

If the role has any preferences associated with it, you may define those preferences in this field. A list of preferences is maintained in the pop-up menu for you to select from at this time, however, there are only two preferences that are applicable to the roles in Self Service:

Open in Safe Mode	This preference will require any users operating in this role to click the `EDIT' button before making any modifications to data within the Self Service. The Open In Safe Mode preference is exclusive to roles (and specifically Web Module Roles) and may not be attached to other items such as functions or users.
Web Menu	This preference allows you to attach a specific web menu (created in (IMMU)) to the role. This means that when a user logs into Self Service in this role capacity, they will be presented with the menu defined here. You may select only one web menu for each role. The Web Menu preference is exclusive to roles and may not be attached to other items such as functions or users.

Priority

This field allows you to define the order in which the preferences will appear. Although at this time none of the preferences you might select would occur at the same time, preferences developed later may need a sequential order.

Value

The details of the preference are specified in this field.

For example: Preference Value OPEN IN SAFE MODE YES WEB MENU ESS MAIN

---

Users#

This tab allows you to see which users have been granted this role. This tab also provides the name and other information on the person.

The default tab only really needs to be set for the database assigned roles.

---

Execution Rights#

This tab is used on only for the execution rights role. For Execution rights roles, the Execution Rights tab defines the functions that this role will be able to access and whether they will be able to Create, Retrieve, Update or Delete within that function.

---

Data Security#

Data Security refers to the information within the field and is set up on the IMSV screen to say what data someone can or cannot see. For example if only US lexicon values should be displayed for the Ethnic field on IEPI we can use Data Security to secure off this information so it's not visible to the user CLEANUP

‘Define Roles’ Usage and Examples

Define Roles (IMRO) - Preferences Define Roles (IMRO) - Users

You may assign this role to specific users through the Users tab. Seq User This field is used to identify the users to whom the current role is assigned. (Mandatory) Default Role If this toggle is checked, the role will be the default role for the user. Person Code This field identifies the user by their person code within the system. Last Name This field identifies the user by their surname. Define Roles (IMRO) - Users This section allows you to grant execution rights to all users assigned this role. Function This field indicates the function you wish to provide execution rights for. Create / Retrieve / Update / Delete Allowed These toggles allow you to indicate the specific execution rights you wish grant to the user or role.