3 Commits

Include renames

Author	SHA1	Message	Date
4 people	6a7ca9dd3b	feat: Add report bar drilldown drawer (#14626) ... ## Description Adds drilldown support for report bar charts powered by `ReportContainer`. Clicking a non-zero report bar now opens a right-side drawer with the conversations or messages that contributed to that bucket, with each row linking to the underlying conversation and message rows linking with `messageId`. This includes a new `GET /api/v2/accounts/:account_id/reports/drilldown` endpoint, backend drilldown builders/serializers, generic chart click emission, local drawer state via `useReportDrilldown`, compact drilldown cards, pagination, stale-response protection, and validation for unsupported drilldown dimensions. Fixes # CW-4497 https://linear.app/chatwoot/issue/CW-4497/drill-down-on-agent-conversations-report ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality not to work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? Ran the focused backend and frontend checks for the drilldown endpoint, builder, chart click handling, drawer/card UI, API helper, and stale-response handling. Here are the screenshots on how it looks like: <img width="1792" height="1199" alt="Screenshot 2026-06-02 at 11 32 11 PM" src="https://github.com/user-attachments/assets/6bdb8832-b9df-4bf3-9a2a-beaefe203b6e" /> <img width="1791" height="1230" alt="Screenshot 2026-06-02 at 11 32 34 PM" src="https://github.com/user-attachments/assets/36e92eb7-3208-4855-87f4-0c7f316df54d" /> <img width="1784" height="1235" alt="Screenshot 2026-06-02 at 11 32 46 PM" src="https://github.com/user-attachments/assets/f7a53916-74f2-4622-9305-042e0ac9e877" /> ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have commented on my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] Any dependent changes have been merged and published in downstream modules --------- Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com> Co-authored-by: Shivam Mishra <scm.mymail@gmail.com>	2026-07-02 16:07:26 +05:30
4 people	379e28df1f	fix: prevent bot metrics double-counting when handoff and resolution coexist [CW-6210] (#14032) ... The bot metrics dashboard can show `handoff_rate + resolution_rate > 100%`. A single conversation can accumulate both `conversation_bot_handoff` and `conversation_bot_resolved` events, and the rate queries count them independently against a shared denominator. ## How it happens ``` Customer messages bot inbox │ ▼ ┌──────────┐ │ pending │ (bot handling) └────┬─────┘ │ bot can't help ▼ ┌──────────┐ │ open │ (handed off → conversation_bot_handoff event created) └────┬─────┘ │ agent clicks "Resolve" WITHOUT sending a message ▼ ┌──────────┐ │ resolved │ conversation_resolved fires └──────────┘ │ ▼ create_bot_resolved_event guard checks: ✅ inbox.active_bot? ✅ no outgoing messages with sender_type: 'User' ← agent never messaged! │ ▼ conversation_bot_resolved event ALSO created ← BUG │ ▼ Same conversation counted in BOTH rates → sum exceeds 100% ``` ## Why fix at the read path, not the write path An earlier attempt added guards in the listener to make the two events mutually exclusive per conversation — deleting `bot_resolved` when a handoff fires, suppressing resolutions when a handoff exists. This was rejected because conversations can be reopened across multiple cycles (bot resolves on day 1, customer returns on day 5, bot hands off). Deleting the day-1 resolution corrupts historical reports, and the async event dispatcher makes listener-level guards vulnerable to race conditions. ## What this PR does Within a reporting window, if a conversation has both events, **handoff wins** — the conversation is excluded from the resolution count. This is applied via SQL subquery across all three read paths: ``` ┌─────────────────────────┐ │ Reporting Events DB │ │ │ │ conv_bot_handoff: [A,B] │ │ conv_bot_resolved: [A,C]│ └────────┬────────────────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ▼ BotMetricsBuilder ReportHelper CountReportBuilder (rate cards) (bot_summary) (timeseries charts) │ │ │ ▼ ▼ ▼ resolutions: resolutions: resolutions: [A,C] minus [A,B] same logic same logic = [C] only = [C] only = [C] only Result: Conversation A → handoff only Conversation B → handoff only Conversation C → resolution only ``` For wide date ranges spanning multiple lifecycles, a conversation bot-resolved in one cycle and handed off in a later cycle will only show as a handoff. This is an acceptable tradeoff — the alternative (>100% rates) is clearly worse, and narrow ranges handle this correctly since the events fall into different windows. No reporting events are modified, so historical data stays intact. ## Diagnostic tool `rake bot_metrics:diagnose` — read-only task that prompts for account ID and date range, shows a before/after rate comparison without modifying data. --------- Co-authored-by: aakashb95 <aakashbakhle@gmail.com> Co-authored-by: Aakash Bakhle <48802744+aakashb95@users.noreply.github.com>	2026-05-13 18:43:23 +05:30
5 people	6cbddbdb67	feat(rollup): report builder abstraction [2/3] (#13798) ... ## PR2: Report builder refactor — DataSource abstraction The existing report builders (timeseries + summary) had their SQL queries inlined — each builder constructed its own scopes, groupings, and aggregations directly. This made it hard to swap the underlying data source without duplicating builder logic. This PR extracts all raw-event querying into a `Reports::RawDataSource` behind a `Reports::DataSource` factory. Builders now call `data_source.timeseries`, `.aggregate`, or `.summary` instead of constructing queries themselves. Behavior is identical — `DataSource.for(...)` returns `RawDataSource` in all cases today. The timeseries path had two separate builders (`CountReportBuilder`, `AverageReportBuilder`) that were selected via a metric-name case statement in `Conversations::BaseReportBuilder`. These are replaced by a single `ReportBuilder` that delegates to the data source. The metric type (count vs average) is now decided inside the data source, not the builder. Summary builders similarly moved their inline SQL into `RawDataSource#summary`, which returns a unified hash keyed by dimension ID. the rollup read path. ## Flow ### Before ``` ReportsController ──▶ case metric ──▶ AverageReportBuilder ──▶ inline SQL ──▶ DB └──▶ CountReportBuilder ──▶ inline SQL ──▶ DB SummaryController ──▶ AgentSummaryBuilder ──▶ inline SQL ──▶ DB └──▶ InboxSummaryBuilder ──▶ inline SQL ──▶ DB └──▶ TeamSummaryBuilder ──▶ inline SQL ──▶ DB ``` ### After ``` ReportsController ──▶ ReportBuilder ──┐ ├──▶ DataSource.for ──▶ RawDataSource ──▶ DB SummaryController ──▶ SummaryBuilder ──┘ ``` ### Expected (after rollup read path) ``` ReportsController ──▶ ReportBuilder ──┐ ├──▶ DataSource.for ──▶ RawDataSource ──▶ reporting_events SummaryController ──▶ SummaryBuilder ──┘ └──▶ RollupDataSource ──▶ reporting_events_rollups ``` ### What changed - `Reports::DataSource` factory + `Reports::RawDataSource` - `TimezoneHelper#timezone_name_from_params` — prefers IANA name, falls back to offset - Unified `Timeseries::ReportBuilder` replaces `CountReportBuilder` + `AverageReportBuilder` - Summary builders delegate to `DataSource` instead of querying directly ### How to test This is a pure refactor — all existing report pages (Overview, Agent, Inbox, Label, Team) should produce identical numbers. No feature flag or new config needed. --------- Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com> Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>	2026-04-20 11:15:48 +05:30