Search Results cs_sr_access_resp_sec

Overview

CS_SR_ACCESS_RESP_SEC is a Service (CS) module view within Oracle E-Business Suite 12.1.1 and 12.2.2. It exposes the access control and responsibility security metadata associated with Service Requests (SRs), which are stored in the INCIDENT tables of the Service foundation layer. The view is designed to support the security model that governs which service request records are visible to a given user based on responsibility and access configuration.

Because the view carries an "_SEC" suffix, it participates in the Oracle EBS row-level security framework used by the Service module. Rather than presenting the transactional service request detail alone, it surfaces the combination of SR attributes and the security attributes needed to filter results according to the responsibilities and access rules assigned to the querying user.

In practice the view plays a reporting and integration role: it allows custom reports, Discoverer workbooks, OBIEE extracts, and interface programs to retrieve service request data conforming to the user's access privileges without re-implementing the underlying security logic manually.

Underlying Base Objects

The supplied ETRM metadata records the implementation status as "Not implemented in this database" and lists no documented referenced base objects. This is significant for two reasons. First, it indicates that in the environment used to generate the extracted metadata, the view may not have been deployed, so introspection could not resolve its dependencies. Second, the absence of documented base objects means the formal dependency list is not authoritative for all environments.

Analysis of the view text reveals that it is defined over a single alias, "B", which is the standard alias for CS_INCIDENTS_ALL_B (or the service request base tables). Every selected column is qualified by "B." and references SR-level attributes. Notably, the view text excerpt does not show a WHERE clause or a join to a security or access mapping table, which suggests the security predicate may be embedded in the remainder of the view text beyond the excerpt, or applied through a policy function on the underlying table. The rows returned are therefore organized by the SR record identified through INCIDENT_ID, with each attribute representing a field on that incident.

Key Columns

• INCIDENT_ID — Primary identifier of the service request; the join key to other SR-related objects.
• INCIDENT_NUMBER — User-facing service request number.
• INCIDENT_STATUS_ID, INCIDENT_TYPE_ID, INCIDENT_URGENCY_ID, INCIDENT_SEVERITY_ID — Status, type, urgency, and severity classification IDs used for filtering and routing.
• INCIDENT_OWNER_ID, OWNER_GROUP_ID — Current owner and owner group, central to responsibility-based access.
• ORG_ID — Operating unit identifier, essential for multi-org security.
• CUSTOMER_ID, ACCOUNT_ID, SITE_ID — Customer, account, and site associations.
• CREATED_BY, LAST_UPDATED_BY, LAST_UPDATE_DATE — Standard audit columns.
• INCIDENT_ATTRIBUTE_1 through INCIDENT_ATTRIBUTE_15 — The flexible descriptive flexfield attribute columns. The user's search for "incident_attribute_1" resolves here: INCIDENT_ATTRIBUTE_1 is the first of fifteen DFF segments used to store customer-defined data on the service request, frequently repurposed for channel, source, or classification values.
• RESOLUTION_CODE, ACTUAL_RESOLUTION_DATE, CLOSE_DATE, EXPECTED_RESOLUTION_DATE — Resolution tracking fields.

Common Use Cases and Queries

Typical uses include building responsibility-scoped service request reports, validating that security rules return the correct rows, and auditing attribute usage across SRs.

SELECT incident_id,
       incident_number,
       incident_status_id,
       incident_attribute_1,
       incident_attribute_2,
       org_id
FROM   cs_sr_access_resp_sec
WHERE  org_id = :p_org_id
AND    NVL(incident_attribute_1, 'X') <> 'X';

The above query finds service requests where the first descriptive flexfield segment (INCIDENT_ATTRIBUTE_1) has been populated, a common requirement when a customer repurposes that segment as a tracking or source code. A second common pattern joins the view to reference tables to resolve the IDs into meaningful values, while a third uses it as the secure data source for extracts, relying on the view's own security behavior rather than adding manual predicates. Because the metadata indicates the view may not be implemented in every database, users should verify its existence and the completeness of its security predicate before depending on it in production.