Search Results igc_cc_access_pk




Overview

IGC_CC_ACCESS is an access control table within the Oracle E-Business Suite IGC (Contract Commitment) product module. It governs which users are permitted to view or act upon contract records and contract groups, functioning as the authorization link between the FND_USER directory and the contract commitment data model. In both Oracle EBS 12.1.1 and 12.2.2, the table is owned by the IGC schema and is documented as VALID in the ETRM repository, with a documented physical schema of eleven columns under the 12.2.2 signature.

From a Data Vault modeling perspective, the mined foreign-key structure suggests classifying IGC_CC_ACCESS as a link entity. It resolves a many-to-many relationship between application users and contract access groupings, carrying descriptive attributes (access level and access type) as link-level payload rather than as a standalone hub or satellite. This classification is a heuristic derived from the FK topology and should be treated as a modeling suggestion rather than an enforced design constraint.

Key Information Stored

The table is anchored by the surrogate primary key IGC_CC_ACCESS_PK, defined on the CC_ACCESS_ID column. A unique index, IGC_CC_ACCESS_U1, is also documented on CC_ACCESS_ID, confirming it as the principal business-key candidate. The most significant columns are:

  • CC_ACCESS_ID — surrogate primary key uniquely identifying each access grant row.
  • USER_ID — foreign key to FND_USER, identifying the application user to whom access is granted.
  • CC_GROUP_ID — foreign key identifying the contract commitment group or grouping construct to which the grant applies.
  • CC_HEADER_ID — reference to the specific contract commitment header record governed by the access row.
  • CC_ACCESS_LEVEL — the permission level assigned to the user for the referenced contract or group.
  • CC_ACCESS_TYPE — categorizes the nature of the access grant (for example, distinguishing group-level from record-level authorization).
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard EBS audit columns capturing who changed the row and when.
  • CREATION_DATE, CREATED_BY — standard EBS audit columns capturing row creation context.

The combination of USER_ID, CC_GROUP_ID, and CC_HEADER_ID defines the effective security scope, while the audit columns support change tracking and concurrency management in a multiuser EBS environment.

Common Use Cases and Queries

Security administrators and developers query IGC_CC_ACCESS to determine which users may access a given contract or contract group, and to troubleshoot permissions when a user reports an authorization failure. Reporting use cases include producing access entitlement audits, identifying orphaned grants for deactivated users, and reconciling group-level versus record-level permissions.

A typical join resolves user identities for a contract header:

  • SELECT a.CC_ACCESS_ID, u.USER_NAME, a.CC_ACCESS_LEVEL, a.CC_ACCESS_TYPE FROM IGC.IGC_CC_ACCESS a, FND_USER u WHERE a.USER_ID = u.USER_ID AND a.CC_HEADER_ID = :header_id;

An entitlement audit listing all groups visible to a user follows the same pattern keyed on USER_ID and CC_GROUP_ID. Because access checks occur at runtime, direct DML against this table is not recommended; modifications should flow through the IGC contract commitment application logic to preserve FK integrity and audit consistency.

Related Objects

The following objects are most significant in relation to IGC_CC_ACCESS, based on the documented FK and PK relationships:

  • FND_USER — referenced via IGC_CC_ACCESS.USER_ID; supplies the identity of the authorized user.
  • IGC_CC_ACCESS_PK — the primary key constraint enforcing uniqueness of CC_ACCESS_ID.
  • IGC_CC_ACCESS_U1 — the unique index backing CC_ACCESS_ID as the business-key candidate.
  • Contract commitment group and header tables referenced through CC_GROUP_ID and CC_HEADER_ID, which define the secured data scope.
  • FND_USER dependent audit and responsibility tables that participate in EBS security resolution.

The table's position as a link between FND_USER and the contract commitment structures makes it a central artifact for any investigation of IGC contract security behavior.