This chapter covers the following topics:
To continuously support the existing Application Object Library (AOL) task security rules used in HTML Task Manager, and to extend the task data security offerings specifically for task related resource assignments to the Forms-based Tasks and to the Oracle Application Self-Service Framework based Tasks, Task Manager leverages the AOL data security based on Virtual Private Database (VPD) policy. This VPD policy is a feature implemented in database to allow security dynamically created at runtime to all queries issued against a database table or view. This security model with VPD feature provides more flexibility in task security for resource assignments by allowing any applications to set product specific security rules around the existing task security.
For example, only the resources that have privileges to access certain types of service request can be assigned to these types of service related tasks as assignees. Therefore, Oracle Service Online can pass its own security functions to Tasks in Forms or in Oracle Applications Framework to allow qualified resources to be retrieved from the resource list of values when assigning them to a service request of certain types.
Be aware that this security model with VPD feature only applies to task security for resource assignments in the Forms-based and Oracle Applications Framework based Task Manager. It is not implemented in task security rules currently used in HTML Tasks, such as customizing contextual task rules using a profile option, building security around the resource list of values, and allowing group managers to access their direct's tasks.
To better understand the Task security rules used in all formats of Task Manager including AOL security model in HTML Tasks, and new security model with VPD feature for Tasks in Forms and Oracle Applications Framework specifically for resource assignments, the following topics are introduced in this section:
Before implementing AOL data security model, Task Manager can implicitly grant users with the following task security access:
For the standalone tasks:
The owner or assignee of a task has full access to the task.
If a group or team is the owner or the assignee of the task, then all the group or team members have full access to that task.
Two security access privileges are used in Tasks:
Read Only Access: Resources can only view tasks.
Full Access: Resources can view, update, and delete tasks.
In addition, a resource can explicitly grant another resource full access or read only access to his or her tasks except the private tasks. This can be done through the calendar grant functionality.
For the context sensitive tasks, Task Manager allows any users who can access the business object to have full access to all contextual tasks related to the object.
By leveraging AOL data security model, HTML Task Manager not only can continue supporting the task security rules granted implicitly or explicitly, but also can provide a flexible mechanism for task security access. This security model provides the ability to restrict data access to appropriate users through a specific authorization process.
For example, if a company only wants certain tasks to be viewed or updated by a particular user or user groups, then, with the AOL security model, this can be achieved by granting a security access privilege (full access or read only) to the particular user or user groups to access specific tasks.
In other words, the task security authorization process can be considered as an analysis around
"Who (users or user groups) has what permission (full or read only access) to access which tasks (specific tasks)"
The following figure illustrates the high level picture of the task security rule analysis.
Task Security Rule Analysis
For example, appropriate users who can be either sales representatives, sales managers, or support managers are granted with full access or read only access permission to access certain tasks, such as from Task1 to Task5.
HTML Tasks Data Security Allows Further Customization
In order to authorize specific tasks access for particular users or user groups, the task security model in HTML Tasks leveraging the concept of AOL data security can further allow users to customize task data for security authorizations. This includes customizing contextual task rules by using a profile option, building security around the resource list of values, and allowing group managers to access their direct's tasks for HTML Tasks.
The Data Security is used to model and enforce security authorizations for access and modification of specific data records. In other words, data security is the finest security level that allows users to customize records in the data level.
To be able to customize task security in the data level, AOL data security model uses the concepts of object, object instance, and object instance sets to represent task features and possible modification, the concepts of privileges and roles to translate data access permissions, and the concepts of grants or global grants to represent the authorization process.
Take one of the existing task rules, for example, to further explain the AOL data concepts used for task rule customization:
The owner or assignee of a task has full access to the task.
In the AOL data security framework, the owner or assignee can be translated as a user or user group. Full access is an access privilege that a user can act upon or perform on a task. As to "the task", Task Manager uses the concepts of objects, object instances, and object instance sets to explain the features of a task. For example, a task is considered as an object, task with number 1234 can be considered as an object instance. A grouping of multiple object instances is an object instance set. Therefore, tasks with number starting at 1000 to 1999 can be an object instance set.
With this security model, the HTML Tasks module enable users to define and further customize the security rules for various business needs.
For detailed information on AOL data security framework, refer to the Oracle Application Object Library Security chapter in the Oracle E-Business Suite Security Guide.
HTML Task Manager uses the following concepts, based on AOL data security model, to provide the flexibility to cover a wide range of data security scenarios:
Users (User Groups)
Objects
For example, a task is considered as an object.
Object Instances
If Tasks is considered as an object, then Task with number 1234 is an object instance.
Object Instance Sets
An object instance set can be expressed in the following predicate for all tasks with a number smaller than 5. To avoid processing issues, all the columns used in the predicate should be prefixed with &TABLE_ALIAS in the object instance set definition. Then, this predicate can be added to the where clause.
SELECT * FROM jtf_tasks_b WHERE Owner_id = FND_GLOBAL.USER_ID AND &TABLE_ALIAS.task_id < 5
Note: Referencing PARAMETERx values from the grants can also parameterize the predicate.
Privileges (Functions)
There are two seeded security privileges currently used in the Task Manager:
JTF_TASK_READ_ONLY (view only)
JTF_TASK_FULL_ACCESS (update and delete)
Since these privileges are registered in the FND_FORM_FUNCTIONS and FND_FORM_FUNCTIONS_TL tables and they are referenced in the actual code so that they cannot be changed or extended.
In addition, privileges (functions) can be grouped into roles (menus) to reduce the granting overhead.
Roles (Menus)
Currently, there are two roles registered in the FND_MENUS and FND_MENUS_TL tables specifically for task security:
JTF_TASK_READ_ONLY: This role contains one privilege, JTF_TASK_READ_ONLY.
JTF_TASK_FULL_ACCESS: This role contains two privileges, JTF_TASK_READ_ONLY and JTF_TASK_FULL_ACCESS.
The role privileges can be registered in the FND_MENU_ENTRIES and FND_MENU_ENTRIES_TL tables.
Note: Roles are user definable, the seeded roles only exist to ensure backward compatibility.
Grants (Authorizations)
A grant consists of the following three components:
Object: Any object instance or object instance set, for instance, all non-private tasks (object: JTF_TASKS and object instance set: JTF_TASK_RESOURCE_TASKS)
Grantee: Any user or user group, for instance, "JDOE" for John Doe
Role (Menu): Any role, for instance, "JTF_TASK_FULL_ACCESS"
This grants the user, John Doe, the privilege to have full access to all non-private tasks.
In addition, all grants should be registered in table FND_GRANTS.
Calendar Grants
Task Manager still supports the calendar grant functionality, which means that when a user gives calendar access to another user, the access for tasks is also given. Since Task Manager uptakes AOL data security model, task security can be further customized. Granting calendar access to another user will still result in granting task access to the user. However, the access to the tasks can be restricted by additional data security implemented for tasks.
Global Grants
To reduce the administration of grants, authorizations can be granted globally to the following:
The "Global" user or user group
The "Global" object instance
For example, any user will have full access to tasks where she or he is the owner or assignee. The seeded global grant uses the following values and customer cannot revoke this grant:
FND_GRANTS GRANTEE_TYPE = "GLOBAL" GRANTEE_KEY = "GLOBAL" MENU_NAME = "JTF_TASK_FULL_ACCESS" OBJECT_NAME = "JTF_TASKS" INSTANCE_TYPE = "SET" INSTANCE_SET_NAME = "JTF_TASK_USER_TASKS"
Another global grant example can be that any user can see any resource team:
FND_GRANTS GRANTEE_TYPE = "GLOBAL" GRANTEE_KEY = "GLOBAL" MENU_NAME = "JTF_TASK_RESOURCE_ACCESS" OBJECT_NAME = "JTF_RS_TEAMS" INSTANCE_TYPE = "GLOBAL"
With the leverage of AOL data security model, Task Manager adds the following two security functions to the security model:
Predicate: Adding a security predicate, the "where" clause, to an application query limits the task instance access for users. The predicate can be considered as the add-on new security rule to Tasks. To avoid processing issues, all the columns used in the predicate should be prefixed with &TABLE_ALIAS in the object instance set definition. As a result, a user will be only able to see certain task instances (such as all tasks with task id less than 5) that she or he has any kind of privileges.
For example, add a predicate (where clause) to an existing query:
SELECT * FROM jtf_tasks_b WHERE Owner_id = FND_GLOBAL.USER_ID AND &TABLE_ALIAS.task_id < 5
Note: In the new security model, a user can have access to an object instance in many ways, such as access to an instance may be granted to the user, to the user's group(s) or to all users. Consequently the predicate might return duplicate instances
Check Function: This allows the system to check whether or not a particular user has an appropriate access privileges (full or read only access) on a specific task instance.
With the two new functions added to Tasks, appropriate task instances are presented in the following logic:
For example, for the standalone task screens:
Add predicate to the main query.
Check full access privilege for retrieved task instances.
Display task instance(s) as updatable or read-only.
Check corresponding privilege before accessing the detail page.
To support existing task AOL data security around the assignment of resources for Tasks in Forms and Oracle Applications Framework, Task Manager enhances the existing AOL security model by implementing Virtual Private Database (VPD) policy which allows various applications to set product specific security rules on top of the task rules for the resource list of values security access to meet their business needs.
See the Oracle Database Security Guide for information about Virtual Private Database.
Note: The resource list of values security access discussed here is restricted to the assignee list of values with resource types of employee, group, and team only.
Business Reason
For example, a service agent in Oracle Service Online needs to assign a service related task with request type of network service only to the service representatives who can handle the network issues. These limited resources can only access certain types of request based on security access privileges. With this enhanced security model, Service Online can pass its own security functions to Tasks in Forms or in Oracle Applications Framework to allow qualified resources to be retrieved from the resource (assignee) list of values when assigning them to a service related task of certain types.
Based on the concept of VPD policy, Task Manager develops a java interface for Tasks in Oracle Applications Framework and parameters for Tasks in Forms to allow integrated applications to pass their product specific security context such as security related attribute sets or value pairs, privilege (view or synonym) names, or implementation classes to the existing Tasks rules based on AOL security model.
To react to the parameters passed by product specific security context, Task Manager needs to perform the following tasks to support the product specific resource list of values security:
For Tasks in Oracle Applications Framework
First translate the class name into a class object, then instantiate the class using TaskAssigneeSecurity interface, and then use the object methods to set the context and get function name to build an LOV query before executing the query.
For Tasks in Forms
Translate the privilege name (view or synonym) if it is not null to the LOV query. Otherwise, the JTF Objects metadata will be used.
As a result, Task Manager changes the process flow of accessing resources of different categories through the LOV queries as follows:
Process Change From the Process used in HTML Tasks
Select the object type, such as Employee (RS_EMPLOYEE) for assignee or owner type
Find related JTF Object
Create query from metadata
Find related FND Object if any
Generate a predicate for the FND Object and Task's standard privilege (data security function)
Add predicate to the query
Execute the query
Process Change To the New Model with VPD Policy for the Oracle Applications Framework and the Forms based Tasks
There are two ways to retrieve resources from the list of values:
Standard Resource Security in HTML Tasks, Forms, and Oracle Applications Framework based Tasks
This is the usual business flow of selecting a resource.
Select a resource object type or category, such as RS_EMPLOYEE
Create a query by using the appropriate security view
Execute the query (database kernel runs policy function) for Tasks in Forms and in Oracle Applications Framework
For HTML Tasks, first get the predicate, add the predicate to a query, and then execute the query.
Non-Standard (Product Specific) Resource Security in Task Forms and the Oracle Applications Framework based Tasks
Compared to the standard resource security, this method requires one additional step to support product specific resource security by using parameters to carry the privilege name for Tasks in Forms or class name for Tasks in Oracle Applications Framework. If the name is passed, Tasks will use it instead of default resource privilege(s). The process of selecting a task resource is as follows:
Select a resource object type or category, such as RS_EMPLOYEE
If a privilege (view/synonym) or class name has been passed:
Set provided view/synonym to the query for Tasks in Forms
Instantiate the class and use the object methods to set the context and get function name for Tasks in Oracle Applications Framework
Create a query by using the appropriate security view
Execute the query (database kernel runs policy function)
Note: The VPD security model currently is only implemented in the resource list of values security access for Tasks in Forms and Oracle Applications Framework, and it is not available in HTML Tasks. See Customizing the Resource List of Values Security for Tasks in Oracle Applications Framework and Forms for more details.
Based on the task security model, Task Manager allows task security rules to be further customized in the following ways:
Set the security profile option for the context sensitive tasks
Grant manager-directs security access
Note: Be aware that the only security rule currently used in the Forms-based Tasks is the resource list of values security. Security rules for contextual tasks and manager-directs security are applied to both HTML Tasks and the Oracle Applications Framework based Tasks.
HTML Tasks and Tasks in Oracle Applications Framework use the Task Manager: Set Context Data Security profile option to control task data security for the context sensitive task instances, such as tasks attached to an opportunity or a lead. By using the profile option, you can choose to turn the task security function on or off based on the following profile values:
If Full Access is selected (default value), then all the tasks related to the context can be viewed, updated, and deleted.
This value turns the security OFF so as to support existing task security, which allows any users with access to related object instance to update (full access) any task instance for that object.
If Security Access is selected, then whether the task for that context can be updated is based on the privileges granted to the user.
This value turns the security ON for all task instances within context and only allows tasks to be accessible to the user with appropriate privileges.
Task Security Access Example
Three tasks (T1, T2, and T3) are created for an opportunity. User 1 is the owner of the task T1 and T2. Task T2 is also assigned to User 2. User 2 owns the Task T3.
Task Data Security Condition:
Grant read only access on task T3 (task id = 120087) to User 1.
FND_GRANTS GRANTEE_TYPE = "USER" GRANTEE_KEY= "USER1" MENU_NAME = "JTF_TASK_READ_ONLY" OBJECT_NAME = "JTF_TASKS" INSTANCE_TYPE = "INSTANCE" INSTANCE_PK1_VALUE = "120087"
If Security Access is selected which turns the security function on, then the access privileges are changed to:
User 1 can have full access to task T1 and T2, but has read only access to T3.
User 2 can have full access to task T2 and T3.
In the past, all users who have access to a business object can have full access to all contextual tasks attached to that object. Therefore, both User 1 and User 2 can have full access to all three tasks attached to that opportunity.
If Full Access is selected which turns the security function off, then the task access privileges for User 1 and User 2 are changed to:
Both User 1 and User 2 can have full access to Task T1, T2, and T3.
This is because if both users can access the opportunity business object, then they should all be able to access all contextual tasks for that object.
Since the profile option controls the security access for contextual tasks, before displaying the task detail page, Task Manager will:
Check the profile value first to determine whether to display task instance(s) as updatable or read-only; then
Check corresponding privilege to determine whether the logged-in user has any particular privilege on the particular task instance before the user can access any task detail page.
In addition to restricting task data access using the profile option for HTML Tasks and Oracle Applications Framework based Tasks, Task Manager also allows you to build security around the resource list of values (LOV) by using the concepts of the AOL data security for HTML Tasks, and using the VPD security model for Tasks in Forms and Oracle Applications Framework.
To further describe the resource LOV security rule for Tasks in different formats, see the following topics:
Based on the existing AOL data security model, HTML Task Manager allows you to customize security for the resource list of values by using the concepts of object instances or object instance sets.
Note: The resource list of values can be resources of any category (employee, party, partner, supplier contact, group, team, other, and to be hired).
Note: In addition, resource LOV security functionality is based on resources. Therefore, it applies to owner, assignee, and reference (relate to) if it is defined based on resources. It does not apply to any customer/contact LOV (such as organization, person, or relationships) and reference other than resources (such as customer/contact and lead.)
Business Reason
For example, a sales manager is responsible for a special deal that only involves limited resources. To make sure that relevant tasks created for that deal are only restricted to certain people, the system administrator can create a specific set of resources and then grant them to the sales manager. Thus, the manager will only see those resources shown in the resource (owner or assignee) list of values when creating a task.
For the similar reason, another set of resources can be granted to sales representatives. As a result, the sales representatives will not be able to see the resources granted to the sales manager, and the manager will not see the resources granted to the representatives.
Before introducing necessary steps to customize resource LOV, it is important to understand JTF object changes and other seeding strategy made in Task Manager to support the LOV security.
In order to support the LOV data security, Task Manager modifies the JTF object metadata form by adding two extra columns grouped in the Data Security Setup region of the LOV and Data Security tab. This establishes the link between JTF_OBJECTS for existing LOV and FND_OBJECTS for all task data security objects.
Because in Tasks, on one hand, all LOVs are rendered using the common LOV Renderer. The LOV Renderer uses JTF_OBJECTS as metadata repository providing input to all needed data when generating the LOV in a query. This query may be defined at design time or generated dynamically from JTF_OBJECTS. The LOVs addressed here are all generated dynamically.
On the other hand, all data security objects are newly defined in the FND_OBJECTS.
In order to build connection between these two so that the existing LOV could have an extra security build on top of it, Task Manager uses the Data Security Setup region in the JTF object metadata form to establish the link.
To access the security set up region, log on with the CRM Administrator responsibility, select the Task and Escalation Manager > Setup > Objects Meta-data.
There are two new fields in the LOV and Data Security tab:
Object Name: It is the object name for a corresponding JTF_OBJECTS code and serves as the foreign key to FND_OBJECTS. This field is not required and can be empty (null).
Predicate Alias: It adds security information to application query. It should only be used to avoid ambiguity when LOV query contains more than one table joined by data object primary key(s) values. For example, if two tables ("jtf_tasks_b" and "jtf_tasks_tl") are used, then it must be entered with either "jtf_tasks_b" or "jtf_tasks_tl". Otherwise Oracle DBMS will report ambiguous task_id reference at the run time.
If this field is entered and the object name is not null, the value will be passed to an internal API to add security to a generated query for the LOV. However, if the object name is empty, then security predicate will not be added to the generated query.
In addition to the JTF object change, HTML Task Manager also makes the following changes in order to support the LOV security:
JTF_TASK_RESOURCE_ACCESS privilege (registered in the FND_FORM_FUNCTIONS table)
JTF_TASK_RESOURCE_ACCESS role (registered in the FND_MENUS table) or JTF_TASK_RESOURCE_ACCESS role (registered in the FND_MENU_ENTRIES table)
Note: This security role (menu) JTF_TASK_RESOURCE_ACCESS is replaced by CAC_TASK_RESOURCE_ACCESS for the resource list of values security access used for Tasks in Forms and Oracle Applications Framework.
Task resource LOV security references the following business objects seeded into JTF Objects:
JTF Object Code | FND Object Name |
---|---|
RS_EMPLOYEE | JTF_RS_RESOURCE_EXTNS |
RS_GROUP | JTF_RS_GROUPS |
RS_TEAM | JTF_RS_TEAMS |
RS_INDIVIDUAL | JTF_RS_RESOURCE_EXTNS |
RS_OTHER | JTF_RS_RESOURCE_EXTNS |
RS_PARTNER | JTF_RS_RESOURCE_EXTNS |
RS_PARTY | JTF_RS_RESOURCE_EXTNS |
RS_SUPPLIER_CONTACT | JTF_RS_RESOURCE_EXTNS |
RS_TBH | JTF_RS_RESOURCE_EXTNS |
In order to provide backward compatibility, the following global grants are shipped:
Any user can see any resource:
FND_GRANTS GRANTEE_TYPE = "GLOBAL" GRANTEE_KEY= "GLOBAL" MENU_NAME = "JTF_TASK_RESOURCE_ACCESS" OBJECT_NAME = "JTF_RS_RESOURCE_EXTNS" INSTANCE_TYPE = "GLOBAL"
Any user can see any resource group:
FND_GRANTS GRANTEE_TYPE = "GLOBAL" GRANTEE_KEY= "GLOBAL" MENU_NAME = "JTF_TASK_RESOURCE_ACCESS" OBJECT_NAME = "JTF_RS_GROUPS" INSTANCE_TYPE = "GLOBAL"
Any user can see any resource team:
FND_GRANTS GRANTEE_TYPE = "GLOBAL" GRANTEE_KEY= "GLOBAL" MENU_NAME = "JTF_TASK_RESOURCE_ACCESS" OBJECT_NAME = "JTF_RS_TEAMS" INSTANCE_TYPE = "GLOBAL"
If a system administrator decides to set the LOV security, then she or he should first disable corresponding global grant for the LOV data object by setting an end date to the specific global grant.
The resource LOV can be further customized if necessary before it is granted to resources or resource groups.
The system administrator can grant an individual resource, all resources, or a specific set of resources to another resource, group of resources, or all resources.
Grant An Individual Resource
For example, in the lowest security level and the most gradual one, a system administrator can grant a single employee resource (resource number 1234) access to the following grantee(s):
A user "John Doe"
All members of a resource group (group number 9876)
All users
Grant All Resources
As opposite to the previous one, in the most global security level, the administrator may grant all resources (global access) to another resource, all members of a resource group, or all users.
Grant A Specific Set of Resources
When there is a need to grant a specific set of resources to a user, all members of a resource group, or all users, the administrator can customize the resource LOV by using object instance sets.
Perform the following procedures:
For example, a company wants to grant access of a specific set of resource to a user, all members of a resource group, or all users.
This specific set of resources can be created by first registering a new parameterized object instance set using the following data:
FND_OBJECT_INSTANCE_SETS INSTANCE_SET_NAME = "X_JTF_RS_GROUP_MEMBERS" DISPLAY_NAME = "Members of Resource Group" DESCRIPTION = "Members of Resource Group" OBJECT_NAME = "JTF_RS_RESOURCE_EXTNS" PREDICATE = "&TABLE_ALIAS.resource_id IN (SELECT resource_id FROM jtf_rs_group_members WHERE TO_CHAR(group_id) = &GRANT_ALIAS.PARAMETER1)"
Please note that &TABLE_ALIAS is added as column alias in order to avoid problems with conflicting column names during runtime execution.
Note: Any new instance set must be designed very carefully. It must be error free and should perform well. Because any error introduced by the new set(s) can cause data corruption or erroneous behavior in Task Manager.
Use the following steps to define object instance sets.
Responsibility: FND Security Administration (Self Service Application)
Tips: First locate the object that you want a new instance set created for, then enter necessary information for the set.
Prerequisites
Steps
Navigate to Objects.
Enter necessary search information in the Find Objects window to locate the JTF_TASKS object. Search results should be listed after executing the search.
Click the object name hyperlink for which you want the new instance set to be created from the search result to open the Find Object Instance Set window.
Existing instance sets for the selected object are also listed here. Click Create New Instance.
Enter instance set detail information including instance set name, display name, description and predicate.
Save your work.
Once the instance set is registered, it can be granted to another resource, group of resources, or all resources. The system administrator needs to set resource group_id in the grant PARAMETER1.
Related Topics
Detailed information on how to define object instance sets, see Oracle E-Business Suite Security Guide.
Before adding new grants, it is necessary to first disable the existing grants or necessary seeded global grants so that they will not interfere with the new grants.
To temporarily disable the existing grants, the system administrator can set the end date for the existing grants, instead of deleting them completely.
Responsibility: FND Security Administration (Self Service Application)
Steps
Navigate to Grants.
Search the existing grants that you want to disable by entering search criteria in the Search Grants window.
Click Go to retrieve the grants that match your search criteria.
Select the grant that you want to disable from the search result.
Set an end date in the Context window and click Finish to disable the grant.
Related Topics
For more information on how to disable existing grants, see Oracle E-Business Suite Security Guide.
Once the customized resource LOV (object instance set) is created and registered, it can be granted to another resource, group of resources, or all resources.
Please note that the administrator can grant users or user groups (grantee) with different levels of data access privileges. The access can be granted to function (menu) level (such as "Administrator" role) or further down to the data level (such as the LOV data level) depends on users or business needs.
Since the LOV access privilege controls the row level of data access, whenever there is a need to create a new grant for LOV security access, use the data grant functionality to add this grant.
For example, if group number 10000123 contains all resources defined for the LOV in the object instance set, then the administrator can use data grant functionality to grant the LOV access to user21. As a result, the user can see all members of resource group 10000123 while creating a task. The data grant information should be like:
FND_GRANTS GRANTEE_TYPE = "USER" GRANTEE_KEY= "USER21" MENU_NAME = "JTF_TASK_RESOURCE_ACCESS" OBJECT_NAME = "JTF_RS_RESOURCE_EXTNS" INSTANCE_TYPE = "SET" INSTANCE_SET_NAME = X_JTF_RS_GROUP_MEMBERS" PARAMETER1 = "10000123"
Use the following steps to add a new grant:
Responsibility: Functional Administrator (Self Service Application)
Steps
Navigate to Grants.
Select Create Data Grant to add new grants to sales managers or sales representatives.
In the Object window, select JTF_TASKS as the object name.
In the Grantee window, select an appropriate radio button.
In the Function Set window, specify a menu name, such as JTF_TASK_RESOURCE_ACCESS.
In the Data Set window, select the A parameterized set of rows (Data Set) radio button. Furthermore, specify the appropriate object instance set that you want to grant to the grantee.
In the Data Set Details window, enter appropriate primary key values.
In the Context window, enter appropriate organization, responsibility and start date information. Leave the End Data field blank.
Enter JTF_TASKS in the Program Name field.
Enter appropriate information in the Program Tag field.
Click Finish. Once it is done successfully, the confirmation page opens with the message saying that the grant has been created.
Related Topics
More information on how to create data grants, see Oracle E-Business Suite Security Guide.
The Task resource list of values (LOV) security based on VPD policy allows managing a row level security for a database object which makes it possible for Tasks to further support product specific security rules. This VPD security model for the resource LOV security access in Tasks Forms and the Oracle Applications Framework based Tasks continues to:
Use AOL Data Security model as the repository for data security definition and the main tool for customization.
Use existing JTF Objects for different applications to integrate with various common application components. There are no changes to JTF Objects for VPD model.
Note: The resource list of value security access discussed here is restricted to the assignee list of values with resource types of employee, group, and team only.
Instead of having multiple views per an object, Task Manager registers necessary data into JTF Objects along with other seeded components.
Task resource LOV security references the following business objects seeded into JTF Objects:
JTF Object Code | FND Object Name | Referenced Object (Table/View) |
---|---|---|
RS_EMPLOYEE | JTF_RS_RESOURCE_EXTNS | JTF_RS_EMP_DTLS_VL |
RS_GROUP | JTF_RS_GROUPS | JTF_RS_GROUPS_VL |
RS_INDIVIDUAL | JTF_RS_RESOURCE_EXTNS | JTF_RS_DTLS_VL |
RS_OTHER | JTF_RS_RESOURCE_EXTNS | JTF_RS_RESOURCE_EXTNS A, JTF_RS_SALESREPS B |
RS_PARTNER | JTF_RS_RESOURCE_EXTNS | JTF_RS_PARTNER_DTLS_VL |
RS_PARTY | JTF_RS_RESOURCE_EXTNS | JTF_RS_PARTY_DTLS_VL |
RS_SUPPLIER_CONTACT | JTF_RS_RESOURCE_EXTNS | JTF_RS_SUPPLIER_DTLS_VL |
RS_TBH | JTF_RS_RESOURCE_EXTNS | JTF_RS_RESOURCE_EXTNS A, JTF_RS_SALESREPS B |
RS_TEAM | JTF_RS_TEAMS | JTF_RS_TEAMS_VL |
Task Manager resource LOV security uses the following seeded data to allow one function or view per an object:
Security Privileges (Functions). These form functions are defined on existing resource objects.
CAC_TASK_RS_EXTNS_SEC for the object JTF_RS_RESOURCE_EXTNS
CAC_TASK_RS_GROUPS_SEC for the object JTF_RS_GROUPS
CAC_TASK_RS_TEAMS_SEC for the object JTF_RS_TEAMS
These new privileges are seeded in the FND_FORM_FUNCTIONS table.
Security Role (Menu). These three new functions are added as menu entries to the followings:
Existing menu, JTF_TASK_RESOURCE_ACCESS, for backward compatibility. This menu is deprecated for Tasks in Oracle Applications Framework and Forms and is replaced by the new menu.
The existing privilege JTF_TASK_RESOURCE_ACCESS is used only in HTML Tasks to support backward compatibility.
New menu, CAC_TASK_RESORCE_ACCESS
This new menu is seeded in the FND_MENUS table or FND_MENU_ENTRIES table.
Security Views. Database views defined on top of existing resource tables:
CAC_TASK_RS_EXTNS_SEC on top of table JTF_RS_RESOURCE_EXTNS
CAC_TASK_RS_GROUPS_SEC on top of table JTF_RS_GROUPS
CAC_TASK_RS_TEAMS_SEC on top of table JTF_RS_TEAMS
VPD Policies. Common policy is attached to all secured views:
CAC_TASK_RS_EXTNS_POL attached to the CAC_TASK_RS_EXTNS_SEC view
CAC_TASK_RS_GROUPS_POL attached to the CAC_TASK_RS_GROUPS_SEC view
CAC_TASK_RS_TEAMS_POL attached to the CAC_TASK_RS_TEAMS_SEC view
Since Task Manager creates three new privileges (functions) and one new role (menu), CAC_TASK_RESORCE_ACCESS, to replace existing role, JTF_TASK_RESOURCE_ACCESS, for backward compatibility, future customization in HTML Task security specifically for the resource list of values security, implementors or system administrators need to use the following new resource privileges. The existing task privilege JTF_TASK_RESOURCE_ACCESS will be depreciated.
CAC_TASK_RS_EXTNS_SEC (for all individual resources)
CAC_TASK_RS_GROUPS_SEC (for resource groups)
CAC_TASK_RS_TEAMS_SEC (for resource teams)
All these new privileges are also added to the existing JTF_TASK_RESOURCE_ACCESS role (menu), so that all existing grants will be automatically uptaken.
For integrated applications that have added task privileges to customized roles, the administrator only need to add new privileges to these roles so that the security rules can be automatically applied.
Applications that want to uptake this resource LOV security should use the following instructions based on the uptake methods:
The standard resource LOV security is applied automatically in Task Manager, so that there is no any specific instruction for applications that will uptake tasks along with the standard resource security.
Example of Building a Secured Resource Query
The task applications code will simply query data by using the secured view instead of the base table. Predicate will be applied automatically by VPD policy.
String query = “SELECT b.group_id, l.group_name, l.group_desc “ + "FROM cac_task_rs_groups_sec b, jtf_rs_groups_tl l “ + “WHERE b.group_id = l.group_id AND l.language = userenv(‘LANG');”;
To incorporate enhanced the resource LOV security into your product, follow these instructions:
Define a privilege, AOL Data Security function, name on each resource object you want to secure for your product.
Define a view or synonym with the exactly same name, just a plain definition: “SELECT * FROM <resource fnd object>”. This is done through XML Definition File (XDF) technology.
Note: The XML Definition File (XDF), the next generation version of the current Object Definition File (ODF) utility, is used to provide support for capturing and altering the definitions for all schema Object types used by Oracle Applications and to eventually replace the ODF Utility.
Attach common AOL policy to the view. This is done through XDF technology.
Seed initial grants if any, such as global grants to support backward compatibility.
Pass product specific parameters to Task Manager for each privilege you want to replace in Forms or pass a class implementation in Oracle Applications Framework.
For Product Specific Resource LOV Security in the Oracle Applications Framework based Tasks
To support dynamic predicate binding into data security objects if passed by product specific security context, Task Manager adds one additional parameter to the TaskAssigneeSecurity interface to allow dynamic bindings of system context before the secured object is queried:
cacTaskAssigneeSecurityImpl = “oracle.apps.myproduct.MyTaskAssigneeSecurityImpl”;
However, if provided class does not exist or cannot be instantiated or executed by the Tasks module, then a run-time exception will be generated.
Example of Query Secured Resources for Tasks in Oracle Applications Framework
Translate the class name into a class object
Class c = Class.forName(<value of parameter cacTaskAssigneeSecurityImpl>);
Reflective instantiation with interface access
TaskAssigneeSecurity mySecurity = (TaskAssigneeSecurity) c.newInstance();
Set context if it is not null
mySecurity.setGroupContext();
Build an LOV query before executing it
String query = “SELECT b.group_id, l.group_name, l.group_desc ” + “FROM “ + mySecurity.getGroupFuncName() + “ b, jtf_rs_groups_tl l ” + “WHERE b.group_id = l.group_id AND l.language = userenv(‘LANG');”;
For Resource LOV Security Access in Forms-Based Tasks
Applications that want to uptake this security should set the necessary context in the parent form, such as Service Request Form, to implement the resource LOV security. If the context is set, then the parent form will pass parameters (function names) to the Task Manager form.
If a parameter value is not null, then the secured views are used to query resources. Otherwise, the JTF Objects metadata will be used.
Note: When defining JTF Objects metadata in the metadata setup window, implementors can select the "From Task" check box for a specific source if tasks can be created, updated, and deleted using the standalone Task Manager. If it is unchecked, then tasks can be queried in read-only format from the Task Manager Forms. Any updates to the tasks should be made from the parent applications.
Additionally, the following three parameters should be passed to Task Manager form:
Employee Resource: TASK_ASG_LOV_EMP_SEC
Group Resource: TASK_ASG_LOV_GROUP_SEC
Team Resource: TASK_ASG_LOV_TEAM_SEC
Example of Query Resources Using Metadata in Forms
If (l_source_object_type_code = 'RS_GROUP') then l_task_asg_lov_group_sec := name_in('parameter.task_asg_lov_group_sec'); If (l_task_asg_lov_group_sec != null) then l_sql_query := 'SELECT b.group_id, l.group_name, l.group_desc'|| ' FROM ' || l_task_lov_group_sec || ' b, jtf_rs_groups_tl l ' || ' WHERE b.group_id = l.group_id AND l.language = userenv("LANG")'; else (Use JTF Objects metadata to query group resources;) end if; end if; else if (l_source_object_type_code = 'RS_TEAM') then (Use JTF Objects metadata to query team resources;) else if (l_source_object_type_code = 'RS_EMPLOYEE') then (Use JTF Objects metadata to query employee resources;) end if;
Task Manager recommends using of the standard resource privileges, not product specific privileges, if you can when uptaking this security feature. Because standard resource privileges, providing standard "one-place” data security setting in your applications to secure tasks access, are seeded with Task Manager which requires no further implementation step.
Applications can use product specific privileges to uptake this resource LOV security only if there are product specific security requirements in place.
Note: Be aware that the product specific privileges belong to the product owner and should be developed, and maintained by the product team, not by Task Manager.
In order to support reporting hierarchy used in Sales or Support organizations, HTML Tasks and Tasks in Oracle Applications Framework allow group managers who have effective manager's role to have appropriate privileges to access their direct's tasks if necessary permissions are granted to them. Sales managers, for example, can view their direct's tasks and be able to track possible sales related activities performed for a particular week.
Task Manager uses the manager-direct security access functionality to grant group managers an appropriate access privilege (read only or full access) to view or update their resource group member's non-private tasks.
Use the following example to understand how this functionality works in a resource group hierarchy.
For example, a resource group is lead by Helen Freeman who has three directs reporting to her. These three directs are Jack William, Jeff Walsh, and Alex Brown who plays the administrator in Helen's group. Jeff Walsh who reports to Helen has three group members directly reporting to him. They are Pat Smith, Jim Breen, and Frank Nelson who plays the administrator role.
Helen Freeman's Group Hierarchy
After this resource group is organized, the hierarchical data will be denormalized and populated in the table JTF_RS_REP_MANAGERS as follows:
Member Name | Associated Group | Hierarchy Type | Parent Resource Name | Denormal- ization Levels |
---|---|---|---|---|
Alex Brown | HF's group | ADMIN_TO_ADMIN | Alex Brown | 0 |
Jeff Walsh | HF's group | MGR_TO_MGR | Helen Freeman | 1 |
Jeff Walsh | JW's group | MGR_TO_MGR | Helen Freeman | 1 |
Jim Breen | JW's group | MGR_TO_REP | Helen Freeman | 1 |
Frank Nelson | JW's group | MGR_TO_ADM | Helen Freeman | 1 |
Pat Smith | JW's group | MGR_TO_REP | Helen Freeman | 1 |
Alex Brown | HF's group | MGR_TO_ADMIN | Helen Freeman | 0 |
Helen Freeman | HF's group | MGR_TO_MGR | Helen Freeman | 0 |
Jack William | HF's group | MGR_TO_REP | Helen Freeman | 0 |
Jeff Walsh | HF's group | MGR_TO_REP | Helen Freeman | 0 |
Pat Smith | JW's group | REP_TO_REP | Pat Smith | 0 |
Jim Breen | JW's group | REP_TO_REP | Jim Breen | 0 |
Jack William | HF's group | REP_TO_REP | Jack William | 0 |
Frank Nelson | JW's group | ADM_TO_ADM | Frank Nelson | 0 |
Pat Smith | JW's group | MGR_TO_REP | Jeff Walsh | 0 |
Frank Nelson | JW's group | MGR_TO_ADM | Jeff Walsh | 0 |
Jim Breen | JW's group | MGR_TO_REP | Jeff Walsh | 0 |
Jeff Walsh | JW's group | MGR_TO_MGR | Jeff Walsh | 0 |
Jeff Walsh | HF's group | REP_TO_REP | Jeff Walsh | 0 |
Note: In addition to the columns in the JTF_RS_REP_MANAGERS table, the following columns must be considered:
START_DATE_ACTIVE
END_DATE_ACTIVE
After understanding the functionality of the manager-directs access and how it works, the definition of a reporting hierarchy should be further identified.
The definition of manager-subordinate hierarchy used for granting security access is based on the resource Group Hierarchy defined in Resource Manager. It is not based on the Human Resource (HR) reporting structure defined in the HR system.
Group Hierarchy in Resource Manager
While defining resource group hierarchy in Resource Manager, each resource will perform certain roles in a resource group. For example, a sales group can be organized by a few sales representatives and a sales manager. The sales representative and sales manager are the roles that are associated with each resource in that group.
In order to determine the reporting hierarchy in a group, each role is also associated to a specific role attribute. When a role is assigned to a resource, a role attribute is also given to that resource simultaneously. A sales representative role is associated with a member role attribute, and a sales manager role is linked to a manager role attribute. Therefore, group members with sales representative roles could report to the group member with sales manager role in the sales resource group mentioned earlier.
Each resource group can be formed for a specific period of time, so as to the group member's roles. Therefore, when an end date (END_DATE_ACTIVE) is specified for a resource group or for any resource role of the group members, that group or a specific role can be terminated.
For more information, see Resource Manager chapter in the Oracle Trading Community Architecture Technical Implementation Guide.
Highlights of Group Hierarchy For the Manager-Directs Security Access
Since the manager-directs security grant functionality is based on the group hierarchy defined in Resource Manager, not HR hierarchy, it is possible to have multiple managers in one resource group, and these managers will all be granted with security access to view or update their direct's tasks for HTML Tasks and the Oracle Applications Framework based Tasks.
In addition, as resource groups and roles can be terminated, only the managers who have effective manager's roles can be granted with security access to their direct subordinate's tasks. This grant only works if the managers belong to an effective resource group. If one of the manager's subordinates left the group, or the role has been terminated, then the manager will not be able to see the subordinate's tasks even if the manager has full access privilege.
Note: Although full access is granted to a group manager, that manager still cannot see his or her direct's private tasks.
A new object instance set JTF_TASK_MANAGER_SECURITY is seeded in Tasks to support the manager-directs security grant functionality.
Task Manager supports the manager-directs security grants, however, there are some restrictions for performance reasons and avoiding complexity.
Only Support "Manager" and "Member" Role Attributes
Resource Manager uses four role attributes (manager, admin, lead, and member) to associate a resource role while defining a resource role. However, this functionality only supports the Manager and Member role attributes.
Only Support One Level of Group Hierarchy
Resource Group Hierarchy
A group might have parent groups and child groups. However, Task Manager only supports one level of group hierarchy for the manager-directs security access. This means that a manager can only be granted with access of his subordinate's tasks of one level below him. It does not include any multiple levels beneath. In other words, this grant only limits to one group. It does not extend to its parent or child groups.
Only Implemented in HTML Tasks and Oracle Applications Framework based Tasks
This functionality only applies to HTML Tasks and the Oracle Applications Framework based Tasks. It is not implemented in the Forms-based Tasks.
Use the following steps to grant security access to group managers:
Use Oracle Resource Manager to define resource group hierarchy.
Note: After defining appropriate groups, the group hierarchical data is denormalized and populated in the table JTF_RS_REP_MANAGERS.
Detailed information on how to define employee resources, group resources, and assigning appropriate group member roles to each group member, see Resource Manager chapter,Oracle Trading Community Architecture Technical Implementation Guide.
Once the appropriate group hierarchy is identified, system administrator can grant the seeded object instance set JTF_TASK_MANAGER_SECURITY with read only or full access to appropriate group managers.
Use the following steps to add a new grant to resource group managers.
Responsibility: FND Security Administration (Self Service Application)
Steps
Navigate to Grants.
Select Create Data Grant to add new grants to sales managers or sales representatives.
In the Object window, select JTF_TASKS as the object name.
In the Grantee window, select an appropriate radio button.
In the Function Set window, specify a menu name (JTF_TASK_READ_ONLY or JTF_TASK_FULL_ACCESS) for either read only or full access.
In the Data Set window, select the A parameterized set of rows (Data Set) radio button. Furthermore, specify the seeded object instance set JTF_TASK_MANAGER_SECURITY.
In the Context window, enter appropriate organization, responsibility and start date information. Leave the End Data field blank.
Enter JTF_TASKS in the Program Name field.
Enter appropriate information in the Program Tag field.
Click Finish. Once it is done successfully, the confirmation page opens with the message saying that the grant has been created.
Related Topics
For more information on how to create data grants, see Oracle E-Business Suite Security Guide.