Results for “igc_cc_access_v”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IGC_CC_ACCESS_V is a reporting view owned by the APPS schema within the IGC (Contract Commitment) product family of Oracle E-Business Suite. In releases 12.1.1 and 12.2.2 the view exposes the security and access-control configuration that governs who may view or act upon contract commitment headers. It is not a transactional data view but rather a denormalized, human-readable representation of the IGC_CC_ACCESS records joined to the descriptive attributes of groups, users, and lookup meanings.

The view exists to simplify both internal form logic and external reporting. Because access records in the base table IGC_CC_ACCESS are stored with either a group reference or a user reference in a single row — one of the two foreign keys being null depending on the access type — the view reconciles these two mutually exclusive patterns using a UNION so that consumers receive a uniform result set with consistent column semantics. This makes the view suitable for access audits, security reviews, and integration extracts that must resolve raw IDs into meaningful names.

Underlying Base Objects

The documented base objects referenced by the view are IGC_CC_ACCESS (synonym), IGC_CC_GROUPS (synonym), FND_USER (synonym), FND_LOOKUPS (view), and FND_GLOBAL (package). The view text is composed of two SELECT branches joined by UNION. The first branch joins IGC_CC_ACCESS to IGC_CC_GROUPS on CC_GROUP_ID where the user reference is null (NVL(USER_ID,0) = 0), returning group-level access rows. The second branch joins IGC_CC_ACCESS to FND_USER on USER_ID where the group reference is null (NVL(CC_GROUP_ID,0) = 0), returning user-level access rows. Both branches outer-join FND_LOOKUPS on lookup type 'IGC_CC_ACCESS_TYPE' to translate CC_ACCESS_TYPE into its descriptive meaning.

Because FND_GLOBAL is a package rather than a table, it is referenced indirectly for session context such as the effective user, which supports applying access filtering in downstream logic. The FND_USER synonym resolves to the standard EBS user table, and IGC_CC_GROUPS holds the commitment group definitions used in the group-based branch.

Key Columns

• ROW_ID — the ROWID of the underlying IGC_CC_ACCESS row, available for direct row addressing.
• CC_HEADER_ID — identifies the contract commitment header to which the access rule applies.
• CC_ACCESS_ID — primary key of the access record.
• CC_ACCESS_LEVEL — the granted access level (the value frequently located via searches for "cc_access_level").
• CC_ACCESS_TYPE — lookup code from the 'IGC_CC_ACCESS_TYPE' lookup type.
• CC_ACCESS_TYPE_NAME — the MEANING from FND_LOOKUPS corresponding to the access type code.
• CC_GROUP_ID / CC_GROUP_NAME — populated in the group branch; zero and blank in the user branch.
• USER_ID / USER_NAME — populated in the user branch; zero and blank in the group branch.
• Audit columns — LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical uses include auditing which users and groups hold access to a given contract commitment, resolving access levels for reporting, and driving custom security checks in extensions.

• List all access rules for a specific header:

  SELECT cc_access_id, cc_access_level, cc_access_type_name,
         cc_group_name, user_name
  FROM   apps.igc_cc_access_v
  WHERE  cc_header_id = :p_header_id;

• Find group-based grants only:

  SELECT cc_header_id, cc_group_id, cc_group_name, cc_access_level
  FROM   apps.igc_cc_access_v
  WHERE  NVL(cc_group_id,0) <> 0;

• Find user-based grants only:

  SELECT cc_header_id, user_id, user_name, cc_access_level
  FROM   apps.igc_cc_access_v
  WHERE  NVL(user_id,0) <> 0;

• Resolve an access level to its descriptive type name:

  SELECT cc_header_id, cc_access_level, cc_access_type_name
  FROM   apps.igc_cc_access_v
  WHERE  user_name = :p_user;

Because the view already outer-joins FND_LOOKUPS and reconciles the group/user duality, reports built on it avoid duplicating that join and branching logic, reducing maintenance and improving consistency across IGC contract commitment reporting.