500 Commits

Author	SHA1	Message	Date
Moreminimore	2495239187	feat(chatbot): OSS self-contained guardrail + knowledge-base chatbot ... Built-in AI chatbot (no EE, uses Llm::Resolver) that answers in-scope chats from a knowledge base and hands off to a human when needed. Selected per inbox via an Integrations::Hook with app_id 'chatbot'. - Integrations::Chatbot::ProcessorService (mirrors Dialogflow/Captain) wired via HookListener + HookJob + apps.yml(chatbot, inbox) - Chatbot::DecisionService: 1-call default ({in_scope/refuse/handoff}), 2-call option; thread-safe prompt threading - Chatbot::KnowledgeRetriever: keyword top-k over KB (+ embedding reserved) - KnowledgeBaseFaq + import service (md per-heading + front-matter tags) - Chatbot::ConfigService + admin chatbot_config endpoint - refs off-topic (e.g. fortune-telling); handoff = bot_handoff! (pending->open)	2026-08-25 16:09:47 +07:00
Moreminimore	b86b0c59f6	feat(analytics): M2 self-improving chatbot analytics ... Daily LLM classification of every chat (topics + product tags + deal won/lost/undecided) aggregated into immutable daily metrics, with a filterable admin report dashboard, product-catalog import (text/CSV/XLSX), weekly persona summary, and an approval flow (LINE -> Telegram -> webhook) for applying persona recommendations. - Llm::AnalyticsClassifier: per-account openai -> Captain fallback cascade - AccountDailyProcessor + Conversation/CustomerDailyMetric aggregation - ReportService + DrilldownService (summary + deep filterable drilldown) - AnalyticsReports.vue + productCatalog import UI (admin-only) - WeeklyPersonaEvaluator + PersonaApprovalService (LINE/Telegram/webhook) - Weekly cron (Mon 10:00) + daily cron (02:30)	2026-08-25 15:56:11 +07:00
Moreminimore	ccff2dfca7	feat(analytics): add LLM credential resolver with cascade ... Add Llm::Resolver which picks the LLM credential/endpoint for a given account for the M2 conversation analytics classifier, in priority order: 1. per-account OpenAI integration hook (settings.api_key + optional settings.base_url, via Account has_many :hooks) 2. instance Captain config (CAPTAIN_OPEN_AI_API_KEY / ENDPOINT) 3. nil => feature disabled for that account (no LLM). Only https base URLs are accepted (safe_https?); a non-https or blank base_url is omitted so callers fall back to the provider default (api.openai.com) rather than an arbitrary host — content never leaks to an unapproved endpoint. Approved by independent five-key pre-commit review deleg_269e20cb (passed=true, blocking arrays empty).	2026-08-19 12:49:21 +07:00
Moreminimore	f9628db0e1	feat(openai): add optional custom base URL to the OpenAI integration ... Add an optional custom OpenAI-compatible base URL to the per-account OpenAI integration (/app/accounts/{id}/settings/integrations/openai) so account owners can point label suggestions / reply suggestions at a self-hosted or proxy endpoint (vLLM, OpenRouter, etc.) instead of the default api.openai.com. - config/integration/apps.yml: add 'base_url' to the openai settings schema + form (optional custom URL input). - lib/integrations/llm_base_service.rb: api_base resolves per-account hook.settings['base_url'] -> CAPTAIN_OPEN_AI_ENDPOINT -> api.openai.com. - lib/integrations/openai/key_validator.rb: valid? accepts an optional base_url keyword; api_base uses it first (backward-compatible). - app/models/integrations/hook.rb: fail-closed validation rejecting a present but non-https base_url; both KeyValidator callers pass the hook base_url. Approved by independent five-key pre-commit review deleg_1c66a89b (passed=true, blocking arrays empty).	2026-08-19 11:18:37 +07:00
Moreminimore	961ecd388c	revert(captain): undo OpenAI provider switch (wrong scope) ... The OpenAI Custom Server request targets the per-account OpenAI integration (/app/accounts/{id}/settings/integrations/openai), not the instance-level Captain config. The CAPTAIN_OPEN_AI_PROVIDER provider-switch added in 46fe70398 was out of the intended scope and is new behavior that did not previously exist, so it is removed. This restores the original Captain behavior (CAPTAIN_OPEN_AI_ENDPOINT remains usable as before, no provider gating). The correct implementation goes in config/integration/apps.yml for the per-account openai integration.	2026-08-19 11:15:28 +07:00
Moreminimore	46fe703986	feat(captain): add OpenAI Custom Server provider option ... Add an operator-level provider switch for Captain AI so it can use any OpenAI-compatible base URL (vLLM, OpenRouter, proxies, etc.) in addition to the default api.openai.com endpoint. - installation_config.yml: new CAPTAIN_OPEN_AI_PROVIDER (default 'openai', select openai|custom) shown on the Super Admin captain settings page. - lib/llm/config.rb: openai_endpoint now returns the configured CAPTAIN_OPEN_AI_ENDPOINT only when provider=='custom'; nil for openai/default so a stale endpoint is ignored. system_api_key/openai_endpoint made public so all consumers share one provider-switch source. - Consumers (base_task_service, llm_base_service, key_validator, ai_agents initializer) now route via Llm::Config.openai_endpoint instead of reading CAPTAIN_OPEN_AI_ENDPOINT directly. - installation_config.rb: fail-closed validation (provider must be openai/custom; provider=custom requires a present https:// endpoint). Approved by independent five-key reviews deleg_b141098a (found+fixed one logic gap) and deleg_3088b922 (passed=true, blocking arrays empty).	2026-08-19 10:52:47 +07:00
Moreminimore	bee28c32eb	[brand] rebrand visible surfaces to Moreminimore Chat (phase 3) ... Replace remaining user-facing "Chatwoot" branding with Moreminimore Chat across visible surfaces (internal Ruby/JS identifiers, ChatwootHub/App and the X-Chatwoot-* webhook signature headers are intentionally unchanged): - app.json: name/description/website/repository/logo + env descriptions. - Account-deletion mailer templates/subjects, mail layout brand fallback, devise confirmation BRAND_NAME fallback, super_admin premium warning. - OpenAI assistant prompt system-role text. - 56 locale .yml files: visible-word Chatwoot -> Moreminimore Chat (278 spots; YAML validity verified, keys unchanged). Emails/support rebranded to @moreminimore.com (contact@, sales@); no stale chatwoot.com references added. Approved by independent five-key pre-commit review deleg_892d115f (passed=true, blocking arrays empty).	2026-08-16 16:01:22 +07:00
Kunthawat Greethong	8101395608	[privacy] remove Community Chatwoot Hub egress ... Remove Community Chatwoot Hub URL/push relay/sync/registration/event/changelog egress. changelog.js becomes a local empty-feed adapter (no axios/fetch/network) exporting the default ChangelogApi; links.js drops the Hub changelog URL. lib/chatwoot_hub.rb removes base_url/push_notification_url/billing_base_url/ instance_config/send_push/send_push_with_response; billing_url reads only an explicit CHATWOOT_BILLING_URL env, HTTPS-only with host and no userinfo, and never falls back to a Hub URL. Enterprise proprietary base_url override is preserved (spec uses singleton_class.instance_methods(false) for edition-safety). privacy_audit uses a narrow per-file/per-rule Enterprise exception (hub-url only) and privacy_audit_test.sh proves forbidden Enterprise runtime lines are still detected; deployment privacy guard unchanged. Approved by independent five-key review deleg_49d6ee2e (passed=true, blocking arrays empty).	2026-08-16 07:37:52 +07:00
Kunthawat Greethong	19dc44969a	[privacy] make observability local-only	2026-08-16 02:29:29 +07:00
Kunthawat Greethong	d9bf4c45de	[verified] Remove automatic signup enrichment	2026-08-15 17:22:44 +07:00
Kunthawat Greethong	1a3697f687	[verified] Restore Chatwoot Hub compatibility APIs	2026-08-15 15:35:55 +07:00
Kunthawat Greethong	832a7fdae0	[verified] Remove Chatwoot Hub sync paths	2026-08-15 13:23:03 +07:00
Aakash Bakhle	13de83d1dc	refactor(captain): route conversation completion by feature (#15317) ... Conversation completion evaluations now use a dedicated internal LLM feature with GPT 4.1 as the default. The internal route keeps the completion model separate from the installation wide Captain model override and from the assistant route, which can use GPT 5.2 for Captain V2 accounts. Evaluations continue to use the installation API key and do not consume Captain response credits. ## What changed Added an internal `conversation_completion` feature to the LLM model config and excluded internal features from account preferences, the Captain settings API, and Super Admin model overrides. Updated `Captain::ConversationCompletionService` to resolve its model through `Llm::FeatureRouter`. Added focused service and request coverage for model routing and settings visibility.	2026-08-13 13:54:35 +05:30
Manoj	1d905fb019	fix: anchor Label title validation with \z instead of \Z (#15443) ... ## Description This isn't tied to an open issue — I found it by extrapolating from the bug class fixed in #15415 ("fix: anchor contact phone number validation"), which fixed a `Contact#phone_number` format validation that was missing a leading `\A` anchor. That made me audit every hand-written regex-based validation in the codebase for the same class of anchoring mistake (`format: { with: ... }` validators, plus `match?`/`=~` calls used for validation-style checks, across `app/`, `enterprise/`, and `lib/`). Everything else was already correctly anchored. One real instance of the *sibling* mistake remains: `RegexHelper::UNICODE_CHARACTER_NUMBER_HYPHEN_UNDERSCORE` (used only by `Label#title`'s format validation) is `/\A[\p{L}\p{N}]+[\p{L}\p{N}_-]+\Z/` — note `\Z` (capital), not `\z`. Unlike `\z`, `\Z` also matches just before a single trailing `"\n"` at the end of the string. The surrounding comment documents the intended character set (unicode letters/numbers/underscore/hyphen, not starting with `_`/`-`) and says nothing about tolerating a trailing newline, so this reads as an unintentional choice of anchor rather than a deliberate one. Concretely: `Label.new(title: "hello_world\n").valid?` returns `true` on current `develop` and persists a title with a literal trailing newline, because `\Z` lets the `\n` slip through. `Label` only lowercases the title before validating (no `strip`), so nothing else catches this. This is a narrower/lower-severity variant of the #15415 bug (it only ever admits one specific trailing character, not an arbitrary prefix/suffix), but it's the same underlying mistake, independently verified against current source, not just pattern-matched from the diff. ## What changed - `lib/regex_helper.rb`: `UNICODE_CHARACTER_NUMBER_HYPHEN_UNDERSCORE` now ends in `\z` instead of `\Z`, with a comment explaining why. ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? Ran against a real local Rails env (Ruby 3.4.4, PostgreSQL 16, Redis): `bundle exec rspec spec/models/label_spec.rb` Added a regression test asserting `Label.new(title: "hello_world\n")` is invalid. Confirmed it fails against the pre-fix `\Z` regex and passes after switching to `\z`. All existing `label_spec.rb` examples (including the existing "foreign characters", "special characters", and "uppercase" title-validation cases) continue to pass unchanged. ## Checklist - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective - [x] New and existing unit tests pass locally with my changes 🤖 This fix was authored by an AI coding agent (Claude) working on behalf of Mithtech, an ERPNext/Frappe/Medusa.js implementation studio, as part of a deliberate effort to build a track record of verified upstream open-source contributions. Flagging this transparently per common courtesy — happy to answer any questions about the change, including how it was found (auditing for the same regex-anchor mistake class as #15415). Co-authored-by: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 12:05:06 +05:30
Shivam Mishra	0a2293f921	feat: record Captain conversation outcome episodes from lifecycle events [CW-7792] (#15316) ... Records Captain conversation outcomes at episode grain so reporting can distinguish initial demand from reopened conversations and measure replies, handoffs, resolutions, human follow-up, and CSAT. Eligibility creates the episode at demand time. Message-derived fields are snapshotted from persisted messages at handoff or resolution, keeping terminal analytics accurate without writing outcomes for every message. Outcome tracking remains reporting-only and fail-open. Builds on the episode-grain schema from #15315. ## Closes - https://linear.app/chatwoot/issue/CW-7792 ## How to test 1. Enable `captain_integration_v2` and connect a Captain assistant to an inbox. 2. Send an inbound customer message and confirm an initial outcome episode is created at the message timestamp. 3. Let Captain reply and then resolve or hand off the conversation. Confirm the episode records Captain reply counts and timestamps, the outcome timestamp, and the handoff category where applicable. 4. Reply after resolution and confirm a `reopen` episode is created while preserving the previous episode. 5. Resolve the reopened conversation and submit CSAT. Confirm the response is attributed to the episode that issued the survey. ## What changed - Creates the initial episode from demand-level eligibility and appends a new episode when a resolved conversation reopens. - Snapshots Captain replies and the first qualifying human reply from persisted messages at handoff and resolution. - Attributes asynchronous resolution events using the episode active at the event timestamp. - Records later CSAT responses using the survey message timestamp. - Keeps boundary writes transactional and fail-open without retries, advisory locks, late-boundary repair, or handoff self-healing. - Adds schema-constrained handoff reason categories, including lifecycle coverage for incomplete V2 tool fallback handoffs. Open, non-terminal episodes may retain empty or stale message-derived fields until handoff or resolution.	2026-08-11 14:57:23 +05:30
Sojan Jose	81fc35e9e6	chore: upgrade Rails to 7.2.3.1 (#13437) ... This upgrades Chatwoot to Rails 7.2.3.1 while retaining the current Rails 7.0 framework defaults, so the runtime upgrade can be deployed and observed independently from default-behavior changes. ## What changed - Upgrade Rails and the compatible dependency set to Rails 7.2.3.1. - Keep `config.load_defaults 7.0` for a staged, lower-risk rollout. - Replace the unmaintained Azure Active Storage fork with the maintained `azure-blob` adapter while preserving the `microsoft` service name. - Pin Sidekiq 7.3.10 with `connection_pool` 2.x after validating scheduled-job execution against Redis. - Update Rails 7.2 compatibility surfaces in Active Record, strong parameters, migrations, storage, and tests. - Add read-only production preflight checks, an opt-in Active Storage smoke script, a deployment runbook, and the full Rails 7.2/8.0/8.1 assessment. ## How to test 1. Sign in and verify the dashboard and conversation UI load normally. 2. Open the agent-management modal and confirm agent data is rendered. 3. Create an API inbox and wait for the asynchronous deletion flow to complete. 4. Open Super Admin pages, including instance status and account-user management. 5. Upload and download an attachment using the configured Active Storage service. 6. Confirm recurring Sidekiq Cron jobs register and execute after startup. ## Rollout Follow `docs/rails_upgrades/7_2.md` for pre-deploy checks, deployment order, smoke tests, monitoring, and rollback. Run `bundle exec rails runner script/rails_upgrade/preflight.rb` against a production-equivalent environment before rollout. ## Tracking - [CW-5863 — Upgrade Rails to 8+](https://linear.app/chatwoot/issue/CW-5863/upgrade-rails-to-8) - [Rails 7.2 to 8.1 upgrade and production rollout plan](https://linear.app/chatwoot/document/chatwoot-rails-72-to-81-upgrade-and-production-rollout-plan-44e9f4964cb2) --------- Co-authored-by: Shivam Mishra <scm.mymail@gmail.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>	2026-08-10 15:49:38 +05:30
Aakash Bakhle	a4eae9710a	test: Add focused Captain response lifecycle logs (#15364) ... ## What changed This pull request adds three focused log emitters for Captain V2 response jobs: * `job_dequeued` when Sidekiq fetches the job from Redis * `job_skipped` when the conversation is not Pending at the first job guard * `response_discarded` when a newer customer message exists before model generation The dequeue middleware identifies V2 jobs by the triggering message ID in the third serialized Active Job argument. It does not log Captain V1 or other Sidekiq jobs. ## Why Recent production incidents have an enqueue record but no later job record. Active Job `Performing` and `Performed` logs are now available temporarily, but they do not show whether Sidekiq fetched a job before a worker disappeared. The dequeue log closes that gap. The two application logs explain the early exits that otherwise produce no model trace. The production root cause remains unresolved. This pull request adds evidence for the next occurrence and does not change Captain response behavior. ## Log volume A Captain V2 response job adds one dequeue line. The other two lines occur only on an early status skip or a pre-generation burst discard. Existing Active Job, Langfuse, completion, failure, handoff, and usage logs cover later stages. ## Validation * Ruby syntax checks passed for the four implementation files. * RuboCop found no offenses in the four implementation files. * No new specs were added because this is temporary diagnostic logging with no response behavior change.	2026-08-09 09:01:03 +05:30
Sony Mathew	56be133bb0	feat(data-imports): add Freshdesk migration (1/3) (#15261) ... ## Description Adds Freshdesk as an integration import source so administrators can validate a Freshdesk domain and API key, then import contacts, tickets, public replies, customer replies, and private notes while tracking progress from Data Imports. The integration has now been validated against a live Freshdesk trial tenant with contacts, Web Chat and phone tickets, public replies, customer replies, a private note, pagination, requester expansion, and attachment metadata. That validation found and fixed the current Web Chat source mapping and prevented the ticket description from duplicating the initial Web Chat message. Related: #15116 ## Closes Closes [CW-7639](https://linear.app/chatwoot/issue/CW-7639/freshdesk-freshworks-migration) ## Type of change - [x] New feature (non-breaking change which adds functionality) ## What changed - Added a shared source adapter, importer, job, retry, restart, creation, and placeholder inbox contract used by Intercom and Freshdesk. - Added Freshdesk API authentication, contact and ticket pagination, requester expansion, conversation retrieval, normalization, channel grouping, and error handling. - Added current Freshdesk source identifiers through SMS, including Web Chat source `15`, and grouped equivalent sources into placeholder inboxes. - Used Web Chat conversation events as the complete message history so the generated ticket description does not duplicate the initial customer message. - Preserved Freshdesk ticket subjects in source metadata and added a sanitized live-derived Web Chat fixture with structured bodies and attachment metadata. - Added Freshdesk selection, domain and API key validation, and provider-neutral import status handling in the Data Imports UI. ## How to test 1. Enable the data_import feature for an account and open Settings > Data > New import. 2. Select Freshdesk and enter a Freshdesk domain and API key. 3. Select contacts and/or conversations, validate the credentials, and start the import. 4. Confirm progress is displayed and imported tickets appear as resolved conversations in Freshdesk placeholder inboxes with public replies and private notes preserved. 5. Verify Web Chat tickets appear in the Chat placeholder inbox and the initial customer message is imported once. 6. Verify an abandoned import can be restarted and a stalled import can be retried. ## Current scope - **Product decision:** Attachment binaries are intentionally not imported in the current migration scope. Attachment metadata is preserved and messages include a skipped-attachment marker. - Adaptive Retry-After scheduling and handling the 30,000-ticket listing ceiling are covered by stacked follow-up PRs. ## 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	2026-08-05 16:25:30 +05:30
Shivam Mishra	7981e2cc75	refactor: introduce normalized Captain lifecycle events [CW-7792] (#15213) ... This introduces a small event layer for the Captain V2 conversation lifecycle. A new `Captain::ConversationEvents` facade dispatches five normalized events (`captain.conversation.engaged`, `captain.conversation.handed_off`, `captain.conversation.resolved`, `captain.response.completed`, `captain.response.failed`) from the points where Captain engages a conversation, replies, fails, hands off, or auto-resolves. Each event carries the conversation, assistant, timestamp, and a `source`/`reason_category` where relevant. ## Why this, why now The Captain V2 flow is about to gain several observers at once: conversation outcome tracking, agent session capture, and analytics all need to know when Captain engages, replies, fails, hands off, or resolves. Wiring each of them directly into `ResponseBuilderJob`, `HookExecutionService`, and the tools would tangle secondary bookkeeping into the paths that deliver customer-facing behavior, and every future consumer would deepen that. Landing the event layer first as its own PR means the flow announces these moments once and stays otherwise untouched: customer-visible behavior (messages, status changes, handoffs, usage enforcement) remains synchronous, while secondary effects subscribe through listeners. The upcoming conversation outcomes PR then reduces to a listener plus a model instead of another round of edits to the core flow, which is why this ships now, before that work merges. The existing inference reporting behavior is folded into this layer: the `conversation.captain_inference_*` events and their dispatch helpers on `Enterprise::Conversation` are removed, and a dedicated `Captain::ReportingEventListener` (registered on the enterprise async dispatcher) maps `source: 'inference'` events to the same stored reporting event names, so recorded analytics and the assistant stats builder are unaffected. ## What changed - New `Captain::ConversationEvents` facade and event type constants - Event emission from `HookExecutionService` (engagement, usage-limit handoff), `ResponseBuilderJob` (response completed/failed, generation-failure handoff), `HandoffTool` (tool handoff), and `InboxPendingConversationsResolutionJob` (inference resolved/handoff) - A dedicated `Captain::ReportingEventListener` preserves inference reporting events through the new event names, removing captain logic from the OSS listener	2026-07-31 13:55:57 +05:30
Muhsin Keloth	d04a717701	fix(whatsapp): resolve replies across scoped message ids (#15107) ... WhatsApp coexistence replies can carry a BSUID-scoped `context.id` even when Chatwoot stored the original message with a phone-scoped WAMID. Although both identifiers refer to the same message, their complete values differ, so incoming replies retained the external reference but did not populate the internal `in_reply_to` relationship. Agents consequently saw the reply text without the quoted-message preview. This resolves the original message within the selected conversation and stores the internal reply relationship. Exact WAMID matches remain the primary path; scoped identifiers fall back to the unique decoded message token. Fixed https://linear.app/chatwoot/issue/CW-7663/whatsapp-quoted-replies-are-not-linked-across-scoped-wamids and https://github.com/chatwoot/chatwoot/issues/14953 ## How to reproduce 1. Use a WhatsApp Cloud inbox with coexistence enabled. 2. Send a message whose source ID is stored using the phone-scoped WAMID. 3. Reply to it from WhatsApp when the webhook carries a BSUID-scoped `context.id` for the same message. 4. Before this change, the incoming message appears without its quoted-message preview. 5. After this change, the reply references and displays the original message. ## What changed - Resolve incoming reply context IDs against messages in the selected conversation. - Keep exact source-ID matching as the first lookup path. - Decode scoped WAMIDs and match only a unique 20- or 32-character message token. - Populate `content_attributes.in_reply_to` while preserving `in_reply_to_external_id`. - Leave malformed, unmatched, or ambiguous identifiers unlinked. ## How to test 1. Open a WhatsApp Cloud conversation and send a message to the contact. 2. Reply to that message from WhatsApp through a coexistence identity. 3. Confirm the incoming message displays the original message as a quoted preview. 4. Confirm ordinary exact-ID replies continue to resolve. 5. Confirm an unknown or malformed context ID does not attach to another message. ## Things to know Meta documents `context.id` as the replied-to message identifier, but does not document the internal WAMID encoding or the phone-versus-BSUID scope transformation. The fallback is therefore limited to the selected conversation and succeeds only when one stored message has the decoded token. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>	2026-07-28 15:28:20 +04:00
Sony Mathew	6baf442c28	fix: enforce email limits for agent invitations (#15082) ... # Pull Request Template ## Description Prevents Chatwoot Cloud accounts from exceeding their daily non-channel email allowance through agent invitations. New-user invitations atomically reserve email capacity before mail is queued; when the budget is exhausted, agent creation rolls back and returns HTTP 429. This covers single and bulk agent creation. Self-hosted installations remain unaffected, and adding an existing user does not consume capacity when no invitation is sent. Related to [CW-7637](https://linear.app/chatwoot/issue/CW-7637/prevent-agent-invitation-email-abuse-after-july-20-incident). ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) - [ ] 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? Verified single and bulk creation at an exhausted budget, successful invitation enqueueing below the limit, no capacity usage for existing users, and no enforcement on self-hosted installations. A concurrent Redis probe admitted exactly five of twenty simultaneous reservations against a limit of five. ## 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	2026-07-24 13:59:28 +05:30
Aakash Bakhle	e10b236871	feat(captain): group conversation FAQ signals (2/4) (#14978) ... Captain can now turn resolved conversations into FAQ suggestions that people can review. When a human support agent gives a reusable answer, Captain saves the question and answer as an observation. Captain groups matching observations into one suggestion instead of creating a pending FAQ for every conversation. This PR does not approve or publish FAQs. PR [#14977](https://github.com/chatwoot/chatwoot/pull/14977) adds the data model and should be reviewed first. The controller and UI PRs will add the review flow. The three PRs should merge together. ## Closes [CW-7495](https://linear.app/chatwoot/issue/CW-7495/backend-llm-changes-to-make-conversation-faqs-as-signalssuggestions). This is PR 2 of 3. The issue is complete after the full stack lands. ## What changed 1. Runs FAQ generation in the low priority queue after a conversation is resolved. 2. Reads only customer messages and answers written by human support agents. 3. Uses the assistant's product details, instructions, response rules, and guardrails to reject spam and unrelated conversations. 4. Stores each reusable question and answer as an observation. 5. Uses exact text similarity search within the conversation language to find likely matches. 6. Asks the LLM whether both FAQs ask the same question and give the same answer. 7. Does not create a new suggestion when an approved FAQ already covers the observation. 8. Adds matching observations to an existing open suggestion and updates its source count. 9. Does not suggest the same FAQ again after someone dismisses it. 10. Creates a new open suggestion only when no approved FAQ or existing suggestion covers the observation. ## How to test 1. Resolve a conversation where a human support agent gives a reusable answer. Confirm that Captain creates one open suggestion with one source. 2. Resolve another conversation with the same question and answer. Confirm that Captain adds a source to the existing suggestion instead of creating another suggestion. 3. Resolve a conversation that is already covered by an approved FAQ. Confirm that Captain creates no new suggestion. 4. Dismiss a suggestion, then resolve another conversation with the same question and answer. Confirm that Captain does not suggest the FAQ again. 5. Resolve a spam or unrelated conversation. Confirm that Captain creates no suggestion. --------- Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>	2026-07-24 11:33:47 +05:30
Shivam Mishra	8c013415b8	fix: localize the captain overview summary greeting (#15108)	2026-07-21 16:29:08 +05:30
Shivam Mishra	7a5385cc32	feat: improve captain overview loading and reuse stats for summary [CW-7610] (#15105)	2026-07-21 15:14:18 +05:30
Sony Mathew	c420edce58	feat: branded email layouts for email inboxes (#14936) ... ## Description Adds an API-only branded email layout feature for Email inbox replies. Administrators can configure an account-level fallback layout and per-email-inbox overrides with Liquid HTML using `{{ content_for_layout }}`, and eligible outbound email replies/transcripts render through the scoped layout when the account feature flag `branded_email_templates` is enabled. The feature is disabled by default and is manually controlled through the normal account feature flag mechanism. Fixes https://linear.app/chatwoot/issue/CW-7514/branded-html-email-templates-per-inboxbrand ## Type of change - [x] New feature (non-breaking change which adds functionality) - [x] This change requires a documentation update ## How to test 1. Start Chatwoot locally and sign in as an administrator. 2. Enable the account feature flag for the account you are testing: ```ruby account = Account.find(<account_id>) account.enable_features!(:branded_email_templates) ``` 3. Create or pick an Email inbox, then note the `account_id` and `inbox_id`. 4. Configure an account-level fallback layout through the API using authenticated admin headers: ```http PATCH /api/v1/accounts/:account_id/branded_email_layout Content-Type: application/json { "branded_email_layout": "<html><body><header>Account Brand</header>{{ content_for_layout }}<footer>Account footer</footer></body></html>" } ``` 5. Confirm `GET /api/v1/accounts/:account_id/branded_email_layout` returns the saved account layout. 6. Configure an inbox-level override for the Email inbox: ```http PATCH /api/v1/accounts/:account_id/inboxes/:inbox_id Content-Type: application/json { "branded_email_layout": "<html><body><header>Inbox Brand</header>{{ content_for_layout }}<footer>Inbox footer</footer></body></html>" } ``` 7. Confirm `GET /api/v1/accounts/:account_id/inboxes/:inbox_id` returns the inbox `branded_email_layout`. 8. Send an Email inbox reply and verify the outbound email body is wrapped with the inbox layout around the generated reply content. 9. Clear the inbox layout by sending a blank value, then send another reply and verify it falls back to the account layout: ```http PATCH /api/v1/accounts/:account_id/inboxes/:inbox_id Content-Type: application/json { "branded_email_layout": "" } ``` 10. Clear the account layout with a blank value and verify Email replies return to the existing no-layout behavior. 11. Verify validation behavior: - Updating either API with a layout that omits `{{ content_for_layout }}` returns `422`. - Updating either API with invalid Liquid returns `422`. - Updating a non-Email inbox with `branded_email_layout` returns `422`. - Disabling `branded_email_templates` and updating a layout returns `422`. ## How Has This Been Tested? Validation: - `bundle exec rspec spec/models/email_template_spec.rb spec/controllers/api/v1/accounts/branded_email_layouts_controller_spec.rb spec/controllers/api/v1/accounts/inboxes_controller_spec.rb spec/lib/email_templates/db_resolver_service_spec.rb spec/mailers/conversation_reply_mailer_spec.rb` - `bundle exec rspec spec/enterprise/services/enterprise/billing/handle_stripe_event_service_spec.rb spec/enterprise/services/internal/reconcile_plan_config_service_spec.rb` - `bundle exec rubocop` on changed Ruby files, excluding generated `db/schema.rb` - `git diff --check` and `git diff --cached --check` - YAML parsing for changed config/Swagger files - `bundle exec rails routes -g branded_email_layout` ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have made corresponding changes to the documentation - [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 - [ ] I have commented on my code, particularly in hard-to-understand areas - [ ] My changes generate no new warnings - [ ] Any dependent changes have been merged and published in downstream modules	2026-07-17 15:25:55 +05:30
Aakash Bakhle	9c68eed676	fix(captain): send custom tool API key headers (#15008) ... Captain custom tools configured with API key authentication now send the configured key in the requested HTTP header. Existing tools begin working without needing to be recreated or reconfigured, while credentials remain protected across redirects. ## How to reproduce 1. Create a Captain custom tool using API Key authentication. 2. Configure `X-API-Key` as the header name and save the tool. 3. Invoke the tool and inspect the incoming request. 4. Before this change, the API key header is absent; after this change, the configured endpoint receives it. ## What changed The UI persists API key authentication as `name` and `key`, but the request builder also required an unused `location: header` property. The request builder now treats API key authentication as header-based, matching the only mode exposed by the UI. Custom authentication headers are also registered as sensitive with `SafeFetch`. They are retained for the configured endpoint and same-origin redirects, but stripped when a redirect crosses origins to prevent credential leakage. Factory, request, and redirect specs cover the real UI payload and both public and private-network fetch paths.	2026-07-15 22:43:30 +05:30
Shivam Mishra	9c444315a6	feat: add api_and_webhooks feature flag reconciled from billing plan (#14972) ... This introduces a new `api_and_webhooks` account feature flag that will control access to the token-authenticated API and account webhooks. The flag is part of the Startup plan features, so paid plans — including trials of paid plans — get it through the billing reconcile, while accounts on the default (Hacker) plan don't, with `manually_managed_features` available as a per-account override. The flag defaults to enabled, and nothing enforces it yet, so this PR is behavior-neutral — enforcement lands in a follow-up. ## What changed - Added `api_and_webhooks` to `features.yml` (first flag on the `feature_flags_ext_1` column, default enabled). - Added the flag to `STARTUP_PLAN_FEATURES` in `Enterprise::Billing::ReconcilePlanFeaturesService`, so all paid tiers get it and the default plan loses it on reconcile. - Added the flag to the manually manageable features list so it can be granted per account via Super Admin. ```rb # Enables the api_and_webhooks feature for all existing accounts and marks it # as manually managed so cloud billing reconciles never strip it. # # NOT committed to source control — run manually on production. # # Usage: # bundle exec rails runner enable_api_and_webhooks.rb # ACCOUNT_ID=123 bundle exec rails runner enable_api_and_webhooks.rb # # Idempotent: accounts already grandfathered are skipped; safe to re-run. probe = Internal::Accounts::InternalAttributesService.new(Account.new) abort 'api_and_webhooks is not in valid_feature_list — deploy the feature flag PR first.' unless probe.valid_feature_list.include?('api_and_webhooks') account_id = ENV.fetch('ACCOUNT_ID', nil) accounts = account_id.present? ? Account.where(id: account_id) : Account.all abort "Account with ID #{account_id} not found" if account_id.present? && accounts.empty? total = accounts.count puts "Grandfathering api_and_webhooks for #{total} account(s)..." puts "Started at: #{Time.current}" updated = 0 skipped = 0 errored = 0 accounts.find_each(batch_size: 500) do |account| service = Internal::Accounts::InternalAttributesService.new(account) features = service.manually_managed_features if features.include?('api_and_webhooks') && account.feature_enabled?('api_and_webhooks') skipped += 1 else service.manually_managed_features = features + ['api_and_webhooks'] unless features.include?('api_and_webhooks') account.enable_features!('api_and_webhooks') updated += 1 end processed = updated + skipped + errored puts "Processed #{processed}/#{total}..." if (processed % 1000).zero? rescue StandardError => e errored += 1 puts "Account #{account.id}: FAILED - #{e.message}" end puts "Done! Updated: #{updated}, Skipped: #{skipped}, Errored: #{errored}, Total: #{total}" ```	2026-07-13 18:20:36 +05:30
Muhsin Keloth	8fc5c7a5c8	feat: add captain general guidelines migration helpers (#14909) ... This PR adds internal tooling and planning docs for migrating existing Captain assistant instructions into the new General Guidelines structure. **Summary** This PR adds a controlled migration path for moving existing Captain V1 assistant instructions into the structured Captain architecture. It introduces a classifier that reads the current `config.instructions` and produces reviewed migration drafts with separate sections for: - assistant description / business context - response guidelines - guardrails - scenario candidates - conversation messages - FAQ/document candidates - needs-review items The migration is intentionally staged. It only targets V1-style assistants that still have custom instructions, are connected to inboxes, and do not already have structured response guidelines, guardrails, or scenario records. When applied, the task writes the extracted business context to the assistant description, response guidelines to `response_guidelines`, guardrails to `guardrails`, and stores scenario candidates / FAQ candidates / review notes under `config["assistant_migration"]`. Scenario candidates are also flattened into response guidelines for now so customer behavior is preserved before we create real `Captain::Scenario` records in a later rollout. The applier stores the original assistant values under migration metadata so conversation message config can be restored if needed. It does not create scenario records yet. **How to generate drafts** For specific assistant IDs: ```bash bundle exec rake captain:assistant_migration:generate \ IDS=546,636,819 \ LIMIT=0 \ OUTPUT=tmp/captain_migration_drafts.jsonl ``` For the first 50 eligible assistants: ```bash bundle exec rake captain:assistant_migration:generate \ OUTPUT=tmp/captain_migration_drafts.jsonl ``` For all eligible assistants: ```bash bundle exec rake captain:assistant_migration:generate \ LIMIT=0 \ OUTPUT=tmp/captain_migration_drafts.jsonl ``` **How to apply drafts** Dry run first: ```bash bundle exec rake captain:assistant_migration:apply \ INPUT=tmp/captain_migration_drafts.jsonl \ DRY_RUN=true ``` Apply changes: ```bash bundle exec rake captain:assistant_migration:apply \ INPUT=tmp/captain_migration_drafts.jsonl \ DRY_RUN=false ``` **How to restore conversation messages** If extracted `welcome_message`, `handoff_message`, or `resolution_message` need to be reverted to their pre-migration values: ```bash bundle exec rake captain:assistant_migration:restore_messages \ IDS=546,636,819 \ DRY_RUN=true ``` ```bash bundle exec rake captain:assistant_migration:restore_messages \ IDS=546,636,819 \ DRY_RUN=false ``` **Notes** - `LIMIT=0` means no limit. - `generate` overwrites the output file. - The apply task skips assistants that are no longer V1 migration candidates. - This PR does not create `Captain::Scenario` records; scenario candidates are staged in assistant config for a future migration. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> Co-authored-by: aakashb95 <aakashbakhle@gmail.com> Co-authored-by: Aakash Bakhle <48802744+aakashb95@users.noreply.github.com>	2026-07-13 14:56:09 +05:30
Sony Mathew	66cfb26c77	feat: Add unread count filters feature flag (1/6) (#14885) ... ## Description Adds the account-level `unread_count_for_filters` feature flag as the dark-launch gate for filtered sidebar unread counts. This reuses the deprecated `quoted_email_reply` flag slot, resets the reused bit for existing accounts, and removes stale defaults so new accounts do not reference the old flag. This also adds the feature where we are now calculating the unread counts for built in filters like mentions, participating and unattended along with unread count for saved filters/folders. Closes [CW-7262](https://linear.app/chatwoot/issue/CW-7262/unread-counts-for-filters-folders) ## Type of change - [ ] 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	2026-07-08 23:50:40 +05:30
Sojan Jose	0e07a27c74	fix: enforce inbox limits at model level (#14949) ... Fixes https://linear.app/chatwoot/issue/CW-7559/inbox-limit-abuse ## Why The regular inbox API checked limits in the controller, but WhatsApp embedded signup creates inboxes through a service using `Inbox.create!`. That let Enterprise account inbox limits be skipped for embedded signup. ## What this change does - Adds an Inbox create-time validation hook in OSS and implements the limit check in the Enterprise Inbox module. - Removes the duplicate controller/helper limit check so the model is the single enforcement point. - Preserves the existing `402 Payment Required` API response for account inbox limit failures. - Keeps updates to existing inboxes allowed when an account is already at its inbox limit. ## Validation - `bundle exec rspec spec/controllers/api/v1/accounts/inboxes_controller_spec.rb spec/enterprise/models/inbox_spec.rb`	2026-07-08 13:18:07 +04:00
Shivam Mishra	29d0b92f1c	fix: captain hours saved metric (#14948) ... Reworks the Captain assistant "hours saved" metric so it produces a believable number. It previously multiplied assistant reply count by customer reply-wait time, which inflated the figure into the millions of hours. It now estimates saved time as replies × a fixed ~2 min per-reply effort assumption. On the overview card the value renders in days once it passes 100 hours, and the label/hint copy was updated to match. ## How to test 1. Open the Captain assistant overview page. 2. Check the "Time saved" card shows a sensible value (hours, or days past 100h). 3. Hover the hint and confirm it reflects the per-reply estimate.	2026-07-07 19:16:24 +05:30
Shivam Mishra	a5fcecb3f6	feat: assistant overview page [CW-7408] (#14889) ... This PR adds a Captain Assistant **Overview** page to show some KPI metrics (conversations handled, auto-resolution, handoff, hours saved, reopen-after-resolve, conversation depth) with trend deltas vs the previous window, a real knowledge card, and a lazily-loaded, cached LLM welcome summary. ### Highlights - **Two contextual banners** on the overview: - **Inbox banner** — prompts the user to connect an inbox when the assistant has none, so it can actually do work. - **Coverage banner** — warns when FAQ coverage is below 85% with more than 100 responses pending review, linking straight to the pending queue. Dismissal persists per-assistant for 24h via localStorage. - **Batched stats builder** (`Captain::AssistantStatsBuilder`) computes both windows in single FILTER-aggregated scans to cut round trips, behind new `stats`/`summary` endpoints. - **Cards included but intentionally left dummy / not rendered yet:** `ResponseQualityCard` (flagged responses) and `CreditUsageCard` (credit usage + daily chart). Credits are an account-wide counter with no per-assistant or daily history, so there is no real data to back them yet; they ship in the codebase but are not wired into the page. ### Index migration - Replaces `index_messages_on_sender_type_and_sender_id` with `index_messages_on_sender_and_created` `(sender_type, sender_id, created_at)`. - **Why it helps:** the per-assistant windowed lookups filter `sender_*` *and* a `created_at` range. The old 2-column index matched every lifetime row for the assistant and filtered the time slice at the heap (~89% of rows discarded); adding `created_at` as a range column lets Postgres scan only the window, and fixes the row-count estimate so the planner picks a hash join over a nested loop on `reporting_events`. - **Why dropping the old index is safe:** the new index is a left-prefix superset `(sender_type, sender_id, ...)`, so every query the old one served is still served. No code references it by name, and dropping it keeps write amplification on `messages` neutral. Built/dropped with `CONCURRENTLY` and `if_not_exists`/`if_exists` guards. ## Preview <img width="2572" height="1754" alt="CleanShot 2026-06-29 at 22 38 51@2x" src="https://github.com/user-attachments/assets/3798d09e-7850-48e4-b2cd-508533f15cea" /> ## Banners #### Inbox connect alert <img width="2178" height="612" alt="CleanShot 2026-06-30 at 14 26 55@2x" src="https://github.com/user-attachments/assets/373c371c-bb7d-4291-a0f9-620673078302" /> #### Coverage alert <img width="2178" height="612" alt="CleanShot 2026-06-30 at 14 25 41@2x" src="https://github.com/user-attachments/assets/e12d6308-11b6-4ba2-88a2-8a3077dd3e8f" /> --------- Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>	2026-07-07 17:54:13 +05:30
Aakash Bakhle	83dda621c5	feat: default new accounts to captain v2 (#14917) ... # Pull Request Template ## Description defaults new accounts to captain v2 ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. locally and specs ## 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 - [x] Any dependent changes have been merged and published in downstream modules	2026-07-07 16:21:51 +05:30
Sony Mathew	7bf76057c2	fix: SLA handling for blocked contacts (#14861) ... # Pull Request Template ## Description Blocked contacts are now excluded from SLA assignment, processing, reports, and conversation SLA UI while they remain blocked. Existing SLA records are preserved, and SLA behavior resumes if the contact is unblocked. Fixes https://linear.app/chatwoot/issue/CW-7435/sla-should-not-trigger-for-blocked-contacts ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? - `bundle exec rspec spec/enterprise/models/conversation_spec.rb spec/enterprise/models/applied_sla_spec.rb spec/enterprise/services/enterprise/action_service_spec.rb spec/enterprise/services/sla/evaluate_applied_sla_service_spec.rb spec/enterprise/jobs/sla/process_account_applied_slas_job_spec.rb spec/enterprise/controllers/api/v1/accounts/applied_slas_controller_spec.rb spec/enterprise/controllers/api/v1/accounts/conversations_controller_spec.rb spec/enterprise/controllers/enterprise/api/v1/accounts/conversations_controller_spec.rb spec/enterprise/presenters/conversations/event_data_presenter_spec.rb` — 78 examples, 0 failures - `bundle exec rubocop enterprise/app/controllers/api/v1/accounts/applied_slas_controller.rb enterprise/app/jobs/sla/process_account_applied_slas_job.rb enterprise/app/models/applied_sla.rb enterprise/app/models/enterprise/concerns/conversation.rb enterprise/app/presenters/enterprise/conversations/event_data_presenter.rb enterprise/app/services/enterprise/action_service.rb enterprise/app/services/sla/evaluate_applied_sla_service.rb lib/tasks/apply_sla.rake spec/enterprise/controllers/api/v1/accounts/applied_slas_controller_spec.rb spec/enterprise/controllers/api/v1/accounts/conversations_controller_spec.rb spec/enterprise/controllers/enterprise/api/v1/accounts/conversations_controller_spec.rb spec/enterprise/jobs/sla/process_account_applied_slas_job_spec.rb spec/enterprise/models/applied_sla_spec.rb spec/enterprise/models/conversation_spec.rb spec/enterprise/presenters/conversations/event_data_presenter_spec.rb spec/enterprise/services/enterprise/action_service_spec.rb spec/enterprise/services/sla/evaluate_applied_sla_service_spec.rb` — no offenses - `pnpm exec vitest --no-watch --no-cache --no-coverage app/javascript/dashboard/components/widgets/conversation/specs/ConversationCard.spec.js` — 2 tests passed - `pnpm exec eslint app/javascript/dashboard/components-next/Conversation/ConversationCard/CardMessagePreviewWithMeta.vue app/javascript/dashboard/components-next/Conversation/ConversationCard/ConversationCardExpanded.vue app/javascript/dashboard/components/widgets/conversation/ConversationCard.vue app/javascript/dashboard/components/widgets/conversation/ConversationHeader.vue app/javascript/dashboard/components/widgets/conversation/specs/ConversationCard.spec.js` — passed with existing raw-text warnings in `ConversationHeader.vue` - `git diff --cached --check` — clean ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [ ] 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: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>	2026-07-02 14:16:29 +05:30
Tanmay Deep Sharma	a3c7f3b204	fix: finalize WhatsApp calls when terminate webhook overtakes connect (#14836) ... ## Description Some inbound WhatsApp calls stayed stuck in "ringing" forever. When a caller hung up within ~1s of dialing, Meta delivered the terminate webhook before the connect webhook. The terminate arrived with no call record yet and was dropped, then connect created the call in ringing with nothing left to close it. These calls now correctly land as missed (no_answer), and an agent who taps Accept on a call that already ended gets a clean "call ended" instead of a generic error. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? - local UI testing ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented on my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes - [ ] Any dependent changes have been merged and published in downstream modules	2026-07-02 13:58:36 +05:30
Sony Mathew	4e26c5b4bb	feat: Route system LLM jobs (4/6) (#14843) ... ## Description Routes the remaining system-only and legacy-sensitive LLM jobs through feature-level model configuration, while preserving system credential usage and usage-accounting behavior. This adds dedicated defaults for help center article generation, onboarding content generation, query translation, transcription, and search embeddings so these flows can be configured per account without falling back to installation-wide model settings. Fixes https://linear.app/chatwoot/issue/CW-7425/test-new-models ## Type of change - [ ] 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? Verified the feature routing defaults and account overrides for the touched Captain/system LLM paths, including the legacy OpenAI transcription and paginated FAQ services. - `eval "$(rbenv init -)" && bundle exec rspec spec/lib/captain/base_task_service_spec.rb spec/lib/llm/models_spec.rb spec/models/concerns/captain_featurable_spec.rb spec/controllers/api/v1/accounts/captain/preferences_controller_spec.rb spec/enterprise/services/captain/llm/paginated_faq_generator_service_spec.rb spec/enterprise/services/captain/llm/pdf_processing_service_spec.rb spec/enterprise/services/messages/audio_transcription_service_spec.rb spec/enterprise/services/onboarding/help_center_article_builder_spec.rb spec/enterprise/services/captain/onboarding/website_analyzer_service_spec.rb` - `eval "$(rbenv init -)" && bundle exec rubocop app/controllers/api/v1/accounts/captain/preferences_controller.rb app/models/concerns/account_settings_schema.rb lib/captain/base_task_service.rb enterprise/app/services/captain/llm/article_translation_service.rb enterprise/app/services/captain/llm/article_writer_service.rb enterprise/app/services/captain/llm/embedding_service.rb enterprise/app/services/captain/llm/help_center_curation_service.rb enterprise/app/services/captain/llm/paginated_faq_generator_service.rb enterprise/app/services/captain/llm/translate_query_service.rb enterprise/app/services/captain/llm/widget_tagline_service.rb enterprise/app/services/captain/onboarding/website_analyzer_service.rb enterprise/app/services/messages/audio_transcription_service.rb spec/enterprise/services/messages/audio_transcription_service_spec.rb spec/lib/captain/base_task_service_spec.rb` - `ruby -e "require 'yaml'; config = YAML.load_file('config/llm.yml'); %w[document_faq_generation help_center_article_generation onboarding_content_generation help_center_query_translation audio_transcription help_center_search].each { |feature| abort(%(missing #{feature})) unless config.dig('features', feature) }; abort('wrong article default') unless config.dig('features', 'help_center_article_generation', 'default') == 'gpt-5.2'; puts 'llm.yml ok'"` - `git diff --check` ## 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	2026-06-25 17:37:45 +05:30
Sony Mathew	91d8a4e2a3	feat: Route reply box LLM tasks (2/6) (#14840) ... # Pull Request Template ## Description Routes OSS reply-box and small Captain tasks through feature-specific LLM model resolution. Rewrite, reply suggestion, summary, follow-up, and CSAT utility analysis now resolve through the `editor` feature; label suggestion resolves through `label_suggestion`. Existing credentials, account OpenAI hook behavior, and instrumentation event names remain unchanged. Linear: https://linear.app/chatwoot/issue/CW-7425/test-new-models Depends on #14839 ## Type of change - [ ] 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? - `bundle exec rspec spec/lib/captain/base_task_service_spec.rb spec/lib/captain/rewrite_service_spec.rb spec/lib/captain/reply_suggestion_service_spec.rb spec/lib/captain/summary_service_spec.rb spec/lib/captain/label_suggestion_service_spec.rb spec/lib/captain/csat_utility_analysis_service_spec.rb spec/lib/captain/follow_up_service_spec.rb` passed with 81 examples, 0 failures. - `bundle exec rubocop lib/captain/base_task_service.rb lib/captain/rewrite_service.rb lib/captain/reply_suggestion_service.rb lib/captain/summary_service.rb lib/captain/label_suggestion_service.rb lib/captain/csat_utility_analysis_service.rb lib/captain/follow_up_service.rb enterprise/lib/enterprise/captain/reply_suggestion_service.rb spec/lib/captain/base_task_service_spec.rb spec/lib/captain/rewrite_service_spec.rb spec/lib/captain/reply_suggestion_service_spec.rb spec/lib/captain/summary_service_spec.rb spec/lib/captain/label_suggestion_service_spec.rb spec/lib/captain/csat_utility_analysis_service_spec.rb spec/lib/captain/follow_up_service_spec.rb` passed with no offenses. - `git diff --check` passed. ## 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	2026-06-25 17:01:05 +05:30
Sony Mathew	8b977b35a8	feat: Add LLM feature router (1/6) (#14839) ... ## Description Adds the foundation for feature-specific LLM model routing so Captain AI features can resolve their effective provider/model from code defaults and account-level overrides. This fixes the provider metadata key in `config/llm.yml`, adds `Llm::FeatureRouter`, and routes existing `CaptainFeaturable` model defaults through the shared resolver. Fixes https://linear.app/chatwoot/issue/CW-7425/test-new-models ## Type of change - [ ] 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? - `bundle exec rspec spec/lib/llm/models_spec.rb spec/lib/llm/feature_router_spec.rb spec/models/concerns/captain_featurable_spec.rb` - 23 examples, 0 failures - `bundle exec rubocop lib/llm/models.rb lib/llm/feature_router.rb app/models/concerns/captain_featurable.rb spec/lib/llm/models_spec.rb spec/lib/llm/feature_router_spec.rb spec/models/concerns/captain_featurable_spec.rb` - no offenses - `bundle exec ruby -e "require 'yaml'; config = YAML.load_file('config/llm.yml'); abort('missing providers') unless config['providers']; abort('missing models') unless config['models']; abort('missing features') unless config['features']; puts 'llm.yml ok'"` - `git diff --check` ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [ ] 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	2026-06-25 17:00:07 +05:30
Shivam Mishra	62cbeae95f	feat: onboarding inboxes UI (#14565) ... After entering their account details, new admins land on an **Inbox setup** screen that shows what we've already set up for them and lets them connect their conversation channels without leaving onboarding. It surfaces the auto-created live chat widget (and Help Center on Enterprise), highlights channels detected from their website, and offers a **View all** dialog to connect any supported channel inline. ### Channel status | Channel | How it connects | Status | PR | |---|---|---|---| | Live chat (Website) | Auto-created during setup | ✅ Done | https://github.com/chatwoot/chatwoot/pull/14314 | | WhatsApp | Meta embedded signup | ✅ Done | https://github.com/chatwoot/chatwoot/pull/14619 | | Facebook | Login + page picker | ✅ Done | https://github.com/chatwoot/chatwoot/pull/14619 | | Instagram | OAuth redirect | ✅ Done | https://github.com/chatwoot/chatwoot/pull/14568 | | TikTok | OAuth redirect | ✅ Done | https://github.com/chatwoot/chatwoot/pull/14569 | | LINE | Inline credential form | ✅ Done | — | | Telegram | Inline credential form | ✅ Done | — | | Gmail / Outlook | OAuth (email) | ⚠️ Disabled — coming in a follow-up | https://github.com/chatwoot/chatwoot/pull/14567 | | SMS / API / Voice / Other email | — | ⛔ Unavailable | — | --------- Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>	2026-06-25 14:54:07 +05:30
Muhsin Keloth	74db16158d	feat: migrate dyte integration to cloudflare realtimekit (#14752) ... Dyte is sunsetting its existing infrastructure after the Cloudflare acquisition, so this migrates Chatwoot’s video call integration to Cloudflare RealtimeKit. The integration now uses Cloudflare Account ID, RealtimeKit App ID, and a Cloudflare API token with Realtime Admin permissions. Meeting creation and participant token generation now call Cloudflare’s RealtimeKit APIs, while the existing Chatwoot call experience remains unchanged for agents and customers. This also adds setup-time credential validation, so admins get clearer errors when the API token is invalid, the Cloudflare account or permissions are incorrect, or the RealtimeKit App ID does not belong to the selected account. Fixes https://linear.app/chatwoot/issue/PLA-176/migrate-dyte-integration-to-cloudflare-realtimekit **How to test** 1. Go to Settings → Integrations → Cloudflare RealtimeKit. 2. Add a Cloudflare Account ID, RealtimeKit App ID, and API token with Realtime Admin permissions. 3. Confirm the integration saves successfully with valid credentials. 4. Try invalid credentials and confirm the error identifies whether the token, account/permissions, or app ID is wrong. 5. Start a video call from a conversation and confirm the RealtimeKit meeting opens. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> Co-authored-by: Sony Mathew <sony@chatwoot.com>	2026-06-24 11:04:08 +04:00
Vishnu Narayanan	f66b551c7d	revert: Sidebar unread counts for filters (CW-7262) (#14769) ... ## Description Reverts [#14726](https://github.com/chatwoot/chatwoot/pull/14726) (\"feat: Add sidebar unread counts for filters (CW-7262)\"), which shipped in 4.15.0. After 4.15.0 rolled out to prod the unread-counts-for-filters code path caused a cascading incident: - `Counter#ensure_filters_cache!` fires on every `/unread_counts/index` and `update_last_seen` request. - On cache miss it calls `Builder#build_filters_for!`, which: - invokes `store.clear_user_filters!` -> `delete_matching` -> a Redis `SCAN_each` over a per-user pattern keyspace, and - runs 4 fresh SQL passes per user (mentions, participating, unattended, and per-folder `Conversations::FilterService` queries). - Threads blocked in the SCAN held their DB connections, the connection pool exhausted, Sidekiq jobs were discarded with `ActiveJob::DeserializationError: could not obtain a connection from the pool`, and the enqueued queue blew past 200K. Related: [CW-7262](https://linear.app/chatwoot/issue/CW-7262/unread-counts-for-filters-folders) ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) - [ ] 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? ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [ ] 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	2026-06-17 14:58:48 +04:00
Sony Mathew	fe6368b42e	feat: Add sidebar unread counts for filters (CW-7262) (#14726) ... ## Description Extends the conversation unread-count system so the left sidebar can show unread badges for Mentions, Participating, Unattended, and saved conversation folders. Folder badges reuse the existing `custom_filters` conversation filter semantics, store user-scoped Redis sets lazily, and skip unsupported folder filters so invalid saved folders continue to render without a badge. The Unattended badge counts all visible unread open conversations that match the existing unattended conversation scope. Closes - [CW-7262](https://linear.app/chatwoot/issue/CW-7262/unread-counts-for-filters-folders) ## What changed - Added user-scoped unread-count Redis keys and cache builders for mentions, participating conversations, unattended conversations, and saved folder filters. - Reused `Conversations::FilterService` through a relation-returning path so folder counts match the folder conversation list behavior. - Invalidated user filter caches from mention, participant, custom-filter, and relevant conversation update events. - Extended the unread-count endpoint payload and sidebar Vuex/sidebar rendering for the new badge counts, including the Unattended sidebar item. - Added Ruby, Enterprise, request, listener, and frontend store coverage for the new unread-count dimensions. ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - Created local validation folders for `john@acme.inc` and confirmed the unread-count payload includes open, resolved, and high-priority folder badges while excluding the invalid unsupported folder. - Added coverage for the Unattended badge rule: all visible unread open conversations matching `Conversation.unattended`. - Ran focused unread-count Ruby specs, including service, listener, request, and Enterprise counter coverage. - Ran frontend unread-count store specs. - Ran RuboCop on the touched Ruby files. - Ran ESLint through the project script; it completed with warnings in existing unrelated files and no errors. <img width="369" height="525" alt="Screenshot 2026-06-13 at 10 51 39 PM" src="https://github.com/user-attachments/assets/36b1d2c4-dac1-4f6f-9c0e-7ef5a6cc2975" /> ## 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 - [x] Documentation changes are not required for this internal unread-count behavior - [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 - [x] No dependent downstream changes are required --------- Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>	2026-06-16 23:46:49 +05:30
Francisco Brito	64b0ebd8dc	feat: Script to migrate images between providers (#9117) ... # Pull Request Template ## Description Storage migration functionality, which allows the transfer of images from one on-premises provider to another (e.g. AWS, Google, etc.) using Active Storage. I ran the unit and integration tests and they all passed correctly. **The command to execute the migration is `FROM=from_service TO=to_service rake storage:migrate`** Fixes #7907 ## Type of change Please delete options that are not relevant. - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? I have tested the storage migration functionality by running the provided unit and integration tests. Additionally, I manually tested the migration process in a local development environment by following these steps: Set up two storage services (e.g., AWS S3 and Google Cloud Storage) with valid configurations. Execute the `FROM=local TO=amazon rake storage:migrate` task with appropriate FROM and TO arguments to migrate blobs between the services. Verified that the blobs were successfully transferred to the target storage service. Checked for any error messages or unexpected behavior during the migration process. ## 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 - [x] 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 - [x] Any dependent changes have been merged and published in downstream modules --------- Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>	2026-06-16 19:12:49 +05:30
Vishnu Narayanan	ee6382109a	feat: prevent deleted email conversations from syncing again (#14612) ... # Pull Request Template ## Description Prevent deleted email conversations from being synced into Chatwoot again while they are still within the IMAP sync window. When an admin explicitly deletes an email conversation, the incoming email message IDs are stored temporarily in Redis. IMAP sync checks these recently deleted message IDs in addition to existing message records. Each Redis key expires automatically after two days. This applies only to explicit conversation deletion. Individual message deletion, inbox deletion, and account deletion keep their existing behavior. Fixes [CW-7214](https://linear.app/chatwoot/issue/CW-7214/deleted-mails-in-gmail-inbox-gets-synced-again)	2026-06-15 17:06:40 +05:30
Sivin Varghese	59d869d1ed	feat: Ability to resize table column width (#14611)	2026-06-09 18:04:48 +05:30
Sony Mathew	e919a2cef5	feat: add contact filter for conversations (#14629) ... # Pull Request Template ## Description Adds a Contact condition to the conversation advanced filter so agents can search for an existing contact and filter conversations by `conversations.contact_id`. Fixes [CW-7239](https://linear.app/chatwoot/issue/CW-7239/contact-filter-for-conversations) ## Type of change - [ ] 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? - `eval "$(rbenv init -)" && bundle exec rspec spec/services/conversations/filter_service_spec.rb` - `pnpm exec vitest --no-watch --no-cache --no-coverage --logHeapUsage app/javascript/dashboard/components-next/filter/helper/filterHelper.spec.js app/javascript/dashboard/store/modules/conversations/helpers/specs/filterHelpers.spec.js app/javascript/dashboard/helper/specs/customViewsHelper.spec.js app/javascript/dashboard/helper/specs/filterQueryGenerator.spec.js` - `pnpm eslint` - `eval "$(rbenv init -)" && bundle exec rubocop spec/services/conversations/filter_service_spec.rb` ## 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: iamsivin <iamsivin@gmail.com> Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>	2026-06-08 16:00:17 +05:30
Aakash Bakhle	45f4b423ae	fix: captain usage for BYOK OpenAI tasks (#14587) ... # Pull Request Template ## Description Fixes: https://linear.app/chatwoot/issue/CW-7167/label-suggestions-bad-ux ## Type of change Please delete options that are not relevant. - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. ## Checklist: - [ ] My code follows the style guidelines of this project - [ ] I have performed a self-review of my code - [ ] I have commented on my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] My changes generate no new warnings - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] New and existing unit tests pass locally with my changes - [ ] Any dependent changes have been merged and published in downstream modules	2026-06-08 13:37:21 +05:30
Aakash Bakhle	eaffad12e7	feat(langfuse): propagate observation metadata for evals (#14634) ... # Pull Request Template ## Description We need to pass on trace level attributes down to the spans inside them like tool calls, observations, etc. This way, we can filter observations based on trace level attributes. ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Attributes added to observation metadata for easy filtering <img width="1327" height="708" alt="image" src="https://github.com/user-attachments/assets/8f1d1bf8-cde4-481d-a2c2-7920ad2fc52e" /> added a `generation_stage` to differentiate llm_calls that call tools vs those that generate a `final_response` <img width="1806" height="968" alt="CleanShot 2026-06-03 at 15 11 09@2x" src="https://github.com/user-attachments/assets/db1fa8e0-7f2d-404b-a719-27a16d400442" /> propagated attributes to tool calls for future use <img width="903" height="517" alt="image" src="https://github.com/user-attachments/assets/edc61ce8-93db-465c-a66e-043138e2dc15" /> ## 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 - [x] Any dependent changes have been merged and published in downstream modules	2026-06-03 16:45:19 +05:30
Sivin Varghese	1beaa284c6	feat: inline images in website and email channels (#14516) ... # Pull Request Template ## Description This PR adds support for inline image uploads in the reply editor for Email and Website (chat widget) channels. Agents can now insert images inline between text and resize them directly in the editor by dragging the bottom corner, similar to the help center editor experience. Image sizes are preserved through markdown using the `cw_image_width` URL param and render correctly in both outgoing emails and chat widget messages. Agents can also paste copied images directly into Email or Website replies using **Shift+Cmd+V** (Shift+Ctrl+V on Windows/Linux). The image gets inserted inline at the cursor position and supports resizing just like uploaded images. Regular **Cmd+V / Ctrl+V** behavior remains unchanged and continues to add images as attachments, so both inline and attachment flows are supported. ### Prosemirror repo PR: https://github.com/chatwoot/prosemirror-schema/pull/48 Fixes https://linear.app/chatwoot/issue/CW-7133/inline-images-in-live-chat-and-email https://linear.app/chatwoot/issue/CW-7225/ghsa-8j9w-jppp-xcfc-html-attribute-injection-via-unvalidated-cw-image ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? ### Screencast https://github.com/user-attachments/assets/a928f852-ab15-413a-9d35-6ea69b718ecf <img width="414" height="654" alt="image" src="https://github.com/user-attachments/assets/205e0729-8f2d-4cc5-9c55-7696f032eca4" /> ## 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 - [ ] 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: Muhsin Keloth <muhsinkeramam@gmail.com>	2026-06-03 15:05:17 +05:30
Vishnu Narayanan	7c16071fc7	fix: Support allowlisted private API inbox webhooks (#14548) ... Self-hosted installations can now opt SafeFetch into private-network access after SSRF hardening. The default remains unchanged: private IP destinations are blocked unless the instance owner explicitly enables private-network requests with `SAFE_FETCH_ALLOW_PRIVATE_NETWORK=true`. Fixes https://linear.app/chatwoot/issue/CW-7131 Fixes https://github.com/chatwoot/chatwoot/issues/14489 Fixes https://github.com/chatwoot/chatwoot/issues/14494 ## How to use For self-hosted installations that need API inbox webhooks, or other SafeFetch-backed requests, to call trusted private services, enable private-network access with a single environment variable: ```bash SAFE_FETCH_ALLOW_PRIVATE_NETWORK=true ``` This is disabled by default. Enable it only when the instance owner controls the deployment network and trusts the configured URLs.	2026-05-26 17:03:19 +05:30