## Summary Add a hyperlink from DAP credit consumption rows in the GitLab Credits user drill-down to the corresponding DAP session details view, using a `session_id` provided by AI Gateway / DAP. **Ownership and scope** * **Utilization** owns: linking the usage-by-user rows to sessions and the associated billable-event fields for linking (user_id, feature_type, credits, timestamp, session_id, optional session_url/project_path). * **DAP** owns: the Session Details user experience and the underlying session data model. This includes what appears on the session details surface (status, tokens, models, actions, transcript, artifacts, etc.). This issue does not define which fields appear on the Session Details view; which are specified here: * [DAP Session Details Panel - Comprehensive Visibility for Artifacts, Credits, and LLM Usage (#584686)](https://gitlab.com/gitlab-org/gitlab/-/issues/584686) * [DAP Flow Session Traceability and Audit Trail for Enterprise Compliance (#584692)](https://gitlab.com/gitlab-org/gitlab/-/issues/584692) This issue ensures that admins can get from the **GitLab Credits dashboard** to those DAP-owned session views for a specific `session_id`. ## Background Today, the **GitLab Credits dashboard** provides a **per-user view** of DAP credit consumption, with a table that shows: * **Date/Time** * **Action** (e.g., _Agentic Chat_, _Foundational Agents_) * **Location** (e.g., _GitLab.org_, _customers-gitlab-com_) * **Credit amount** {width="900" height="353"} This view shows who used how many credits, when, and where. However, it does not provide insight into what exactly happened in that DAP session. To investigate, admins and support engineers must manually correlate timestamps with DAP session logs or ask the AI teams to dig into separate traces. ## Problem Customers and internal stakeholders need to be able to trust that billing accurately reflects what actually ran. * Today, the Credits dashboard shows aggregate usage by user and action, but there is no direct link to which DAP session produced that usage. * Field teams cannot easily show customers a mapping from session to credits consumed, which would increase confidence in usage-based billing. Without a session-level link, we are missing: * An audit trail between billing and AI sessions. * A fast path for debugging bills and support escalations. * A clear UX method to view concrete session behavior ## In-Scope 1. Session Correlation * Allow anyone who can access the usage-by-user view in the GitLab Credits dashboard (Group Owners for the namespace and Instance Admins for the instance/Dedicated environment) to go from a Credits dashboard row to the exact DAP session that generated it, using `session_id`. This also enables Support to do the same when operating with equivalent access. 2. Minimal UI Change * Reuse the existing user drill-down table and make DAP actions clickable, rather than adding new UI in the billing surface. ## Out of Scope 1. Inline full DAP session logs or transcripts directly in the Credits dashboard table. For this feature, the Credits dashboard must remain a high-level billing summary plus a link into the DAP session details surface, not a full log viewer for every row. 2. Change who is authorized to see DAP session contents (auth remains defined and enforced by DAP / AI Gateway). 3. Solve all aspects of in-session usage visibility (like live token meters or pre-run estimates). ## Proposal Make the **Action** column a hyperlink for DAP rows. In the GitLab Credits User drill-down, for rows representing DAP credit consumption: * Keep the existing columns: * Date/Time * Action * Location * Credit amount * Change the **Action** cell to be clickable when we have a session to link to. **Behavior:** * If the underlying billable event has a `session_id` and/or `session_url`: 1. Render **Action** (like "Agentic Chat” or “Foundational Agents”) as a standard link. 2. On click, navigate to a DAP session details surface. * If no `session_id` is available (legacy or non-DAP rows), the **Action** remains plain text and no link is rendered. ### User Experience 1. **Open GitLab Credits dashboard** * Admin (Group Owner on SaaS, Instance Admin on SM/Dedicated) opens the GitLab Credits dashboard in GitLab. * They see the existing summary cards and the Usage by user view entry point. 2. **Usage by user view** * Admin opens the **Usage by user** view. * They see the existing per-user table (no changes required). * They click a specific user to open the **user drill-down** view for that user. 3. **User drill-down (existing view with a small enhancement)** * The drill-down view shows a table of that user's usage events with the existing columns: * **Date/Time** (from `timestamp`) * **Action** (from `feature_type`) * **Location** (rendering of `project_path`, where available) * **Credit amount** (from `credits`) * For rows backed by DAP billable events that include a `session_id` (and/or `session_url`), the **Action** value is rendered as a clickable hyperlink. * For rows without a `session_id` (non-DAP or legacy), the Action remains plain text. 4. **Click Action and navigate to DAP session details** * When the admin clicks a clickable **Action** value: * The UI resolves a **Session URL** (prefer `session_url` if present; otherwise construct from `project_path` + `session_id`; otherwise fall back to a generic `/-/duo/sessions/{session_id}` route once that exists). * The browser navigates to that Session URL (same tab or new tab per DAP/UX decision). * From the Credits dashboards perspective, this is the only new behavior: Action now acts as a link into DAP session details for events that have a session identifier. 5. **Session details (DAP-owned surface)** * The Session URL opens a DAP session details view for that `session_id` (for example, a Session Details page or panel). * The exact fields shown there (status, model, token usage, step timeline, transcript, etc.) are defined by DAP session-details / traceability issues, not by this Credits dashboard issue. * For this issue, the only requirement is that such a surface exists and can be reached via `session_id` / `session_url`, so that admins can inspect what happened in a session after clicking through from the Credits dashboard. ## **Data Requirements** **Fields:** For each billable DAP event that appears in the Credits dashboard: 1. **Required fields (existing):** * `user_id` (GitLab user who triggered the flow) * `feature_type` (such as `agentic_chat`, `foundational_agent`, `fix_pipeline`) * `credits` (numeric credit amount consumed) * `timestamp` (when the billable event occurred) 2. **Required fields (new for this feature):** * `session_id` (DAP session identifier) 3. **Optional but strongly recommended if available:** * `session_url` (if possible) * `project_path` (GitLab project or namespace context like `gitlab-org/customers-gitlab-com`, if needed to construction the session) **Ownership:** * AIG / DAP: * Defines what a session is comprised of and which ID is used. * Emits `session_id` (and optional `session_url`, `project_path`) on every billable DAP event. * Utilization: * Stores `session_id` in ClickHouse and the Usage Service. * Exposes `session_id` via the Credits dashboard API / GraphQL schema. * Connects the **Action** link in the user drill-down to the right DAP session URL. ## Roles and Permissions 1. **Credits dashboard access (unchanged):** * Only **Group Owners** and **Instance Admins** (for self-managed / Dedicated) can access the GitLab Credits dashboard and the user drill-down views. 2. **Session details access:** 1. Anyone who can access the **usage-by-user view** (i.e., Group Owners for the namespace and Instance Admins for the instance/Dedicated environment) **must** be able to access the linked DAP session details for sessions in their scope. 2. When a user in that audience clicks a linked Action: 1. The Credits dashboard navigates to the DAP session surface (page or panel) for that `session_id`. 2. The DAP endpoint is responsible for enforcing auth, but must treat these users as having at least read-only access to view the session details associated with their namespace/instance. 3. Other users who do not have access to the usage-by-user view should not see the Credits dashboard or the links. ## Backend Changes 1. **AI Gateway to Usage Billing** * Extend DAP billable events to include: * `session_id` (required). * Optionally, `session_url` and/or `project_path`. 2. **Usage Billing storage** * Add `session_id` (and optionally `session_url`, `project_path`) to the relevant tables storing per-user DAP usage. * Ingest and persist these fields for all new events. * Legacy rows may remain without `session_id`. 3. **Usage Service / GraphQL schema** * Extend the Credits usage schema used by the **user drill-down view** to include `session_id` (and `session_url` if we support it in the response). * Ensure this field is available to: * The GitLab.com Credits UI. * Any future CSV export logic, so session IDs can be exported alongside usage. ## Frontend Changes 1. **Credits user drill-down table** * For rows where `feature_type` indicates DAP usage and `session_id` is present: * Render **Action** as a link (or link+icon) to the session URL. * For rows without `session_id`, render Action as plain text (current behavior). 2. **Routing** * Link resolution priority: 1. If `session_url` is present, use it. 2. Else construct a URL from `project_path` + `session_id` following DAP conventions. 3. Else fall back to `/-/duo/sessions/{session_id}` (once that route is stable), assuming it can look up the session from the ID alone. ## Acceptance Criteria **Data:** * [ ] Every new DAP billable event includes a `session_id` when sent to Usage Billing. * [ ] The backend for the Credits dashboard returns `session_id` for every DAP usage row, so the UI can display it and turn it into a link. **UI:** * [ ] In the user drill-down view, each DAP usage row with a `session_id` has a clickable Action that navigates to a DAP session surface. * [ ] Rows without `session_id` render Action as plain text with no link (legacy-safe). **Permissions:** * [ ] Only users who can currently access the Credits dashboard can see the linked Actions. * [ ] DAP surfaces enforce their own auth and return a clear error for unauthorized viewers.