Search Results jtf_rs_role_type




Overview

APPS.JTF_RS_ROLE_RELATIONS_VL is a reporting and integration view in the Oracle E-Business Suite Resource Manager (JTF_RS) schema. It presents the relationship between a role definition and the resource or group to which that role is assigned, joined to the role's descriptive attributes and to the lookup that classifies the role type. Because the view resolves the role type code to its lookup meaning and filters out logically deleted rows, it provides a clean, denormalized projection suitable for concurrent programs, OAF/Forms LOVs, Oracle Reports, XML Publisher data templates, and inbound/outbound interface extracts.

The "_VL" suffix conventionally denotes a view that has been validated for translation-enabled columns via a corresponding "_TL" table pattern; here the joined role view JTF_RS_ROLES_VL supplies the translated role name while the role relations themselves remain language-independent. The view is owned by APPS and is therefore expected to be queried with the standard MO: Operating Unit and MO: Security Profile initialization, since row visibility in the Resource Manager model is often driven by FND_GLOBAL context.

Underlying Base Objects

The view is defined over three joined sources plus one documented package dependency:

  • JTF_RS_ROLE_RELATIONS (accessed via synonym) — the driving table holding one row per role-to-resource assignment, including the polymorphic role_resource_type/role_resource_id pair, the validity dates, and the delete_flag.
  • JTF_RS_ROLES_VL (view) — supplies role_name, role_code, role_type_code, and the role behavior flags (member_flag, admin_flag, lead_flag, manager_flag) for the joined role_id.
  • FND_LOOKUPS (view) — resolves role_type_code against lookup_type = 'JTF_RS_ROLE_TYPE' to return the descriptive meaning of the role type.
  • FND_GLOBAL (package) — documented as a referenced base object, confirming that the view participates in the standard EBS runtime context (user_id, responsibility_id, org_id) used by Resource Manager security and defaulting logic.

The join conditions are rrt.role_id = rol.role_id for the role attributes and rol.role_type_code = fnd.lookup_code with fnd.lookup_type = 'JTF_RS_ROLE_TYPE' for the classification meaning. The predicate NVL(rrt.delete_flag,'N') <> 'Y' excludes soft-deleted relations, so consumers should not need to add their own delete_flag filter.

Key Columns

Common Use Cases and Queries

Typical uses include listing all roles held by a resource, reporting role membership by role type, and feeding role-assignment extracts.

  • Roles for a specific resource:
    SELECT role_name, meaning, start_date_active, end_date_active FROM apps.jtf_rs_role_relations_vl WHERE role_resource_type = :p_type AND role_resource_id = :p_id AND TRUNC(SYSDATE) BETWEEN NVL(start_date_active,SYSDATE) AND NVL(end_date_active,SYSDATE+1);
  • Headcount by role type:
    SELECT meaning, COUNT(*) FROM apps.jtf_rs_role_relations_vl GROUP BY meaning ORDER BY 2 DESC;
  • Manager-flagged assignments:
    SELECT role_name, role_resource_id FROM apps.jtf_rs_role_relations_vl WHERE manager_flag = 'Y';

Because the lookup join is an inner join on role_type_code, roles whose type code is not present in FND_LOOKUPS for 'JTF_RS_ROLE_TYPE' will be omitted from this view; validate lookup completeness before relying on it for reconciliation. The search term "jtf_rs_role_type" corresponds to this lookup_type, which is the classification backbone of the view.