Search Results bsc_kpi_shell_cmds_user




Overview
Explore in AI Chat

Overview

The BSC_KPI_SHELL_CMDS_USER table is a core data object within the Oracle E-Business Suite Balanced Scorecard (BSC) module. Its primary function is to manage user-level security and personalization for executable commands associated with Key Performance Indicators (KPIs). The table acts as a junction or linking table, establishing a many-to-many relationship between users (BSC_USERS) and available shell commands (BSC_KPI_SHELL_CMDS_TL). This design enables the system to control which specific commands, such as drill-downs, analyses, or external application launches, are accessible to individual users for a given KPI, thereby enforcing role-based access within the performance management framework.

Key Information Stored

The table's structure is defined by a composite primary key, which uniquely identifies each user-command permission record. The critical columns are:

  • INDICATOR: A foreign key column that, in conjunction with SHELL_CMD_ID, references the BSC_KPI_SHELL_CMDS_TL table. This identifies the specific KPI or indicator to which the command is attached.
  • SHELL_CMD_ID: The second part of the foreign key to BSC_KPI_SHELL_CMDS_TL, uniquely identifying the command shell definition for the given indicator.
  • USER_ID: A foreign key column referencing the BSC_USERS table. This identifies the user who is granted access to the specific command for the specific indicator.

The presence of a row in this table signifies that the user has permission to see and execute the linked command. The absence of a row implies the command is hidden or disabled for that user.

Common Use Cases and Queries

A primary use case is auditing and administering user permissions for KPI actions. System administrators may query this table to generate reports on which commands are available to specific users or roles, or to troubleshoot cases where a user cannot see an expected KPI action button. A common pattern is to join with the translation table to get the command's display name and with the users table for user details.

Sample Query: List Commands for a User
SELECT usr.USER_NAME, cmd.NAME, ksu.INDICATOR
FROM BSC_KPI_SHELL_CMDS_USER ksu,
BSC_USERS usr,
BSC_KPI_SHELL_CMDS_TL cmd
WHERE ksu.USER_ID = usr.USER_ID
AND ksu.INDICATOR = cmd.INDICATOR
AND ksu.SHELL_CMD_ID = cmd.SHELL_CMD_ID
AND usr.USER_NAME = 'JDOE';

Another critical operational use is during the rendering of a KPI dashboard. The application logic will query this table, filtered by the current user's ID and the displayed KPIs, to dynamically build the list of actionable commands presented in the UI.

Related Objects

The table is centrally connected to two other primary BSC tables via foreign key constraints:

  • BSC_USERS: The relationship is BSC_KPI_SHELL_CMDS_USER.USER_ID → BSC_USERS. This links the permission record to a defined user within the Balanced Scorecard.
  • BSC_KPI_SHELL_CMDS_TL: The relationship is BSC_KPI_SHELL_CMDS_USER.(INDICATOR, SHELL_CMD_ID) → BSC_KPI_SHELL_CMDS_TL. This links the permission record to the master definition and translated name of the executable command shell for a KPI.

These relationships ensure referential integrity, meaning a user-command link cannot exist for a non-existent user or a non-existent command definition. The BSC_KPI_SHELL_CMDS_TL table itself is likely a child of a base definition table (such as BSC_KPI_SHELL_CMDS_B), forming the complete command metadata model.