Walkthrough

Adds Ask chat usage metrics to the analytics dashboard by integrating chat creation audit logging, extending analytics queries to aggregate chat events, and refactoring the analytics UI to display metrics with period-based filtering (daily/weekly/monthly). Updates documentation and audit action types accordingly.

Changes

Sequence Diagram

sequenceDiagram
    participant User
    participant ChatAction as Chat Action<br/>(createChat)
    participant AuditService as Audit Service
    participant Database as Database
    participant AnalyticsQuery as Analytics Query
    participant Dashboard as Analytics Dashboard

    User->>ChatAction: Create Ask chat
    ChatAction->>AuditService: Log chat creation
    AuditService->>Database: Store user.created_ask_chat audit entry
    
    Dashboard->>AnalyticsQuery: Fetch metrics for period
    AnalyticsQuery->>Database: Query aggregated metrics<br/>(active_users, code_searches,<br/>navigations, ask_chats)
    Database-->>AnalyticsQuery: Return aggregated data
    AnalyticsQuery-->>Dashboard: Return analytics response
    Dashboard->>Dashboard: Filter data by selected period<br/>(daily/weekly/monthly)
    Dashboard-->>User: Display metrics with Ask Chats

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Suggested reviewers

• brendan-kellam

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

• 📝 Generate docstrings

packages/db/tools/scripts/inject-audit-data.ts (2)

27-32: Unused actions array.

The actions array is defined but never referenced—each loop hardcodes its action strings directly. Consider either removing this dead code or refactoring to actually use this array for action selection.

---

130-139: Consider extracting timestamp generation helper.

The timestamp generation logic (lines 70-79, 97-105, 131-139) is duplicated across all three record types. For maintainability, consider extracting this into a helper function.

♻️ Example helper function

function generateTimestamp(currentDate: Date, isWeekend: boolean): Date {
    const timestamp = new Date(currentDate);
    if (isWeekend) {
        timestamp.setHours(9 + Math.floor(Math.random() * 12));
    } else {
        timestamp.setHours(9 + Math.floor(Math.random() * 9));
    }
    timestamp.setMinutes(Math.floor(Math.random() * 60));
    timestamp.setSeconds(Math.floor(Math.random() * 60));
    return timestamp;
}

packages/web/src/features/chat/actions.ts (1)

49-63: Consider handling audit failures gracefully.

If auditService.createAudit() throws, the entire createChat call will fail despite the chat already being created in the database (line 40-47). This could leave users unable to create chats if the audit system has issues.

Consider wrapping in a try-catch to ensure audit failures don't block the primary functionality:

♻️ Suggested approach

         // Only create audit log for authenticated users
         if (!isGuestUser) {
-            await auditService.createAudit({
-                action: "user.created_ask_chat",
-                actor: {
-                    id: user.id,
-                    type: "user",
-                },
-                target: {
-                    id: org.id.toString(),
-                    type: "org",
-                },
-                orgId: org.id,
-            });
+            try {
+                await auditService.createAudit({
+                    action: "user.created_ask_chat",
+                    actor: {
+                        id: user.id,
+                        type: "user",
+                    },
+                    target: {
+                        id: org.id.toString(),
+                        type: "org",
+                    },
+                    orgId: org.id,
+                });
+            } catch (e) {
+                logger.error('Failed to create audit log for chat creation', e);
+            }
         }

packages/web/src/ee/features/analytics/analyticsContent.tsx (1)

263-292: Consider memoizing the charts configuration array.

The charts array is recreated on every render. Since it depends on selectedPeriod and theme (via getColor), wrapping it in useMemo would prevent unnecessary object allocations:

♻️ Suggested memoization

-    const charts = [
+    const charts = useMemo(() => [
         {
             title: `${periodLabels[selectedPeriod]} Active Users`,
             icon: Users,
             color: getColor("users"),
             dataKey: "active_users" as const,
             gradientId: "activeUsers",
         },
         // ... other charts
-    ]
+    ], [selectedPeriod, getColor])

