This page (revision-26) was last changed on 26-Nov-2021 10:22 by RForbes

This page was created on 26-Nov-2021 10:22 by Administrator

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note
26 26-Nov-2021 10:22 8 KB RForbes to previous
25 26-Nov-2021 10:22 7 KB RForbes to previous | to last
24 26-Nov-2021 10:22 7 KB JEscott to previous | to last
23 26-Nov-2021 10:22 7 KB JEscott to previous | to last
22 26-Nov-2021 10:22 8 KB JMyers to previous | to last
21 26-Nov-2021 10:22 8 KB JEscott to previous | to last

Page References

Incoming links Outgoing links
IMRO
IMRO

Version management

Difference between version and

At line 4 removed 3 lines
Roles are identities created and assigned to a user profile to allow employees to access the system in different
capacities, such as employees, managers or system administrators.
At line 9 removed one line
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).
At line 11 changed one line
All roles should have a role type, and you shouldn't try to do anything outside of that type with that role.
You need to establish the roles that will be used to identify what users 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).
At line 13 changed one line
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.
All roles should have a role type, and you shouldn't try to do anything outside of that type with that role. There are several types of roles that will be used:
At line 15 removed 2 lines
There are several types of roles that will be used and each has a separate purpose and use in the application:
At line 24 changed one line
!Execution Rights Role
!Execution
At line 27 changed 10 lines
A starter execution rights role called P2K_MASTER is provided, and must be assigned to the P2K user. With every load of the full seed data the rights assigned to this role are re-built so as to include the latest functions and the correct rights as per the function. This role must ALWAYS be assigned to the P2K user but should only be given to other users while the system is first being setup. You should be creating your own Execution Rights roles and grant them to your users with the specific functions they need.
Each function supplied comes with the maximum Execution Rights it is designed to use defined on it. The Execution Rights to be granted to a User/Role are limited to this.
Each form definition on [IMFD] has a section called Form Table Usages which has the maximum Execution Rights defined for each table used in the Form these should not be changed.
!Database Security Role
Basically, there are two database roles that are supplied:
;[P2K_USER]:everyone has this
;[P2K_DBA]:for only those who have administrator capability
!Database
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
At line 39 removed 5 lines
!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)].
At line 47 changed one line
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] tables.
!Object Security
The Object Security role defines for the specific users what fields they can see on a function, further defining the function.
At line 49 changed 10 lines
;[Role Name|ROLE_NAME]:This field holds the actual name of the role.
;[Role Type|ROLE_TYPE]: This field allows you to classify the role into a specific category.
;[Description|DESCRIPTION]:This field provides a short description of the role.
;[Password|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|PASSWORD_CHANGED_DATE]:This field will display the date the password was last changed.
;[Changed By|PASSWORD_CHANGED_BY]:If the password has been changed, this field will indicate the user who last changed it.
;[Default Role|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 Personality 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.
%%information 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.
For example if there is no need to have a field displayed on a screen that field can be removed using Object Security.
At line 35 added 2 lines
This will be explained further during the discussion of Field Security (IMFOS).
At line 61 changed 2 lines
!!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 color for the web theme, or allow query.
[{Image src='IMRO_Preferences.JPG' width='360' align='right' link='attach/IMRO/IMRO_Preferences.JPG'}]
!!Preferences
Preferences for roles depend on the type of role. Most are set only for a business roles, not database roles, etc.
At line 64 changed 6 lines
;[Preference|PREFERENCE_VALUE]: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 a few that are applicable to the roles in Self Service.
;[Priority |PREFERENCE_SEQUENCE]: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|PREFERENCE_VALUE]: The details of the preference are specified in this field. For example:
||Preference|| Value
|OPEN IN SAFE MODE|YES
|WEB MENU|ESS MAIN
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.
At line 72 changed 2 lines
!!Users tab
You may assign this role to specific users through the Users tab. This tab also provides the name and other information on the person.
[{Image src='IMRO_Users.JPG' width='360' align='right' link='attach/IMRO/IMRO_Users.JPG'}]
!!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.
At line 76 removed 6 lines
;[Seq|ROLE_SEQUENCE]: If the user profile has been assigned more than one role, this field identifies the order in which the roles will be presented when the user logs in.
;[User|USER_NAME]:This field is used to identify the users to whom the current role is assigned.
;[Default Role|DEFAULT_ROLE]:If this toggle is checked, the role will be the default role for the user.
;[Person Code|PERSON_CODE]:This field identifies the user by their person code within the system.
;[Last Name|LAST_NAME]:This field identifies the user by their surname.
At line 84 changed 2 lines
!!Execution Rights tab
This tab is used 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.
[{Image src='IMRO_ExecutionRights.JPG' width='360' align='right' link='attach/IMRO/IMRO_ExecutionRights.JPG'}]
!!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.
----
[{Image src='IMRO_DataSecurity.JPG' width='360' align='right' link='attach/IMRO/IMRO_DataSecurity.JPG'}]
!!Data Security
At line 87 changed one line
;[Function|FUNCTION_NAME]: This field displays the function the role has execution rights to.
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]
At line 89 removed one line
;[Description|DESCRIPTION]: This field displays a description of the function the execution right is for.
At line 91 removed one line
;[Create|CREATE_ALLOWED]/[Retrieve|RETRIEVE_ALLOWED]/[Update|UPDATE_ALLOWED]/[Delete Allowed|DELETE_ALLOWED]:These toggles identify the exact execution rights the role has to the function.
At line 93 changed 2 lines
----
!!Data Security tab
DEFINE ROLES
At line 96 changed one line
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.
The Define Roles (IMRO) form is used to view supplied roles as well as create and update customer defined roles.
This section explains the Define Roles form and its associated fields.
At line 98 changed one line
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.
There are four main types of roles used in the eP application, Business, Object Security, Data Security, and Execution. Each has a separate purpose and use in the application.
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.
Select the role you wish to define, by scrolling through the following fields.
X Role Name
X Description
X Role Type
At line 100 changed 4 lines
;[Security Right|SECURITY_RIGHT_CODE]:This field will store the security right code associated to the role.
;[Rule|SECURITY_VALUE_RULE]:The security rule which is to apply to the role is defined here, for example, 'Restricted To'.
;[Look Up Value|DRV_SECURITY_VALUE_LK]:The LOV value that the role is secured to/from (depending on the rule chosen) will display here.
;[Stored Value|SECURITY_VALUE]:The stored value of the LOV value that the role is is secured to/from (depending on the rule chosen) will default in here.
‘Define Roles’ Usage and Examples
Role Info
Role Name
This field holds the actual name of the role. (Mandatory)
Role Type
This field allows you to classify the role into a specific category. (Mandatory)
Roll Types include the following:
At line 87 added 6 lines
Execution Roles - provide execution rights to various screens and reports in the application
Database Roles
Self Service Roles
Object Security Roles - restrict access to features fields and tabs in the application
Business Roles
Data Security Roles - restrict users with no view, no update
At line 94 added 32 lines
Description
This field provides a short description of the role.
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.
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 By
If the password has been changed, this field will indicate the user who last changed it.
Changed On
This field will display the date the password was last changed.
Define Roles (IMRO) - Preferences
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. (Mandatory)
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. (Mandatory)
For example:
Preference Value
OPEN IN SAFE MODE YES
WEB MENU ESS MAIN
Define Roles (IMRO) - Users
At line 107 changed 3 lines
----
![Notes|Edit:Internal.IMRO]
[{InsertPage page='Internal.IMRO' default='Click to create a new notes page'}]
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.
This page (revision-26) was last changed on 26-Nov-2021 10:22 by RForbesTop