Customizing Tasks Security

This chapter covers the following topics:

Task Security Overview

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:

Understanding AOL Data Security in HTML Tasks

Before implementing AOL data security model, Task Manager can implicitly grant users with the following task security access:

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

The following figure illustrates the high level picture of the task security rule analysis.

Task Security Rule Analysis

the picture is described in the document text

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:

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 System Administrator's Guide - Security.

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:

How Does the AOL Security Model Work?

With the leverage of AOL data security model, Task Manager adds the following two security functions to the security model:

With the two new functions added to Tasks, appropriate task instances are presented in the following logic:

For example, for the standalone task screens:

  1. Add predicate to the main query.

  2. Check full access privilege for retrieved task instances.

  3. Display task instance(s) as updatable or read-only.

  4. Check corresponding privilege before accessing the detail page.

Security Model for Tasks in Forms and Oracle Applications Framework for Resource Assignments

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:

Business Process Change to Support VPD Security Model

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

  1. Select the object type, such as Employee (RS_EMPLOYEE) for assignee or owner type

  2. Find related JTF Object

  3. Create query from metadata

  4. Find related FND Object if any

  5. Generate a predicate for the FND Object and Task's standard privilege (data security function)

  6. Add predicate to the query

  7. 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:

Customizing Tasks Data Security

Based on the task security model, Task Manager allows task security rules to be further customized in the following ways:

Setting the Security Profile Option

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:

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:

If Security Access is selected which turns the security function on, then the access privileges are changed to:

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:

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:

  1. Check the profile value first to determine whether to display task instance(s) as updatable or read-only; then

  2. 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.

Customizing the List of Values Security Access

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:

Customizing the List of Values Security for HTML Tasks

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.

JTF Object

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:

Other Seeding Strategy

In addition to the JTF object change, HTML Task Manager also makes the following changes in order to support the LOV security:

Creating Privilege (Function) and Role (Menu)

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.

Registering LOV Object Data

Task resource LOV security references the following business objects seeded into JTF Objects:

Seeded Object Data
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

Creating Global Grants

In order to provide backward compatibility, the following global grants are shipped:

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.

Customizing Resource LOV

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.

Perform the following procedures:

  1. Defining Object Instance Sets

  2. Disabling Existing Grants

  3. Adding New Grants

Defining Object Instance Sets

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)"

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

  1. Navigate to Objects.

  2. Enter necessary search information in the Find Objects window to locate the JTF_TASKS object. Search results should be listed after executing the search.

  3. 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.

  4. Existing instance sets for the selected object are also listed here. Click Create New Instance.

  5. Enter instance set detail information including instance set name, display name, description and predicate.

  6. 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 System Administrator's Guide.

Disabling Existing Grants

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

  1. Navigate to Grants.

  2. Search the existing grants that you want to disable by entering search criteria in the Search Grants window.

  3. Click Go to retrieve the grants that match your search criteria.

  4. Select the grant that you want to disable from the search result.

  5. 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 System Administrator's Guide.

Adding New Grants

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

  1. Navigate to Grants.

  2. Select Create Data Grant to add new grants to sales managers or sales representatives.

  3. In the Object window, select JTF_TASKS as the object name.

  4. In the Grantee window, select an appropriate radio button.

  5. In the Function Set window, specify a menu name, such as JTF_TASK_RESOURCE_ACCESS.

  6. 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.

  7. In the Data Set Details window, enter appropriate primary key values.

  8. In the Context window, enter appropriate organization, responsibility and start date information. Leave the End Data field blank.

  9. Enter JTF_TASKS in the Program Name field.

  10. Enter appropriate information in the Program Tag field.

  11. 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 System Administrator's Guide.

Customizing the Resource List of Values Security for Tasks in Oracle Applications Framework and Forms

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:

Task Resource LOV Security Seeding Strategy

Instead of having multiple views per an object, Task Manager registers necessary data into JTF Objects along with other seeded components.

JTF Objects

Task resource LOV security references the following business objects seeded into JTF Objects:

Seeded Object Data
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

Other Seeding Data

Task Manager resource LOV security uses the following seeded data to allow one function or view per an object:

Impact on Existing HTML Tasks

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.

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.

Uptake Instructions

Applications that want to uptake this resource LOV security should use the following instructions based on the uptake methods:

Uptake with Standard Task Resource Security

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');”;

Uptake with Product Specific (Non-Standard) Resource Security

To incorporate enhanced the resource LOV security into your product, follow these instructions:

  1. Define a privilege, AOL Data Security function, name on each resource object you want to secure for your product.

  2. 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.

  3. Attach common AOL policy to the view. This is done through XDF technology.

  4. Seed initial grants if any, such as global grants to support backward compatibility.

  5. 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

  1. Translate the class name into a class object

    Class c = Class.forName(<value of parameter cacTaskAssigneeSecurityImpl>);

  2. Reflective instantiation with interface access

    TaskAssigneeSecurity mySecurity = (TaskAssigneeSecurity) c.newInstance();

  3. Set context if it is not null

    mySecurity.setGroupContext();

  4. 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:

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;

Uptake Considerations

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.

Granting Manager-Directs Security Access

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.

The Functionality of Manager-Directs Security Access

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.

After this resource group is organized, the hierarchical data will be denormalized and populated in the table JTF_RS_REP_MANAGERS as follows:

Group Denorm Data in the JTF_RS_REP_MANAGERS TABLE
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:

After understanding the functionality of the manager-directs access and how it works, the definition of a reporting hierarchy should be further identified.

Definition of Reporting Hierarchy

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.

Seeding Strategy

A new object instance set JTF_TASK_MANAGER_SECURITY is seeded in Tasks to support the manager-directs security grant functionality.

Other Limitations

Task Manager supports the manager-directs security grants, however, there are some restrictions for performance reasons and avoiding complexity.

Customizing Manager-Directs Security Access

Use the following steps to grant security access to group managers:

Defining Resource Group Hierarchy

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.

Granting Security Access to Relevant Resources

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

  1. Navigate to Grants.

  2. Select Create Data Grant to add new grants to sales managers or sales representatives.

  3. In the Object window, select JTF_TASKS as the object name.

  4. In the Grantee window, select an appropriate radio button.

  5. 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.

  6. 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.

  7. In the Context window, enter appropriate organization, responsibility and start date information. Leave the End Data field blank.

  8. Enter JTF_TASKS in the Program Name field.

  9. Enter appropriate information in the Program Tag field.

  10. 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 System Administrator's Guide.