Note: getColor would need to be memoized or inlined for this to work correctly.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Reviewing files that changed from the base of the PR and between a6e2b69 and 527e8e0.

• docs/images/analytics_demo.mp4 is excluded by !**/*.mp4
• docs/images/code_nav_chart.png is excluded by !**/*.png
• docs/images/code_search_chart.png is excluded by !**/*.png
• docs/images/dau_chart.png is excluded by !**/*.png

• CHANGELOG.md
• docs/docs/configuration/audit-logs.mdx
• docs/docs/features/analytics.mdx
• packages/db/tools/scripts/inject-audit-data.ts
• packages/web/src/ee/features/analytics/actions.ts
• packages/web/src/ee/features/analytics/analyticsContent.tsx
• packages/web/src/ee/features/analytics/types.ts
• packages/web/src/features/chat/actions.ts

📄 CodeRabbit inference engine (.cursor/rules/cloud_agent.mdc)

After creating a GitHub PR, create a follow-up commit with a Changelog entry in CHANGELOG.md with a short description of the change. Follow the existing conventions: entries must be parented under a header (Added, Changed, Deprecated, Removed, Fixed, or Security), and entries must include the GitHub pull request id at the end of the line, formatted as #

Files:

• CHANGELOG.md

packages/web/src/ee/features/audit/factory.ts (1)

• getAuditService (9-13)

• GitHub Check: build

CHANGELOG.md (1)

10-11: LGTM!

The changelog entry follows the established conventions: it's placed under the correct "Added" header, includes the [EE] prefix for enterprise features, provides a concise description, and properly links to PR #736. This aligns with the coding guidelines.

docs/docs/features/analytics.mdx (1)

41-42: LGTM!

The new "Ask Chats" metric documentation is consistent with the existing metric sections in style and format. The description accurately reflects the feature's functionality.

docs/docs/configuration/audit-logs.mdx (1)

122-122: LGTM!

The new user.created_ask_chat action type is properly documented with consistent actor and target types matching similar user actions in the table.

packages/web/src/ee/features/analytics/types.ts (1)

8-8: LGTM!

The ask_chats field is correctly added to the schema using z.number(), consistent with the other count metrics. The Zod schema ensures runtime validation and type inference for the new metric.

packages/web/src/ee/features/analytics/actions.ts (3)

36-37: LGTM!

The user.created_ask_chat action is correctly added to the core CTE filter, enabling the audit events to be included in the analytics aggregation.

---

81-81: LGTM!

The aggregation correctly uses COUNT(*) FILTER (WHERE c.action = 'user.created_ask_chat') to count Ask chat creations, following the same pattern as the existing metrics.

---

95-95: LGTM!

The COALESCE(a.ask_chats, 0)::int pattern correctly handles NULL values for periods without any Ask chat activity, ensuring the response always contains valid integer values.

packages/db/tools/scripts/inject-audit-data.ts (1)

141-152: LGTM!

The Ask chat audit record structure correctly mirrors the production audit creation in chat/actions.ts, with consistent action, actorType, targetId, and targetType values.

packages/web/src/features/chat/actions.ts (1)

36-68: LGTM!

The conditional audit logging for authenticated users is well-placed and the audit payload structure is consistent with the data injection script and analytics queries.

packages/web/src/ee/features/analytics/analyticsContent.tsx (3)

308-317: LGTM!

The period selector implementation is clean. The type cast on onValueChange is safe since the SelectItem values are constrained to valid TimePeriod values.

---

177-192: LGTM!

The skeleton count (4) correctly matches the number of charts being rendered, providing a consistent loading experience.

---

294-334: Well-structured refactor.

The data-driven chart rendering approach makes adding new metrics straightforward. The separation of period filtering (line 261) from chart configuration and rendering is clean and maintainable.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

• X
• Mastodon
• Reddit
• LinkedIn

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai review

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.