In 11i there is a profile option: "Concurrent: Report Access Level" that defines who can access the output of concurrent requests. It could be set to 'User' or 'Responsibility'. When set to Responsibility, the responsibility the report was created under must be assigned to the user who wishes to view the report.
In R12 this was replaced by Role Based Access Control. The UMX Role Based Access Control (RBAC) is to control who can view request output files.
For additional information, please see:
In R12 this was replaced by Role Based Access Control. The UMX Role Based Access Control (RBAC) is to control who can view request output files.
For additional information, please see:
Oracle E-Business Suite Security Guide Release 12.2
- Chapter 2 - Access Control with Oracle User Management
- Chapter 3 - Oracle User Management Setup and Administration
Oracle E-Business Suite Setup Guide Release 12.2
- Chapter 4 - Concurrent Processing - Sections:
- Controlling Access to Concurrent Programs with Request Security Groups
- Controlling Access to Concurrent Programs using Role-Based Access Control (RBAC)
"Administrators can assign individual programs/sets, all programs/sets in a request group, programs/sets belonging to one or more applications, and so on, either to the
user directly or to a role that can then be assigned to one or more users."
user directly or to a role that can then be assigned to one or more users."
"If applications are included in the request groups, all programs/requests sets that are created in these applications will also be automatically included. Please note that
request submission applies to both programs and request sets."
request submission applies to both programs and request sets."
The following types of "instance sets" can be used for assignment (but administrators can create new instance sets based on their needs):
• All programs in a particular request security group
• All request sets in a particular request security group
To enable this functionality, the following are seeded:
- Permission "Submit Request"
- Permission "View Request"
- Permission Set "Request Operations" containing the permissions "Submit Request" and "View Request"
- Object "Concurrent Programs"
- Object Instance Set "Programs that can be accessed"
- Object Instance Set "Request sets that can be accessed"
To grant access to a request security group to a role, follow these steps:
- Define your role (User Management responsibility).
- Define your request security group (System Administrator responsibility).
- Define your grant (Functional Administrator responsibility):
- Enter a Name and Description (optional) for the grant.
- Enter the Security Context for the grant.
- Under Data Security, choose "Concurrent Programs" or "Request Sets" as the object. Click Next.
- For the Object Data Context, select "Instance Set" for the Data Context Type.
Choose either "Programs that can be accessed" or Request Sets that can be
accessed" as appropriate. Click Next.- Review the Instance Set information. Under Instance Set Details, enter the
request group and its application. Specifically, enter the request group name
as Parameter 1 and the application short name as Parameter 2.- Choose "Request Operations" as the permission set under "Set". Click Next.
- Review the grant information and save your work.
Note that there are two seeded grants for all users to account for request group assignments that already exist for legacy responsibilities. These are:
• Programs - Grant Defaults
• Request Sets - Grant Defaults
Viewing Requests
You can control users' access to viewing requests with RBAC.
• Request Sets - Grant Defaults
Viewing Requests
You can control users' access to viewing requests with RBAC.
Note: In previous releases, the Concurrent: Report Access Level profile was used to control privileges to report output files and log files generated by a concurrent program. This profile is no longer used.
Seeded "instance sets" allow administrators to grant:
- All requests submitted by a user
- All requests submitted by a user for a given application
- All requests belonging to a program submitted by a user
- All requests belonging to a request set submitted by a user (irrespective of the constituent programs' owning application) to another user (or a group of users - via a role).
System administrators can create new "instance sets" based on their needs. They can grant access to requests (of a particular program/set) submitted by all users to a specific
set of users. For example, say a given application's administrators group want to track all requests of a particular type or program submitted by business users. Then the
following approach, to grant specific programs' requests to a group of users, can be used:
set of users. For example, say a given application's administrators group want to track all requests of a particular type or program submitted by business users. Then the
following approach, to grant specific programs' requests to a group of users, can be used:
1. Create an instance set that selects all the requests belonging to the particular program irrespective of which user submitted it.
For example,
For example,
&TABLE_ALIAS.request_id in
( select cr.request_id
from fnd_concurrent_requests cr, fnd_concurrent_programs cp
where cr.concurrent_program_id = cp.concurrent_program_id
and cr.program_application_id = cp.application_id
and cp.concurrent_program_name = &GRANT_ALIAS.PARAMETER1)
( select cr.request_id
from fnd_concurrent_requests cr, fnd_concurrent_programs cp
where cr.concurrent_program_id = cp.concurrent_program_id
and cr.program_application_id = cp.application_id
and cp.concurrent_program_name = &GRANT_ALIAS.PARAMETER1)
If you want to grant access to a set of programs instead of a single program,
'&GRANT_ALIAS.PARAMETER1' can be replaced with a subquery that returns all
the programs in a particular request group.
2. Create a grant to grant this instance set to (an existing) role, for example,
"
"Concurrent Requests" data object in creating this grant.
3. Ensure that the role is assigned to all users that should have access to these requests.
No comments:
Post a Comment