Top of SEC | Index | Table of Contents | Feedback |
SECF0021 - Maintain System Users
Purpose |
To control the primary level of data access of users of the system. |
|
SubSystem |
Security |
|
Normally Run By | Security Specialist | |
Anticipated Frequency | As required. | |
Structure | Block | Person |
Person Role Grant | ||
Sub Block | Restrictions | |
Buttons | Organisational Unit (SECF0032) | |
Note Type (SECF0040) | ||
Correspondence Type (SECF0033) | ||
Appeal Type (SECF0090) |
Person block The Person block displays personal details that have already been recorded in the System, for a person. Additional information may be added in this block to record the person as a System user. The buttons (from the sub block), invoke restriction forms that allow the user's access to be restricted to data for particular organisational units or data for particular correspondence types. A validation prevents the password being updated if the user has a username matching one of the database schema owner users (eg. SIS_OWNER, CC_OWNER, COFI_OWNER, etc). In addition, the ability to inactivate the person as an Oracle user will be prevented for these particular users. Having established a person as a system user, it is necessary to grant them access to the areas of the system that they are entitled to use. This is accomplished by assigning Security Roles to them. Security Roles define the primary levels of access to the system and are created and maintained by the Database Administrator. Security Roles also give a system user access to specific menu items that have been granted to their Security Role (see SECF0063). Access can be further controlled by the use of the Auto Enable check box. If the check box is deselected for a role grant, the user is only able to access data applicable to that role by using Callista forms, jobs and reports. If the check box is selected for the role grant, the user has the same data access via Callista but is also able to access that data using applications other than Callista (eg. third party reporting tools). Note that a person can be a non-oracle user and still be granted roles using this form (but not the corresponding oracle role). When inserting/deleting person_role_grant records, the form will only attempt to grant/revoke the corresponding oracle role if the person is an active oracle user. |
The Person block contains:
The Person Role Grant block contains:
|
Rules/Notes: If a Person record exists with the Oracle Username field matching one of the database Schema Owner Usernames, the following actions will be prevented:
The manner in which the database Schema Owners are identified can probably be no more elaborate than returning all of the distinct owners who own any objects in the database. Each Restrictions navigation button is only available to users who have Security Access to the form that it navigates to. Validations include:
|
To record a person as a System user using the Maintain System Users form:
|
Rules/Notes: If entering a password for a user, they should be advised to change their password (using the Change Password option under the Action menu in the menu bar) as soon as possible.The password field may be used to create a temporary password for users who have lost their password.
|
To grant a Security Role to a System user using the Maintain System Users form:
|
Rules/Notes: When a user is granted a security role their access to particular note types may be affected by note type restrictions applied to that role in SECF0041. If their is a conflict in these restrictions (i.e. Note Types from within the same Note Type Group have different Restricted Select values) then a warning will display and log records will be created that can be viewed in GENF0001. If there is an overlap in restrictions (i.e. Different Note Type Restrictions applied to a Note Type) then no warning is displayed, but log records (overlap) are created and can be viewed in GENF0001. A warning is displayed if the context Person is not an active oracle user and the role contains grants to forms, jobs, self serve applications and/or SSF menus. Assigning a Security Role to a system user gives them access to specific menu items that have been granted to the Security Role (see SECF0063). |
To
remove a Security Role from a user using the Maintain System Users form:
|
Rules/Notes: When a security role is removed from a user the system redetermines their effective note type restrictions. Warnings and Log records are generated as described in the previous Rules/Notes section. |
To inquire on the Security Roles granted to an individual user using the Maintain System Users form:
|
Rules/Notes:
If the Include Deleted Grants checkbox is selected, all of the Security Roles which have ever been granted to the user will be displayed. The deletion time and date for deleted Security Roles will also be displayed. If the Include Deleted Grants checkbox is not selected, only those Security Roles currently granted to the user will be displayed. Selecting or deselecting the Include Deleted Grants checkbox does not have immediate effect. The records in the Person Role Grant block must be requeried for the displayed records to be reflected in the change. |
Last Modified on 22-Oct-2008 4:11 PM
History Information
Release Version | Project | Change to Document |
15.0.0.2 | 1842 - Support, Calipso 36395 | Added note about granting Security Roles access to menu items. |
12.0.0.2 | 1595 - Security | Added note about non-oracle users now being granted roles. |
11.1 | 1448 - ESOS | Added Appeal Type button |