To define a security profile:You can define security profiles in the Security Profile window (to give access to a single business group) or the Global Security Profile window (to allow users to access records from more than one business group).
See also: Security Profiles
Note: Using the Global Security Profile window does not give Oracle HRMS users access to records from multiple business groups within the same responsibility; users must still switch responsibilities to see records from different business groups. However, HRMS users can see a restricted set of information in records from more than one business group within a single responsibility if the HR:Cross Business Profile profile option is set to Yes. In addition, you can use people management templates to query and update worker information across business groups using a single responsibility.
If you want to associate a reporting user with the new security profile, the ORACLE database administrator must create a new reporting user ORACLE ID. The system administrator must register the new ORACLE IDs as restricted privilege users with the Application Object Library.
See: Setting up Reporting Users
To define a security profile:Enter a name for the security profile.
If you are using the Security Profile window, select a business group. Users will have access only to records within this business group. This does not need to be the business group associated with your responsibility.
If you are using the Global Security Profile window, users will have security access to records from all business groups, subject to other restrictions you set up.
If you want reporting users to be able to use this security profile, select the Reporting User name for the ID set up by the database administrator (this option is not available when setting up Global Security).
You can choose to apply the security restrictions you set up to employees, applicants, contingent workers, contacts, candidates or any combination of these.
Note: You can only restrict access to candidates if you have iRecruitment installed. If you do not have iRecruitment, the application uses the default setting of All for the View Candidates box.
For example:
If you want the security restrictions to apply to employees, select Restricted from the View Employees box.
To ignore the security restrictions for employees and allow access to all employees, select All from the View Employees box.
To prevent access to any employee records, even if the other security restrictions allow access, select None from the View Employees box.
You can set the View Applicants, View Contingent Workers, and, if you have iRecruitment, View Candidates, options independently, giving different security access to employees, applicants, contingent workers, and candidates using the same security profile.
For contacts, or other people of person type Other, you can choose one of two options:
All: Access is unrestricted, so that all people of type Other are visible to the security profile
Restricted: The profile restricts access to contacts to those people who are related to employees, applicants, or contingent workers who are visible within the security profile. If you can see the record of an employee, applicant, or contingent worker, you can also see the records of people of type Other specified as related to them (using the Contact Relationship field). All people of type Other who are unrelated to any employee, applicant, or contingent worker are also visible to the security profile.
Select the Allow Granted Users option to allow a self-service user with this security profile to access the records of other self-service users, provided that the other users grant them access using the self-service application.
Note: This setting applies to the self-service application only and has no effect on users of Oracle HRMS.
Select the Restrict on Individual Assignments option to build security hierarchies based on a person's individual assignments. Oracle HRMS builds the security hierarchy and assesses each individual assignment. The hierarchies generated by the security process will then only contain the particular assignments to which the manager has access. If you do not select this option, a manager who can see one assignment for a person can see all other assignments.
For more information on restricting by individual assignment and securing your forms, see: Assignment-Level Security.
In the Organization Security tabbed region:
To restrict by organization list, select the Secure organizations by organization hierarchy and/or organization list option in the Security Type poplist. Select the organizations in the Organization Name field, and choose the Include option button.
To restrict by organization hierarchy, select the Secure organizations by organization hierarchy and/or organization list option. Select an organization hierarchy, and a top organization. Select the Include Top Organization option if you want to allow access to this organization.
If you are using user-based security, you can choose to use the organization linked to a person's assignment as the top organization by selecting the corresponding option. The security process identifies the organization linked to the user's assignment when the user logs on (or when the Security List Maintenance process is run).
If required, you can add organizations not in the hierarchy to the list, by selecting the organizations in the Organization Name field and choosing the Include option button. You can also remove specific organizations from the selected hierarchy by selecting an organization in the Organization Name field and choosing the Exclude option button.
Note: The Secure organizations by single operating unit and Secure organizations by operating unit and inventory organizations options are for use by non-HRMS users, and have no effect on the HRMS application.
By default, the Exclude Business Groups check box is unchecked, giving users access to the business groups themselves, and therefore to employees or applicants who have the business group(s) as their organization. Check the box to prevent access to the business group(s) and the employees or applicants attached to them (for example, to prevent users from seeing new starters and other employees who have been assigned to the business group by default).
In the Position Security tabbed region, deselect the View All Positions option. Select a position hierarchy, and a top position. Check the Include Top Position check box if you want to allow access to this position.
If you are using user-based security, you can choose to use the position linked to a person's assignment as the top position by selecting the corresponding option. In this case, the security process identifies the position linked to the user when the user logs on (or when the Security List Maintenance process is run).
In the Payroll Security tabbed region:
To give access to all payrolls, check the View All Payrolls check box.
To give access to many payrolls, uncheck the View All Payrolls check box, and uncheck the Include check box. Select the payrolls you want to exclude.
To give access to a small number of payrolls, uncheck the View All Payrolls check box, and check the Include check box. Select the payrolls to include.
In the Supervisor Security tabbed region, you can further specify how to create your supervisor hierarchy. You can either create a hierarchy based on a person's supervisor assignment or based on a person's supervisor.
For more information, see: Security Profiles for Supervisor Security.
Select either the person-based or assignment-based option and enter the number of levels of access you want to allow the supervisor to see in the Maximum Hierarchy Levels box (or leave the field blank to allow access to all levels).
Note: When you set up security based on supervisor hierarchies, you can choose to generate the list of employees visible to a user at the start of the session (user-based security). For supervisors with a large number of subordinates (for example, at higher management levels) leaving the Maximum Hierarchy Levels box blank may result in a delay in generating the list. You can improve performance by limiting the number of hierarchy levels a supervisor can access or by using the Static List functionality.
For more information, see: Static Lists.
Alternatively, for the highest levels of management, consider setting up security using organization hierarchies.
If you are using person-based supervisor security, you can choose whether to display multiple assignments in the supervisor hierarchy. By default, the Primary Assignments Only option is not selected, which gives users access to people who report to them in any assignment. If you only want to give users access to people who report to them in their primary assignment, select this option.
The list of people whose records are accessible using a security profile can change with the user name of the person who logs in (if you are using user-based security). If you want the application to evaluate permissions based on a specific person (and not vary depending on the user name of the person who logs in) enter a name in the Named User field. For example, to set up supervisor-based security for reporting users who do not have any association with employees, enter the name of a person at the required supervisory level.
To prevent users from seeing their own records, check the Exclude User check box (if you have entered a name in the Named User box, users will be prevented from seeing the records of the named user rather than their own records).
Note: This functionality is not supported in Self-Service Human Resources (SSHR).
In the Custom Security tabbed region, select the custom restriction option. The options are as follows:
No custom security
Restrict the people visible to this profile
The Security List Maintenance process is the basis for this type of custom security. The security data is held in a static list.
Restrict the people visible to each user using this profile
Oracle HRMS assesses the custom security when the user signs on. In addition, the custom security code can include references to user specific variables, for example, fnd_profile.value() and fnd_global.employee_id.
Enter a valid SQL WHERE clause fragment to select a group of records. For example, to add a restriction that assignments must be based in either London or Paris, add the following SQL fragment:
ASSIGNMENT.location_id in (select LOC.location_id
from hr_locations_all LOC
where LOC.location_code
in ('London','Paris'))
Alternatively, you could create custom code to use user-specific variables. The following example illustrates the use of user-specific variables:
In this example, the custom code creates a rule whereby a user can display employees or contingent workers whose last name begins with the same letter as their own. The security profile is called "Same first letter of last name".
substr(person.last_name,1,1) = (select substr(i.last_name,1,1) from per_all_people_f i where i.person_id = fnd_global.employee_id and trunc(sysdate) between i.effective_start_date and i.effective_end_date)
Note: In addition, the View Employees or View Contingent Workers option is set to Restricted, and the "Restrict the people visible to each using this profile" option is set on the Custom Security tab.
If the clause is valid, it is automatically incorporated in an SQL select statement that the system generates to restrict access to records, based on the restrictions you have set up in the other tabbed regions. The list of employees, contingent workers, and applicants specified by these other restrictions is therefore further restricted by the custom restriction.
The clause fits into the system-generated statement in the following way (this statement is not visible on screen):
select 1
from per_all_assignments_f ASSIGNMENT,
per_all_people_f PERSON,
per_person_type_usages_f PERSON_TYPE
where ASSIGNMENT.assignment_id=:asg_id
and:effective_date betweeen ASSIGNMENT.effective_start_date
and ASSIGNMENT.effective_end_date
and PERSON.person_id=ASSIGNMENT.person_id
and :effective_date between PERSON.effective_start_date
and PERSON.effective_end_date
and PERSON.person_id=PERSON_TYPE.person.id
and :effective_date between PERSON_TYPE.effective_start_date
and PERSON_TYPE.effective_end_date
and {your custom where clause fragment goes here}
Attention: Custom restrictions directly restrict employees, contingent workers, and applicants only; you cannot create custom restrictions on people with a system person type of Other. However, if you add custom restrictions on employees, contingent workers, or applicants, related people with a system person type of Other are restricted according to the setting of the "View Contacts" option.
Choose the Verify button to check that the clause you have entered is valid. If it is invalid, an error message appears explaining the reasons.
Static lists enable you to assess security periodically and store the data. You add users to the static list and their security permissions are evaluated when the Security List Maintenance process is run. Oracle HRMS stores the permissions for quick retrieval when the user logs on and freezes the permissions until you run the Security List Maintenance process again.
To specify which users to include in a static list, enter the user ID in the field.
To include a specific user or group of users in the next Security List Maintenance run, select the Process in Next Run option for those users.
Save your work.
When you have modified or created new security profiles, it may be necessary to run security processes to activate your changes.
See: Security Processes