937 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	161e4210b7	feat(analytics): add product catalog data foundation ... Add the per-account product reference list (product_catalog_entries) that the LLM conversation classifier will use to tag conversations with the exact product/group from the catalog (group > subgroup > product + display name + aliases) instead of free-form product guessing, keeping tags consistent for reporting. - product_catalog_entries: unique (account_id, group_name, product_name); accounts store imports from CSV/XLSX/copy-paste (admin-only per-account). - ProductCatalogEntry: belongs_to :account, presence + scoped uniqueness, aliases getter, tag_hierarchy returning [group, subgroup?, product]. Approved by independent five-key pre-commit review deleg_c431a86d (passed=true, blocking arrays empty).	2026-08-19 12:46:39 +07:00
Moreminimore	0fad9ce6b8	feat(analytics): add customer daily metrics data foundation ... Add the migration + model for per-customer-per-day conversation analytics (M2 phase 1b). Complements the per-account ConversationDailyMetric with a per-contact/day view so reports can drill into individual customers and see per-agent attribution, while the per-account table keeps the aggregate totals. - customer_daily_metrics: unique (account_id, contact_id, date); message/ conversation/resolved/unresolved counts, avg session duration, top tags, deal outcome breakdown, and agent_ids (jsonb). - CustomerDailyMetric: belongs_to :account + :contact (Contact convention), validations, JSONB getters defaulting to []/{}. Approved by independent five-key pre-commit review deleg_434fc544 (passed=true, blocking arrays empty).	2026-08-19 12:43:54 +07:00
Moreminimore	9fbb0da9b8	feat(analytics): add conversation daily metrics data foundation ... Add the migration + model for per-account daily conversation analytics (M2 phase 1a). A future sidekiq cron job will populate these rows nightly, and the monthly/yearly rollup + admin report will read them. - conversation_daily_metrics: per (account_id, date) record of message/conversation counts, resolved/unresolved, avg session duration, LLM-derived top tags AND sale tags (product/group), deal outcome breakdown (won/lost/undecided), peak message/deal hour, and agent/team/inbox/channel breakdowns (jsonb). - Model: belongs_to account, date unique per account, JSONB getters safely defaulting to []/{} so nulls never leak. Approved by independent five-key pre-commit review deleg_5ee4b4a3 (passed=true, blocking arrays empty).	2026-08-19 12:00:20 +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
Kunthawat Greethong	f17ce89d01	[brand] rebrand to Moreminimore Chat (configurable, phase 1) ... Set the default brand to Moreminimore Chat while keeping branding configurable via the existing InstallationConfig/ENV mechanism. - installation_config.yml: INSTALLATION_NAME/BRAND_NAME -> Moreminimore Chat, BRAND_URL/WIDGET_BRAND_URL -> https://www.moreminimore.com, TERMS/PRIVACY -> moreminimore.com, MAILER_SUPPORT_EMAIL -> contact@moreminimore.com; drop LOGO_DARK (single PNG logo for light+dark). - Mailer sender defaults -> 'Moreminimore Chat Team <contact@moreminimore.com>' across devise.rb, application_mailer, conversation_reply_mailer, mail_presenter, email_address_parseable. - Replace SVG brand assets with logo.png/logo_thumbnail.png (1000x1000); update onboarding, super_admin login/nav, Vue login/signup/saml, survey, helpcenter, widget, year-in-review to use the single PNG and Moreminimore Chat name; remove dark dual-logo pattern. - manifest.json name/short_name -> Moreminimore Chat; en.yml integration copy. Approved by independent five-key pre-commit review deleg_a733cdf4 (passed=true, security_concerns=[], logic_errors=[]). Privacy audit findings=0.	2026-08-16 08:20:13 +07:00
Kunthawat Greethong	5619cc38d5	SM-08 remove GTM portal analytics path	2026-08-15 18:07:55 +07:00
Kunthawat Greethong	d9bf4c45de	[verified] Remove automatic signup enrichment	2026-08-15 17:22:44 +07:00
Sivin Varghese	2ed68cf207	feat: cache canned responses in the browser (#15401)	2026-08-13 11:54:32 +05:30
Shivam Mishra	a24f5a3e7a	fix: anchor contact phone number validation (#15415) ... Contact phone numbers with stray text in front of them, like `abc+12312312321`, were saving successfully instead of being rejected as invalid. Agents could end up with unusable numbers on a contact, and the same values were persisted rather than discarded when captured through the live chat widget. ## How to reproduce 1. Open a contact and edit its details. 2. Set the phone number to `abc+12312312321` via the API (`PATCH /api/v1/accounts/:id/contacts/:id`). 3. Before this change the update succeeds. Now it fails validation. ## What changed The E.164 format check was missing a leading `\A` anchor, so Rails matched it anywhere in the string and accepted any prefix ahead of a valid number. Both the validation and the `phone_number_format` fallback used by `discard_invalid_attrs` are now anchored, so the widget path discards these values instead of storing them. Contacts already holding a prefixed number will now fail validation on their next save. Worth a count on production first: ```sql SELECT count(*) FROM contacts WHERE phone_number !~ '^\+[1-9][0-9]{1,14}$' AND phone_number <> ''; ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-08-12 15:28:49 +05:30
Devi R	8397fa7eaf	fix: include account_id in FCM push payload (#15260) ... ## Description - fcm_push_data didn't include the account id, so mobile clients had no way to know which account a push notification belonged to. This adds account_id to the FCM payload (it was already present in push_event_data for ActionCable, just not FCM). - Prerequisite for the mobile-side fix for [chatwoot-mobile-app#1121](https://github.com/chatwoot/chatwoot-mobile-app/pull/1121) (opening a conversation from a notification for a non-active account). - Added a spec asserting fcm_push_data includes the account id. Fixes [CW-4235](https://linear.app/chatwoot/issue/CW-4235/the-conversation-fails-to-open-when-the-notifications-account-differs) ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>	2026-08-11 20:10:51 -07:00
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
Sojan Jose	f12529105b	fix: align AgentBot ownership with conversation counts (#15343) ... AgentBot-owned conversations are now treated as assigned across conversation lists, counts, pagination, permissions, unread membership, human auto-assignment, and advanced assignee filters. ## Closes - https://linear.app/chatwoot/issue/CW-7689/align-agent-bot-ownership-with-unassigned-counts-and-pagination ## Follow-ups - https://linear.app/chatwoot/issue/CW-7870/refresh-agentbot-ownership-state-when-deleting-an-agent-bot tracks ownership refresh during AgentBot deletion. - https://linear.app/chatwoot/issue/CW-7899/refresh-saved-filter-totals-after-live-conversation-ownership-changes tracks the existing saved-filter header count refresh gap. ## Why The backend treated every conversation without a human assignee as unassigned, even when an AgentBot owned it. The frontend already hid AgentBot-owned conversations from the Unassigned list, so counts, pagination, filters, unread membership, direct-access permissions, and auto-assignment could disagree with the visible queue. ## What changed - Treat conversations with either a human assignee or AgentBot owner as assigned. - Keep conversation counts, pagination, unread memberships, advanced filters, and automation assignee conditions aligned with the shared ownership semantics. - Keep human assignee equality and not-equality filters human-only, even when a human and AgentBot have the same numeric ID. - Exclude AgentBot-owned conversations from both legacy and V2 human auto-assignment, and from unassigned-only Enterprise access. - Preserve AgentBot ownership when Twilio or WhatsApp call flows reuse or accept an assigned conversation. - Emit ownership-change updates when only the AgentBot owner changes, so connected clients refresh queue state. ## Validation - AgentBot assignment changed ownership to the bot, moved the conversation to pending, and removed it from the open queue. - Assignee "is present" returned human- and AgentBot-owned conversations; "is not present" returned only genuinely unassigned conversations. - Automation assignee presence conditions treated AgentBot ownership as present and did not execute the absent-owner path. - Live human-assignee equality and not-equality filters excluded AgentBot-owned conversations, including numeric ID collisions. - A 32-conversation pending queue loaded across pagination with matching totals and no missing or duplicate rows. - AgentBot ownership changes and human takeover updated filtered rows immediately without a reload. - Human takeover opened the conversation and restored the public reply composer; subsequent unassignment kept the conversation open. - An unassigned-only custom-role agent saw only genuinely unassigned conversations and could not see AgentBot-owned conversations. - AgentBot-owned conversations showed the handled-by-bot banner, Take over action, and disabled public reply composer. - New conversations in the connected inbox were assigned to the AgentBot and excluded from human auto-assignment. - Opening an AgentBot-owned conversation did not let the legacy assignment callback or its locked recheck replace the bot. - Moving an AgentBot-owned conversation to an auto-assigning team preserved the bot and did not create a second human owner. - Twilio conference pickup, Twilio outbound reuse, WhatsApp outbound reuse, and inbound WhatsApp acceptance preserved existing AgentBot owners. - Focused ownership, filters, pagination, permissions, unread-count, auto-assignment, frontend, and lint checks passed locally. - GitHub Actions, Docker builds, CircleCI, security checks, and the final Codex review are green on the final head.	2026-08-07 14:17:34 -07:00
Sony Mathew	696d2a5d37	fix: add default names to data imports (#15345) ... Data imports created without a name now receive a readable default such as `Contacts - 2026-08-06`. This prevents legacy CSV contact imports from appearing as `Untitled import` under Settings → Data while preserving names supplied by users or other import providers. ### Closes - [CW-7877](https://linear.app/chatwoot/issue/CW-7877/add-default-names-for-unnamed-data-imports) ## 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? 1. Create a contact CSV import without supplying a name. 2. Open Settings → Data and confirm its name follows `Contacts - YYYY-MM-DD`. 3. Create an import with an explicit name and confirm that name remains unchanged. ## 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 - [ ] 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-06 13:20:56 +05:30
Sojan Jose	3b74f9c359	fix: prevent Captain bot collisions (#15324) ... Prevents Captain from being scheduled for replies or inactive-conversation resolution when an inbox already has an active AgentBot or Dialogflow integration. ## Closes [CW-7834](https://linear.app/chatwoot/issue/CW-7834/prevent-captain-from-processing-agentbot-and-dialogflow-conversations) ## Why Captain and an external inbox bot could both process conversations from the same inbox. ## What this change does - Distinguishes external inbox bots from Captain in the existing bot predicate. - Skips Captain reply scheduling when an external bot is active. - Skips Captain inactive-resolution scheduling when an external bot is active. ## Validation - Connect an AgentBot to a Captain-enabled inbox and confirm Captain does not reply or schedule inactive resolution. - Enable Dialogflow on a Captain-enabled inbox and confirm Captain does not reply. - Remove the external bot integration and confirm Captain resumes normal processing. --------- Co-authored-by: Aakash Bakhle <48802744+aakashb95@users.noreply.github.com>	2026-08-05 16:34:46 +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
Muhsin Keloth	e1270a4ef8	fix(whatsapp): render template values in conversation transcript (#15255) ... WhatsApp template messages can be delivered with the correct variable values while the Chatwoot conversation shows numeric placeholders instead. This affects template sends where the client submits the raw template body together with valid processed parameters; WhatsApp delivery itself remains unchanged. The message model currently passes outgoing content through Liquid before saving it. Liquid interprets positional WhatsApp placeholders such as `{{1}}` and `{{2}}` as numeric expressions, even though the WhatsApp sender independently uses `processed_params.body` to build the provider payload. Fixes https://linear.app/chatwoot/issue/PLA-192/render-whatsapp-template-values-in-conversation-transcripts ### What changed For WhatsApp template messages, Chatwoot now substitutes positional or named body placeholders from `processed_params.body` before saving the transcript. Missing values remain visible as placeholders, and ordinary outgoing Liquid messages continue through the existing rendering path. The existing message model regression suite remains green, and the reported payload now persists as `Hello Ahmad, Furqan is your contact.` ### Things to know This corrects newly created messages. Existing conversation messages that were already stored as `1`, `2`, and so on are not backfilled. ### How to reproduce 1. Open a WhatsApp conversation outside the 24-hour messaging window. 2. Send a positional template whose body contains `{{1}}` and `{{2}}`. 3. Supply values for both parameters while submitting the original template body as the message content. 4. Observe that WhatsApp delivers the substituted values, while the Chatwoot transcript shows `1` and `2`. ### How to test 1. Select a WhatsApp template with two body variables. 2. Enter `Ahmad` and `Furqan` as the values and send the message. 3. Confirm the recipient receives the substituted template. 4. Confirm the Chatwoot conversation also displays `Ahmad` and `Furqan` instead of the numeric placeholders. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>	2026-08-03 12:31:06 +04:00
Sivin Varghese	6347ad1926	feat: add analytics providers to help center (#15124)	2026-08-03 10:39:02 +05:30
Tanmay Deep Sharma	0c606babea	feat: time based automation (#15022) ... ## Description Add automations that trigger based on how long a conversation has been in a given state. ## Type of change - [ ] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - UI flows - Specs (https://github.com/chatwoot/chatwoot/pull/15021) ## 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 --------- Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> Co-authored-by: iamsivin <iamsivin@gmail.com>	2026-07-30 16:04:17 +05:30
Aakash Bakhle	38a317962b	fix: Captain handles message bursts with a single reply (#15133) ... Captain now handles a burst of customer messages with one reply. If more messages arrive before Captain replies, the latest job uses the full conversation history. The change applies only to Captain V2 and works across every channel that Captain supports. Blocked on: https://github.com/chatwoot/chatwoot/pull/15212 ## Closes Closes https://github.com/chatwoot/chatwoot/issues/14545 ## How to reproduce 1. Start a pending conversation with Captain V2. 2. Send several messages while Captain is preparing a reply. 3. Captain can generate and send a separate reply for each message. ## What changed * Each Captain V2 job records the incoming message that started it. * A job stops before generation if a newer message already exists. * Captain discards a generated reply if a newer message arrived during generation. * The latest job replies using the full conversation history. * Langfuse records whether a generation was discarded and whether a customer credit was used. * Captain V1 keeps its existing behavior. ## Tradeoffs Discarded generations still cost money. Message bursts can also increase background job work and model provider load. A continuous stream of incoming messages can delay the reply until one generation finishes without a newer message. A small timing window remains if a message arrives after the final check and before Captain saves the reply. A handoff also cannot be undone if a newer message arrives after Captain has already changed the conversation status. ## How to test 1. Enable Captain V2 and start a pending Captain conversation. 2. Send several messages while Captain is preparing a reply. 3. Confirm that Captain sends one reply based on the full message history. 4. Confirm that Langfuse marks discarded runs with `discarded=true` and `credit_used=false`. 5. Disable Captain V2 and confirm that Captain V1 behavior is unchanged. --------- Co-authored-by: Sony Mathew <sony@chatwoot.com>	2026-07-30 15:58:54 +05:30
Muhsin Keloth	59eac9a7c5	feat(whatsapp): add cloud template management token (#15218) ... Chatwoot Cloud customers can now provide a dedicated WhatsApp business management token when their Embedded Signup credential cannot access message templates. Once validated, the token is stored securely and used only for template synchronization. Existing inboxes continue using their configured WhatsApp API key when no business management token is present. Sending, receiving, webhooks, phone-number health, and other WhatsApp operations remain unchanged. ### Things to know - This option is available only on Chatwoot Cloud. - Saving the token verifies that `whatsapp_business_management` is granted through Meta's permissions endpoint; template synchronization still verifies access to the configured WhatsApp Business Account. - The token is encrypted using the existing external-credentials encryption mechanism. - Self-hosted installations continue using the existing API key flow. ### How to test 1. On Chatwoot Cloud, open a WhatsApp Cloud inbox and go to **Configuration**. 2. Enter a token with `whatsapp_business_management` access and save it. 3. Confirm the token is accepted and the value is not exposed again in the UI or API. 4. Select **Sync Templates** and confirm templates are fetched with the saved business management token. 5. Remove the token and confirm template synchronization falls back to the inbox API key. 6. Confirm the business management token controls are not shown on a self-hosted installation. ### What changed - Added an encrypted `business_management_token` credential to WhatsApp channels. - Added Cloud-only endpoints and UI controls to validate the required permission, save, and remove the token. - Added template-sync credential selection with API-key fallback. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>	2026-07-29 13:37:59 +04:00
Vishnu Narayanan	3a8c5117da	fix(perf): lazy load super admin dashboard stats (#15147) ... The super admin landing page runs all its stat queries synchronously before rendering anything. On large installs the exact `COUNT(*)` on conversations and the 30-day chart group-by scan the whole table and exceed the request timeout, so the first page load fails and the console is unreachable.	2026-07-28 15:54:51 +05:30
Sony Mathew	7c1711170b	feat: Add account suspension metadata in Super Admin (#15158) ... ## Description Super Admins can now record a category and reason when suspending an account, review the complete suspension history on the account details page, and correct the latest suspension metadata without losing its original timestamp. Suspension events are stored internally on the account without changing customer-facing account API payloads. ## Closes - [CW-7653](https://linear.app/chatwoot/issue/CW-7653/ability-to-add-notes-while-suspending-an-acocunt) - [Implementation plan](https://linear.app/chatwoot/document/super-admin-account-suspension-metadata-implementation-plan-e7e4eb79d078) ## 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 ## What changed - Require a suspension category and a reason of up to 256 characters when an active account is suspended. - Store append-only suspension events in `accounts.internal_attributes`, while preserving unrelated internal metadata. - Allow corrections to the latest event for an already suspended account without changing its timestamp. - Show the full suspension history, newest first, on the Super Admin account details page. - Add visual dividers between top-level sections on the Super Admin account edit page. - Keep legacy suspended-account edits and new-account creation behavior unchanged. ## How to test 1. Open an active account in Super Admin and choose **Suspended**. 2. Confirm the category and reason controls appear, reject incomplete or invalid values, and enforce the 256-character reason limit. 3. Suspend the account with each supported category and confirm the event appears on the details page. 4. Reactivate and suspend the account again; confirm prior history is retained and a new event is added. 5. Edit a suspended account's latest category or reason; confirm its original timestamp is preserved. 6. Confirm a legacy suspended account without history can still be edited without supplying suspension metadata. ## 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 - [ ] 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-07-24 14:48:14 +05:30
Sony Mathew	65499df6a3	fix(email): allow larger email templates (#15146) ... ## Description Branded email layouts and other email templates can now contain up to 262,144 characters instead of the generic 20,000-character text limit. This supports customer layouts around 41 KB and 100 KB while retaining a defined application-level ceiling. The account and inbox API schemas now expose the same maximum. ## Closes [CW-7682](https://linear.app/chatwoot/issue/CW-7682/allow-larger-branded-email-templates) Related: [CW-7514](https://linear.app/chatwoot/issue/CW-7514/branded-html-email-templates-per-inboxbrand) ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) - [x] This change requires a documentation update ## How Has This Been Tested? 1. As an administrator with `branded_email_templates` enabled, update an account branded layout with a 100 KB Liquid layout containing `{{ content_for_layout }}` and confirm the request succeeds. 2. Update an Email inbox layout with more than 262,144 characters and confirm the API returns `422`. 3. Confirm a layout at exactly 262,144 characters remains valid. ## 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 - [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	2026-07-24 14:00:01 +05:30
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
Muhsin Keloth	d644c207f0	feat: monitor whatsapp phone number health (#15100) ... Adds scheduled WhatsApp Cloud API phone-number health synchronization and expands the Account Health page with phone, capacity, business-account, webhook, coexistence, and recovery details. Authorization failures now guide administrators to the appropriate Configuration flow without exposing technical Meta error codes. Fixes [CW-7621](https://linear.app/chatwoot/issue/CW-7621/store-whatsapp-phone-number-health-status) **Preview** <img width="2594" height="1676" alt="CleanShot 2026-07-22 at 10 55 01@2x" src="https://github.com/user-attachments/assets/de606cb4-5682-4178-87e9-c18752d299b5" /> <img width="2576" height="1506" alt="CleanShot 2026-07-22 at 10 55 08@2x" src="https://github.com/user-attachments/assets/4eb1810f-be12-4fbc-bcb0-9e2906785c48" /> <img width="1748" height="1150" alt="CleanShot 2026-07-22 at 11 10 05@2x" src="https://github.com/user-attachments/assets/64f5be5a-c127-4372-889f-d392947c13b8" /> ### How to test 1. Open **Settings → Inboxes → a WhatsApp Cloud API inbox → Account Health**. 2. Confirm the page shows separate Phone number, Health and capacity, Business account, and Webhook configuration sections. 3. Confirm the configured webhook URL can be copied and the expected URL appears only when it differs. 4. For a coexistence number, confirm **Coexistence · Active** appears; confirm it is hidden for standard Cloud API numbers. 5. With an invalid Embedded Signup token, confirm the page asks to refresh the WhatsApp connection and **Go to Configuration** opens the Configuration tab. 6. With an invalid manually configured token, confirm the page asks the administrator to verify or replace the access token. 7. Confirm authorization states do not display Meta error codes or the manual-migration recommendation. ### What changed - Persists the latest successful phone health snapshot, check time, and most recent error while retaining the last successful data after a failed refresh. - Refreshes stale active Cloud API channels every six hours through low-priority jobs. - Fetches phone, WABA, business portfolio, webhook, and coexistence details. - Uses Meta's current `whatsapp_business_manager_messaging_limit` field while preserving the existing UI response key. - Classifies authorization failures for setup-specific recovery guidance and logs new risky quality/status transitions. - Adds focused service, scheduler, job, trigger, and API coverage. Internal alerts, throttling, automatic inbox disablement, and customer notifications remain outside this PR and are tracked separately in CW-7622. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>	2026-07-24 12:00:37 +04:00
Sony Mathew	7786e38df9	feat: retry stalled Intercom imports after 15 minutes (#15050) ... ## Description Adds a guarded retry action for Intercom imports that have not recorded progress for 15 minutes. The API reports stalled state, rotates the import run identifier under an account lock, preserves existing progress and logs, and queues a fresh worker only when no other Intercom import is active for the account. The import details page shows Retry immediately before Abandon only while the server reports the import as stalled. This is Phase 1, Task 1 of the [Intercom import optimization plan (CW-7615)](https://linear.app/chatwoot/issue/CW-7615/optimize-intercom-import-reliability-and-bulk-message-ingestion). This replaces #15049 with the updated 15-minute threshold and is based directly on the latest `develop`. ## Closes - [CW-7519](https://linear.app/chatwoot/issue/CW-7519/explore-intercom-import) ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How to test 1. Open a processing Intercom import updated within the last 15 minutes and confirm Retry is hidden. 2. Set its updated timestamp to more than 15 minutes ago and reload the details page. 3. Confirm Retry appears immediately before Abandon. 4. Retry the import and confirm it returns to Pending while existing progress, logs, and the original start time remain intact. 5. Confirm a second retry is rejected and another active Intercom import prevents queueing. ## Checklist - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have added tests that prove the change is effective - [x] New and existing focused tests pass locally with my changes	2026-07-24 12:30:36 +05:30
Sojan Jose	56e72eff8d	feat: assign connected agent bot owner (#14875) ... Connected Agent Bot-handled conversation creation now records the bot as the explicit owner instead of relying on pending status alone. Closes: https://linear.app/chatwoot/issue/CW-7449/set-connected-agent-bot-as-owner-in-bot-handled-flows ## Why When an inbox has a connected Agent Bot, bot-handled conversations already move to pending for queue placement. They should also carry explicit Agent Bot ownership so agents can see that the bot is handling the conversation and later takeover/hand-back behavior has a real owner to work with. ## What changed - Sets active connected Agent Bot inbox conversations to pending. - Sets `assignee_agent_bot` to the connected Agent Bot when no explicit human assignee is present. - Clears the human `assignee` when assigning the connected Agent Bot owner. - Preserves explicit human assignees on conversation creation. - Sets bot-initiated campaign conversations in active Agent Bot inboxes to pending and owned by the connected Agent Bot. - Keeps human-sender campaign conversations open and without Agent Bot ownership. - Leaves Dialogflow pending behavior without Agent Bot ownership. - Clears `assignee_agent_bot` when the bot hands the conversation off. ## Validation - Create a conversation in an inbox with an active connected Agent Bot and verify it is pending and owned by the Agent Bot. - Create a conversation in that inbox with an explicit human assignee and verify the human assignee is preserved. - Create a bot-initiated campaign conversation in the same inbox and verify it is pending and owned by the Agent Bot. - Create a human-sender campaign conversation and verify it remains open without Agent Bot ownership. - Create a Dialogflow-handled pending conversation and verify no Agent Bot owner is set. - Trigger bot handoff and verify the Agent Bot owner is cleared.	2026-07-23 19:22:35 -07:00
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
Sivin Varghese	331875cdaa	feat: Add popular content per locale (#14939)	2026-07-17 14:43:42 +05:30
Shivam Mishra	522e3c4d3f	feat: enforce api_and_webhooks feature for token API and account webhooks (#14973) ... This gates API-token access and outgoing account webhooks behind the `api_and_webhooks` account feature introduced in #14972. On Chatwoot Cloud, Hacker accounts lose token-authenticated account API access and account webhook delivery, while paid accounts retain them through the billing-plan feature reconcile. Community and self-hosted installations continue to work without any upgrade-time interruption. ## What changed - Added `Account#api_and_webhooks_enabled?` as the single backend kill switch. Core returns enabled; the Enterprise override consults the account flag on Chatwoot Cloud and remains enabled off-Cloud. - Account-scoped v1 and v2 requests authenticated with a user or agent-bot API token now return `403 Forbidden` when the feature is disabled. Invalid tokens still return 401, and dashboard session requests are unaffected. - Profile responses return an empty access token when none of the user's accounts has access. The stored token is preserved, and the profile UI disables its token controls with paid-plan copy on Cloud. - Account webhook delivery stops when the feature is disabled. Webhook CRUD remains available to session-authenticated dashboard requests, API-inbox webhooks continue to be delivered, and the Cloud dashboard shows a webhook paywall instead of the webhook list. - Removed the database backfill migration. Existing paid Cloud accounts should be enabled with the one-off script below before enforcement is deployed. ## Existing paid-account rollout Run this as an ad-hoc Rails runner script on Chatwoot Cloud. It intentionally targets only the Startups, Business, and Enterprise plans and does not add `api_and_webhooks` to `manually_managed_features`, so future billing reconciles remain authoritative. ```rb paid_plan_names = %w[Startups Business Enterprise] accounts = Account.where("custom_attributes ->> 'plan_name' IN (?)", paid_plan_names) total = accounts.count enabled = 0 skipped = 0 puts "Enabling api_and_webhooks for #{total} paid account(s)..." accounts.find_each(batch_size: 500).with_index(1) do |account, processed| if account.feature_enabled?('api_and_webhooks') skipped += 1 else account.enable_features!('api_and_webhooks') enabled += 1 end puts "Processed #{processed}/#{total}..." if (processed % 1000).zero? end puts "Done! Enabled: #{enabled}, Skipped: #{skipped}, Total: #{total}" ``` For example, save the snippet outside the repository as `enable_api_and_webhooks.rb`, then run: ```sh bundle exec rails runner /path/to/enable_api_and_webhooks.rb ``` ## How to test - On Cloud, use a Hacker account and confirm token-authenticated requests to account-scoped v1 and v2 endpoints return 403, while the same dashboard actions continue to work through session authentication. - Confirm profile access-token controls are disabled with paid-plan copy when all accounts are ineligible, and remain available when at least one account has the feature. - Confirm the Webhooks settings page shows the billing paywall for a Cloud account without the feature; admins get the billing action and agents get the existing ask-an-admin message. - Confirm outgoing account webhooks stop for an ineligible Cloud account while API-inbox webhooks still deliver. - Confirm community and self-hosted installations retain API and webhook behavior after upgrading, even when an existing account does not have the stored feature bit. ### Screenshots ## Cloud <img width="2590" height="642" alt="CleanShot 2026-07-15 at 15 13 14@2x" src="https://github.com/user-attachments/assets/431a7bd8-1742-4e7a-b312-d3ad92015f9b" /> <img width="2152" height="994" alt="CleanShot 2026-07-15 at 15 14 37@2x" src="https://github.com/user-attachments/assets/475dda48-d1c5-4be5-a3c3-7a96b9713724" /> --------- Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>	2026-07-16 13:43:49 +04:00
Muhsin Keloth	0a25a0ef66	fix(whatsapp): log manual transfer only for embedded signup migrations (#15032) ... The `[WHATSAPP_MANUAL_TRANSFER] success` log introduced in #14975 to track embedded signup → manual migrations was firing on any WhatsApp credential change — including routine `api_key` rotations on inboxes that were already manually configured — inflating the migration count. The log now fires only for the actual migration, and uses a new tag so log searches don't match the older over-counted entries. ## How to reproduce 1. On a manually configured WhatsApp Cloud inbox, update the API key from inbox settings → Configuration. 2. Before this change, the app log records a `[WHATSAPP_MANUAL_TRANSFER] success` line even though no migration happened; after this change it stays silent. 3. Switching an embedded signup inbox to manual setup still logs the migration (now as `[WHATSAPP_EMBEDDED_TO_MANUAL] success`). ## What changed - `Channel::Whatsapp#log_credentials_transfer` now keys off the migration's unique signal — `provider_config['source']` changing from `embedded_signup` to absent — instead of diffing credential keys. - Renamed the log tag from `WHATSAPP_MANUAL_TRANSFER` to `WHATSAPP_EMBEDDED_TO_MANUAL` (success and failure lines) so the corrected entries are searchable without matching pre-fix false positives. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>	2026-07-16 13:35:20 +04:00
Sivin Varghese	0fccb7dacd	feat: stage edits to published articles as drafts (#14842)	2026-07-16 12:44:10 +05:30
Aakash Bakhle	354c2cab6b	fix(captain): handle resolved conversation context (#14433) ... # Pull Request Template ## Description Fixes: https://github.com/chatwoot/chatwoot/issues/13880 Uses approaches discussed from: https://github.com/chatwoot/chatwoot/pull/13883 Activity messages pertaining to resolve are included along with an instruction for the LLM to choose whether to consider them or not along ## 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. locally and with 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 --------- Co-authored-by: Sony Mathew <sony@chatwoot.com>	2026-07-15 23:30:17 +05:30
Sony Mathew	11c65f3b9a	feat: Intercom import workflow (#14922) ... ## Description Adds an admin-only Intercom import workflow under Settings > Data. Admins can connect an Intercom access token, start named historical contact/conversation imports, monitor active and previous import runs, review paginated skip/error logs, download skip logs, and route imported conversations into source-bucket API inboxes that can be renamed later. The import path stores durable source mappings, batches Intercom contact/conversation pages through Sidekiq, records already-imported records as skipped, and writes historical messages without normal outbound delivery callbacks. The PR also includes the Intercom import PRD/TDD document for review context. Closes [CW-7519](https://linear.app/chatwoot/issue/CW-7519/explore-intercom-import) ## 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) - [x] This change requires a documentation update ## How Has This Been Tested? Tested importing using actual data through integration. Screenshots: <img width="1800" height="948" alt="Screenshot 2026-07-02 at 10 48 48 PM" src="https://github.com/user-attachments/assets/e74d9ed6-0bca-47de-b6ef-e589afcddfde" /> <img width="1800" height="1008" alt="Screenshot 2026-07-02 at 10 49 03 PM" src="https://github.com/user-attachments/assets/1bd12fdb-0a47-4287-ac1d-ea308e70a9cd" /> <img width="1800" height="1005" alt="Screenshot 2026-07-02 at 10 49 21 PM" src="https://github.com/user-attachments/assets/3d8145f5-1794-4cc3-b3fa-de5cd80e6ca3" /> <img width="1800" height="1002" alt="Screenshot 2026-07-02 at 10 49 38 PM" src="https://github.com/user-attachments/assets/6f818efd-4193-43c2-84eb-66970dca4490" /> Passed locally: ```sh eval "$(rbenv init -)" && bundle exec rspec spec/models/data_import_spec.rb spec/jobs/data_import_job_spec.rb spec/requests/api/v1/accounts/data_imports_spec.rb spec/requests/api/v1/accounts/integrations/intercom_spec.rb spec/jobs/data_imports/intercom/import_jobs_spec.rb spec/services/data_imports/intercom/importer_spec.rb spec/services/data_imports/intercom/placeholder_inbox_builder_spec.rb spec/services/data_imports/intercom/source_bucket_spec.rb ``` ```sh eval "$(rbenv init -)" && bundle exec rubocop app/controllers/api/v1/accounts/data_imports_controller.rb app/controllers/api/v1/accounts/integrations/intercom_controller.rb app/jobs/data_imports/intercom app/models/data_import.rb app/models/data_import_error.rb app/models/data_import_item.rb app/models/data_import_mapping.rb app/models/integrations/hook.rb app/policies/data_import_policy.rb app/policies/hook_policy.rb app/services/data_imports/intercom db/migrate/20260702000000_expand_data_imports_for_intercom_imports.rb db/migrate/20260702000001_create_data_import_items.rb db/migrate/20260702000002_create_data_import_mappings.rb db/migrate/20260702000003_create_data_import_errors.rb spec/jobs/data_imports/intercom spec/requests/api/v1/accounts/data_imports_spec.rb spec/requests/api/v1/accounts/integrations/intercom_spec.rb spec/services/data_imports/intercom ``` ```sh pnpm exec eslint app/javascript/dashboard/api/dataImports.js app/javascript/dashboard/api/integrations.js app/javascript/dashboard/routes/dashboard/settings/data/Index.vue app/javascript/dashboard/routes/dashboard/settings/data/Show.vue app/javascript/dashboard/routes/dashboard/settings/data/data.routes.js app/javascript/dashboard/routes/dashboard/settings/data/importStatus.js app/javascript/dashboard/routes/dashboard/settings/integrations/Intercom.vue app/javascript/dashboard/routes/dashboard/settings/integrations/integrations.routes.js app/javascript/dashboard/routes/dashboard/settings/settings.routes.js app/javascript/dashboard/components-next/sidebar/Sidebar.vue app/javascript/dashboard/routes/dashboard/settings/inbox/Index.vue ``` ```sh git diff --check ``` Note: the RSpec boot logs the existing local `chatwoot_dev` purge warning because other database sessions are open, then continues and completes with 52 examples, 0 failures. ## 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 - [x] I have made corresponding changes to the documentation - [ ] 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: Shivam Mishra <scm.mymail@gmail.com> Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> Co-authored-by: iamsivin <iamsivin@gmail.com>	2026-07-13 15:25:07 +05:30
Tanmay Deep Sharma	9c10fe4eb1	fix: default assignment age exclusion (#14998) ... ## Description Auto-assignment was skipping the 7-day staleness check entirely for inboxes that don't have an assignment policy attached. Those inboxes would pull unassigned conversations of any age off the backlog and hand them to agents — including conversations untouched for months — while the activity log still credited "Default Policy" for the assignment. This makes the default behaviour match what that label implies: with no policy configured, conversations with no activity in the last 7 days are now excluded, the same window a freshly created policy uses. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) ## 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-13 14:01:47 +05:30
Tanmay Deep Sharma	b560720e08	feat: allow switching embedded signup whatsapp embedded inboxes to manual setup (#14975) ... Since embedded signup has been disabled on production, WhatsApp inboxes that were created through it have no way to be managed going forward. This PR lets admins transfer an embedded signup inbox to a manual Cloud API setup: the inbox settings Configuration tab now shows the webhook verification token and a "Switch to Manual Setup" form (pre-populated with the Phone Number ID, Business Account ID, and API key stored during the embedded signup journey) instead of the old Reconfigure button. Saving the form updates the channel's `provider_config` without the `source: embedded_signup` marker, so the inbox becomes a regular manually-configured WhatsApp Cloud inbox. The backend re-validates the submitted credentials against Meta before accepting the change. ## How to test 1. Open the settings page of a WhatsApp inbox created via embedded signup → Configuration tab. 2. The Reconfigure button is gone; you see the webhook verification token and a Switch to Manual Setup form pre-filled with the stored credentials. 3. Configure the webhook in your own Meta app using the verification token, enter a permanent access token from that app, and click "Switch to Manual Setup". 4. On success the page switches to the standard manual configuration view (verify token, API key update), and messaging continues to work with the new credentials. Invalid credentials are rejected with an error. ## What changed - `ConfigurationPage.vue`: replaced the embedded-signup Reconfigure section (and the hidden reauthorize component) with the manual transfer form. - New `WHATSAPP_MANUAL_TRANSFER_*` translation keys. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> Co-authored-by: iamsivin <iamsivin@gmail.com>	2026-07-13 13:48:38 +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
Sony Mathew	873d16f54c	feat: Extend account feature flag storage (#14947) ... # Pull Request Template ## Description Extends account-level feature flags by adding a second bigint bitset column, `feature_flags_ext_2`, while preserving the existing `flag_shih_tzu` feature check and enable/disable APIs. Existing flags continue to live on `feature_flags`; future flags can opt into the extension column through `config/features.yml` metadata. Fixes [CW-7238](https://linear.app/chatwoot/issue/CW-7238/feature-flag-extension) ## 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 -)" && RAILS_ENV=test POSTGRES_DATABASE=chatwoot_test_31a6 bundle exec rspec spec/models/concerns/featurable_spec.rb spec/models/account_spec.rb spec/lib/config_loader_spec.rb spec/controllers/platform/api/v1/accounts_controller_spec.rb spec/controllers/super_admin/accounts_controller_spec.rb spec/enterprise/models/account_spec.rb` - 144 examples, 0 failures - `eval "$(rbenv init -)" && bundle exec rubocop app/models/concerns/featurable.rb app/models/account.rb db/migrate/20260706215758_add_feature_flags_ext_2_to_accounts.rb spec/models/concerns/featurable_spec.rb spec/models/account_spec.rb spec/lib/config_loader_spec.rb spec/enterprise/models/account_spec.rb` - 7 files inspected, no offenses detected - `ruby -ryaml -e "features = YAML.safe_load(File.read('config/features.yml')); abort unless features.size == 63; puts features.group_by { |f| f['column'] || 'feature_flags' }.transform_values(&:size).inspect"` - `{"feature_flags" => 63}` - `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 - [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	2026-07-08 17:38:26 +05:30
Muhsin Keloth	ce8c8e9a11	fix: sanitize control characters in team names (#14865) ... Team names created via the API could contain control characters (for example a trailing newline). Because the team-delete confirmation dialog requires you to retype the team name and matches it against the stored value, a hidden control character meant the typed name never matched — leaving the team impossible to delete from the UI. This sanitizes team names on save so they stay clean and deletable. #### How to reproduce 1. Create a team via `POST /api/v1/accounts/{account_id}/teams` with `{"name": "test\n"}`. 2. The team is created with the trailing newline stored in `name`. 3. In **Settings → Teams**, click delete and type the team name to confirm — the match fails, so the team cannot be deleted. #### What changed - `app/models/team.rb`: the existing `before_validation` now strips control characters and surrounding whitespace before downcasing the name. Names that reduce to blank (e.g. only newlines/tabs) are rejected loudly by the existing `presence` validation. - Fixing at the model layer covers the API and every other create/update path, rather than relying on the frontend confirm-dialog `.trim()` (which only handles leading/trailing whitespace, not internal control characters). Note: this prevents new malformed names. Any team already saved with a control character can be made deletable again simply by renaming it (an update re-runs the same sanitization). | Input | Stored as | Result | |---|---|---| | `"test\n"` | `"test"` | valid, deletable | | `"te\nst"` (internal) | `"test"` | valid | | `"\t\n "` (only control/ws) | — | rejected: "Name must not be blank" | | `"Customer Support"` | `"customer support"` | unchanged behavior | 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-07 18:04:24 -07:00
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
Sivin Varghese	34d8741b9b	feat: drag to reorder help center articles across pages (#14910)	2026-07-02 15:47:01 +05:30
Sony Mathew	b8b62ad0f1	feat: Harden model override preferences (5/6) (#14846) ... ## Description Hardens the Captain model override preferences API so account-level overrides follow the same feature-router contract used by runtime LLM calls. The API now permits model and feature keys from `llm.yml`, removes blank model overrides, rejects invalid saved model combinations, and returns each feature's effective model, provider, and source for UI clients. 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 account preferences API and account model validation behavior for valid overrides, invalid model values, unknown feature keys, blank override removal, and effective model/provider/source payload metadata. - `eval "$(rbenv init -)" && bundle exec rspec spec/controllers/api/v1/accounts/captain/preferences_controller_spec.rb spec/models/account_spec.rb spec/models/concerns/captain_featurable_spec.rb spec/lib/llm/feature_router_spec.rb` - `eval "$(rbenv init -)" && bundle exec rubocop app/controllers/api/v1/accounts/captain/preferences_controller.rb app/models/concerns/account_settings_schema.rb app/models/concerns/captain_featurable.rb spec/controllers/api/v1/accounts/captain/preferences_controller_spec.rb spec/models/account_spec.rb spec/models/concerns/captain_featurable_spec.rb spec/lib/llm/feature_router_spec.rb` - `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 - [ ] 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:38:11 +05:30
Sony Mathew	43e0f8a141	feat: Route Enterprise LLM services (3/6) (#14841) ... # Pull Request Template ## Description Routes Enterprise assistant, copilot, FAQ, contact memory, action-classifier, and false-promise detector LLM paths through feature-specific model resolution. `Llm::BaseAiService` now accepts feature/account context and uses `Llm::FeatureRouter` when that context is present, while retaining the installation-model fallback for unmigrated callers. This also adds a `document_faq_generation` feature default for generative FAQ/document content. Linear: https://linear.app/chatwoot/issue/CW-7425/test-new-models Depends on #14840 ## 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/enterprise/services/llm/base_ai_service_spec.rb spec/enterprise/services/captain/copilot/chat_service_spec.rb spec/enterprise/services/captain/llm/assistant_chat_service_spec.rb spec/enterprise/services/captain/llm/faq_generator_service_spec.rb spec/enterprise/services/captain/llm/conversation_faq_service_spec.rb spec/enterprise/services/captain/llm/assistant_action_classifier_service_spec.rb spec/enterprise/services/captain/llm/assistant_false_promise_service_spec.rb spec/enterprise/jobs/captain/conversation/response_builder_job_spec.rb` passed with 112 examples, 0 failures. - `bundle exec rspec spec/models/concerns/captain_featurable_spec.rb spec/models/account_spec.rb spec/controllers/api/v1/accounts/captain/preferences_controller_spec.rb spec/lib/llm/feature_router_spec.rb` passed with 87 examples, 0 failures. - `bundle exec rubocop enterprise/app/services/llm/base_ai_service.rb enterprise/app/services/captain/copilot/chat_service.rb enterprise/app/services/captain/llm/assistant_chat_service.rb enterprise/app/services/captain/llm/faq_generator_service.rb enterprise/app/services/captain/llm/conversation_faq_service.rb enterprise/app/services/captain/llm/contact_notes_service.rb enterprise/app/services/captain/llm/contact_attributes_service.rb enterprise/app/services/captain/llm/assistant_action_classifier_service.rb enterprise/app/services/captain/llm/assistant_false_promise_service.rb spec/enterprise/services/llm/base_ai_service_spec.rb spec/enterprise/services/captain/copilot/chat_service_spec.rb spec/enterprise/services/captain/llm/assistant_chat_service_spec.rb spec/enterprise/services/captain/llm/faq_generator_service_spec.rb spec/enterprise/services/captain/llm/conversation_faq_service_spec.rb spec/enterprise/services/captain/llm/assistant_action_classifier_service_spec.rb spec/enterprise/services/captain/llm/assistant_false_promise_service_spec.rb spec/enterprise/jobs/captain/conversation/response_builder_job_spec.rb` passed with no offenses. - `bundle exec ruby -e "require 'yaml'; config = YAML.load_file('config/llm.yml'); abort('missing document_faq_generation') unless config.dig('features', 'document_faq_generation'); abort('missing default') unless config.dig('features', 'document_faq_generation', 'default'); puts 'llm.yml ok'"` passed. - `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:03:07 +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
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
Sivin Varghese	e8edc9ebf5	feat: allow users to set an icon or emoji for teams (#14767)	2026-06-23 20:53:31 +05:30
Aakash Bakhle	84fda8a323	fix(captain): move false promise harness setting to account (#14823) ... # Pull Request Template ## Description moves the harness to account settings rather than assistant settings ## Type of change refactor ## 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-06-23 16:55:42 +05:30