# Pull Request Template
## Description
This PR removes the old Captain label suggestion card above the reply
box. Label suggestions now come from the Captain suggestions in the
conversation sidebar.
This also removes the Label Suggestion toggle in Captain settings and
the "Show label suggestions" option on the OpenAI integration. A
migration clears old saved values so existing accounts keep saving.
## Type of change
- [x] Breaking change (fix or feature that would cause existing
functionality not to work as expected)
## 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: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
# Pull Request Template
## Description
Agents using an input method editor (Vietnamese Telex, Chinese,
Japanese, Korean) press Enter once to confirm the word being composed
and again to send. The reply box treated the first Enter as send, so the
full message was sent, the editor cleared, and the browser inserted the
half-finished word back into the empty box. The second Enter then sent
that fragment as a separate message.
The reply box now ignores Enter and Cmd/Ctrl+Enter while an IME
composition is in progress, so only the second Enter sends the message.
Fixes
https://linear.app/chatwoot/issue/CW-8345/reply-box-sends-the-message-when-enter-confirms-an-ime-word-then-the
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### How to reproduce
1. Switch to an IME input source, for example Vietnamese Telex on macOS,
and set the send key to Enter.
2. Type a sentence and stop while the last word is still underlined.
3. Press Enter once. Before this change, the whole message is sent and
the word reappears alone in the editor. After this change, nothing is
sent and the word is confirmed.
4. Press Enter again. The complete message is sent once.
## 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
## Description
`AutoAssignment::RateLimiter` counted an agent's recent assignments with
`Redis::Alfred.keys_count`, which runs `SCAN` over the whole keyspace
once per candidate agent per conversation on every assignment run. On a
large keyspace that is thousands of round trips per check, and the cost
scales with keyspace size rather than with assignments.
This stores assignments in one sorted set per inbox and agent (member:
conversation id, score: assignment time), trims entries older than the
window on write, expires the key with the window, and counts with
`ZCOUNT`. Limits, windows and defaults are unchanged.
Existing per-assignment keys are not migrated: windows in progress at
deploy time reset, and the old keys expire on their own.
Fixes https://linear.app/chatwoot/issue/INF-116
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
`bundle exec rspec spec/services/auto_assignment
spec/jobs/auto_assignment` (62 examples, 0 failures). The rate limiter
spec now asserts Redis state directly, including trimming and the
sliding window via `travel_to`.
## 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
## Description
Migrations with hand-written, rounded versions (e.g. `20260925000000`)
keep colliding across branches. Git merges two such files cleanly
because the filenames differ, and spec CI stays green because it loads
the schema instead of running migrations. The failure only shows up on a
real `db:migrate`: a `DuplicateMigrationVersionError`, or a database
that already recorded one branch's migration silently skipping the
other.
This adds:
- A `Migration Version Check` workflow on PRs that touch `db/migrate`.
It fails when a migration added or renamed in the PR has a version
ending in `0000`, and when two files in `db/migrate` share a version.
Existing migrations are not flagged.
- An `AGENTS.md` rule to create migrations with `rails g migration`
instead of writing the version by hand.
Linear: https://linear.app/chatwoot/issue/INF-118
## Type of change
CI and contributor guidelines only, no app code changes.
## How Has This Been Tested?
Ran both steps locally against simulated PR merge commits on top of
develop: a generated timestamp passes, `...000000` and `...090000`
versions fail, renaming a migration to a rounded version fails, and a
duplicate of an existing version fails. Develop as-is passes both
checks.
## 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
- [ ] 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
Presence pings from the dashboard, mobile app, and widget now run one
less Postgres query each. Agents and visitors see no change in behavior.
## What changed
- `OnlineStatusTracker.get_available_user_ids` loaded the `Account` row
only to reach `account_users`. It now queries `AccountUser` by
`account_id` and plucks the user ids.
- `OnlineStatusTracker.get_availability_from_db` gets the same change.
Its account lookup was served by the query cache until now, and would
have become a real query once the first lookup was gone.
## Why
`RoomChannel#update_presence` calls `get_available_user_ids` on every
ping. On Chatwoot Cloud that was one `Account` query per ping, about
367M a week, averaging 2.9 ms each as measured from the app. The method
was written for auto-assignment, where one extra query per assignment
costs little.
Auto-assignment and inbox agent availability call the same method and
return the same results as before.
<details>
<summary>Benchmark</summary>
Based on local benchmarking of 40,000 pings over 5 threads, the change
cuts Postgres queries from 2 per ping to 1. Throughput rose from about
1,050 pings a second to between 1,460 and 1,600. Median ping time fell
from 4.1 ms to 2.8 ms.
The run used the production traffic mix of 7% agent pings and 93% widget
pings. It ran against a local database and Redis in development mode, so
absolute times in production will differ.
### Script
Save it as `presence_concurrent.rb` and run it with `bundle exec rails
runner presence_concurrent.rb`. `TOTAL` and `THREADS` set the number of
pings and threads. It reads Postgres only, and it writes presence
heartbeats to the local Redis. The `Before` module is a copy of the
method on `develop`, so both versions run in one process.
```ruby
# Runs presence pings from several threads at once, before and after the change.
# Reads Postgres only. Writes presence heartbeats to the local Redis, as a real ping does.
TOTAL = (ENV['TOTAL'] || 40_000).to_i
THREADS = (ENV['THREADS'] || 5).to_i
AGENT_SHARE = 7 # percent of pings that come from agents, as measured in production
# The method as it is on develop
module Before
def self.get_available_users(account_id)
user_ids = get_available_user_ids(account_id)
return {} if user_ids.blank?
user_availabilities = ::Redis::Alfred.hmget(OnlineStatusTracker.status_key(account_id), user_ids)
user_ids.map.with_index { |id, index| [id, (user_availabilities[index] || OnlineStatusTracker.get_availability_from_db(account_id, id))] }.to_h
end
def self.get_available_user_ids(account_id)
account = Account.find(account_id)
range_start = (Time.zone.now - OnlineStatusTracker::PRESENCE_DURATION).to_i
user_ids = ::Redis::Alfred.zrangebyscore(OnlineStatusTracker.presence_key(account_id, 'User'), range_start, '+inf')
user_ids += account.account_users.where(auto_offline: false)&.map(&:user_id)&.map(&:to_s)
user_ids.uniq
end
end
PG_QUERIES = Concurrent::AtomicFixnum.new
ActiveSupport::Notifications.subscribe('sql.active_record') do |*, payload|
PG_QUERIES.increment if !payload[:cached] && payload[:name] != 'SCHEMA' && payload[:name].present?
end
accounts = Account.where(id: Conversation.distinct.pluck(:account_id)).to_a
users = accounts.flat_map { |a| a.account_users.pluck(:user_id).map { |id| [a.id, 'User', id] } }
contacts = accounts.flat_map { |a| a.contacts.limit(3000).pluck(:id).map { |id| [a.id, 'Contact', id] } }
random = Random.new(42)
work = Array.new(TOTAL) { random.rand(100) < AGENT_SHARE ? users.sample(random: random) : contacts.sample(random: random) }
puts "accounts=#{accounts.size} users=#{users.size} contacts=#{contacts.size} threads=#{THREADS} db_pool=#{ActiveRecord::Base.connection_pool.size} env=#{Rails.env}"
# One ping, as RoomChannel#update_presence runs it inside the Rails executor
ping = lambda do |tracker, account_id, type, id|
Rails.application.executor.wrap do
OnlineStatusTracker.update_presence(account_id, type, id)
data = { account_id: account_id, users: tracker.get_available_users(account_id) }
data[:contacts] = OnlineStatusTracker.get_available_contacts(account_id) if type == 'User'
data
end
end
run = lambda do |tracker|
queue = Queue.new
work.each { |item| queue << item }
latencies = Array.new(THREADS) { [] }
PG_QUERIES.value = 0
started = Process.clock_gettime(Process::CLOCK_MONOTONIC)
THREADS.times.map do |index|
Thread.new do
loop do
item = begin
queue.pop(true)
rescue ThreadError
break
end
t0 = Process.clock_gettime(Process::CLOCK_MONOTONIC)
ping.call(tracker, *item)
latencies[index] << (Process.clock_gettime(Process::CLOCK_MONOTONIC) - t0) * 1000
end
end
end.each(&:join)
elapsed = Process.clock_gettime(Process::CLOCK_MONOTONIC) - started
all = latencies.flatten.sort
{ elapsed: elapsed, rate: TOTAL / elapsed, avg: all.sum / all.size, p50: all[all.size / 2], p95: all[(all.size * 0.95).to_i],
p99: all[(all.size * 0.99).to_i], pg: PG_QUERIES.value }
end
work.first(500).each { |item| ping.call(Before, *item) && ping.call(OnlineStatusTracker, *item) }
[['before', Before], ['after', OnlineStatusTracker], ['before', Before], ['after', OnlineStatusTracker]].each do |label, tracker|
r = run.call(tracker)
puts format('%-7s %6.1f s %6.0f pings/s avg %.2f ms p50 %.2f p95 %.2f p99 %.2f postgres queries %d (%.2f per ping)',
label, r[:elapsed], r[:rate], r[:avg], r[:p50], r[:p95], r[:p99], r[:pg], r[:pg] / TOTAL.to_f)
end
```
</details>
# Pull Request Template
## Description
Fixes https://linear.app/chatwoot/issue/CW-8369/super-admin-redesign
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## 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
- [ ] Any dependent changes have been merged and published in downstream
modules
Enriching a company now also sets its logo. Previously enrichment filled
in the profile (industry, size, location, socials) but left the avatar
untouched, so companies kept a low-resolution favicon or no logo at all,
even after "Company profile refreshed." In the company notes feed, notes
without an author now show as **System** with a gear icon instead of
"Someone".
## How to reproduce
1. Open a company that has a domain but no logo (or only a blurry
favicon), on an account with company enrichment enabled.
2. Click **Enrich**. The profile fields refresh, but the logo does not
change.
3. Open the **Notes** tab for a company that has a note created without
an agent (for example via automation or the API). The author shows as
"Someone" with initials.
## What changed
- `Companies::EnrichmentService` attaches the Context.dev logo as the
company avatar, preferring the square `icon` variant and falling back to
the first logo.
- Automatic enrichment on company creation only fills a missing avatar.
The manual **Enrich** action replaces the existing avatar, matching how
it already overwrites other fields.
- Logos in formats avatars do not accept (such as SVG) are skipped and
the existing avatar is kept.
- Authorless notes in the company notes feed render with the name
"System" and a gear icon.
## Notes
- Companies created before favicon fetching existed still have no avatar
until they are enriched or `rake companies:fetch_missing_avatars` is
run.
- For newly created companies, the favicon job can attach before
automatic enrichment finishes, in which case the favicon stays until
someone clicks **Enrich**.
Stripe customer lookups currently return `stripe_unavailable` without
enough information to identify the underlying provider failure. This
adds minimal server-side diagnostics for Stripe API and network errors
while keeping the customer-facing response unchanged.
### What changed
Log the error class and, for Stripe API errors, the error code, HTTP
status, and Stripe request ID. Raw response bodies, exception messages,
credentials, and customer data are excluded.
### Things to know
Authentication and OAuth error handling remain unchanged. No migrations,
configuration changes, or feature-flag changes are required.
### How to reproduce
With Stripe connected, a customer lookup that encounters a Stripe API or
network error returns `stripe_unavailable`, but previously did not log
the provider details.
### How to test
In a test environment, trigger a customer lookup with a simulated Stripe
API failure. Confirm the response remains `422` with
`stripe_unavailable` and the server log contains only the safe error
details. Confirm successful customer lookups still display billing
information normally.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Adds a read-only Stripe integration so support agents can view customer
details, subscriptions, and recent invoices directly in the conversation
sidebar without asking a teammate to look them up in Stripe.
Account administrators connect through OAuth and manage the connection
from Settings → Integrations. Super Admin controls the Stripe app
configuration. Sandbox and live connections are supported; Chatwoot's
own subscription billing is unchanged.
### Things to know
- This is an initial read-only integration. Refunds, payment actions,
and webhook-driven updates are not included.
- Customer lookup uses the conversation contact's email. When multiple
Stripe customers match, the agent selects one. Billing data is scoped to
conversations the agent can access.
- Customer matching uses Stripe Search with an exact case-insensitive
email check. Newly created or edited customers may not appear
immediately because of indexing delays. Stripe Search is unavailable to
businesses in India; this integration currently shares that limitation.
See [Stripe Search
limitations](https://docs.stripe.com/search#limitations).
- Connections reuse integration hooks, with encrypted OAuth credentials
and token refresh. No new database table is required. Active Record
encryption must be configured.
- Configure the matching OAuth installation link and developer secret in
Super Admin → Settings → Stripe. The Stripe app must allow the
installation's `/stripe/callback` URL. Each installation uses one
credential pair; changing environments requires reconnecting accounts.
- Disconnecting removes the local credentials. Uninstall the app in
Stripe to revoke provider-side access.
- The sandbox flow has been exercised locally. Live-mode behavior has
automated coverage, but live credentials, an internal live pilot,
deployment, and Marketplace publishing are deferred.
### How to test
1. Configure a sandbox OAuth link and matching developer key in Super
Admin → Settings → Stripe, with Active Record encryption enabled.
2. As an account administrator, open Settings → Integrations → Stripe
and connect a sandbox. Confirm the connected account, environment, date,
and dashboard link.
3. Create a Stripe customer whose email matches a Chatwoot contact, with
a subscription and invoices. Open that contact's conversation and expand
Stripe to see the customer, subscription status, and recent invoice
amounts, dates, and statuses.
4. Check a contact with no email, no matching customer, and multiple
matching customers. The sidebar should show the appropriate empty state
or customer selector.
Use a mixed-case email in Stripe to verify case-insensitive matching,
and edit the contact email with the sidebar open to verify it reloads
and clears the old customer selection. Allow time for Stripe's search
index to update.
5. Confirm agents cannot manage the connection or retrieve Stripe data
through an inaccessible conversation.
6. Disconnect and confirm the sidebar is no longer available.
Live-account verification is a separate rollout step and has not been
performed.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
Admins can now browse the Captain tools catalog and install toolsets
from it. A new "Tools Catalog" button on the tools page opens a page
listing the toolsets published in
[chatwoot/tools](https://github.com/chatwoot/tools), filterable by
category. Clicking a toolset opens a side panel with its tools, the
configuration it needs, and its README, with an Install button that
opens the install preview from #15997. Toolsets the assistant already
has are marked "Installed", or "Update available" when the catalog has a
newer version. Each toolset shows its author, and toolsets authored by
Chatwoot are listed first.
Toolsets can also be installed from a shareable link,
`/captain/toolsets/install?source=chatwoot/tools/<folder>`. It opens the
dashboard in the user's current account, asks which assistant to install
to when there is more than one, and opens the install preview over that
assistant's tools page.
This is part 4 of a series of PRs that bring toolset manifest import to
Captain, stacked on #15997.
## How to test
1. In Super Admin, enable "Captain Tools Manifest". The Captain Tools
Catalog URL defaults to `https://www.chatwoot.com/captain/tools`;
locally, point it at a deployment that serves the catalog, for example
`https://deploy-preview-322--chatwoot.netlify.app/captain/tools`.
2. On an account with the custom tools plan, open Captain > Tools and
click "Tools Catalog".
3. Switch between category pills and check the cards filter.
4. Click a card, review the tools, configuration and README in the side
panel, then click Install and complete the install.
5. Check you land back on the tools page with the new tools listed, and
that the catalog now marks that toolset as installed.
6. Open `/captain/toolsets/install?source=chatwoot/tools/better-stack`
as an admin. With more than one assistant, pick one, then complete or
cancel the install and check you end up on that assistant's tools page.
7. Turn "Captain Tools Manifest" off and check the Tools Catalog button
is hidden on the tools page.
## Changes
- `CAPTAIN_TOOLS_CATALOG_URL` installation config, exposed to the
dashboard through the global config.
- Tools Catalog page at `/captain/:assistantId/tools/explore` with
category pills and a three column card grid.
- Toolset details side panel with tools, configuration fields, README,
and an Install button for admins.
- Installed and update available badges, backed by a new `GET
captain/tools_manifest/installed` endpoint.
- Shareable install link at `/captain/toolsets/install?source=...`, with
an assistant picker when the account has more than one.
- The "Captain Tools Manifest" setting only hides the Tools Catalog
button; the preview and install APIs still enforce it. The catalog, its
install actions and the install link stay behind the custom tools
paywall.
- Custom tool templates no longer render with `strict_variables`, so `{%
if response.error %}` and `| default:` work on optional fields. Liquid
syntax errors still fail the call.
- Custom tool endpoint URLs may contain Liquid tags (`{% %}`); the
save-time URL check ignores them, and SafeFetch still checks the real
host on every call.
- The catalog is fetched from the browser without credentials, so the
catalog host must allow cross-origin requests.
## Known limitations
- An install link opened while logged out, or in an account with no
assistants yet, does not resume after login or assistant creation.
Opening the link again works.
Messages Chatwoot posts into a Slack thread now show who sent them more
clearly:
- Captain's replies are labelled **(Captain)** and use the Captain logo
instead of the generic bot one.
- Contact, agent, bot and system messages get new, sharper avatars in
one consistent style.
- Agents who are also super admins are now labelled **(Agent)**; they
were shown as **(Bot)**.
This is split out of #16129. The borders for private notes and activity
messages are in #16142; the two can merge in either order.
## How to test
1. Connect the Slack integration and start a conversation so a thread is
created in the channel.
2. Let Captain reply in the conversation: in Slack the message shows as
`<assistant name> (Captain)` with the Captain logo. A reply from another
agent bot shows as `(Bot)` with the bot avatar.
3. From the dashboard, reply as an agent without a profile picture, and
send a message as a contact: each shows its new default avatar in the
thread. An agent with a profile picture still shows their own.
4. Reply from the dashboard as an agent who is also a super admin: the
message is labelled `(Agent)`.
5. Resolve or reassign the conversation: the activity message appears in
the thread under **System** with the new system avatar.
Slack caches avatars per message, so only messages posted after this
change show the new ones.
## What changed
- `SendOnSlackService` maps each sender label to an avatar file
explicitly. The avatars live under new file names in
`public/integrations/slack/` so Slack fetches them fresh; `user.png`
stays (redrawn) because the Dyte integration uses it as its default
avatar.
- Agents without a profile picture now get the agent avatar. They were
pointed at `agent.png`, which does not exist.
Moves Slack request signature verification out of the events webhook
controller into `Integrations::Slack::SignatureVerifier`, so other Slack
endpoints can reuse it. There is no change in behaviour for the events
webhook.
This is split out of #16129, which adds a second Slack endpoint
(interactive button clicks) that needs the same check.
## What changed
- New `Integrations::Slack::SignatureVerifier` with the signing secret
lookup and the signature check, moved as they were from
`Api::V1::Integrations::WebhooksController`.
- The events webhook controller calls the verifier. It still skips
verification with a warning when no signing secret is configured, and
still returns `401` for a missing, stale or invalid signature.
- `SignatureVerifier.valid?` returns `false` when no signing secret is
configured. The events webhook never reaches that case because it checks
for the secret first; it is there so a caller that requires a secret can
use `valid?` alone.
Conversation monitors now allow **10,000,000 calls per UTC month** and
**500,000 calls per UTC day**, per account. Allowances count attempted
provider requests, including preview calls, and no longer depend on
estimated token lengths. Pending evaluations retain their quota holds
when new messages arrive and resume after the applicable reset without
retrying ahead of a provider cooldown.
## What changed
- Enforce both call limits using persisted daily usage under the account
lock, so concurrent workers cannot exceed the remaining allowance. Each
attempted provider batch consumes one call, even when it evaluates
multiple monitors or returns a provider error.
- Remove the daily token reservation and reconciliation, which mixed
JSON request bytes with provider input tokens. Keep request-size limits
and provider token/cost telemetry.
- Preserve daily and monthly quota holds across new conversation input.
Spread retries over up to four hours after the later of the quota reset
and the longest provider cooldown recorded across failed batches.
- Report when the current monthly allowance was reached, ignoring
timestamps from the previous 100,000-call allowance.
- Document the RubyLLM bundle-audit exceptions for the pinned Ruby 3.4.4
runtime, with reassessment required when the runtime or supported
dependency versions change.
## Quota logging
When a committed call reaches the daily or monthly account cap, emit one
structured `conversation_monitor_limit_reached` log event for that
period. It includes `account_id`, `period` (`daily` or `monthly`),
`used`, `limit`, and the UTC reset timestamp `resets_at`. Rolled-back
calls and subsequent blocked retries do not emit events. Reaching both
caps in the same call emits one event for each period.
The event uses the existing Rails log forwarding path. In New Relic,
group events by account and period with:
```sql
FROM Log
WITH aparse(message, '%"account_id":*,%') AS account_id,
aparse(message, '%"period":"*"%') AS period
SELECT count(*)
WHERE message LIKE '%conversation_monitor_limit_reached%'
FACET account_id, period
SINCE 7 days ago
LIMIT MAX
```
## Closes
Fixes https://linear.app/chatwoot/issue/INF-117
## How to reproduce
1. Exhaust an account's daily allowance, then receive additional
conversation messages before the next UTC midnight. Previously, each
message could pull the held work into an early retry and accumulate
another job at the reset. The work now retains its saved retry time
while recording the new input.
2. Have an earlier provider batch return a long `Retry-After`, then
exhaust the daily or monthly allowance before the next batch. The saved
retry now honors both the allowance reset and the longer provider
cooldown before adding jitter.
## Rollout
Existing quota holds retain their saved retry times; the increased
allowances apply when work next reserves a call. Already-scheduled jobs
from before deployment will still run once.
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
Merchants installing Chatwoot from Shopify can create an account or sign
in to an eligible existing workspace, then continue to Shopify billing
setup. The installation destination follows them through email
confirmation, invitation acceptance, password reset, Google sign-in,
SAML, and MFA.
This is the final Shopify onboarding PR. Dashboard connections and the
installation foundation have already merged in #16084 and #16085; this
PR targets `develop` and completes the App Store signup and
authentication flows.
### Closes
- Fixes
https://linear.app/chatwoot/issue/CW-6500/support-shopify-app-store-install-flow-for-merchant-initiated
- Fixes
https://linear.app/chatwoot/issue/PLA-170/resolve-shopify-app-store-billing-rejection
### Things to know
- Shopify remains behind its feature flag. Shared signup, login,
confirmation, password-reset, and account-routing code changes in this
PR still require regression coverage with Shopify disabled.
- App Store onboarding uses Shopify billing. Existing Stripe customers
continue connecting through the dashboard flow.
- Google signup rejection preserves the target workspace. Invalid or
claimed installation tokens return a recoverable error, and invitation
password-setup links preserve the installation continuation.
- Account membership creates notification settings within its
transaction and reuses existing settings when an agent is re-added.
Unrelated agent-cleanup, IMAP entitlement, and shared-plan lookup
changes are excluded.
- No Shopify lookup-index migration is included; those indexes are
deferred.
- Shop-scoped locking and database uniqueness enforcement are deferred.
Concurrent signups using separate pending tokens for the same shop can
create duplicate connections and block later App Store launches.
Database transactions and model validation do not prevent this race. The
installation/uninstall race is also deferred. Both are accepted risks,
not fixed issues:
https://github.com/chatwoot/chatwoot/pull/13550#discussion_r4154926009
and
https://github.com/chatwoot/chatwoot/pull/13550#discussion_r4152556108.
- Configure the Shopify app URLs for the target environment. Webhook
testing requires a reachable callback host.
### How to test
1. With Shopify enabled, install from a development store, create an
account, confirm the email, and complete billing setup with a test plan.
Verify the store is connected to the new workspace.
2. Repeat while signed out of an eligible existing workspace. Verify
workspace selection and the installation destination survive
email/password login, Google, SAML, and MFA.
3. Start with an unconfirmed invited administrator, resend confirmation,
accept the invitation, and set a password. Verify onboarding resumes in
the intended workspace.
4. Exercise password reset and confirmation resends from a Shopify
continuation. Verify the installation token or billing destination and
workspace are preserved.
5. Reject a personal Google signup and retry with the correct identity.
Verify the target workspace is retained. Retry with an expired or
claimed installation token and verify a recoverable error appears
instead of a server error.
6. With Shopify disabled, verify ordinary signup, confirmation,
invitation acceptance, login/logout, password reset/change, Google,
SAML, and MFA. Check existing Stripe billing and account access.
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
## Description
Conversation create now validates `assignee_id` and `team_id` before
creating the conversation, and returns `422` for values that don't
resolve, in line with how bulk actions handle them. Requests without
these fields behave as before.
Fixes https://linear.app/chatwoot/issue/CW-8347
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added request specs for invalid assignee and team values (422, no
conversation created). Existing conversations controller specs pass.
## 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
Bulk conversation assignments now accept only users and teams belonging
to the current account. Invalid assignment targets return `422` before
the bulk job is queued, so the request does not partially change
conversation status, labels, or assignments.
Existing assignment removal remains supported: `assignee_id: null`,
`team_id: null`, and the dashboard's `team_id: 0` value. Valid
assignments and other bulk actions keep their current behavior.
### How to test
1. As an agent with access to an inbox, select multiple conversations
and assign an agent and team from the current account. Confirm the
assignments update.
2. Remove the agent and team assignments. Confirm both are cleared.
3. Submit a bulk request with an assignment target outside the current
account or a nonexistent target. Expect `422` and no conversation
changes, including when the request also changes status.
4. Bulk-update conversation status without assignment fields. Confirm it
still works.
The pushed commit was checked against a running local Rails server and
Sidekiq worker with synthetic accounts. All 12 HTTP checks passed,
including rejected requests leaving conversations unchanged.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
This draft improves Shopify connections started by administrators from
dashboard settings. It adds expiring OAuth state, feature-gate checks,
store-domain validation, and protection against reconnecting an
installation during uninstall cleanup.
Existing signup, login, password reset, and billing behavior remain
unchanged.
Related: https://github.com/chatwoot/chatwoot/pull/13550
### Things to know
- First PR in the Shopify split; merge this before the installation
foundation and signup/authentication changes.
- Shopify remains behind its feature flag.
- Includes dashboard integration and cleanup specs. No database
migrations.
- Browser verification and frontend tests remain outstanding; this draft
is not a merge-readiness confirmation.
### How to test
1. Enable Shopify for a test account and connect a development store
from Settings → Integrations → Shopify.
2. Verify customer orders appear in conversations.
3. Disconnect and reconnect the store.
4. Disable Shopify and verify connection attempts are blocked.
5. Confirm an existing Stripe account retains its billing configuration.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Administrators can use an active conversation monitor as an automation
event. They can create a rule from the automation screen or from the
monitor list and report, then see linked rules on the monitor report. A
rule fires when a live public message first makes the conversation
match, whether that message is incoming or outgoing. Replies generated
by another automation remain visible in monitor reporting but cannot
trigger a linked rule; historical scans do not run actions. Pausing or
deleting a monitor disables its linked rules, and resuming the monitor
leaves them disabled until an administrator re-enables them.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## Closes
-
[CW-8304](https://linear.app/chatwoot/issue/CW-8304/trigger-automations-from-conversation-monitor-matches)
## How to test
1. Use an account with Reports, Conversation Monitors, and Automations
enabled and a configured monitor provider.
2. Create a monitor, then create an automation with **Monitor matched**
as its event and select that monitor. Confirm only active monitors are
offered.
3. From the monitor list or report, create another automation and
confirm the selected monitor is prefilled. After saving, confirm the
monitor report shows the linked rule.
4. Send a new public incoming or outgoing message that first makes the
monitor match. Confirm the rule's action runs. Send an
automation-generated reply that alone matches the monitor, including
immediately after a customer message, and confirm it records the match
without running the linked rule. Confirm historical scans do not run
actions and the same recorded match is not replayed.
5. Pause the monitor and confirm its linked rules become disabled.
Resume it and confirm the rules stay disabled until explicitly
re-enabled. Deleting a monitor should also disable its linked rules.
## What changed
- Added monitor event validation, account scoping, live activity
attribution, durable delivery records, and action dispatch in
Enterprise.
- Kept automation-generated replies in monitor reporting while excluding
them from the action-eligible message context.
- Preserved live eligibility when a new message is updated before
commit, and isolated delivery inserts so deleting a linked rule cannot
discard the monitor match.
- Added the monitor event picker, rule status and search, monitor
shortcuts, and linked rule list in the dashboard.
- Added coverage for API validation, delivery behavior, lifecycle
changes, and frontend selection and navigation.
## 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 feature works
- [x] New and existing focused unit tests pass locally with my changes
## CI follow-up
- Extended the automation composable spec to cover the monitor event.
---------
Co-authored-by: Aakash Bakhle <48802744+aakashb95@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Webhook payloads and dashboard live updates for a contact now carry its
type: `visitor`, `lead` or `customer`. Since #16077 a visitor's first
conversation sends a `contact_updated` event whose `changed_attributes`
names `contact_type`, but the payload itself did not carry the field.
Now it does, so a consumer can read the new type from the event instead
of fetching the contact again.
## Closes
Part of
[CW-8316](https://linear.app/chatwoot/issue/CW-8316/contacts-contact-type-stale-contact-cleanup-and-opensearch-migration).
Follows up on the review of #16077.
## How to test
- Add an account webhook subscribed to `contact_created` and
`contact_updated`.
- Open the widget on a site as a new visitor and send a message. The
`contact_updated` delivery carries `"contact_type": "lead"`, and its
`changed_attributes` shows the change from `visitor`.
- Create a contact from the dashboard. The `contact_created` delivery
carries `"contact_type": "lead"`.
- Keep the contacts page open in the dashboard while a contact changes.
The live update for that contact carries `contact_type` too.
## What changed
- `Contact#webhook_data` and `Contact#push_event_data` gain
`contact_type`. Both are additive: no existing field changes.
- The REST contact payload is unchanged.
Contacts now get the right type as they are created and updated. A
contact becomes a lead when it has an email, a phone number or an
identifier, when it has a conversation (clicking a campaign message
counts, since that opens one), or when it was created on purpose through
the contacts API, the dashboard or an import. Everyone else stays a
visitor, and a lead never goes back to being a visitor.
This is the first phase of making `contact_type` the source of truth for
contacts. Nothing reads the type differently yet, so the contact list,
search, filters and exports behave as before on accounts without
`crm_v2`. Existing contacts are not touched; the backfill is the next
PR.
## Closes
Part of
[CW-8316](https://linear.app/chatwoot/issue/CW-8316/contacts-contact-type-stale-contact-cleanup-and-opensearch-migration).
This is phase 1 of 5, so the issue stays open.
## How to test
There is no UI for the type yet. Read it from the console with
`Contact.find(id).contact_type`.
- Open a site with the widget and do nothing: the contact is a visitor.
- Send a first message from the widget: the contact becomes a lead.
- Click a campaign message in the widget without typing anything: the
contact becomes a lead.
- Call `setUser` with only an identifier: lead.
- Create a contact with only a name, from the dashboard or with `POST
/api/v1/accounts/:id/contacts`: lead.
- Import a CSV whose rows have only a name: every row is a lead.
- Create a contact on an API inbox with only a name: visitor, until its
first conversation.
- Start a conversation from the dashboard with a contact that has no
email, phone or identifier: lead.
- Merge a lead into a visitor: the surviving contact is a lead.
- Remove the email, phone and identifier from a lead: it stays a lead.
## What changed
- `Contacts::SyncAttributes` also promotes a visitor when it has an
`identifier`.
- `Conversation` gets an `after_create` that marks a visitor contact as
a lead. It runs inside the insert's transaction instead of after commit.
The app runs `load_defaults 7.0`, so commit callbacks run in reverse
declaration order, and one that raises skips the remaining commit
callbacks of every record in the transaction, which would drop
`conversation_created` and the first message's callbacks.
- `Api::V1::Accounts::ContactsController#create` builds the contact as a
lead.
- `DataImport::ContactManager` builds new CSV rows as leads.
`Contact.import` does not run save callbacks, so until now every new CSV
contact was stored as a visitor, even with an email.
- `DataImports::Importer` (Freshdesk, Intercom) always imports contacts
as leads and promotes a matched visitor.
- `ContactMergeAction` keeps the higher of the two types.
- No write reads the `crm_v2` flag, and the `contacts` table is
unchanged.
## Things to know
- A contact's first conversation sends one extra `contact_updated` event
to webhooks, the dashboard and the LeadSquared hook. Its
`changed_attributes` names `contact_type`, which the payload itself does
not carry.
- The contact row is updated inside the conversation's transaction, so
it stays locked until that transaction commits. On Facebook that
includes the attachment download.
- Conversations created by the Freshdesk and Intercom importers are
inserted in bulk and do not run the new callback. The importer marks its
contacts as leads directly.
- Accounts with `crm_v2` on already read `contact_type = lead` for the
contact list, so they will see the newly promoted contacts.
- Captain prompts print the contact type. Anyone in a conversation now
reads as a lead there.
Fixes#16019
`MailPresenter#from` previously chose a present `reply_to` array before
checking its entries, then called `downcase` on every entry. `[nil]` is
present in Rails, so a malformed Reply-To address list raises
`NoMethodError`. The IMAP fetch job counts the exception and skips the
message for six hours after three failures.
This removes nil/blank entries before downcasing. A Reply-To with no
usable addresses falls back to From. If neither list has an address, the
presenter returns `[]`, leaving the existing IMAP sender-validity check
to ignore the mail. No changes to the fetch cache or unrelated sender
parsing.
Regression specs cover mixed and empty address lists in the presenter,
plus a synthetic raw-email fixture whose `Reply-To: <"">` parses as
`[nil]`. The IMAP mailbox regression uses that fixture without stubbing
`reply_to` and creates a conversation and message from the valid From
address.
### Related issues
- Linear:
[CW-8301](https://linear.app/chatwoot/issue/CW-8301/imap-mailpresenterfrom-calls-downcase-on-nil-and-the-message-is)
- Sentry:
[CHATWOOT-FAZ](https://chatwoot-p3.sentry.io/issues/7696163347/)
- Sentry:
[CHATWOOT-FEY](https://chatwoot-p3.sentry.io/issues/7708063382/)
---------
Co-authored-by: Sojan Jose <sojan@pepalo.com>
## Description
Adds logs for super admin impersonation.
Fixes https://linear.app/chatwoot/issue/CW-8337
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
Existing impersonation and session specs pass with the change.
## 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
## Description
Conversation monitors are now included with Business and Enterprise
Cloud plans. Captain Classifier remains available on every paid plan,
including Startups. Shopify-billed accounts receive Captain Classifier
on entitled plans; monitor access follows each plan's configured
`conversation_monitors` feature. Existing monitor definitions remain in
place after a downgrade, while the monitor API and workers respect the
updated account flag.
Closes
[CW-8331](https://linear.app/chatwoot/issue/CW-8331/limit-conversation-monitors-to-business-plans-and-above).
Follow-up to
[CW-8305](https://linear.app/chatwoot/issue/CW-8305/enable-conversation-monitors-and-captain-classifier-for-all-paid-plans).
Rollout dependency: update `CHATWOOT_SHOPIFY_PLANS` so only
Business-equivalent Shopify tiers and above include
`conversation_monitors`. After deployment, run the reviewed
Rails-console backfill manually to refresh existing billed accounts. The
script previews changes and preserves explicit
`manually_managed_features` grants. Audit any older direct Super Admin
grants before running it; those grants are not distinguishable from
former plan grants in the feature bit alone.
## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] 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 Stripe plan matrix, Shopify catalog-based grants,
downgrades, and manual overrides with focused RSpec coverage (84
examples passed).
- Verified that a Startups account loses monitor API access after
reconciliation.
- RuboCop passed for all changed Ruby files; `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
- [ ] 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
Fixes a bug with outbound Twilio calls. If an agent hung up before the
callee answered, the callee's phone kept ringing. If they then picked
up, they heard hold music with nobody on the line. Now hanging up in the
dashboard also hangs up the callee's Twilio call leg. A leg that still
gets answered after the call has ended is sent `<Hangup/>` instead of an
empty conference.
In production, 38 of 289 agent-ended outbound Twilio calls (13.1%) kept
the callee's leg alive after teardown. 22 of them were answered into
hold music, 12 rang on to `no-answer`, and 4 ended `busy`. That comes to
about 49 minutes a month of billed Twilio audio with nobody on our side.
## Closes
-
## How to reproduce
1. Place an outbound call from a Twilio voice inbox to a phone you have
with you.
2. While it is still ringing, hang up in the dashboard.
3. Before this fix, the phone keeps ringing, and answering it plays hold
music. After this fix, it stops ringing right away.
## What changed
- `ConferenceService#terminate_call` hangs up `provider_call_id`, and
also `parent_call_sid` when it is set and different, with
`Status=completed`. It uses `call.inbox.channel.client`, so api-key mode
works. `ConferenceController#destroy` calls it before `end_conference`,
and both run before the call is finalized, so a failure still leaves the
call repairable. `end_conference` stays as it was, because it handles
the agent's leg and any other participants already in a live conference.
- Why `completed` in every state: Twilio documents that "Specifying
`canceled` will attempt to hang up calls that are queued or ringing;
however, it will not affect calls already in progress. Specifying
`completed` will attempt to hang up a call even if it's already in
progress." Sending `canceled` would silently do nothing if the callee
answers while the request is in flight, and that is exactly this bug.
- For a leg that has already ended (the normal case, 251 of 289 calls),
Twilio returns HTTP 200 and leaves the status unchanged. We tested this
against a real account for both status values, on both `completed` and
`no-answer` legs. So no rescue is needed.
- In `Twilio::VoiceController#call_twiml`, if the resolved call is
already terminal, it now renders `<Hangup/>` instead of the conference
TwiML. This covers the race where the callee answers while the hang-up
request is in flight. The `reject_inbound?` path is unchanged.
- This also fixes the August bug where an inbound caller was stuck in
hold music. When the conference was still in `init`, `end_conference`'s
`status: 'in-progress'` query found nothing. `terminate_call` acts on
the Call resource instead, so the conference state no longer matters.
## Out of scope (follow-ups)
- `useCallSession.js#endCall` has no in-flight lock (unlike `joinCall`'s
`globalIsJoining`), so 18% of call_sids get duplicate `destroy` calls.
Those are harmless now, because a hang-up on an ended leg returns 200.
- Outbound calls are marked `in_progress` when the agent joins the
conference, not when the callee answers. So calls nobody answered still
get a "completed" bubble.
- `Voice::Provider::Twilio::Adapter#twilio_client` pairs `account_sid`
with `auth_token`, which is broken in api-key mode.
## Description
Impersonation tokens were minted every time a super admin opened a user
page, since the link was rendered into the page. They are now minted
only when a super admin clicks.
- Impersonate user opens the customer dashboard in a new tab, as before.
- Copy link copies a single-use link (valid for 5 minutes) to the
clipboard, for opening in another browser or an incognito window.
Both are authenticated, CSRF-protected POSTs, and the token is bound to
the super admin who clicked.
<img width="1138" height="857" alt="image"
src="https://github.com/user-attachments/assets/86f54dd5-9efa-4c05-a005-257c8ef32a5a"
/>
Depends on #15976.
Fixes https://linear.app/chatwoot/issue/CW-8276
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Request specs cover: no token minted on page render, a token bound to
the signed-in super admin on both actions, authentication required, and
CSRF rejection.
## 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
## Description
Impersonation links now record which super admin generated them, and the
session they create carries that super admin on its token, so a live
impersonation session can be attributed to a staff member. A durable
staff-side record of impersonation will follow in a separate PR.
This also fixes impersonation showing up in the customer's audit log.
Impersonation sign in and ending it (sign out) wrote regular sign_in and
sign_out entries to the account's audit log, so account admins saw
logins they did not make, from an unfamiliar location. Both are now
skipped for impersonation sessions, the same way session tracking
already skipped them.
Fixes https://linear.app/chatwoot/issue/CW-8272
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
Specs cover the super admin binding on the token and session, and the
skipped sign in and sign out audit events.
## 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
Agents can request a phone number again from eligible WhatsApp Cloud
conversations identified by a BSUID. The action now checks availability
when an agent opens a conversation whose contact has no phone number,
and refreshes as the contact or request state changes.
Eligibility is fetched separately from conversation rendering, keeping
pending-request history queries out of conversation lists. Existing
checks still prevent duplicate pending requests and require an approved
Request Contact Info template outside the messaging window.
Related:
https://linear.app/chatwoot/project/whatsapp-bsuid-4df5614db3f9/issues
### Background: previous approach
[PR #15826](https://github.com/chatwoot/chatwoot/pull/15826) temporarily
hid the dedicated Request Contact Info action to remove pending-request
message-history lookups from routine conversation rendering, including
inbox lists, filtered lists, contact conversation lists, and individual
conversation responses. These eligibility checks added database work to
ordinary browsing. Checking only the messages loaded in the UI would
also miss pending requests in older history, potentially showing an
action that the backend would then reject.
This PR restores the action through a separate availability request for
the selected WhatsApp Cloud conversation when the contact has no phone
number. The endpoint retains the full pending-request check across
conversations sharing the contact-inbox identity, while keeping history
lookups out of conversation rendering as in #15826. History lookups
still occur for the selected conversation's eligibility check; they are
no longer part of routine list rendering.
### Things to know
- No database migrations or feature flags are required. The unused
static `contact_info_request` field is removed from conversation
responses; the dashboard reads availability from the dedicated endpoint.
External clients consuming that field must use the endpoint instead.
- Availability requests are cancelled when switching conversations, and
a pending request remains disabled even when its message is outside the
loaded message history.
- The interactive request and customer phone-sharing response were
manually verified end to end. The template flow outside the messaging
window has not been tested live.
- Existing targeted validation passed: 29 Ruby service examples, 155
frontend tests, Ruby and JavaScript linting, and focused endpoint,
authorization, and concurrent-request checks.
### How to reproduce
Open a WhatsApp Cloud conversation with a BSUID contact, no phone
number, and an active messaging window. Before this fix, the Request
Contact Info action is hidden because the conversation payload reports
the capability as unavailable.
### How to test
1. Open an eligible WhatsApp Cloud conversation whose contact has no
phone number. Confirm Request Contact Info appears in the composer.
2. Send the request. Confirm the action is disabled while a request is
pending, including after reopening the conversation.
3. Share the phone number from WhatsApp. Confirm the contact is updated
and the action disappears.
4. Switch between conversations while availability is loading. Confirm
the action reflects the selected conversation.
5. Open a conversation outside the messaging window. With an approved
Request Contact Info template, confirm the action opens the template
picker; without one, confirm the action is hidden.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Adds the API and install dialog for installing Captain toolsets from the
[chatwoot/tools](https://github.com/chatwoot/tools) repository. The
dialog takes `chatwoot/tools/<folder>`, previews the toolset and its
tools, asks for the inputs and secrets it declares, and installs the
latest commit from the default branch. If an older version is installed,
it offers to update it. Installed tools show where they came from and
are read-only, apart from enabling or disabling them. The dialog has no
entry point on its own; the Tools Catalog in the next PR opens it.
Installs require the `custom_tools` plan and a new Super Admin switch,
"Captain Tools Manifest", which is off by default.
This is part 3 of a series of PRs that bring toolset manifest import to
Captain, following #15996 (merged).
## Changes
- Preview and install API for toolsets in chatwoot/tools, for
administrators.
- Short, translated error messages for bad sources and configuration
issues.
- Install dialog, opened by the Tools Catalog in the next PR.
- Installed tools show their source, open read-only, and can only be
enabled or disabled.
- Tool titles open the side panel: editable for admins' own tools,
read-only otherwise.
Adds the backend for installing Captain toolsets from the
[chatwoot/tools](https://github.com/chatwoot/tools) repository. A
toolset is addressed as `chatwoot/tools/<folder>` and pinned to a
commit, either one passed in or the latest on the default branch.
Installing the same commit again is a no-op, and a new commit updates
the existing tools in place while keeping their slugs and the admin's
enabled or disabled choice. Nothing calls these services yet; the API
and UI come in the next PRs.
This is part 2 of a series of PRs that bring toolset manifest import to
Captain, following #15995 (merged).
## Changes
- Custom tools record their source (repository, folder, tool id, commit,
version).
- Install service that fetches a toolset from chatwoot/tools and
installs it onto an assistant.
- Toolsets are validated before they are merged into chatwoot/tools, so
Chatwoot only parses the manifest and fills in defaults. Every installed
tool still goes through the custom tool model's validations (headers,
endpoint safety, auth config), and the admin's install values are
checked for type and required fields.
- Optional internal GitHub token for commit lookups, with fallback when
it's rejected.
Captain custom tools can now send static HTTP headers with every
request, for APIs that expect something like `cal-api-version` or a
tenant ID. Header rules match the tools catalog manifest schema, so
manifests the catalog accepts will import cleanly. Tools can also use
PUT, PATCH and DELETE, which the manifest allows. The tool form moves to
a side panel, with collapsible sections for headers, parameters and
templates.
This is part 1 of a series of PRs that bring toolset manifest import to
Captain.
## Changes
- Static headers on custom tools, following the catalog manifest rules.
- PUT, PATCH and DELETE support for custom tools.
- Test button now applies the same validation as saving a tool.
- Redesigned tool form in a side panel.
## Description
`20260922090000_add_contact_inbox_to_campaign_recipients` added the
`contact_inbox_id` column together with a database foreign key to
`contact_inboxes`, in a single transaction. The column add takes an
`ACCESS EXCLUSIVE` lock on `campaign_recipients`, and the foreign key
then needs a lock on `contact_inboxes`. Any in-flight transaction that
has written to `contact_inboxes` and then reads `campaign_recipients`
ends up waiting on the migration while the migration waits on it, so
Postgres aborts the migration with `PG::TRDeadlockDetected`. On a busy
install this happens on every attempt.
We manage associations in Rails rather than with database foreign keys
(see
https://github.com/chatwoot/chatwoot/pull/8602#discussion_r1461694017),
so this drops the foreign key:
- `20260922090000` now only adds the column and index. It touches a
single table, so it cannot deadlock.
- `CampaignRecipient` already declares `belongs_to :contact_inbox,
optional: true`, so no model change is needed.
- `AGENTS.md` documents the foreign key convention.
Follow-up to https://github.com/chatwoot/chatwoot/pull/15854
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Fresh database: rolled the migration back and ran it again. The column
and index exist and there is no foreign key to `contact_inboxes`.
- Reproduced the original deadlock in plain SQL with a concurrent
transaction that writes `contact_inboxes` and then reads
`campaign_recipients`; the column-only migration does not lock
`contact_inboxes` at all.
## 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
- [ ] 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>
Captain label and priority suggestions and conversation monitors call
Jev outside RubyLLM. Those requests were missing from Langfuse.
<img width="1732" height="1526" alt="CleanShot 2026-09-28 at 12 07
01@2x"
src="https://github.com/user-attachments/assets/ce8735af-c360-4373-91d4-4e01822e65c0"
/>
## What changed
- Route both features through one System One HTTP client.
- Record a Langfuse generation with the complete request and response,
served model, reported token usage, cost, account, and conversation
session.
- Keep monitor credit accounting, response validation, scoring, and
error mapping in its decision service.
- Mark Jev's remote call as an OpenTelemetry client span and record its
operation, returned model, conversation ID, and low-cardinality failure
type.
## Langfuse v4 and OpenTelemetry review
The existing exporter already uses OTLP/HTTP at
`/api/public/otel/v1/traces`, Basic Auth, and
`x-langfuse-ingestion-version: 4`. Each Jev call exports one completed
generation span with its full request and response on the observation.
The v4 migration does not require a new Langfuse API or SDK here. The
new Jev fields follow the current OpenTelemetry GenAI client-span
guidance while keeping the stable feature-specific span name.
Jev's reported token counts are copied from its response. The full HTTP
request body is captured, but Jev does not expose any internal
representation it may build from that body. Higher token counts do not
establish a specific hidden prompt or overhead.
## Verification
- 103 focused RSpec examples passed for the shared Jev implementation;
the four Jev client examples pass after the OpenTelemetry follow-up.
RuboCop passes on the changed Ruby files.
- Synthetic classifier and monitor calls succeeded locally. Langfuse
returned one `GENERATION` observation for each call, with the request,
response, model, usage, and cost.
References: [Langfuse v4 custom
ingestion](https://langfuse.com/integrations/native/opentelemetry/migration-to-v4),
[Langfuse OTEL
mapping](https://langfuse.com/integrations/native/opentelemetry),
[OpenTelemetry GenAI client
spans](https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md).
Updates `rack-proxy` to a patched release so the `bundle-audit` step in
CI passes again. The refreshed advisory database flags the version in
our lockfile, which currently fails the `security-scan` job on every
open PR. `rack-proxy` is only used by the Vite dev server proxy, which
is mounted in development and local test runs, so the app's request
handling in production is not affected.
Fixes: GHSA-42qh-8mx8-7wqm
## How to reproduce
On `develop`, run:
```
bundle exec bundle-audit update
bundle exec bundle-audit check
```
It reports `rack-proxy 0.7.7` with the solution `upgrade to '>= 1.0.3'`
and exits with a non-zero status.
## What changed
- Updates `rack-proxy` from 0.7.7 to 1.0.3, the patched version named in
the advisory.
- Updates `vite_ruby` from 3.10.2 to 3.10.6. `rack-proxy` is a
transitive dependency of `vite_ruby`, and 3.10.2 pins it to `~> 0.6`.
Support for `rack-proxy` 1.0 landed in 3.10.5.
- Keeps `vite_ruby` on the 3.10 line on purpose. 3.11.0 detects the dev
server by reading a `tmp/vite-ruby.json` file written by a newer
`vite-plugin-ruby` than the 5.2.1 we use, so it needs to be taken
together with a JS dependency update.
- Only `Gemfile.lock` changes. No other gems are updated.
Show sent WhatsApp campaigns in the conversation timeline so agents can
see what the contact received. Send large campaigns in smaller batches,
and make campaign analytics available on Business and Enterprise Cloud
plans.
### What changed
- Display campaign content, title, timestamp, and delivery status in
neutral message bubbles.
- Scope history to the contact, WhatsApp inbox, and conversation time
window so saved campaign sends appear in the conversation active when
they were sent, even when contact-inbox identities differ.
- Process campaign audiences in batches of 100.
- Keep live chat, SMS, and WhatsApp campaigns available on all paid
Cloud plans through the shared campaigns feature flag.
- Show an analytics upgrade prompt on Startups; Hacker accounts do not
have campaign access.
- Warn that deleting a campaign also removes its saved history and
delivery details.
### Things to know
- History starts at the selected conversation’s creation time and ends
before the next conversation for the same contact and inbox. Campaigns
sent before the conversation started are excluded.
- The change does not backfill historical sends that have no saved
campaign-recipient record.
- Replies are not explicitly attributed to campaigns.
- Analytics reflect progress so far while a campaign is sending.
- Durable resume and duplicate-send prevention remain follow-up work.
Retried batches can resend messages on Community Edition; concurrent
jobs or interruption between provider acceptance and saving delivery
status can also cause duplicates.
### How to test
1. Open a WhatsApp conversation, then send a campaign to that contact.
Reopen the conversation and confirm the campaign appears with its
content, title, timestamp, and delivery status.
2. Repeat with a contact that has multiple WhatsApp identities in the
same inbox. Confirm the campaign appears in the contact-and-inbox
conversation active when it was sent.
3. Open two conversations for the same contact and inbox. Confirm each
shows campaigns from its start time until the next conversation begins,
and that earlier campaigns are excluded.
4. Load earlier campaign history and switch conversations; check
ordering and scroll position.
5. Send a campaign to more than 100 contacts and confirm processing
continues through subsequent batches.
6. Confirm Business and Enterprise accounts can access analytics. On
Startups, confirm campaigns remain available and analytics shows an
upgrade prompt. On Hacker, confirm campaign pages are unavailable.
7. Check the campaign deletion warning.
Related:
https://linear.app/chatwoot/issue/CW-7891/batch-and-resume-large-campaign-sends
Related:
https://linear.app/chatwoot/issue/CW-7825/persist-whatsapp-campaign-messages-and-attribute-replies-to-campaigns
---------
Co-authored-by: iamsivin <iamsivin@gmail.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
# Pull Request Template
## Description
The GHSA to Linear sync posts a notification per new advisory to a
Discord webhook. This adds an equivalent Slack notification.
https://linear.app/chatwoot/issue/INF-111
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## 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
- [ ] 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
Conversation Monitors and Captain Classifier will be available to every
paid Chatwoot Cloud account, including Stripe Startups, Business, and
Enterprise customers and paid Shopify App Pricing customers. Existing
accounts need the manual backfill below; future plan changes use billing
reconciliation.
## Closes
-
[CW-8305](https://linear.app/chatwoot/issue/CW-8305/enable-conversation-monitors-and-captain-classifier-for-all-paid-plans)
— paid-plan entitlement rollout, child of
[CW-8270](https://linear.app/chatwoot/issue/CW-8270/conversation-monitors-to-reports-with-jev)
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## What changed
- Grant `conversation_monitors` and `captain_classifier` from the Stripe
Startups tier upward; Business and Enterprise inherit both. Downgrades
to Hacker revoke plan-managed grants unless the account has a manual
grant.
- Grant both flags to paid Shopify App Pricing accounts during billing
reconciliation, alongside their catalog features. Shopify subscription
loss removes the plan-managed flags; the catalog continues to manage
other Shopify entitlements.
- Keep both flags available for manual grants in Super Admin.
- Restrict the minute-by-minute monitor dispatcher to accounts with
active monitors so broader eligibility does not scan every paid account.
## Manual rollout
Run this one-off script in the **Chatwoot Cloud Rails console before
deploying this PR**. It records existing pilot grants as manual
overrides before the new reconciliation rules can remove them, then
enables both flags for existing paid accounts. It is safe to rerun.
```ruby
raise 'Chatwoot Cloud only' unless ChatwootApp.chatwoot_cloud?
features = %w[conversation_monitors captain_classifier]
plans = %w[Startups Business Enterprise]
features.each do |feature|
Account.public_send("feature_#{feature}").find_each(batch_size: 100) do |account|
next if account.billing_provider == 'shopify' && Array(account.internal_attributes['shopify_managed_features']).include?(feature)
manual = Array(account.internal_attributes['manually_managed_features'])
next if manual.include?(feature)
account.internal_attributes = account.internal_attributes.merge('manually_managed_features' => manual | [feature])
account.save!(validate: false)
end
end
stripe = Account.where("custom_attributes->>'plan_name' IN (?)", plans)
.where("COALESCE(NULLIF(internal_attributes->>'billing_provider', ''), 'stripe') = 'stripe'")
shopify = Account.where("internal_attributes->>'billing_provider' = 'shopify'")
.where("custom_attributes->>'plan_name' <> ''")
[stripe, shopify].each do |scope|
scope.find_each(batch_size: 100) do |account|
next if account.billing_provider == 'shopify' && !Shopify::FeatureGate.enabled?(account: account)
missing = features.reject { |feature| account.feature_enabled?(feature) }
next if missing.empty?
account.enable_features(*missing)
account.save!(validate: false)
end
end
```
After the backfill, deploy this PR. New upgrades and downgrades are
handled by the billing reconciler. No database migration is included in
the PR.
## Rollout notes
- Confirm `CAPTAIN_OPENROUTER_API_KEY` and
`CAPTAIN_OPENROUTER_DECISION_MODEL_ENDPOINT` are configured before
enabling Captain Classifier for customers. The classifier calls
OpenRouter directly and currently has no per-account credit metering or
quota; monitor usage limits do not cover classifier requests. Check
expected traffic and provider costs before rollout.
## How to test
1. On Chatwoot Cloud, confirm Hacker has neither feature without a
manual grant. Upgrade a Stripe account to Startups, Business, and
Enterprise; both features should be available at each paid tier.
2. Downgrade the Stripe account to Hacker; both plan-managed flags
should become unavailable. A previously granted pilot account should
retain its manual grants.
3. After the manual backfill, confirm existing paid accounts have both
flags without waiting for another billing event. Open Reports → Monitors
and check Captain Classifier suggestions in a conversation.
4. Confirm a paid Shopify Basic or Pro account receives both flags even
if the Shopify catalog omits them, and loses them when its subscription
ends. Other Shopify features continue to follow the catalog.
5. Confirm a self-hosted account is unchanged.
# Pull Request Template
## Description
This PR adds icons to conversation monitors, making them easier to
identify in the list. Each new monitor gets a random icon and color in
either outline or filled style.
Admins can change the icon, color, or emoji when creating or editing a
monitor using the same picker used in Teams. The selected icon is shown
in the monitors list and next to the monitor name on its report page.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Screenshots
<img width="580" height="647" alt="image"
src="https://github.com/user-attachments/assets/b97761c4-72bc-4573-9cf5-8648ede04be0"
/>
## 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: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
The empty Monitors page keeps its centered heading, create action, faded
preview, and compact template list. It now offers four familiar customer
conversation topics: missing order updates, feature requests, refund
requests, and cancellation intent. Selecting one prefills its name and
full condition. The preview uses example text without invented counts,
and the WhatsApp BSUID and self-hosted automation examples are removed.
Related to #15966.
## How to test
1. Open Reports → Monitors in an account with no monitors. Confirm the
existing centered empty-state layout and four compact template rows
appear.
2. Select Missing order updates or Feature requests. Confirm the
creation form contains the corresponding name and full condition.
3. Confirm Login problems, Competitor mentions, WhatsApp BSUID, and
self-hosted automation examples are absent, and the faded preview shows
no fabricated counts.
4. Sign in without administrator access. Confirm the templates are
disabled and the administrator help text appears.
When someone is reviewing a monitor's conversation drill-down,
background chart updates now leave the drawer and its displayed chart
snapshot in place. The chart catches up when the drawer closes, so
rolling bucket boundaries and incoming matches no longer dismiss an
active review.
Related to #15966.
## How to reproduce
1. Open a monitor with a nonempty chart bucket and select that bucket.
2. Leave the drill-down open through the next automatic refresh or a
monitor update event. The drawer stays open on the same snapshot.
3. Close the drawer. The chart fetches the latest results.
## Summary
1. Return HTTP 202 after queuing a Playground response job.
2. Run Captain V2 Playground generation in Sidekiq and remove the legacy
Playground branch.
3. Deliver the result or error to the requesting user through Action
Cable.
4. Match responses by request ID and ignore stale results after a reset.
5. Keep Playground runs conversationless so conversation actions cannot
change a conversation.
6. Remove the dashboard's V1 fallback and always initialize the V2 test
setup.
## Validation
1. Focused Rails request, job, configuration, and run-detail specs
passed with 54 examples.
2. Playground and Action Cable frontend specs passed with 26 tests.
3. RuboCop, ESLint, Prettier, and git diff check passed.
4. A live Cook run completed in Sidekiq in 2.922 seconds, broadcast the
WebSocket event, and displayed `WebSocket V2 works` with run details.
5. The Playground and V2 test setup rendered correctly at desktop and
mobile sizes.
Linear:
https://linear.app/chatwoot/issue/AI-213/playground-should-work-via-websocket
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
## Description
Adds an email delivery diagnostic to the super admin user page.
When an address hard-bounces or gets a spam complaint, SES adds it to
the account-level suppression list and silently drops every later email
to it. The app still logs the send, so nobody sees a failure. This adds
an **Email** menu on the super admin user page with:
- **Check email delivery**: looks up the address on the SES suppression
list and shows whether it is blocked, why (bounce or spam complaint) and
since when.
- **Unblock email**: removes a bounce entry after an in-app
confirmation. Disabled for spam complaints, which need engineering.
- **Send test email**: sends a plain-text email through the regular
mailer path to confirm delivery end to end.
- **Resend confirmation email**: the existing action, moved into the
menu for unconfirmed users.
Unblock and test email write a structured log line with the super admin
and target user. Results show as a toast under the header actions on
this page, so the page does not shift.
The feature is inert unless `SES_SUPPRESSION_ROLE_ARN` is set: the
actions return 404 and the page keeps the existing standalone resend
confirmation button. SES calls assume that role from the instance
profile, so the storage keys are never used. `SES_SUPPRESSION_REGION`
overrides the default `us-east-1`. Adds the `aws-sdk-sesv2` gem.
<img width="784" height="390" alt="image"
src="https://github.com/user-attachments/assets/65f87198-1bb7-4523-8d74-94d12e4e3003"
/>
Fixes https://linear.app/chatwoot/issue/CW-7953
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Service, mailer and super admin controller specs, with SES stubbed
through the SDK.
- Ran locally with SES responses mocked and checked each state (not
blocked, bounce, spam complaint, unblock, test email, unconfirmed user)
in the browser.
## 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
## Description
Create the disabled-by-default data foundation for conversation
monitors. One reversible migration creates the five final tables for
monitors, conversation decisions, unified historical/resume scans,
durable work, and daily usage. The optional `user_id` identifies the
user who created the monitor; account ownership remains separate. All
schema changes live in this PR, with no follow-up migrations in the
later stack.
**Review question:** Does the schema preserve account boundaries and
durable lifecycle state?
## Closes
Part of
[CW-8270](https://linear.app/chatwoot/issue/CW-8270/add-conversation-monitors-to-reports-with-jev).
The full stack delivers the feature.
## Stack
**1 of 10**. Base: `develop`. Next:
[15967](https://github.com/chatwoot/chatwoot/pull/15967).
| Order | Draft PR | Review scope |
| --- | --- | --- |
| 1 | [#15966](https://github.com/chatwoot/chatwoot/pull/15966) | define
monitor data contracts |
| 2 | [#15967](https://github.com/chatwoot/chatwoot/pull/15967) |
enforce monitor call credits |
| 3 | [#15968](https://github.com/chatwoot/chatwoot/pull/15968) |
evaluate monitor conditions through OpenRouter |
| 4 | [#15969](https://github.com/chatwoot/chatwoot/pull/15969) |
process durable monitor evaluations |
| 5 | [#15970](https://github.com/chatwoot/chatwoot/pull/15970) | track
monitor source activity |
| 6 | [#15971](https://github.com/chatwoot/chatwoot/pull/15971) |
support monitor lifecycle transitions |
| 7 | [#15972](https://github.com/chatwoot/chatwoot/pull/15972) | expose
conversation monitor APIs |
| 8 | [#15973](https://github.com/chatwoot/chatwoot/pull/15973) |
display live monitor reports |
| 9 | [#15974](https://github.com/chatwoot/chatwoot/pull/15974) | create
and preview conversation monitors |
| 10 | [#15975](https://github.com/chatwoot/chatwoot/pull/15975) |
manage conversation monitors |
[Original reference PR
#15962](https://github.com/chatwoot/chatwoot/pull/15962), frozen at
`562de2bccef4ff9b13179a35e08cb09971971c4c`.
Review and merge in this order. Only the first PR targets develop.
Before merging a child, replay its own changes onto updated develop and
retarget it; do not merge it into the predecessor branch. Account for
squash-merge ancestry and refresh descendants in order. Keep collection
disabled until the complete stack is merged and verified.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
- [x] This change requires a documentation update
## How to test
Apply the single migration on an isolated installation and confirm the
five monitor tables are created. Roll it back and reapply it. Confirm
the monitor flag remains disabled and no new dashboard entry or message
processing is exposed. Existing local prototype databases should be
reconciled separately; this migration describes the unreleased
production schema.
## 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
- [ ] 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
Regression tests are carried with the implementation slice they
exercise. This is an extraction of the validated reference feature;
predecessor drafts remain unmerged. Shared OpenRouter configuration must
be reconciled with [classifier PR
#15906](https://github.com/chatwoot/chatwoot/pull/15906) before both
features land.
---------
Co-authored-by: iamsivin <iamsivin@gmail.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
# Pull Request Template
## Description
Adds an account-level setting, "Enforce two-factor authentication", that
requires every member of the account to enrol in TOTP.
- New `enforce_mfa` key in account `settings`, editable by
administrators from Account Settings. Available on all plans, and hidden
when the installation has no Active Record encryption keys configured.
- A member without 2FA signing in with a password receives a `206` setup
challenge and completes enrolment on the login page itself (QR or manual
secret, verification, backup codes), then lands in the app
authenticated. Nobody is ever locked out: the setup path is always
completable.
- Sign-ins through Google or SAML are exempt, since the identity
provider already applies a second factor. SAML members are also exempt
from the token gate below.
- `api_access_token` requests from members who have not enrolled are
rejected with `403` / `error_code: mfa_enrollment_required` for the
enforcing account. Session-minting side doors are covered as well:
account update, v1/v2 account creation, and conversation direct uploads.
Profile MFA endpoints now require an interactive session, so an access
token cannot enrol or manage 2FA by itself.
- Password reset and email confirmation no longer issue a session when
the user still owes a second factor (enrolled or pending); they are
redirected to sign in.
- While enforcement is on, members cannot disable their own 2FA
(server-side `403`, and the profile UI shows a "required by your
account" note). Backup code regeneration remains available.
- The setup challenge token is purpose-tagged and bound to the current
password, the login MFA token now carries a typed claim, and new
Rack::Attack buckets rate limit setup verification. As part of this, the
auth throttles now parse JSON bodies; previously the `mfa_login/*`
buckets never matched the web client's JSON sign-in requests.
Note for mobile clients: a password sign-in into an enforcing account
returns `206` with `mfa_setup_required` and a readable `error` message.
Un-enrolled users are intentionally hard-blocked on mobile until they
enrol via the web app.
Ref: https://linear.app/chatwoot/issue/CW-8206
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Request/controller/model specs across sign-in, activation, token
gates, reset/confirmation, and profile MFA endpoints, all guarded by the
existing encryption-config skip and added to `run_mfa_spec.yml`.
- Component tests for the login enrolment wizard.
- Manual browser run on a local build: enable toggle as admin, forced
enrolment with wrong and right codes, backup codes, subsequent sign-in
challenge, API token gating, and blocked self-disable.
## 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 my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
## Summary
- Remove the Captain V1 conversation runner, model services, settings,
and playground paths. Route Captain assistants through V2.
- Keep `captain_integration` at its original bit as the active paid
Captain entitlement. Retain `captain_v1_action_classifier` and
`captain_integration_v2` in their original positions as deprecated
markers so persisted bits retain their meaning.
- Preserve legacy assistant instructions only as source data for the
existing reviewed migration task. Add a self-hosted migration runbook.
- Keep editor and Copilot routes and model selection working with the
shared Captain entitlement.
## Release checklist
- [x] **Cloud paid Captain inventory:** The production Rails console
query returned `paid_captain_accounts: 393` and `paid_without_v2_ids:
[]` for accounts with a linked assistant. All 393 paid Captain accounts
in that group have V2 enabled. The operator also confirmed no Captain V1
traces for the past 2 to 3 weeks. Linked assistants on accounts without
the paid Captain feature are outside this rollout check. Repeat the paid
entitlement query immediately before rollout.
- [x] **Stored data compatibility:** `captain_integration` remains the
active paid entitlement at its original bit. The retired
`captain_v1_action_classifier` and `captain_integration_v2` entries
retain their bit positions as deprecated entries. Legacy assistant
instructions remain stored for migration. This PR adds no database
migration.
- [x] **V2 runtime and UI:** In isolated Cook slot 2, a synthetic
customer message received a Captain reply with V2 response parts. A V2
system setting saved through the UI and was verified in the database,
then restored. The playground replied on desktop and mobile.
- [x] **Editor and Copilot:** The editor generated a reply suggestion
that was discarded without sending. Copilot summarized the synthetic
conversation, and the user, tool, and assistant messages persisted. Ruby
examples for these paths passed.
- [x] **Migration task smoke test:** A synthetic legacy assistant passed
`captain:assistant_migration:generate`, dry-run `apply` without writes,
and reviewed `apply` with V2 guidelines and guardrails saved. Original
instructions were preserved.
- [ ] **Self-hosted coverage:** Publish the upgrade notice and runbook.
Admins using V1 instructions must migrate them before installing the V1
removal release. The task is available from v4.16.0, which still has V1.
It handles only assistants with nonempty V1 instructions, a linked
inbox, and no existing scenarios, guardrails, or guidelines. Its
generator requires an endpoint that serves `gpt-5.2`; provide a manual
path for other installations. Admins need a backup and should test
migrated assistants before the final upgrade.
- [ ] **Self-hosted rehearsal:** Upgrade a representative paid
Enterprise installation with V1 instructions, and separately rehearse
the manual path for a provider that cannot serve `gpt-5.2`. Verify V2
settings, inbox replies, and model selection before publishing the
release.
- [x] **Queued work snapshot:** A production Rails console check at
2026-09-23 22:59 UTC returned `{}` for Captain `ResponseBuilderJob`
across queued, scheduled, retry, dead, and running Sidekiq jobs. The
operator reports no V1 jobs during the past month; this snapshot only
verifies current Redis state.
- [ ] **Cutover timing and pending conversations:** Confirm the
end-of-October sunset window and verify pending conversations transition
safely.
- [x] **Final CI:** All PR checks passed on head `fa6881f9e8`, including
Ruby lint, frontend tests, backend tests, builds, and CircleCI coverage.
Local frontend Vitest could not collect tests through the linked
`fake-indexeddb/auto` dependency.
- [ ] **Canary and rollback:** Watch Captain response failures,
handoffs, response credits, editor suggestions, and Copilot after
deployment. Keep the previous release and database backup available for
rollback.
## Self-hosted migration
V2 becomes the Captain runtime after upgrade. Admins who rely on V1
instructions must move them into V2 settings before installing the V1
removal release. They can use the existing `captain:assistant_migration`
task on a release that still has V1, or configure V2 manually. The task
is optional, handles only eligible assistants, and requires an endpoint
that serves `gpt-5.2`; its drafts need human review. The task is present
from v4.16.0. See `docs/captain_v1_sunset.md` for the upgrade order and
limits.
## Verification
- 520 changed-path Ruby examples passed; 78 final focused examples
passed after the last runtime edits.
- 48 Copilot examples and 11 editor reply suggestion examples passed.
- ESLint passed for changed frontend files. The six Ruby files flagged
by CI now pass RuboCop locally.
- Captain V2 settings, a live inbox reply, and playground replies were
checked in the in-app browser at desktop and mobile sizes.
- The migration generator and apply task were exercised with synthetic
data in an isolated Cook environment.
- Frontend Vitest suites could not collect tests in this worktree
because the linked `fake-indexeddb/auto` dependency failed to load.
Basic Companies is now available by default for new Community and
self-hosted accounts, and included in Chatwoot Cloud Startups and
higher. AI enrichment remains in Enterprise. Existing-account enablement
will be handled manually, outside this PR.
## Why
Company records and contact association are core CRM capabilities, but
the previous premium flag and dashboard installation gate kept the core
implementation unavailable to Community users.
## What this change does
- Moves the existing Companies model, APIs, jobs, services, views, and
tests from the Enterprise overlay into core without changing the API
contract.
- Makes `companies` a standard default feature for new self-hosted
accounts.
- Includes Companies in the Cloud Startups entitlement (and higher
plans), while new Hacker accounts remain gated until billing assigns a
plan.
- Removes the dashboard's Cloud/Enterprise installation restriction. The
account feature flag and API authorization still apply.
- Does not backfill existing account flags or persisted installation
feature defaults; those will be updated manually during rollout.
## Validation
- In an isolated Community preview (`DISABLE_ENTERPRISE=true`), opened
the Companies list and detail page, edited a company, and reassigned a
contact through the company selector.
- In an isolated Enterprise-enabled preview, created a company through
the contact selector's Add company modal and saved the contact
association.
- Checked a new Cloud account through Hacker, Startups, and Hacker
entitlement states; Companies was off, on, and off respectively.
- Checked that disabling the account feature hides Companies navigation
and the API rejects the list request.
# Pull Request Template
## Description
This PR adds a reading mode when browsing a customer's older
conversations, so agents don't accidentally reply from an old
conversation.
Clicking **Previous conversation** switches the list to the customer's
history and opens older conversations with the editor folded into
**Reply to this older conversation**. Clicking the bar or using a
writing action opens the editor, while the latest conversation opens
with the normal editor.
### What changed
Previous/Next pills now navigate into the customer's history view. Older
conversations use a reading mode with the editor folded by default,
while the latest conversation keeps the normal editor.
The editor is restored when clicking the bar or when a writing action is
triggered. The back arrow returns to the latest conversation.
Also shortened the pill labels, moved the customer name to the tooltip,
limited previews to the first paragraph, and shared one
`useContactConversationNavigation` instance per conversation view.
Fixes
https://linear.app/chatwoot/issue/CW-8265/replies-sent-while-browsing-an-older-conversation-land-in-that-older
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Screenshots
<img width="1668" height="972" alt="image"
src="https://github.com/user-attachments/assets/fb579f90-419c-4760-97de-aae66c150521"
/>
## 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
Call recordings and transcripts now work for Twilio voice inboxes set up
with an API Key. Before this change, calls went through fine but the
recording never showed up on the call and no transcript was created,
because Chatwoot downloaded the recording with the wrong credential
pair. Agent-initiated outbound calls had the same problem and now use
the same credentials as the rest of the voice channel.
## How to reproduce
1. Create a Twilio inbox with voice enabled, using an API Key SID and
API Key Secret.
2. Enable call recording and place a call, then end it.
3. The call works, but no recording is attached and no transcript
appears. Logs show Twilio rejecting the recording download with a 401
(error 20003).
## What changed
- Added `basic_auth_credentials` on `Channel::TwilioSms`. OSS pairs
`api_key_sid` (or `account_sid`) with `auth_token`; the enterprise
override prefers `[api_key_sid, api_key_secret]` when both are set,
mirroring the existing `client` override.
- The recording download and the Twilio media download now use
`basic_auth_credentials`.
- The outbound voice adapter now uses `channel.client` instead of
building its own client from `account_sid` and `auth_token`.
Mention labels (`[@name](mention://…)`) are now HTML-escaped when
markdown is rendered, so they're handled the same way as the rest of the
message text. The Help Center **Pending changes** panel also renders the
title and content diff through the sanitized `v-dompurify-html`
directive used across the dashboard.
## Closes
- Closes CW-8212 — https://linear.app/chatwoot/issue/CW-8212
## How to test
1. In a conversation, add a private note that mentions an agent or a
team — the mention pill renders as before.
2. Open a Help Center article that has unpublished edits (ideally one
with a table and a video link) and click **Pending changes** — the title
and content diffs render as before; tables keep their column widths and
video links still show a player.
3. A mention whose label contains `<`, `>` or `&` now shows those
characters literally.
## What changed
- `shared/helpers/markdownIt/link.js`: the mention renderer escapes the
label with `md.utils.escapeHtml`.
- `ArticleDiffPanel.vue`: `v-html` → `v-dompurify-html` for both the
title and the content blocks.
- `MessageFormatter.spec.js`: covers mention rendering and label
escaping.
Document `Authorization: Bearer <token>` for existing Chatwoot API
tokens, available from v4.19.0. The OpenAPI auth option explains where
to obtain user, agent bot, and platform app tokens while retaining
`api_access_token` as a legacy option.
Follow-up to https://github.com/chatwoot/chatwoot/pull/15941. Related:
https://github.com/chatwoot/chatwoot/issues/1615 and
https://linear.app/chatwoot/issue/CW-2866/chore-standardise-the-access-token-based-authentication-in-chatwoot.
## Why
API consumers and generated clients should be able to discover the
standard Bearer header and reuse their existing tokens without changing
permissions.
## What this change does
- Adds HTTP Bearer as a separate authentication alternative wherever
existing API tokens are accepted.
- Explains that Bearer authentication is available from Chatwoot v4.19.0
and where to get user, agent bot, and platform app tokens.
- Recommends Bearer auth while keeping the `api_access_token` header
supported ahead of a future deprecation.
- Updates the attachment request example and generated OpenAPI JSON.
## Validation
Open the generated API documentation and confirm Bearer and legacy API
key options appear. On a v4.19.0 instance, authorize with an existing
API token and call an allowed endpoint. Confirm the attachment example
uses `Authorization: Bearer`.
## Description
When `ENABLE_MESSENGER_CHANNEL_HUMAN_AGENT` or
`ENABLE_INSTAGRAM_CHANNEL_HUMAN_AGENT` is enabled, every outgoing Meta
message is currently sent with `messaging_type: MESSAGE_TAG` and `tag:
HUMAN_AGENT` — regardless of who wrote it and whether the conversation
is still inside the standard 24-hour window.
Meta only allows the HUMAN_AGENT tag on replies written by a human agent
and sent after the 24-hour window has closed. Tagging automated replies
(agent bots, Captain) violates the Messenger Platform policy, and
tagging ordinary in-window replies is incorrect usage. Apps that enable
the flag today are exposed to enforcement on the whole app.
This PR applies the tag only when both conditions hold:
- the sender is a human agent (`User`), and
- the last incoming message in the conversation is older than 24 hours.
Otherwise the message is sent exactly as it is today when the flag is
off (`RESPONSE` for Facebook; no tag for Instagram).
The check lives in a small shared module,
`Facebook::HumanAgentTagHelpers`, included by
`Facebook::SendOnFacebookService` and `Instagram::BaseSendService`, so
the three send paths — Messenger, Instagram Login and Instagram via a
Facebook Page — share one rule. It reuses
`Conversations::MessageWindowService::MESSAGING_WINDOW_24_HOURS` for the
window length.
Automation rule messages have no sender, so they are never tagged.
Macros run by an agent keep the agent as sender, so they are tagged
outside the window, as a human-initiated reply should be.
Fixes#15887
Related: #14679
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
The existing HUMAN_AGENT specs were rewritten, because they encoded the
behaviour being fixed or did not assert the payload at all:
- `send_on_facebook_service_spec` asserted that any message is tagged
when the flag is on.
- `instagram/send_on_instagram_service_spec` enabled
`ENABLE_MESSENGER_CHANNEL_HUMAN_AGENT` while the service reads
`ENABLE_INSTAGRAM_CHANNEL_HUMAN_AGENT`, and only checked that
`HTTParty.post` was called — so it passed whatever tag was sent.
- `instagram/messenger/send_on_instagram_service_spec` had the same
`have_received(:post)` check without arguments.
Each of the three now covers:
- a human agent reply after the 24-hour window → tagged `HUMAN_AGENT`
- a human agent reply inside the window → not tagged
- an agent bot reply after the window → not tagged
Tests use `AgentBot` rather than `Captain::Assistant`, since the CE
suite runs with `enterprise/` removed. Captain senders are covered by
the same `User` check.
Run locally in CE mode, mirroring `run_foss_spec.yml` (`enterprise/` and
`spec/enterprise/` removed, Ruby 3.4.4, `pgvector/pgvector:pg16`,
Redis):
```
bundle exec rspec spec/services/facebook/send_on_facebook_service_spec.rb \
spec/services/instagram/send_on_instagram_service_spec.rb \
spec/services/instagram/messenger/send_on_instagram_service_spec.rb
```
- With this change: **37 examples, 0 failures**.
- Same specs against unmodified `develop` services: **37 examples, 6
failures** — exactly the six negative cases (in-window human reply, and
agent bot reply after the window, for each of the three services). The
new specs fail on the old behaviour and pass on the fix.
- `rubocop` on the eight changed files: no offenses.
## 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] 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
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Date filters once again follow the user's local calendar day, without
the performance regression that led to the rollback in #15815. A
conversation created on September 7 at 9:49 PM in Brasília (September 8
at 00:49 UTC) now matches a `Created at < September 8` filter, the same
way the day's report counts it.
Existing folders and contact segments keep their previous UTC behavior
until they are opened and saved once, which records the browser's
timezone on their date conditions.
### Closes
- Reintroduces #15784 after the rollback in #15815
- Support report:
https://app.chatwoot.com/app/accounts/1/conversations/91709
### How to reproduce
1. Use a browser in `America/Sao_Paulo` and a conversation created at
`2026-09-08 00:49 UTC`, which appears as September 7 at 9:49 PM locally.
2. Apply `Status = All`, `Created at > September 6`, and `Created at <
September 8`, then save the folder.
3. Before this fix, the conversation is missing even though it appears
in the September 7 report. With this fix, it appears in the folder and
stays there after reloading.
4. Open an older folder with a date condition, save it once, and confirm
it now uses local calendar days.
### What changed
- Local dates are converted to UTC boundaries before querying, so the
timestamp column is compared directly and PostgreSQL can use its
indexes. On 500,000 indexed timestamps, a selective filter went from a
150.57 ms sequential scan to a 0.95 ms index-only scan.
- `Days before` uses today's date in the saved timezone.
- Conversation lists compute the boundaries once per filter set instead
of formatting every conversation.
- Invalid timezones return `422 Unprocessable Entity`.
- Automation rules and Captain audience conditions keep their existing
behavior.
### Why not send UTC timestamps instead
Converting the local date to a UTC timestamp in the frontend fixes
`is_less_than` and `is_greater_than`, but `Days before` needs today's
date in the user's timezone at query time, so it would stay on UTC.
Saved folders would also store timestamps that must be converted back to
dates for editing. Saving the timezone fixes all three operators and
keeps the stored value as the date the user picked.
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Existing Chatwoot API tokens can now be sent as `Authorization: Bearer
<token>` on Application APIs, conversation direct uploads, and Platform
APIs. The legacy `api_access_token` header remains supported, with the
same token permissions and lifetime.
## Closes
Closes https://github.com/chatwoot/chatwoot/issues/1615
Closes
https://linear.app/chatwoot/issue/CW-2866/chore-standardise-the-access-token-based-authentication-in-chatwoot
## Why
A standard Authorization header works with common API clients and
proxies that drop headers containing underscores. This provides the
token transport needed for future OAuth support without adding OAuth
issuance or changing authorization in this PR.
## What changed
- Accept existing user, agent bot, and platform app tokens through
Bearer authentication.
- Preserve encoded dashboard Bearer authentication and existing account,
bot, and platform resource restrictions.
- Give Bearer tokens precedence when both API headers are present;
invalid Bearer tokens return 401.
## How to test
1. Call `/api/v1/profile` using an existing user token in
`Authorization: Bearer <token>`; verify the same profile is returned
using `api_access_token`.
2. Send different tokens in both headers and verify the Bearer token
determines the authenticated identity. An invalid Bearer token returns
401 even when a valid legacy token is present.
3. Sign in to the dashboard and verify normal dashboard requests still
work.
4. Use an agent bot token on an allowed conversation endpoint and for a
conversation direct upload. Verify disallowed endpoints remain denied.
5. Use a platform app token on a permitted Platform API resource and
verify an unpermitted resource remains denied.
Contact history can omit an older conversation even when it has recent
activity. Ordering the limited history list by creation date puts newer,
less recently active conversations ahead of it, affecting both the
contact history UI and the contact conversations API.
This restores ordering by last activity, with ID as a stable
tie-breaker, so recently active conversations appear in the history
again.
Related: https://github.com/chatwoot/chatwoot/pull/15427
### Things to know
The list remains limited to 25 conversations. Permission filtering and
creation-date-based in-thread navigation are unchanged.
### How to reproduce
1. Use a contact with more than 25 conversations, including an older
WhatsApp conversation outside the 25 newest by creation date.
2. Receive or send a message in that older conversation.
3. Open the contact's history. Before this fix, the conversation is
omitted despite its recent activity.
### How to test
Repeat the steps above and confirm the older conversation appears near
the top of the history. Confirm the contact conversations API returns it
and that previous/next conversation navigation still follows creation
order.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Channel updates create an audit log entry against the inbox with the
channel's `saved_changes`. This change extends the excluded attribute
list so that `provider_config`, known credential columns, and any Active
Record encrypted attributes of the channel (for example email IMAP/SMTP
passwords, bot tokens, and access tokens) are never written to the
`audits` table. The static list covers installs where Active Record
encryption keys are not configured; the dynamic `encrypted_attributes`
lookup covers future encrypted columns. Legitimate configuration changes
continue to be audited as before.
Fixes https://linear.app/chatwoot/issue/CW-8195
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added specs in `spec/enterprise/models/inbox_spec.rb` covering email and
telegram channels: updating `provider_config` and credential attributes
does not add those keys to the audit entry, while a regular attribute
change in the same update is still recorded. Ran `bundle exec rspec
spec/enterprise/models/inbox_spec.rb` both with and without
`ACTIVE_RECORD_ENCRYPTION_*` keys configured; all examples pass in both
modes.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
## Description
The authentication rate-limit rules read request parameters with Rack's
`req.params`, which only parses query strings and form bodies. The
dashboard and mobile clients post JSON, so for those requests every key
came back empty. Two consequences:
- The MFA/device-verification code submissions were not recognised as
such (the `mfa_token` was invisible), so they were counted against the
password-login throttles and the dedicated `mfa_login/*` throttles never
fired.
- Code submissions carry no email, so the `login/email` discriminator
resolved to an empty string. Because an empty string is a valid key,
every code submission across the whole deployment shared a single
bucket, effectively one global limit for all users.
This change adds a JSON-aware `auth_param` helper on the throttle
request class that falls back to `ActionDispatch::Request` (which parses
JSON) and returns nil for blank or non-string values, so a throttle
keyed on a missing value skips instead of sharing one bucket. It is
applied to the login, password-reset and resend-confirmation email
throttles and to the MFA-login throttles. Parameter parsing is wrapped
so a malformed body or an oversized/over-nested query can never raise
out of a throttle. The blocked-event log line now records which rule
matched.
Fixes https://linear.app/chatwoot/issue/CW-8264
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added `spec/initializers/rack_attack_spec.rb` covering the login,
MFA-login, reset-password and resend-confirmation throttles for both
JSON and form-encoded bodies: MFA submissions are exempted from the
password throttles, a missing email skips instead of sharing a blank
key, a non-string email and a malformed/over-nested body fail closed
without raising, and the blocked-event log records the matched rule.
Existing sessions and device-verification specs pass.
## 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
Document `SIDEKIQ_ALIVE_HOST` and `SIDEKIQ_ALIVE_PORT` in `.env.example`
so operators can configure the Sidekiq health endpoint. Uncommenting
`SIDEKIQ_ALIVE_HOST=127.0.0.1` restricts the listener to localhost;
deployments using remote probes can configure the appropriate bind
address.
The gem reads both variables directly, so no application initializer is
needed. Without an explicit host setting, its existing `0.0.0.0:7433`
default remains unchanged. Existing installations must set the variable
and restart their workers to restrict the listener. This documentation
change does not fix the gem's EOF parsing bug.
Fixes#15818.
Thanks to @md-riaz for reporting and investigating the issue.
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
## Description
Device verification returns its errors as server-rendered strings, and
both the web login screen and the mobile app display them verbatim
(inline on web, toast plus inline text on mobile). When a wrong code is
submitted, the current message, "Invalid verification code", does not
tell the user where the correct code actually is.
This matters most on mobile builds that predate [feat(auth): verify new
devices with an emailed code on sign-in
(chatwoot-mobile-app#1183)](https://github.com/chatwoot/chatwoot-mobile-app/pull/1183).
Those builds reuse the MFA screen for the device verification challenge,
so the on-screen copy points at an authenticator app. Device
verification only triggers for users without MFA enabled, so those users
have no authenticator code, and the emailed code is the only valid
input. Since the error string comes from the server, updating it here
reaches already-shipped app versions without an app update.
The message now reads: "Incorrect code. Enter the 6-digit code we sent
to your email."
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Validated the locale file parses and the key resolves through I18n. No
specs assert this string literally, the controller specs compare against
`I18n.t` and the service specs use error symbols, so behavior coverage
is 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
# Pull Request Template
## Description
This PR adds table support to the email reply editor. Agents can insert
tables from the editor menu, edit them in place, and send them as real
HTML tables with inline styles that render reliably in Gmail and
Outlook, in both light and dark mode.
It also fixes an issue where the reply editor stopped growing beyond
120px after visiting a Help Center article. `FullEditor.vue`'s global
editor height cap was leaking into the reply editor, causing the message
body to remain clipped when expanding or resizing the editor.
### https://github.com/chatwoot/prosemirror-schema/pull/60
### What changed
* `Channel::Email` formatting now enables the `table` node and
`insertTable` menu item. Column resizing is disabled for messages.
* `ChatwootMarkdownRenderer` and `MarkdownRendererService` now enable
CommonMarker's table extension.
* `BaseMarkdownRenderer` renders tables with inline styles and ensures
empty cells retain their height.
* `MessageFormatter` fills empty markdown table cells so they render
correctly in conversation bubbles and the quoted-reply preview.
* `FullEditor.vue` no longer applies a global editor height constraint;
the article editor already defines its own height.
* Requires `@chatwoot/prosemirror-schema` with message table support.
Fixes
https://linear.app/chatwoot/issue/CW-8157/support-tables-in-email-bodies
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### How to test
1. Open an email conversation, select some text in the reply, and click
the table icon in the editor menu.
2. Enter content in the cells, add rows and columns using the hover
controls, and send the message.
3. Verify that both the conversation bubble and received email render a
bordered table. Also verify that an empty cell retains its height.
4. Open a Help Center article, return to the conversation, and expand
the reply box. Verify that the editor grows to fill the available space.
## 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
## Description
`GlobalConfigService.load` returned early only when the cached value was
`present?`. A stored
boolean `false` (any `type: boolean` config that is switched off) is not
"present", so every
call fell through to the one-time ENV migration path: an
`InstallationConfig.first_or_create`
plus an unconditional `GlobalConfig.clear_cache`. On a hot caller this
means a DB roundtrip and
a full config cache wipe per call, and `clear_cache` itself ran a
blocking Redis `KEYS` command
followed by one `EXPIRE` per key.
Three changes:
- `load` returns cached nonblank values and boolean `false`. Stored
blank strings are still
treated as unconfigured, preserving current behavior for installations
that saved empty
values (for example Firebase settings) from super admin.
- After a cached blank, the cache is cleared when the database lookup
returns a configured
value, including boolean `false`. This also handles a row created by a
concurrent request;
existing blank rows do not trigger a cache clear.
- `clear_cache` uses cursor-based `SCAN` followed by one multi-key `DEL`
instead of `KEYS`,
avoiding a single blocking keyspace scan.
The hot caller that surfaced this is fixed independently in
https://github.com/chatwoot/chatwoot/pull/15899.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
New specs cover: a stored boolean false served from cache without
clearing other cached
configs, an existing row with a blank value not clearing the cache, a
stored empty string
still treated as unconfigured, and the create path clearing a stale
cached nil. Existing
`GlobalConfig` cache specs pass unchanged. A deterministic two-reader
probe also confirms
that concurrent configuration creation clears the stale cached nil and
subsequent reads
are served from cache.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
Adds admin-only episode drilldowns to the Captain overview so aggregate
metrics and resolution flows can be traced back to their underlying
conversations.
- Add drilldowns for handled, auto-resolved, handed-off, reopened, and
durable-resolution metrics.
- Add drilldowns for resolution-flow nodes and individual handoff
reasons, excluding the aggregated Other reasons node.
- Keep repeat conversation episodes distinct and show their start times
in the drawer.
- Reuse the report drilldown cards with pagination, loading, empty, and
error states.
Bot handoffs now play the dashboard sound and show a browser-tab badge,
so agents know when a conversation needs human attention without waiting
for another message.
Alerts use the agent's existing audio settings, including assignment
filters and whether to alert while the dashboard is visible. Captain
private notes remain visible in the conversation but no longer trigger
alerts. The handoff itself is what requests attention.
## How it works
- A bot handoff starts a 2.5-second window, giving automatic assignment
time to finish.
- At the end of the window, the dashboard checks the latest available
assignment and status before applying the agent's alert settings.
- A human takeover or a conversation that is no longer open cancels the
alert. Unrelated updates, such as an out-of-office message, do not
cancel it.
- If the conversation is not stored locally, the dashboard uses the
original handoff details.
- A bot handoff now only applies to pending conversations. On a
conversation that is already open or resolved, it does nothing: no
status change, no `waiting_since` update, and no handoff event. This
affects agent-bot and API handoffs, handoff notifications, and handoff
reporting, not just alerts.
```mermaid
sequenceDiagram
participant Captain
participant Conv as Conversation#bot_handoff!
participant Listener as ActionCableListener
participant Assign as Auto-assignment
participant WS as actionCable.js
participant Audio as DashboardAudioNotificationHelper
Captain->>Conv: hand off
Conv->>Conv: return false unless pending?
Conv->>Listener: conversation.bot_handoff
Listener->>WS: broadcast to inbox members
WS->>WS: start 2.5s timer (key = account:id, duplicates ignored)
Assign->>Listener: assignee_changed (performed_by Inbox/AssignmentPolicy)
Listener->>WS: assignee.changed + assignment{automatic, assignee_id, type, updated_at}
WS->>WS: store updates conversation
Note over WS: timer fires
WS->>WS: alertOnSettledHandoff()
WS->>Audio: onConversationBotHandoff(conversation)
Audio->>Audio: triggerAlert → filters → sound + badge + 30s repeat
```
The window is intentionally limited. If automatic assignment takes
longer than 2.5 seconds, agents using assignment-based filters may miss
that handoff alert. A late assignment does not restart it.
## Alert preferences
Agents control these alerts in **Profile Settings → Audio Alerts → Alert
events for conversations**, using the same options as message audio
alerts: my assigned conversations, unassigned conversations, and open
conversations assigned to others.
Unchecking all three disables handoff sounds and their tab badges
(`ui_settings.enable_audio_alerts = 'none'`). There is no separate
bot-handoff toggle, so this also disables message audio alerts. The
existing inactive-window and 30-second reminder settings apply to
handoffs too.
## How to test
1. Enable dashboard audio alerts and switch to another browser tab.
2. Ask Captain to hand a pending conversation to a human. Confirm the
sound and tab badge appear after about 2.5 seconds, without a second
alert from the private note.
3. Try assignment filters, disabled alerts, and viewing the conversation
in the active tab. Confirm the existing settings are respected.
4. With automatic assignment enabled, select "My assigned conversations"
and confirm the selected agent is alerted when assignment finishes
within the window.
5. Take over or resolve the conversation during the window and confirm
the alert is cancelled. An out-of-office message alone should not cancel
it.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
## Description
`Shopify::FeatureGate.globally_enabled?` resolved the flag through
`GlobalConfigService.load`,
which is a write-capable helper. When the stored value is boolean
`false` (the shipped default
for `ENABLE_SHOPIFY_INTEGRATION`), it never takes the cached early
return, so every call runs
`InstallationConfig.first_or_create` and `GlobalConfig.clear_cache`.
Since the gate is invoked
from the account payload and integration surfaces added in
https://github.com/chatwoot/chatwoot/pull/15756, every dashboard request
paid for a DB
roundtrip, a full config cache wipe, and the blocking Redis `KEYS` scan
inside `clear_cache`.
The gate now checks `ENV` first and falls back to the cached,
side-effect-free
`GlobalConfig.get`. Flag behavior is unchanged: disabled by default,
enabled via super admin.
The ENV override now genuinely works as a kill switch; previously it was
unreachable once a
config row existed, even though the specs asserted it.
Specs that enabled the gate by stubbing `GlobalConfigService.load` now
configure a real
installation config row instead, since the stubbed call no longer
happens.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Feature gate spec rewritten against real config rows, covering the
disabled/enabled states,
cache survival across calls, no config writes from the read path, and
both ENV overrides.
All OSS and Enterprise specs referencing the flag were run locally and
pass.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
## Description
Follow-up to #15879. Adds `DEVICE_VERIFICATION_ENABLED` to the internal
super admin config allowlist so the device verification toggle can be
flipped from Super Admin → Settings → Internal instead of the Rails
console.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
Added a request spec asserting the toggle saves through the internal
config section. Existing app config specs pass.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
The teams API already accepts `icon` and `icon_color` when you create or
update a team, and returns both on the team resource, but the API
reference never documented them. Anyone reading the docs wouldn't know
they can set or read a team's icon. This adds the two fields so the spec
matches what the endpoint actually does.
The fields were introduced with team icons (#14767); the swagger
definitions were missed at the time.
### What changed
- Added `icon` and `icon_color` (both `string`) to the team
create/update request payload and to the team resource in
`swagger/definitions/`.
- Regenerated `swagger.json` from the definitions.
Co-authored-by: Shaurya <19599684+no-hup@users.noreply.github.com>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
Fix custom-attribute conversation filtering by using numeric inputs for
number attributes and preserving zero and false values when matching
conversations.
## Related issue
Related to #15767. The original inbox-ID mismatch was fixed separately
in #14523; this PR addresses the remaining custom-attribute cases.
## Why
Number filters previously emitted text values, which did not match
numeric conversation values in the dashboard. Zero and false were also
treated as missing custom attributes.
## What changed
- Reuse the existing numeric input conversion for number custom
attributes.
- Preserve zero and false when reading conversation custom attributes.
- Keep strict equality unchanged instead of coercing every attribute to
a string.
## How to reproduce
1. Set a number custom attribute on a conversation, then filter for that
number.
2. Repeat with zero and a checkbox attribute set to false.
3. Check that matching conversations remain visible and that the
not-equal filter excludes them.
Existing saved filters containing string values are not migrated by this
change. Fresh UI verification is still pending.
---------
Co-authored-by: Sojan Jose <sojan@pepalo.com>
# Pull Request Template
## Description
This PR adds a banner in Super Admin when a user session is active.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## 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
## Description
Adds an optional verification step for password sign-ins on Chatwoot
Cloud. When a sign-in comes from a device that has not been seen before,
the user is emailed a 6-digit code and must enter it to finish signing
in.
The step is off by default and controlled by an installation setting. It
works with existing web and mobile clients without an update. Sign-ins
through SSO, and users who already have two-factor authentication
enabled, are not affected. Once a device has been verified it is
remembered, so the same device is not asked again; that trust is reset
when the account password or email changes.
<img width="659" height="781" alt="image"
src="https://github.com/user-attachments/assets/721fdf03-d0e8-4c3e-a9d2-52b293b03709"
/>
Ref: https://linear.app/chatwoot/issue/CW-8225
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Request specs covering when the step is required versus skipped,
single-use codes, the attempt limit, the trusted-device path, and that
verification always resolves to a normal sign-in or a clear error.
- Service and mailer specs for the code and email flows.
- Frontend unit tests for the verification screen.
- Manual end-to-end in a browser: a new-device sign-in shows the email
step, the emailed code completes sign-in, and a return visit on the same
device skips it. On-device mobile confirmation is pending.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
Account suspension history now records the signed-in super admin's user
ID and shows their name in a **Suspended by** column beside the reason.
Editing a reason preserves the original actor. Adding details to an
already-suspended legacy account keeps the actor unknown; older entries
and entries for deleted users also show **Unknown user**. User names are
loaded together in one query, and only English source strings are added.
## Closes
No linked ticket.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How to test
1. In Super Admin, edit an active account, suspend it with a category
and reason, and save. Open the account and confirm that the suspension
history shows your name beside the reason.
2. Sign in as another super admin and edit the reason. Confirm that the
original suspending user's name is preserved. Reactivate and suspend the
account again; confirm that the new entry shows the second admin's name.
3. Open an account with older suspension history that has no recorded
user. Confirm that the history still renders and shows **Unknown user**.
## What changed
- Record the actor only when an active account is suspended, and show
their name alongside each suspension reason.
- Replace the MFA suite's hardcoded `000000` invalid-code fixtures with
a value that cannot be generated as an OTP. The failed CI run generated
`000000` as a valid code, so its rejection test incorrectly expected an
error.
## 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
## Description
Show past-due payment warnings for Cloud accounts as soon as recovery is
needed. Administrators can open billing and resolve payment; agents are
directed to their administrator. The billing page hides the renewal date
until the subscription recovers.
This is the base PR for Cloud support, targeting `develop`. Self-hosted
installation warnings and the Hub dependency are isolated in
https://github.com/chatwoot/chatwoot/pull/15859, stacked on this branch.
Cloud support can be deployed independently of Hub.
## What changed
- Share account payment status between the app-wide banner and billing
page, with administrator-only billing actions and refresh on focus,
reconnect, and billing events. Shopify accounts retain their existing
billing experience.
- Reconcile canonical Stripe subscription state under an account lock,
support item-level subscription fields, preserve replacement
subscriptions, and prevent duplicate renewals from resetting Captain
usage twice.
- Preserve the free-plan cancellation flow and record cancellation once
per subscription, distinguishing payment failure, voluntary
cancellation, trial non-conversion, and unknown history. Mixed invoices
and post-cancellation payments do not establish paid churn; attribution
updates preserve billing records.
Stripe retry, cancellation, and invoice settings remain unchanged. Live
retry count/timing and endpoint configuration still need verification.
PLA-205's existing configuration behavior is preserved.
## Closes
Related to
[PLA-218](https://linear.app/chatwoot/issue/PLA-218/add-past-due-warnings-and-verify-payment-recovery).
The ticket remains open for rollout and live Stripe configuration
verification.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
## How to test
1. Open a Cloud account with a past-due Stripe subscription, including a
future period end. Check the app-wide warning and billing-page recovery
action. Switch between administrator and agent memberships; agents
should see contact-administrator wording without a billing action or
billing API access. Verify Shopify behavior is unchanged.
2. Recover payment and return to the app. Both warnings should clear and
renewal details should reappear. Repeat renewal and delayed failure
events; plan, usage, and credits should remain correct. A cancellation
for an old subscription must preserve its replacement.
3. Inspect cancellation records: paid payment failure and voluntary
cancellation are separate from trial non-conversion, free subscriptions,
and ambiguous payment history.
4. Open a self-hosted installation and confirm this base PR adds no
installation payment warning.
## Screenshots
[Cloud administrator, mobile, agent, and recovered-state
screenshots](https://github.com/chatwoot/chatwoot/pull/15852#issuecomment-5706659815).
## 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: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com>
## Description
Known crawlers that directly load an embedded widget no longer create
anonymous contacts or contact-inbox records. They receive an empty `204
No Content` response with `X-Robots-Tag: noindex` before visitor-token
processing and contact creation. Normal visitors, including requests
without a user-agent header, keep the existing widget behavior.
Follows the merged #15873 and targets `develop`. The existing `Disallow:
/widget` rule remains in place. This adds a server-side check using the
existing Browser library; it does not detect crawlers that disguise
themselves as ordinary browsers. Website-token validation and
suspended-account checks still run before the crawler response.
## Closes
Related to
https://linear.app/chatwoot/issue/CW-8224/prevent-login-page-indexing-on-non-cloud-installations
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
1. Load `/widget?website_token=<valid-token>` from a normal browser. The
widget initializes and creates an anonymous contact. Reload with its
existing `cw_conversation` token and confirm the same contact is reused.
2. Request the same widget URL with a `Googlebot` or `bingbot`
user-agent. Confirm an empty `204` response with `X-Robots-Tag:
noindex`, and no new contacts or contact-inbox records, including when
an invalid `cw_conversation` token is supplied.
3. Confirm invalid website tokens still return `404` and suspended
accounts still return `401`. Requests without a user-agent continue to
initialize normally. Verify these behaviors with Enterprise enabled and
disabled.
## 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
Closes#15819.
## Problem
`config/puma.rb` reads `WEB_CONCURRENCY` to run Puma in clustered mode:
```ruby
workers ENV.fetch("WEB_CONCURRENCY", 0)
preload_app!
```
But `WEB_CONCURRENCY` is absent from `.env.example`, so most self-hosted
installs leave it unset and Puma defaults to `workers=0` (single
process, only `RAILS_MAX_THREADS` threads). Under the GVL, CPU-bound
requests then serialize and can queue/timeout even on multi-core
servers.
## Change
Add a commented `WEB_CONCURRENCY` entry next to `RAILS_MAX_THREADS` in
`.env.example`, explaining clustered mode and how to size it.
The line is **commented out**, so default behavior is unchanged — this
only documents and surfaces the knob to self-hosters, leaving the actual
default value as a deployment choice. Docs-only, no code paths touched.
## Description
Fixes#15840.
The reporter traced valid Meta Graph response shapes that the current
mapping discards: a profile with only `name` becomes `John Doe`, while a
profile with only `first_name` gains a fabricated `Doe` surname. This
change preserves a nonblank full `name` first, otherwise joins only
nonblank first/last components, and keeps `John Doe` solely as the
all-fields-missing fallback.
Regression specs cover full-name-only and single-part-name responses.
This intentionally does not rewrite historical placeholders because
distinguishing generated placeholders from agent-edited names needs a
separate product policy.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `git diff --check` passes.
- Specs were added but not run locally because the bundle/runtime is
unavailable in this environment.
## 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 my fix is effective
- [ ] New and existing unit tests pass locally with my changes
> Built by breken, your AI support engineer - breken.ai - this one's on
us.
## Description
Prevent non-Cloud login and application pages, Super Admin, and
installation setup pages from being indexed. Cloud application pages
remain eligible for indexing. Widget pages always include `noindex`, and
their existing crawl exclusion is preserved to avoid creating contacts
from crawler requests. Public Help Center homepages and articles retain
their existing indexing behavior, including when a widget is embedded.
A public Rails route replaces the static robots.txt file and retains
`Disallow: /widget`. The application layout uses the existing Cloud
detection helper to apply `noindex` conditionally; widget, Super Admin,
and setup pages include it on every installation. Public Help Center
layouts remain unchanged.
Because widget crawling remains blocked, crawlers cannot reliably read
its `noindex` tag to remove already-indexed widget URLs. Allowing widget
crawling safely requires a separate change to make widget GET requests
create no records.
## Closes
Closes
https://linear.app/chatwoot/issue/CW-8224/prevent-login-page-indexing-on-non-cloud-installations
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
1. On a self-hosted installation, open the page source for `/app/login`,
`/app/login/sso`, `/app`, `/`, and
`/widget?website_token=<valid-token>`. The HTML head includes `<meta
name="robots" content="noindex">`, including when the manifest is
disabled.
2. Set the installation's `DEPLOYMENT_ENV` to `cloud` with Enterprise
enabled and reload. The application pages no longer include the
directive, while the widget still includes it. Community installations
retain the directive on application and widget pages.
3. Open `/super_admin/sign_in`, sign in, and inspect `/super_admin` and
`/super_admin/accounts`. All include `noindex` on Cloud, self-hosted
Enterprise, and Community installations.
4. On a fresh installation, open `/` and follow the redirect to
`/installation/onboarding`. The setup page includes `noindex`.
5. Open a public Help Center homepage, article, and custom-domain
homepage using either portal layout, including with a widget attached.
None receives the directive. Plain article previews remain unaffected.
6. Open `/robots.txt` without signing in. It returns plain text with
`User-agent: *` and `Disallow: /widget`, including in API-only
deployments. Other paths remain crawlable.
## 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
## Description
This fixes Facebook Messenger postback events not being received by
Chatwoot inboxes.
Previously, Chatwoot subscribed Facebook pages without the
`messaging_postbacks` webhook field, so actions like `Get Started` and
button postbacks were not delivered. This change adds the missing
subscription field, registers a Messenger `:postback` handler, and maps
postback payloads into the existing Facebook inbound message flow.
Fixes#8821
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Manual reproduction steps:
1. Create or connect a Facebook Page inbox in Chatwoot.
2. Configure a Messenger `Get Started` button or a button that sends a
postback.
3. Trigger the postback from Messenger.
4. Confirm the event is received and created through the existing
Facebook inbound message pipeline.
Automated coverage added:
- Added a model spec to verify `messaging_postbacks` is included in
Facebook page webhook subscriptions.
- Added a builder spec to verify a Messenger postback creates an
incoming message using the postback title.
Note:
- I could not run the full local Ruby test suite in the current
environment because Ruby/Bundler was not available in the active shell.
## 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: Muhsin Keloth <muhsinkeramam@gmail.com>
Fixes#15797 - credit to @Uankur for the precise report and diagnosis
(exact citations, repro curls, and the proposed direction); this PR
implements the fix they sketched, verified independently against current
`develop`. @Uankur - would love your eyes on this.
## Problem
`GET /api/v1/accounts/:account_id/portals/:slug` returns HTTP 500 when
the slug does not exist in the account. `fetch_portal` uses
`find_by(slug:)`, which returns nil instead of raising, and `show` then
calls `@portal.articles` on nil. The blast radius is wider than `show`:
`fetch_portal` runs as a `before_action` for every portal action except
`index`/`create`, so `update`, `destroy`, `archive`, `logo` and
`send_instructions` hit the same nil crash (EE `ssl_status` too).
## Fix
One-token change: `find_by` -> `find_by!`.
`ActiveRecord::RecordNotFound` then flows through the existing
`handle_with_exception` rescue, which renders the standard 404
`"Resource could not be found"` - the same pattern sibling controllers
already use (`labels_controller` uses `find`, and the public portals
controllers use `find_by!(slug:)`). The lookup stays scoped to
`Current.account.portals`, so a slug belonging to another account also
returns 404, matching the reporter's expectation. Pundit authorization
is class-level here and unchanged.
## Tests
Two request specs added to `portals_controller_spec.rb`: unknown slug ->
404 with the standard body, and cross-account slug -> 404.
**Test status (honest):** the specs are written but NOT executed - no
Ruby toolchain was available in our environment. Verification was
static: the nil path, the `handle_with_exception` RecordNotFound -> 404
rescue, and the sibling/public-controller `find_by!` precedent were all
confirmed against current `develop` (`2f1ed80f89`). The one-token change
mirrors the repo's own usage elsewhere.
> Built by breken, your AI support engineer - breken.ai - this one's on
us.
Ruby 3.4 with YJIT enabled inlines constant values at compile time, so
`stub_const` in tests can't replace a class-level constant that YJIT has
already cached — the spec calls still see the original value and the
session-limit tests return 200 instead of 409.
## What changed
- Removed the `MAX_SESSIONS` class constant from
`DeviseOverrides::SessionsController`
- `sessions_limit_reached?` now reads `ENV.fetch('MAX_USER_SESSIONS',
25).to_i` directly on each call (with a guard for `<= 0`)
- Updated the spec to use `with_modified_env` instead of `stub_const` so
the limit is configurable at test time without hitting the YJIT cache
## How to test
Run the session limit enforcement specs:
```
bundle exec rspec spec/controllers/devise_overrides/sessions_controller_spec.rb
```
All tests should pass, including on Ruby 3.4 with YJIT enabled.
---------
Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com>
Summary
This PR fixes XSS vulnerabilities by sanitizing unsafe HTML rendering
paths:
Replaced unsafe
[v-html](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)/[innerHTML](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
rendering with
[v-dompurify-html](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
in captain assistant UI components
Sanitized signup terms HTML before rendering in the signup form
Added server-side markdown sanitization in
[chatwoot_markdown_renderer.rb](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
before marking HTML safe
Added regression coverage for markdown XSS sanitization.
Changed files
[MessageList.vue](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
[ScenariosCard.vue](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
[Index.vue](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
[Form.vue](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
[chatwoot_markdown_renderer.rb](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
[chatwoot_markdown_renderer_spec.rb](vscode-file://vscode-app/c:/Users/gurji/AppData/Local/Programs/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html)
Testing
bundle exec rspec spec/lib/chatwoot_markdown_renderer_spec.rb
Optional frontend validation by building the dashboard and confirming
the updated components render safely without unsafe HTML injection
paths.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
## Problem
Widget file uploads via ActiveStorage DirectUpload fail on production
with:
```text
ActionController::InvalidAuthenticityToken (Can't verify CSRF token authenticity.)
```
This occurs because `Api::V1::Widget::DirectUploadsController` inherits
from `ActiveStorage::DirectUploadsController` →
`ActiveStorage::BaseController`, which has protect_from_forgery with:
:exception enabled.
While CSRF works on same-origin, it fails in production because the
widget is embedded in an iframe on third-party customer sites
(cross-origin)
## Solution
Skip CSRF verification for the widget direct uploads endpoint - this is
safe because:
- Widget endpoints authenticate via website_token + X-Auth-Token
(token-based auth)
- CSRF protection is designed for session-based auth, not token-based
auth
---------
Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com>
WhatsApp Cloud attachments are now uploaded to Meta's media endpoint and
sent by `media_id` instead of a public `link`. Meta no longer downloads
the file from the Chatwoot server, so outbound media stops failing
intermittently with `131053: Media upload error` on hosts that share an
ASN with other Chatwoot/Evolution API instances — Meta's `fwdproxy` rate
limits per destination ASN, not per WABA account. It also removes the
secondary failure where `fwdproxy` does not follow ActiveStorage's `302`
redirect and reports `Unsupported mime type text/html`.
Operators who need the previous behaviour can set
`WHATSAPP_MEDIA_UPLOAD_STRATEGY=link`. No migrations, no config required
on upgrade.
Supersedes #15069 by @AdarshJ173, which established this approach and
the `media_id` direction. The review points raised by @nestordavalos on
that PR are addressed here.
## Closes
- Closes#13540
- Supersedes #15069
## How to reproduce
On a WhatsApp Cloud inbox, send an image, document or voice note from an
instance whose hosting provider shares an ASN with other Chatwoot
deployments (e.g. Hostinger, ASN 47583). Meta's webhook returns:
```
Downloading media from weblink failed with http code 429
ratelimit reason: Request ratelimit by fwdproxy
[GlobalCountingRatelimiter] Request hit ratelimit policy — destination matcher asn_list: 47583
```
After this change the file is uploaded first and the message references
the returned `media_id`, so Meta never fetches it from us.
## What changed
- **New `Whatsapp::MediaUploadService`** — streams the blob to `POST
/{version}/{phone_number_id}/media` as multipart form data and returns
`{ 'id' => media_id }`, or `nil` when the upload is disabled or fails.
- **`WhatsappCloudService#build_attachment_content`** sends the returned
media object, falling back to `{ 'link' => download_url }` so a
media-endpoint failure never blocks a message.
- Uses `Faraday::Multipart::FilePart`, matching
`Telegram::SendAttachmentsService`, the codebase's existing multipart
upload. The file part carries an explicit filename and content type.
- Reads the blob through `blob.open` and streams it via Faraday's
`CompositeReadIO`, so large attachments are never buffered in memory and
any ActiveStorage backend works.
- Follows `WHATSAPP_API_VERSION` via `GlobalConfigService`, matching
`calls_phone_id_path` in the enterprise provider, rather than pinning a
version in source.
- Falls back to the link on `Faraday::Error` or a non-success response
only; other errors surface instead of silently degrading.
- Logs one warning naming the fallback and Meta's own error, including
for non-JSON error pages: `[WHATSAPP] Media upload failed, falling back
to link for account … attachment …: HTTP 429 Request ratelimit by
fwdproxy`.
The `voice`/`caption`/`filename` fields and the existing `audio/opus` →
`audio/ogg` normalisation are unchanged; the normalisation now also
governs the uploaded part's content type.
---------
Co-authored-by: A.Adarsh Jagannath <adarshjagannath777@gmail.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Add reconnect attempts configuration for Redis.
## Description
This PR fixes an issue where Chatwoot stops delivering websocket updates
after Redis is restarted.
For the past few months, `needrestart` has been silently restarting
services that depend on upgraded libraries during system updates,
including Redis. This is the case for me, and maybe it will be for other
people as well.
Issue is When Redis restarts, Action Cable loses its Redis subscription
connection.
The root cause is that the Redis client used by Action Cable only
performs a limited reconnect attempt. If Redis is unavailable during
that window, the subscription remains disconnected permanently. As a
result, websocket connections stay open and continue sending pings, but
no real-time updates are delivered to clients.
This change configures Redis subscription reconnection attempts with
exponential backoff, allowing Action Cable to recover automatically from
temporary Redis outages and service restarts.
Closes#14705
## Type of change
* [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Reproduction Steps
1. Deploy Chatwoot v4.8.0.
2. Open the Chatwoot admin panel.
3. Verify that real-time updates are working.
4. Restart Redis:
```sh
sudo systemctl restart redis-server
```
5. Send a new message or trigger a real-time event.
### Before this change
* Websocket connections remain open.
* Only ping frames are exchanged.
* No real-time updates are delivered.
* Chatwoot requires a restart to restore functionality.
### After this change
* Action Cable automatically reconnects to Redis.
* Real-time updates continue working after Redis becomes available.
* No Chatwoot restart is required.
## 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
## Environment
| Component | Version |
|---|---|
| **OS** | Ubuntu (Noble/24.04) |
| **Ruby** | 3.4.4 |
| **Rails** | 7.1.5.2 |
| **ActionCable** | 7.1.5.2 |
| **redis** (gem) | 5.0.6 |
| **redis-client** (gem) | 0.22.2 |
| **Redis Server** | 8.0.5 |
---------
Co-authored-by: tejush <mac@MacBook-Air.local>
## Description
Restore the dependency-audit CI check by adding a documented exception
for RubyLLM's CVE-2026-67991 on Chatwoot's supported runtime. The change
adds only this advisory to `.bundler-audit.yml`, with the applicability
rationale and removal condition. RubyLLM remains at 1.15.0 and every
other advisory remains subject to the existing audit configuration.
### Advisory verification and applicability
[CVE-2026-67991 /
GHSA-42r3-x6vx-x49x](44784c2953/gems/ruby_llm/CVE-2026-67991.yml)
describes polynomial-time name normalization on Ruby 3.1.x when a very
long crafted class, agent, or tool name reaches the affected operation.
The released 1.15.0 gem contains the regex inline in
`RubyLLM::Tool#name`; the advisory's later `Utils.underscore` reference
does not mean released gems were unaffected.
The exception is based on the application's runtime and actual input
paths:
- **Runtime:** the Gemfile, `.ruby-version`, CircleCI and Docker images
specify Ruby 3.4.4. A bounded local probe of the installed `Tool#name`
method reproduced quadratic behavior on Ruby 3.1.0, but linear behavior
on Ruby 3.4.4. The latter also reports this regex as linear-time,
consistent with [Ruby's regex memoization introduced in
3.2](https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/).
- **Built-in tools:** names come from fixed application classes, rather
than user-generated class names.
- **Custom tools:** [slugs are limited to 64
characters](e16d8f2fa4/enterprise/app/models/captain/custom_tool.rb (L38-L65)).
[Toolable overrides the name
method](e16d8f2fa4/enterprise/app/models/concerns/toolable.rb (L8-L25))
to return that slug directly, bypassing RubyLLM's normalizer.
- **Agent handoffs:** Chatwoot uses `Agents::Agent` from ai-agents; its
handoff tools override naming with a separate lowercase/filter
conversion. Scenario handoff names also have a length budget. Ordinary
prompt/message text does not automatically enter the affected
normalization operation.
Local timings for synthetic all-capital class names:
| Characters | Ruby 3.1.0 | Ruby 3.4.4 |
| --- | ---: | ---: |
| 5,000 | 104 ms | 0.85 ms |
| 10,000 | 430 ms | 1.72 ms |
| 20,000 | 1,676 ms | 3.31 ms |
These measurements characterize the reported regex behavior, not
production capacity. Ruby 3.1.0 was used only for the isolated method
probe; Chatwoot itself was not run on that unsupported version. Live
deployment runtimes were not remotely inspected.
### Why this PR does not upgrade RubyLLM
As of 16 September 2026, stable 1.16.0 still contains the pattern and
still matches the advisory. The [upstream
fix](9d75b033d7)
is released starting with 2.0.0.rc1; the latest release is 2.0.0.rc4,
also a prerelease.
`ai-agents 0.12.0` requires `ruby_llm ~> 1.14`. An isolated Bundler
resolution rejects 2.0.0.rc4. Bypassing the constraint for a
compatibility probe makes `require 'agents'` fail on the removed `param`
method. Chatwoot [requires agents unconditionally during
initialization](e16d8f2fa4/config/initializers/ai_agents.rb (L1-L3)),
so simply widening that constraint can prevent application startup,
including when Captain is unused.
The [2.0
migration](https://github.com/crmne/ruby_llm/blob/v2.0.0.rc4/docs/_reference/upgrading.md)
also affects existing Chatwoot behavior:
| Surface | Required migration |
| --- | --- |
| Captain V2 / scenario handoffs | Replace removed `Tool::Halt`, update
instruction/tool replacement APIs, and preserve runner state and handoff
control. |
| Built-in/custom tools and Copilot | Update `param`/`params`,
parameter-schema readers, tool registration, provider options and
callbacks. |
| Rewrites, replies, summaries, labels and other Captain tasks | Replace
direct token readers; current response conversion can otherwise fail
after a successful provider response. |
| Images and conversation replay | Replace `RubyLLM::Content` with the
new attachment/message API. |
| Structured generation | Read parsed output through `response.parsed`;
current Hash consumers can otherwise produce empty overview points,
blank article fields or raw JSON taglines. |
| OpenAI-compatible endpoints | Make protocol selection explicit: 2.0
defaults to `/responses` instead of `/chat/completions`. Existing
`response_format` options and custom endpoints need adaptation or an
explicit Chat Completions protocol. |
| Request behavior / observability | Validate temperature settings,
token/cost tracing and the renamed model-registry refresh method. |
The isolated request probe confirmed the protocol change and that a
GPT-5.2 request configured with temperature 0.5 sends 1.0 under 1.15 and
0.5 under rc4. No live provider requests were made.
There is no `acts_as_chat`/`acts_as_message` persistence integration in
Chatwoot, so the upstream Rails data migration does not automatically
apply. Embedding/moderation readers used here still exist, and legacy
speech/PDF operations use the separate OpenAI client. RubyLLM remains
MIT licensed. A supported upgrade should be coordinated with ai-agents
instead of being folded into this audit exception.
### Removal condition
Remove the exception when Chatwoot adopts a supported patched
RubyLLM/ai-agents combination, including a recognized compatible 1.x
backport if one becomes available. Reassess it if the supported Ruby
runtime or tool-name construction changes. This records advisory
applicability; it does not claim that RubyLLM 1.15.0 includes the
upstream fix.
The original audit failure was reproduced against ruby-advisory-db
`44784c295391577f25d198a9205eae4ba73ec4da`. The actual changed
configuration now passes the refreshed audit, YAML formatting and
whitespace checks. The prior investigation passed 528 existing focused
specs on this application revision; after adding the exception, all 131
selected Captain base-task, custom-tool and scenario specs passed again.
Existing Rails enum deprecation warnings remain unchanged. No new specs
were added for the configuration-only change.
## Closes
No linked ticket.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How to reproduce
1. On the parent commit, run the CircleCI dependency-audit check with an
updated ruby-advisory-db. It reports RubyLLM 1.15.0 / CVE-2026-67991 and
exits unsuccessfully.
2. Run the same check on this branch. It succeeds with the documented
exception; the gem versions and application behavior remain unchanged.
## 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 (inline
exception rationale and removal condition)
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works (not applicable: audit configuration only)
- [x] New and existing unit tests pass locally with my changes (131
focused existing examples)
- [ ] Any dependent changes have been merged and published in downstream
modules (not applicable: no dependent changes)
# Pull Request Template
## Description
This PR fixes sidebar navigation items not behaving like real links.
Middle-click, Cmd/Ctrl-click, and the browser’s “Open link in new tab”
action now work as expected.
Fixes
https://linear.app/chatwoot/issue/CW-7868/impossibility-to-open-navigation-menu-items-in-a-new-window-or-new-tab
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Screenshots
**Before**
<img width="369" height="387" alt="image"
src="https://github.com/user-attachments/assets/280b540a-1c4c-4f7c-b459-17ea8823fd67"
/>
**After**
<img width="369" height="387" alt="image"
src="https://github.com/user-attachments/assets/87a02578-7064-41ae-abd9-2f6bd4cb5a5e"
/>
## 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
Answering an incoming WhatsApp call from the call bubble in the
conversation could show "Internal Server Error", and the caller then saw
the call as missed. This happened when the call wasn't in the agent's
calls store: it rang while the agent wasn't online, or it was dismissed
earlier. In that case the dashboard fell back to the Twilio flow and
requested a Twilio token for the WhatsApp inbox.
## Closes
- https://linear.app/chatwoot/issue/CW-8174
## How to reproduce
1. Set your availability to Busy or Offline and receive a WhatsApp call
on an inbox with calling enabled.
2. Open the conversation and click Answer on the ringing call bubble.
3. Before: "Internal Server Error" and the call ends as missed. After:
the call connects.
## What changed
- The call bubble adds the call to the calls store from its own message
data before joining, so the WhatsApp answer path is used.
- `ConferenceController` only resolves Twilio inboxes, so the Twilio
token and conference endpoints return 404 for other inboxes instead of
500.
Incoming WhatsApp replies through Twilio lose their quoted-message
context, leaving agents unable to tell which earlier message the
customer means. This change displays the referenced message when it
exists in the same conversation.
The Twilio callback now accepts `OriginalRepliedMessageSid` and passes
it to the existing message reply resolver as `in_reply_to_external_id`.
### Things to know
- Applies to incoming quoted replies. Sending quoted replies through
Twilio remains unchanged.
- Uses the existing same-conversation lookup; references to unavailable
messages retain the existing unresolved-reply behavior.
- Previously received messages are not backfilled.
### How to reproduce
1. In a Twilio WhatsApp conversation, reply to an earlier message using
WhatsApp's reply action.
2. Before this fix, Chatwoot displays the reply without the quoted
message even when Twilio supplies its SID.
### How to test
1. Reply to a recent message in an existing Twilio WhatsApp
conversation.
2. Confirm the incoming reply displays the original message in its quote
preview.
3. Click the quote preview to navigate to the original message.
Locally verified by posting a mock Twilio webhook to the callback
endpoint: the incoming message persisted both reply identifiers and
displayed the original message in the conversation UI. Regression
coverage checks that the controller forwards the quoted SID and the
incoming-message service persists both reply identifiers. The focused
Twilio suite passed with 52 examples and no failures; RuboCop and diff
checks also passed.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Agents can now use the existing conversation sort menu while viewing
conversations narrowed by advanced filters or saved folders. Changing
the order refetches the filtered result set before pagination, so
oldest/newest, activity, unread, priority, and waiting-time ordering
remain consistent across loaded pages.
## Closes
-
[CW-7862](https://linear.app/chatwoot/issue/CW-7862/lack-of-sorting-options-when-using-filters-in-conversations-tab)
## 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
## What changed
- Keep the existing order menu available for ad-hoc filtered and
saved-folder conversation lists while hiding the conflicting status
selector.
- Share the server-side sort whitelist between standard and filtered
conversation queries, preserving existing defaults and legacy aliases.
- Send the selected sort through filtered fetches, pagination, and
reconnect refreshes, with client-side ordering aligned to the server.
- Document the optional `sort_by` parameter for the conversation filter
API.
## How to test
1. Open Conversations and apply an advanced filter.
2. Open the sort menu and confirm the existing order options are
available while the status selector is hidden.
3. Change between oldest/newest, unread, priority, and waiting-time
options and confirm the filtered list refetches in the selected order.
4. Open a saved conversation folder and confirm the same sorting
behavior, including after loading another page.
## 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: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
# Pull Request Template
## Description
Sign-in and sign-out write one audit row per account the user belongs to
using `insert_all!`, which bypasses the `after_create_commit` that
enqueues the IP geolocation lookup added in #15455. Session audits were
the only rows that never got a city or country.
Restoring the callback would undo #15572, which took a 500-account
sign-in from 2016 queries to 519. Since every row from one sign-in
shares a `remote_address` and `request_uuid`, this enqueues a single job
per sign-in that resolves the address once and applies it to that
request's rows in one `update_all`, scoped to accounts with `ip_lookup`
enabled. Constant cost regardless of membership count.
The second commit fixes a defect found while testing. `audit_event_rows`
used `::Audited.store[:current_request_uuid] || SecureRandom.uuid`.
Rails strips an inbound `X-Request-Id` to an empty string when it holds
only punctuation, and `""` is truthy, so those rows were written with a
blank uuid and the new job would skip the batch. Now uses `.presence`.
Fixes https://linear.app/chatwoot/issue/CW-8135
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
New job spec: one lookup applied to every row of a request, isolation
from other requests, a batch spanning eligible and ineligible accounts,
no lookup for ineligible or empty scopes, error swallowing.
Session controller spec: exactly one job enqueued for a user in four
accounts, and rows still share a generated uuid when the request id
sanitises to blank. Verified that spec fails without the `.presence`
fix.
27 examples, 0 failures locally. Rubocop clean.
## 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] 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
The Contacts page could fail to load on larger accounts. When a user has
never picked a sort, the list asked for contacts ordered by **oldest**
activity first. No index can serve that order, so every page load read
every contact in the account just to return 15. When those rows aren't
cached, or the database disk is under load, that runs past the 14s
statement timeout and the page never loads. The page now defaults to
**most recent** activity first. The existing `(account_id,
last_activity_at DESC NULLS LAST)` index serves that order, so a page
load reads about 20 pages whatever the account's size. Users who picked
a sort keep it.
## Closes
- No existing issue. Found via recurring `PG::QueryCanceled` /
`Rack::Timeout` errors on `contacts#index`.
## How to reproduce
1. On a large account, open **Contacts** as a user who has never changed
the sort.
2. The page sends `GET
/api/v1/accounts/:id/contacts?sort=last_activity_at`, which becomes
`ORDER BY last_activity_at ASC NULLS LAST LIMIT 15`.
3. Postgres fetches and sorts every listed contact of the account. When
those pages come from disk, the request hits the statement timeout.
## What changed
- `ContactsIndex.vue`: when no `contacts_sort_by` UI setting is saved,
the default sort is now `-last_activity_at` instead of
`last_activity_at`.
- Measured on production for a ~57k-contact account:
- old default: 57,768 pages read per load (56 ms cached, about 24s from
disk at the measured ~0.42 ms per page);
- new default: an index scan that stops after 15 rows.
- Contact search uses the same plan for either sort direction (trigram
bitmap scan, then a sort of the matches), so it is unaffected.
- Known trade-off: on accounts made up mostly of anonymous visitors, the
new order walks more of the activity index before finding 15 listed
contacts. A partial index restricted to listed contacts removes that
cost if it shows up.
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Temporarily hide the WhatsApp Request Contact Info action in
conversation responses to remove message-history lookups from routine
inbox browsing. Conversation payloads keep the existing fields but
return `available: false`, `reason: null`, and `delivery_mode: null`.
This is an alternative to #15825. Instead of displaying an action that
can later fail because of a pending request in older history, this
mitigation hides the dedicated action entirely while a cheaper
pending-state approach is considered.
## What changed
- Return disabled contact-info availability from the shared conversation
partial without invoking eligibility checks.
- Disconnect the batch lookup from list rendering while retaining the
service code for re-enabling the feature.
- Preserve validation for direct API requests and manually selected
contact-info templates. This disables the dedicated UI action, not the
backend capability.
## How to reproduce
Open a WhatsApp Cloud conversation for a BSUID contact without a phone
number. Before this change, conversation rendering checks message
history to determine whether to show or disable Request Contact Info.
After this change, the dedicated action is hidden and rendering no
longer runs that lookup.
Check conversation lists, filtered lists, contact conversation lists,
and individual conversation responses. Each should return the disabled
contact-info payload.
Fixes advanced-filter totals reverting to open-conversation counts when
requests finish out of order. Count updates now follow request order
within the active view, preserving newer event refreshes and allowing
useful metadata updates when a list refresh fails.
Adds regression coverage for request ordering, failures, pagination, and
cached assignee-tab switches.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Email inboxes can now configure custom SMTP while using forwarding for
incoming mail. Disabling IMAP also preserves the existing SMTP
configuration, so changing the inbound method does not disable outbound
delivery.
## What changed
- Show SMTP settings for email inboxes independently of IMAP.
- Keep SMTP settings untouched when saving IMAP configuration.
- Replace the IMAP prerequisite message with guidance about receiving
mail through IMAP or forwarding.
- Add regression coverage for SMTP visibility and preserving SMTP when
disabling IMAP.
## How to test
1. Open an email inbox that receives mail through forwarding, with IMAP
disabled.
2. Open Configuration and confirm SMTP settings are available.
3. Configure a valid SMTP provider, save, and reload. Confirm IMAP stays
disabled and SMTP stays enabled.
4. Send a reply and confirm delivery through the configured SMTP
provider.
5. In an inbox with both IMAP and SMTP enabled, disable IMAP and save.
Reload and confirm SMTP remains enabled.
Date filters return to their previous UTC-based behavior. This reverts
the timezone-aware calendar-date handling introduced in #15784 across
saved filters, live filtering, unread counts, and the filter API schema.
Reverts #15784
Google, Microsoft, and legacy Google email inboxes now prompt for
reconnection after repeated IMAP authentication rejections. Previously,
these failures were only logged, leaving affected inboxes unable to
receive email without showing a reconnection prompt.
Counts explicit authentication failures, Gmail's invalid-credentials
response, and Microsoft's code-less authentication rejection toward the
existing 10-error threshold. Temporary failures and other IMAP providers
retain their existing behavior.
Date filters now keep conversations on the calendar day the user
expects. Applying or saving a filter records the browser's timezone, so
a conversation started late in the evening is no longer excluded just
because its UTC date is already the next day.
### The bug
A conversation created on **September 7 at 9:49 PM in Brasília** is
stored as **September 8 at 00:49 UTC**. A folder with `Created at >
September 6` and `Created at < September 8` compared the UTC date and
excluded it. The September 7 report used the viewer's timezone and
included it, leaving the folder with three conversations while the
report showed four.
### The fix
- Save the browser's IANA timezone with `Created at` and `Last activity
at` filter conditions. Named timezones account for daylight-saving
changes on the date being filtered.
- Convert stored timestamps to that timezone before comparing calendar
dates, and use the same timezone for `Days before`.
- Apply the same date comparison in frontend filtering. Saved-folder
unread counts use the same backend conditions.
- Preserve the saved timezone when editing folders or contact segments.
The shared date-filter path also fixes contact timestamp filters.
Existing folders and API filters without a timezone retain their
previous UTC behavior. **Open and update an existing folder once to
adopt timezone-aware filtering.** Date-only custom attributes are not
timezone-converted, and automation payload generation keeps its existing
behavior.
### How to reproduce
1. Use a browser in `America/Sao_Paulo` and a conversation created at
`2026-09-08 00:49 UTC`, which appears as September 7 at 9:49 PM locally.
2. Apply `Status = All`, `Created at > September 6`, and `Created at <
September 8`, then save the folder.
3. Before this fix, the conversation is missing even though it appears
in the September 7 report. With this fix, it appears in the folder and
stays there after reloading.
4. Edit the saved folder and update its name. Its timezone and matching
conversations should stay the same.
### Closes
Support report:
https://app.chatwoot.com/app/accounts/1/conversations/91709
Fixes the backend FOSS CI failures caused by the paid self-hosted plan
specs added in #15760. PRs containing those specs can fail before the
plan checks even run.
The FOSS job removes Enterprise code. These tests then pretend
Enterprise is installed, and loading `ChatwootHub` for the first time
tries to load the missing Enterprise extension. That crashes with
`undefined method 'const_defined?' for false`.
The fix explicitly loads `ChatwootHub` before the tests override the
edition checks. This lets it load using the actual installation state,
then allows each test to simulate its plan as intended.
Refines the Captain overview with clearer reporting periods,
comparisons, and knowledge coverage. The new overview remains behind the
localStorage toggle.
- Add This week and Last week, group day/week/month options, and reveal
ranges as data becomes available from August 11, 2026.
- Align resolution trend comparisons by weekday and time of day, show
both periods’ dates in tooltips, and omit comparisons before tracking
began.
- Show a muted dash with an explanatory tooltip for seven-day durability
in Last 7 days and This week.
- Use purple for the resolution trend and muted purple for comparison
bars.
- Simplify knowledge coverage labels, use a continuous progress bar, and
align approved and suggested FAQ counts.
- Soften the coverage banner, separate its action and dismiss buttons,
and limit it to coverage below 75%.
- Keep summary points around 180–220 characters and reserve three lines
of space to prevent layout shifts.
Enable the new overview in the browser console:
```js
localStorage.setItem('captain_overview_v2', 'true');
location.reload();
```
Switch back:
```js
localStorage.removeItem('captain_overview_v2');
location.reload();
```
Closes
https://linear.app/chatwoot/issue/DESN-65/overview-page-design-feedback
When a WhatsApp call fails, the call button now displays the backend's
error message instead of the generic “Request failed with status code
422” toast. This lets agents understand failures such as unavailable
business-initiated calling.
The existing error-message fallbacks remain available when the response
has no explanation. This changes only error presentation; calling
eligibility and consent handling remain unchanged.
### How to reproduce
1. Open a contact with a WhatsApp inbox that cannot initiate business
calls.
2. Click Call and select the inbox if prompted.
3. Previously, the toast showed only the HTTP 422 error even though the
response contained the reason.
### How to test
Attempt a WhatsApp call that returns a backend error. Confirm that the
toast shows the response's error message. If no backend message is
provided, confirm that the existing error fallback is still shown.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
While looking through #13340 and the recent Premium fix in #15727, I
noticed we’re handling Enterprise and Premium as separate cases where
the intent is simply “paid self-hosted.”
This adds `ChatwootApp.self_hosted_paid?` and uses it consistently
across Captain reply search, model overrides, settings access,
new-account defaults, and document sync eligibility.
The existing sync configuration and `enterprise` fallback stay
unchanged. No new self-hosted configuration or intervals are introduced.
Cloud behavior and Premium seat limits remain unchanged.
## How to test
- Verify the affected Captain features are accessible on Premium and
Enterprise, but not Community.
- Confirm the installation model override and new-account Captain
defaults work on both paid plans.
- Confirm document sync still uses the existing configuration.
This follow-up gives the Captain assistant runner a typed extension
point for request-scoped behavior. It keeps the runner constructor
stable while preserving existing playground, Copilot reply-suggestion,
and conversation-response behavior.
This PR is stacked on #15652 and should be reviewed after that PR.
## Closes
[CW-8057](https://linear.app/chatwoot/issue/CW-8057/make-the-captain-playground-better)
## What changed
- Added a typed RunOptions value object for callbacks, source,
burst-protection context, and playground runtime configuration.
- Updated every production runner construction path to use RunOptions.
- Removed the Metrics/ParameterLists suppression from
AgentRunnerService.
- Updated focused service, job, request, and Copilot coverage for the
new boundary.
## How to test
1. Open a Captain V2 playground and send a message with temporary test
setup enabled; confirm the response and run details still appear.
2. Generate a Copilot reply suggestion for a conversation; confirm the
suggestion is returned normally.
3. Send a customer message to a Captain-enabled inbox; confirm Captain
generates one response and message-burst protection remains active.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
Adds the Captain assistant attached to an inbox to the conversation
assignment dropdown and lets agents explicitly assign conversations to
it through the typed AI-assignee contract.
## Closes
-
https://linear.app/chatwoot/issue/CW-7452/add-captain-to-the-assignment-dropdown
## Why
Captain ownership is supported by the backend, but agents need an
explicit way to assign or hand a conversation back to the inbox's
Captain assistant. Manual assignment is a human decision and should not
be blocked by the audience, business-hours, response-quota, or
external-bot rules used for automatic Captain engagement.
## What this change does
- Replaces the Agent Bot-only assignable-agents opt-in with
`include_ai_assignees`, returning typed User, AgentBot, and Captain
owners.
- Adds the Captain assistant to the conversation assignment dropdown
when the same assistant is attached to the requested inbox.
- Accepts a manual Captain assignment only when the selected assistant
is attached to the conversation inbox.
- Assigns Captain as the AI owner, clears the human owner, and moves the
conversation to `pending`.
- Removes the temporary Captain assignment rollout guard.
- Displays Captain-owned conversations with the AI-assignee icon in
conversation cards.
- Keeps automatic Captain engagement and eligibility behavior unchanged.
- Leaves human-only and bulk assignment surfaces unchanged.
This PR is stacked on #15421.
## Validation
1. Attach a Captain assistant to an inbox.
2. Open a conversation from that inbox and expand the assignee dropdown.
3. Verify the Captain assistant appears alongside human agents and Agent
Bots.
4. Assign Captain and verify it becomes the displayed owner and the
conversation moves to `pending`.
5. Verify an assistant that is not attached to the conversation inbox
cannot be assigned.
6. Verify Captain is not offered in human-only or bulk assignment
surfaces.
This is the infrastructure stage of Shopify installation and billing,
split from #13550 so it can be reviewed and merged before the shared
signup and authentication changes. It adds gated Shopify subscription
verification, billing details, plan mapping, and lifecycle cleanup for
Shopify-billed accounts.
Existing accounts default to Stripe billing. The new Shopify billing
flow requires both `ENABLE_SHOPIFY_INTEGRATION` and the account-level
`shopify_integration` feature. The global switch defaults to disabled.
This PR is not a rollout of the complete merchant installation journey.
### Related
- Stacked follow-up: #13550, which should merge only after this PR and a
final end-to-end sanity check.
- Related:
https://linear.app/chatwoot/issue/CW-6500/support-shopify-app-store-install-flow-for-merchant-initiated
- Related:
https://linear.app/chatwoot/issue/PLA-170/resolve-shopify-app-store-billing-rejection
### What changed
- Shopify domain validation, feature gates, API clients, secure
pending-install storage, and subscription snapshots.
- Shopify billing identity, hosted pricing URLs, billing summary API/UI,
plan mapping and fixed plan limits.
- Subscription sync/reconciliation and signed uninstall/privacy cleanup.
- Shopify configuration fields and integration availability checks.
### Things to know
- Shared signup/auth controllers, password reset, resend confirmation,
mailers, user/notification callbacks, Google OAuth, MFA, and auth
navigation are unchanged from `develop`.
- The minimal shared integration points include account billing
identity, account serialization, billing controller/routes/UI,
provider-specific plan resolution, Stripe-event protection, hook
validation, configuration screens, and the hourly scheduler. These still
need review; this PR is not exclusively new files.
- The complete installation/callback/signup wiring remains in #13550. Do
not enable this as a standalone merchant rollout.
- No database migration or schema change is included. The duplicate-hook
cleanup and unique indexes remain in #13550, along with their
database-level tests.
- Captain reservation accounting, IMAP processing changes, notification
callback changes, and global configuration-loader changes remain in
#13550.
- Uninstall/privacy cleanup intentionally works while the global feature
is disabled.
- The existing Stripe plan feature catalog is preserved;
Shopify-specific entitlement cleanup has its own feature set.
### How to test
1. With Shopify disabled, verify ordinary signup, login, confirmation
resend, password reset, and existing Stripe billing continue working;
Shopify should be absent from the integrations list and direct details
should be unavailable.
2. In a disposable cloud-mode test instance, configure the Shopify
Partner API, app handle, and test plan catalog. Enable the global and
account Shopify flags for a pre-provisioned Shopify-origin account with
a connected development-store hook.
3. Open Settings → Billing. Verify that it displays the Shopify
subscription and that Manage in Shopify opens Shopify-hosted pricing.
4. Select a development-store plan only when Shopify confirms there will
be no charge. Return to billing and verify the authoritative plan,
state, renewal date, and fixed account limits.
5. Confirm ordinary accounts continue using Stripe checkout and billing.
A Shopify account must not enter Stripe subscription or top-up actions.
6. Verify signed uninstall cleanup clears store credentials and removes
Shopify entitlements, including while the integration flag is off.
The full first-install, signup, confirmation, and reinstall/reconnect
test belongs to #13550 after this infrastructure is merged.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Summary
This change removes the confusing manual setup copy for Twilio webhook
configuration when finish setup can already be handled automatically,
and aligns the finish-setup user experience so onboarding is consistent
across SMS, WhatsApp, and Bandwidth channels.
## What changed
- Update the Twilio/SMS Finish Setup screen so Twilio-related channels
that are already auto-configured do not require users to manually edit
callback URLs.
- Keep manual guidance only where Twilio channels still require user
action (WhatsApp-specific onboarding path).
- Ensure Bandwidth retains clear guidance only where the callback URL
still must be configured by the user.
- Persist any webhook changes needed for WhatsApp flow directly during
channel save so users are no longer blocked by an extra external config
step.
## How to test
- Open each channel setup flow and validate finish-setup messaging/next
actions.
- Confirm WhatsApp still shows the expected setup step when webhook
auto-setup is not available.
- Verify Bandwidth still shows callback-URL guidance.
## Screenshots
- Twilio SMS:
<img width="1280" height="720" alt="twilio-sms-finish-final"
src="https://github.com/user-attachments/assets/2d22ae5f-1d50-42f2-9049-241340d40bb1"
/>
- Twilio WhatsApp:
<img width="1280" height="720" alt="twilio-whatsapp-finish-final"
src="https://github.com/user-attachments/assets/a85bec5a-5e23-4cbe-88f4-1f104fbdc8a1"
/>
- Bandwidth SMS:
<img width="1280" height="720" alt="bandwidth-sms-finish-final"
src="https://github.com/user-attachments/assets/59b9898f-e643-4dab-91d4-7b01c125a123"
/>
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
`Attachment#inline_audio_url` hardcoded `rails_storage_redirect_url`, so
audio playback ignored `config.active_storage.resolve_model_to_route`.
On S3 setups configured with `:rails_storage_proxy` (required to avoid
CORS/ORB failures) audio URLs still pointed directly at S3, and Chrome
blocked the cross-origin range request with `ERR_BLOCKED_BY_ORB`, so
playback failed. This switches the method to `url_for(file)` — the same
helper `file_url` already uses — so the configured Active Storage route
is honoured. Fixes#15006.
### Root cause
`app/models/attachment.rb:118-122` called
`Rails.application.routes.url_helpers.rails_storage_redirect_url(file,
disposition: 'inline')`, which always builds a redirect URL regardless
of `resolve_model_to_route`. `file_url` (`:57`) uses `url_for(file)` and
respects the setting — audio was the only inconsistency.
### Solution
Use `url_for(file)` in `inline_audio_url`, mirroring `file_url`.
- Default installs (`:rails_storage_redirect`) are unchanged — they keep
redirect URLs, preserving the audio-on-redirect behavior introduced in
#14440 (which keeps large recordings off the proxy range-limiter).
- Only installs that explicitly set `:rails_storage_proxy` now serve
audio through the proxy — exactly what those admins configured, and
consistent with all other media via `file_url`.
- Inline playback is preserved by the `content_types_allowed_inline`
allowlist in `config/initializers/active_storage.rb`, so dropping the
explicit `disposition: 'inline'` has no effect on playback.
- The `ActiveStorageProxyRangeLimit` mitigation from #14440 is untouched
and still applies to any proxy traffic.
Note: the issue also mentions opus S3 object-metadata handling (Meta
error 131053). That is a separate, larger change and is intentionally
out of scope here.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Added `spec/models/attachment_spec.rb` example asserting the audio
`data_url` honours `resolve_model_to_route` when the proxy route is
configured; it fails without the fix (URL was `.../blobs/redirect/...`)
and passes after.
- `bundle exec rspec spec/models/attachment_spec.rb` ✅ (27 examples, 0
failures)
- `bundle exec rubocop --parallel` ✅
- Manual QA: N/A — reproducing requires an S3 backend with
`resolve_model_to_route = :rails_storage_proxy`; behavior is covered by
the spec.
## 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 my code in hard-to-understand areas (where
needed)
- [ ] I have made corresponding changes to the documentation (N/A —
product docs are separate)
- [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
- [x] Targets the `develop` branch
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Conversation priority mutations and filters now reject malformed request
values through Chatwoot's existing `422 Unprocessable Entity` paths
instead of allowing enum, bind, or database errors to reach Sentry.
## Closes
- [Sentry 6625387934](https://chatwoot-p3.sentry.io/issues/6625387934/)
- [Sentry 7288018570](https://chatwoot-p3.sentry.io/issues/7288018570/)
- [Sentry 7664169339](https://chatwoot-p3.sentry.io/issues/7664169339/)
## How to reproduce
- Send the unsupported `priority: "none"` value to a conversation
priority endpoint. It previously reached the enum assignment and raised
`ArgumentError`.
- Submit a conversation filter whose `values` contains an object. It
previously reached Active Record as a structured bind value and raised
`TypeError`.
## What changed
- Route priority updates through the existing strong-parameter method
and reject values outside the conversation priority enum.
- Remove the unsupported `none` value from the public priority API
schemas.
- Reject structured filter values in the shared filter-condition
validator while preserving scalar and scalar-array values.
- Document the request-boundary validation rule in `AGENTS.md`.
Customers can request WhatsApp Embedded Signup access by submitting
their business use case in the dashboard. Access is enabled immediately
and preserved across billing changes.
#### How to test
On a Cloud account without Embedded Signup access, open WhatsApp inbox
setup, click **Request access**, and submit a use case. The signup form
should appear immediately, and access should remain enabled after
refreshing.
<img width="1596" height="1456" alt="CleanShot 2026-09-09 at 12 14
55@2x"
src="https://github.com/user-attachments/assets/a4ea5824-a4ec-48fc-9bab-b7858386fb78"
/>
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Fixes#14911
Adds optional `description` support for `input_select` items and
forwards it when WhatsApp providers build interactive list rows. This
lets integrations use compact row titles with longer explanatory
subtitles in WhatsApp list messages while keeping existing
`input_select` payloads backward compatible.
I kept this as an optional passthrough and did not add WhatsApp-specific
length validation in the generic content attribute validator, matching
the existing behavior for row titles.
## 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?
Ran the focused lint and specs in the Chatwoot devcontainer image
against current `origin/develop` after rebasing:
```bash
bundle exec rubocop app/models/concerns/content_attribute_validator.rb app/services/whatsapp/providers/base_service.rb spec/controllers/api/v1/accounts/conversations/messages_controller_spec.rb spec/services/whatsapp/providers/whatsapp_cloud_service_spec.rb spec/services/whatsapp/providers/whatsapp360_dialog_service_spec.rb
bundle exec rspec spec/services/whatsapp/providers/whatsapp_cloud_service_spec.rb spec/services/whatsapp/providers/whatsapp360_dialog_service_spec.rb spec/controllers/api/v1/accounts/conversations/messages_controller_spec.rb
```
Result: RuboCop reported no offenses; RSpec finished with 49 examples, 0
failures. Also ran `bundle exec rake swagger:build` after updating the
OpenAPI source.
## 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: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Opening a team from Reports > Teams now keeps the selected date range
and Business Hours setting, so the detail cards use the overview
filters. The shared link applies the same behavior to agent, inbox, and
label reports.
The link preserves the current route query, matching the existing report
entity selector. A regression test clicks each report link and checks
that report filters and unrelated query parameters survive navigation.
Supersedes #14202 for the reproduced filter reset. The supplied
reproduction showed matching aggregates after manually restoring
identical filters. Local verification reproduced the dropped query and
confirmed the navigation fix; the database-backed browser comparison was
not repeated in this task.
## Closes
Fixes#14141
## How to reproduce
1. Open Reports > Teams, select Last 30 days, and enable Business Hours.
2. Click a team in the overview table.
3. Confirm the detail page retains Last 30 days and Business Hours
instead of resetting to Last 7 days with Business Hours off.
Customers can already create and schedule campaigns through the API, but
these endpoints are missing from the public API reference. This adds
campaign documentation to the Application API so integrators can
discover the existing functionality and use it without relying on
dashboard requests.
Documents listing, creating, retrieving, updating, and deleting
campaigns, with request and response schemas and a scheduled campaign
example. Includes administrator permissions, account API access
requirements, account-scoped campaign IDs, and the distinction between
website triggers and scheduled one-off campaigns.
### Things to know
- Documentation only; runtime behavior is unchanged.
- Requests accept an ISO 8601 scheduling timestamp; responses return
Unix seconds.
- Existing channel-specific availability and campaign requirements still
apply.
- Regenerated the combined and grouped OpenAPI files. All five documents
pass OpenAPI validation, and campaign references resolve.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Summary
- Enable documentation search for reply suggestions on self-hosted
Premium installations.
- Keep the existing Cloud and self-hosted Enterprise behavior.
- Add a focused regression test for the Premium path.
## Why
Self-hosted Premium includes Captain and embeddings, but the reply
suggestion search gate only allowed Cloud and self-hosted Enterprise.
Agents on Premium received suggestions without FAQ search.
## Tests
- `bundle exec rspec spec/lib/captain/reply_suggestion_service_spec.rb`
- `bundle exec rubocop
enterprise/lib/enterprise/captain/reply_suggestion_service.rb
spec/lib/captain/reply_suggestion_service_spec.rb`
- `git diff --check`
Linear:
https://linear.app/chatwoot/issue/AI-211/enable-search-documents-in-reply-suggestions-for-self-hosted-premium
## Description
FAQ suggestions currently use the conversation language, so an English
account can receive Arabic suggestions. Generate FAQ questions and
answers in the account language regardless of the source conversation
language.
Use the account locale for the generation prompt, saved suggestion and
observation language, matching scopes, and job lock. Keep the language
columns and existing base-language normalization. If the account locale
changes, new FAQs use the new language and existing records retain their
original language.
Language selection reads the account locale directly. No language
classifier or extra LLM call is added.
Fixes
[CW-7568](https://linear.app/chatwoot/issue/CW-7568/suggestions-to-be-made-in-account-locale).
## Type of change
- [x] Bug fix
## How has this been tested?
- FAQ service and job specs: 34 examples, 0 failures in an isolated Cook
test database, with mocked LLM responses.
- RuboCop passed for all three changed files.
- The final tree exactly matches the previously tested account-locale
change after reverting the CLD3 follow-up.
- `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 added tests that prove my fix is effective
- [x] New and existing focused unit tests pass locally
WhatsApp tracking callbacks currently create background jobs even though
Chatwoot does not consume them. This change acknowledges payloads
containing only `tracking_events` after signature verification and the
inactive-number check, then skips enqueueing them to reduce unnecessary
webhook processing.
Normal message-status updates, incoming messages, WhatsApp Business app
echoes, calls, and mixed payloads retain their existing processing.
### Closes
Closes
https://linear.app/chatwoot/issue/CW-8124/skip-unused-whatsapp-tracking-events-before-enqueueing
### How to test
- Send a validly signed tracking-only webhook to an active test inbox.
Expect HTTP 200 and no WhatsApp event job.
- Send a validly signed tracking-only webhook for a number in
`INACTIVE_WHATSAPP_NUMBERS`. Expect HTTP 422 and no job.
- Send the same payload with an invalid signature to an inbox that
requires signature verification. Expect HTTP 401 and no job.
- Send and receive a normal WhatsApp message. Confirm incoming messages
appear and delivery/read indicators continue to update.
- Replay a payload containing both tracking events and a normal message
event. Confirm it is still enqueued through the existing path.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Adds provider-level regression coverage confirming that HTML-like
outbound content reaches the WhatsApp Cloud API request unchanged
instead of becoming an empty message.
This is a focused follow-up to #14192.
## Closes
Regression coverage for #13493, which was fixed by #14192.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
The new provider-level example passes against current develop and fails
against the pre-fix parent, where the request contained an empty text
body. The focused WhatsApp provider and markdown renderer suites pass.
## 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
- [x] Any dependent changes have been merged and published in downstream
modules
Instagram and TikTok inboxes now keep the provider username on the
channel, while Facebook inboxes keep the provider Page name.
Reauthorizing a connection refreshes this provider-owned value without
overwriting the inbox alias chosen by an administrator.
## Closes
Closes
[CW-8060](https://linear.app/chatwoot/issue/CW-8060/persist-provider-names-for-social-inbox-channels).
Related identifier work:
[CW-7245](https://linear.app/chatwoot/issue/CW-7245/show-phone-numberchannel-identifier-consistently-in-inbox-ui).
Implementation plan: [CW-8060 provider-name
plan](https://linear.app/chatwoot/document/cw-8060-persist-provider-names-for-social-inbox-channels-5d0dbd35814c).
## What changed
- Add a nullable provider_name column to Instagram, TikTok, and Facebook
Page channel tables.
- Persist provider usernames or Page names during connection and refresh
them during reauthorization.
- Preserve customized inbox names during Instagram and TikTok
reauthorization.
- Expose provider_name as a read-only inbox API attribute and update the
generated Swagger contracts.
- Add a reusable, sequential backfill service plus the
social_channels:backfill_provider_names Rake task with dry-run, account,
provider, delay, retry, and provider-scoped resumable batch controls.
- Validate all numeric backfill controls strictly so malformed values
fail before provider requests.
- Remove Facebook callback diagnostics that logged access tokens.
## How to test
1. Connect Instagram, TikTok, and Facebook Page inboxes and confirm the
channel provider_name contains the provider username or Page name.
2. Rename an inbox, reauthorize it, and confirm provider_name refreshes
while the inbox name stays unchanged.
3. Fetch the inbox API and confirm provider_name is returned for these
three channel types.
4. Preview the backfill with bundle exec rake
social_channels:backfill_provider_names.
5. Run a limited write batch with DRY_RUN=false PROVIDER=tiktok
LIMIT=100 and optional ACCOUNT_ID and DELAY_SECONDS values.
6. Continue the same provider with AFTER_ID set to the prior summary's
last_attempted_id. The remaining count includes earlier failed or
skipped records so they can be retried separately.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Preserves messages containing raw HTML-like text instead of silently
dropping their contents before channel delivery. Telegram escapes the
literal tags because its provider payload uses HTML parse mode, while
the other text-based channels retain the original content.
## Closes
Closes#13493
## How to reproduce
1. Send `<a>\n<b></b></a>asdf` through a WhatsApp or another text-based
inbox.
2. Without this change, the outbound markdown renderer returns an empty
string and the message cannot be delivered.
3. With this change, the original content is retained. Telegram displays
the same literal text through an HTML-safe payload.
## What changed
- Render CommonMark HTML block and inline HTML nodes from their stored
string content.
- Escape those nodes specifically in the Telegram renderer to preserve
literal text without treating it as provider markup.
- Add exact regression coverage for all affected channel mappings,
tags-only content, trailing content, inline HTML, Twilio WhatsApp
routing, and the final Telegram request payload.
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
## Pull Request Description
The email-collect web-widget template can run twice for the same
conversation and create a duplicate pair of messages (the "Give the team
a way to reach you." line + the email-input box appear twice in the
widget).
`MessageTemplates::HookExecutionService#should_send_email_collect?`
guards only with `email_collect_was_sent?` (does an `input_email`
message already exist?), checked outside any lock. When two hook
executions race for the same conversation — e.g. two incoming widget
messages in quick succession — both pass the guard before either
commits, so each creates the pair. Because the two messages are created
in one transaction, the within-run after_create_commit re-trigger is
already safe; the gap is the lack of serialization across separate
executions.
This:
- Serializes creation in
`MessageTemplates::Template::EmailCollect#perform` with
`conversation.with_lock` and re-checks inside the lock, so concurrent
executions can't both create the pair. (`reload` first because the
conversation passed in from the message hook can carry an unpersisted
`display_id` change, which Rails refuses to row-lock.)
- Adds `return false unless message.incoming?` to
`should_send_email_collect?`, so the hook only reacts to the contact's
incoming message and never to the template messages it creates —
consistent with `should_send_out_of_office_message?`.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `spec/services/message_templates/template/email_collect_spec.rb` —
added a test that invoking the template twice for the same conversation
creates only one pair.
- Existing `hook_execution_service` specs (OSS + enterprise) pass.
## Checklist
- [x] My code follows the style guidelines of this project
- [x] I have added tests that prove my fix is effective
- [x] New and existing unit tests pass locally with my changes
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
# Pull Request Template
## Description
Fixes#13986
This PR fixes duplicate WhatsApp contacts created for Brazilian and
Argentine phone number variants.
When WhatsApp Coexistence receives device-initiated or echo messages,
the same customer can arrive with different valid number formats. For
example, Brazil numbers may arrive with or without the extra mobile 9,
and Argentina numbers may arrive with or without the extra 9 after
country code 54.
Previously, Whatsapp::PhoneNumberNormalizationService checked only one
normalized number format. If an existing contact_inbox was stored using
the alternate format, Chatwoot did not find it and created a duplicate
contact and conversation.
This change updates the normalization lookup to:
- Check the incoming number first.
- Check the normalized number.
- Check Brazil-specific alternate formats.
- Check Argentina-specific alternate formats.
- Reuse the existing contact_inbox if any candidate matches.
- Fall back to the original incoming number if no existing contact is
found.
This preserves existing behavior for new contacts while preventing
duplicate contacts for known WhatsApp number variants.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Tested using the affected WhatsApp and Twilio inbound message specs.
Run:
bundle exec rspec spec/services/twilio/incoming_message_service_spec.rb
bundle exec rspec
spec/services/whatsapp/incoming_message_service_spec.rb
Verified scenarios include:
Brazilian WhatsApp numbers with and without the ninth digit.
Argentine WhatsApp numbers with and without the extra 9 after country
code.
Existing contact inbox is reused when an alternate number format already
exists.
New contact inbox is created using the original incoming number when no
existing contact is found.
## 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: malit <malit@mit.edu>
Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
## Description
Audit log entries expose the raw client IP address in plaintext to
everyone with audit-log access. This shows a derived geo location (city,
country) by default and keeps the raw IP hidden unless an account
explicitly opts in.
- The audit log API now returns a derived `location` (city, country),
resolved from the stored IP via the existing GeoIP lookup in a
background job, so no request is blocked on the lookup.
- When a location cannot be resolved, a partially masked IP (e.g.
`203.0.113.x`) is returned as a fallback. The full IP is never sent to
the client unless the new per-account `audit_log_ip_address` feature
flag is enabled.
- The raw IP is still stored on the record; only what the API renders
changes.
Note: location requires the GeoIP database to be provisioned; without
it, the masked-IP fallback is shown.
Part of https://linear.app/chatwoot/issue/CW-7852
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
Added model, job, and request specs covering masking (IPv4, IPv6 incl.
compressed, malformed, nil), background resolution, and flag on/off API
behaviour. Existing audit-log and account specs pass.
## 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 feature works
- [x] New and existing unit tests pass locally with my changes
The billing page now shows when a subscription is set to end. After a
customer cancels from the Stripe portal, the plan card shows "Cancels on
<date>" instead of "Renews on", and goes back to "Renews on" if they
resume.
## Closes
-
[CW-8034](https://linear.app/chatwoot/issue/CW-8034/mark-the-subscription-as-cancelled-at-the-end-of-the-period)
## How to test
1. On a cloud account with a paid plan, cancel the subscription from the
billing portal.
2. Settings → Billing shows "Cancels on <date>", and the plan stays
active until that date.
3. Resume the subscription, or change the seat count, in the portal —
the card goes back to "Renews on".
## What changed
- `subscription_cancels_on` is read from Stripe's `cancel_at` (falling
back to the period end for older subscriptions that only set
`cancel_at_period_end`), stored on the account and exposed in the
account payload.
- Account deletion now schedules the cancellation with an explicit
`cancel_at` timestamp. `cancel_at_period_end` is deprecated and is not
used by Stripe's flexible billing mode, where it stays `false` even
while a cancellation is scheduled.
WhatsApp customers can become addressable only by a BSUID after WhatsApp
stops sharing their phone number. Text messages already follow the exact
identity attached to the conversation, but outbound calling still
assumes that the contact has a phone number. This hides or rejects the
call action for BSUID-only customers and can select the wrong
destination after contacts are merged.
This PR makes the current conversation's WhatsApp identity authoritative
for outbound calls. Calls and call-permission requests use the exact
`ContactInbox#source_id` attached to that conversation. Phone-number
calling continues to work as before.
### What changed
- Show the call action for a BSUID-only conversation when its WhatsApp
inbox has calling enabled.
- Send the BSUID in Meta's `recipient` field for outbound calls and
call-permission requests.
- Keep phone-number recipients on the existing `to` field.
- Preserve the selected conversation instead of guessing between
identities owned by a merged contact.
- Keep contact-level calling phone-only when no conversation has
established the destination.
### Things to know
- This change applies to Meta Cloud WhatsApp calling. Twilio Voice does
not use the WhatsApp BSUID calling API and remains unchanged.
- This PR is based on
[#15175](https://github.com/chatwoot/chatwoot/pull/15175). Once that PR
is merged, this PR should be retargeted to `develop`.
### How to test
1. Use a Meta Cloud WhatsApp inbox with calling enabled.
2. Open a conversation whose `ContactInbox#source_id` is a BSUID and
whose contact has no phone number.
3. Confirm the call action is available and start an outbound call.
4. Confirm the call remains in the same conversation and Meta receives
the BSUID as `recipient`.
5. Test a customer without call permission and confirm the permission
request is sent to the same BSUID identity.
6. Confirm a normal phone-number conversation still places the call
using the existing flow.
### Fixes
Fixes https://linear.app/chatwoot/issue/CW-7807
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
Corrects `differnt` to `different` in the `shouldGroupWithNext` JSDoc
description in
`app/javascript/dashboard/components-next/message/provider.js`.
Comment-only change; no runtime behavior changes.
Signed-off-by: Vaibhav Srivastava <vaibhavsri1712@gmail.com>
# Pull Request Template
## Description
This PR fixes stray `\` characters and missing `--` signature separators
when replies contain empty lines above the email signature. Empty lines
and Shift+Enter line breaks are now preserved as composed across
delivered emails, dashboard bubbles, text channels, and webhook
payloads.
### https://github.com/chatwoot/prosemirror-schema/pull/59
### What changed
* Bump `@chatwoot/prosemirror-schema` to 1.4.5, which fixes markdown
serialization of empty lines, hard breaks, and setext underline escaping
at the source.
* Strip the escaped signature delimiter cleanly when toggling or
removing the signature, so it never leaves a trailing `\`.
* Unescape the serializer's underline escape (`\--` → `--`) in
`WebhookContentNormalizer`, so API-channel and webhook consumers receive
the original text.
* Add end-to-end rendering specs covering every editor output shape with
23 byte-exact fixtures across cmark, both email modes, and all channel
renderers.
Fixes
https://linear.app/chatwoot/issue/CW-8062/email-replies-show-a-stray-backslash-instead-of-the-signature
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### How to reproduce
On an email inbox with a message signature enabled, type a reply and
press Enter at the end, leaving an empty line above the `--` separator,
then send. The delivered email and email bubble show a stray `\` where
the empty line should be, and the `--` separator disappears.
## 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
Fixes a frontend race that can leave messages from a previously opened
conversation visible in the current conversation until the page is
refreshed.
Switching A → B → A before A’s history finishes loading can request the
same page twice. Both responses prepend the same messages. If reconnect
sync later sorts those duplicates, Vue can leave stale bubbles behind
while reconciling duplicate message keys.
History loads now share pending requests for the same account,
conversation, and pagination cursors. History merges skip existing
message IDs, preserving newer realtime updates, and failed loads remain
eligible for retry. Regression specs cover rapid switching, response
isolation, failure and retry, pagination, and overlapping history.
## How to reproduce
1. Choose two conversations, A and B, with distinct messages and enough
history to scroll.
2. Open browser DevTools and set Network throttling to **Slow 3G**.
3. Reload the page to clear the frontend conversation cache.
4. Open A, switch to B, then return to A **before A’s message history
finishes loading**.
5. Wait for the requests to finish. Repeat from step 3 if needed, since
this depends on timing.
6. Briefly disconnect and reconnect your network to trigger reconnect
sync, then switch between A and B.
**Before the fix:** Duplicate messages may appear, and reconnect sync
can leave stale message bubbles from another conversation visible until
a refresh.
**Expected after the fix:** Each conversation shows only its own
messages, without duplicates. Scrolling up continues to load older
messages correctly.
Personal email signups through Google now show the existing error toast
when redirected back to login. The message remains visible for six
seconds.
The login page previously emitted the toast before the snackbar
subscribed to events. Emit it after mounting and the next Vue tick so
the snackbar receives it.
## How to reproduce
1. Open `/app/login?error=business-account-only` while signed out, or
attempt Google signup with a new personal email on an installation that
requires work emails.
2. Confirm the work-email error toast appears for six seconds.
3. Confirm the `error` query parameter is removed after the toast is
triggered.
Adds a session-only test setup panel to the Captain V2 playground so
teams can test saved or temporary scenarios, response guidelines,
guardrails, and pasted knowledge without changing assistant
configuration. Temporary items can be promoted individually by
administrators, and each response exposes safe run details for scenario
handoffs and tool calls.
## Closes
-
https://linear.app/chatwoot/issue/CW-8057/make-the-captain-playground-better
## What changed
- Adds a responsive, tabbed test setup panel with saved items collapsed
by default.
- Supports saved and disabled scenario selection, temporary scenarios
and rules, and up to 10,000 characters of pasted knowledge.
- Lets administrators save temporary scenarios, guidelines, and
guardrails individually, and save pasted knowledge as a Markdown
document.
- Applies runtime-only prompt and agent overrides and returns sanitized
tool and handoff run details.
- Keeps Captain V1 and production agent flows unchanged; customer and
conversation targeting are not included in this version.
## How to test
1. Open a Captain V2 assistant playground and confirm saved scenarios,
guidelines, guardrails, and knowledge counts load after refresh.
2. Add or exclude temporary and saved items, send messages, and inspect
run details.
3. As an administrator, promote one temporary item and confirm it
remains included without clearing the chat.
4. Save pasted knowledge permanently and confirm a Markdown document is
created for the assistant.
5. Reset test setup and confirm temporary content and messages clear
while the latest saved configuration is restored.
6. Check the panel on a narrow viewport and confirm the V1 playground
remains unchanged.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
Instagram button-click postbacks that reach Chatwoot now appear as
incoming messages in both Instagram Login and Facebook Login inboxes.
Previously, these events were acknowledged but skipped by the Instagram
webhook job.
Postbacks use the existing Instagram message flow, preserving their
external message IDs and reusing its contact lookup, duplicate
detection, authorization handling, and conversation selection. Event
types are evaluated per item so a batch containing a postback followed
by a regular message or read event is routed correctly.
### Closes
Fixes https://github.com/chatwoot/chatwoot/issues/13033
### Things to know
- This handles received `postback` events. Webhook subscriptions and
updates to existing connected inboxes are outside this PR.
- Quick replies delivered as `message.quick_reply` continue through the
normal message path.
- This does not establish the cause of
https://github.com/chatwoot/chatwoot/issues/14584, which reports missing
webhook delivery.
### How to test
1. With Instagram postback delivery configured, click an icebreaker or
template button for an Instagram Login inbox. Confirm the selected title
appears as an incoming message.
2. Repeat for an Instagram inbox connected through Facebook Login.
3. Replay the same event. Confirm that only one message exists for its
message ID.
4. For a known contact, make profile lookup unavailable and send another
postback. Confirm the message still appears.
5. Enable the single-conversation setting, resolve the conversation, and
send a new postback. Confirm the existing conversation is reused.
6. Deliver a batch containing a postback and a normal DM. Confirm each
retains its own message text.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
BSUID-only contacts can now be included in one-off WhatsApp campaigns
for Meta Cloud inboxes instead of being skipped because the contact has
no phone number. Campaign delivery resolves a unique BSUID for the
selected inbox, sends supported templates through Meta's `recipient`
contract, and keeps existing phone-number campaign delivery unchanged.
Fixes
https://linear.app/chatwoot/issue/CW-7802/support-bsuid-recipients-in-whatsapp-campaigns-and-bulk-sends
### Things to know
- This PR is intentionally scoped to Meta Cloud WhatsApp campaigns.
- Twilio WhatsApp campaign support is deferred; this PR does not change
Twilio campaign UI, template parsing, provider submission, or analytics.
- A phone number remains the preferred campaign destination when
present.
- Phone-less recipients require exactly one BSUID on the selected inbox.
Missing or ambiguous identities are skipped/failed per recipient instead
of selecting another merged identity.
- Authentication templates are blocked for BSUID-only campaign
recipients before provider submission.
### How to test
1. Create a one-off WhatsApp campaign using a Meta Cloud inbox and an
audience containing a contact with no phone number but exactly one BSUID
ContactInbox in that inbox.
2. Select an approved non-authentication template and start the
campaign.
3. Confirm the provider request addresses that contact by BSUID and the
recipient is not skipped for a missing phone number.
4. Add a phone number to the same contact and confirm the campaign still
sends to the phone number.
5. Add two BSUID ContactInboxes for the same contact and selected inbox;
confirm the recipient is not sent because Chatwoot refuses to choose an
ambiguous destination.
6. Select an authentication template for a BSUID-only recipient; confirm
Chatwoot blocks it before provider submission.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Refreshes the conversation list from page one after a WebSocket
reconnect while retaining the cached list if the refresh fails. It keeps
the active conversation up to date and prevents stale responses from
inactive or cached tabs from overwriting the current view.
## Related
This reconnect work was split from
https://github.com/chatwoot/chatwoot/pull/15523 so the shared tab-cache
changes can be reviewed separately.
## How to reproduce
1. Load enough conversations to populate multiple pages and open an
older conversation.
2. Disconnect the browser from the network, then update the active
conversation from another session.
3. Restore the network and switch to another cached assignee tab while
the reconnect request is pending.
4. Before this fix, the old response can overwrite the newly active tab,
the selected conversation metadata can remain stale, and the selected
item can break the server-provided list order.
5. After this fix, the active tab remains authoritative, the active
conversation metadata and messages refresh, and the page-one order is
preserved.
6. Make the reconnect request fail and verify the existing cached list
remains available.
## What changed
- Replaces the reconnect delta query with a fresh page-one request.
- Invalidates in-flight list requests whenever chat-list filters change,
including cached assignee-tab switches.
- Replaces cached conversations and resets pagination only after a
successful response.
- Preserves the server response order while merging the selected
conversation's local message state.
- Retains an active conversation outside page one and refreshes its
conversation metadata before syncing messages.
- Shares request freshness across standard, advanced-filter, and
saved-folder list requests.
- Clears the loading state when the current standard-list request fails.
## Description
When Captain used the resolve conversation tool, it resolved the
conversation without sending the Assistant's configured resolution
message.
This change moves resolution message creation into a shared service and
calls it from both Captain resolution paths. The tool sends the
configured message before resolving the conversation. The inactivity job
keeps its existing translated fallback when no custom message is
configured.
Human initiated resolution is unchanged.
Fixes
[AI-206](https://linear.app/chatwoot/issue/AI-206/resolution-tool-doesnt-not-trigger-the-resolution-message)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `bundle exec rspec
spec/enterprise/services/captain/conversation/resolution_message_service_spec.rb
spec/enterprise/lib/captain/tools/resolve_conversation_tool_spec.rb
spec/enterprise/jobs/captain/inbox_pending_conversations_resolution_job_spec.rb`
- 51 examples, 0 failures
- `bundle exec rubocop
enterprise/app/services/captain/conversation/resolution_message_service.rb
enterprise/app/jobs/captain/inbox_pending_conversations_resolution_job.rb
enterprise/lib/captain/tools/resolve_conversation_tool.rb
spec/enterprise/services/captain/conversation/resolution_message_service_spec.rb
spec/enterprise/lib/captain/tools/resolve_conversation_tool_spec.rb`
- 5 files inspected, no offenses detected
## 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 relevant unit tests pass locally with my changes
BSUID-only WhatsApp contacts can now share their phone information
without agents having to ask manually or move the conversation away from
its active BSUID identity. Eligible WhatsApp Cloud conversations expose
a Request Contact Info action, track the request separately from message
delivery, and safely add a valid returned phone identity to the existing
contact.
The flow is limited to contacts whose active inbox identity is a BSUID
and who do not already have a phone number. Phone-backed conversations,
Twilio WhatsApp inboxes, and ordinary shared-contact messages keep their
existing behavior.
### Closes
Fixes
https://linear.app/chatwoot/issue/CW-7809/recover-phone-information-for-bsuid-only-whatsapp-contacts
Note: CW-7810 and CW-7811 were merged into CW-7809 as duplicate scope,
so response-processing and agent-UX requirements are now tracked under
CW-7809.
### Things to know
- This first delivery supports WhatsApp Cloud only. Twilio remains
unavailable until its request-and-response contract is verified end to
end.
- Inside the customer service window, Chatwoot sends Meta's interactive
contact-information request. Outside the window, agents can use an
approved template containing a `request_contact_info` button.
- A conflicting phone identity is surfaced as an identity conflict and
is never merged automatically.
- The generic Save Contact action is hidden only when the contact card
is the response to Chatwoot's contact-information request. It remains
available for ordinary shared contacts.
### What changed
- Added backend-controlled eligibility, delivery, and request-state
handling for BSUID-only WhatsApp Cloud conversations.
- Added safe processing for `origin: contact_request` responses while
preserving the active BSUID conversation and existing aliases.
- Added the agent action, template filtering, pending/shared/conflict
status display, and contact-panel refresh behavior.
### How to test
1. Open a WhatsApp Cloud conversation whose active contact inbox uses a
BSUID and whose contact has no phone number.
2. Select **Request Contact Info** and confirm that the outgoing message
shows **Waiting for contact information**.
3. In WhatsApp, select **Share Contact Info** and share the current
user's contact.
4. Confirm that Chatwoot adds the phone identity to the existing
contact, keeps the conversation on its BSUID contact inbox, and updates
the request state.
5. Confirm that the requested-response contact card does not show **Save
Contact**, while an ordinary shared-contact message still does.
6. Outside the customer service window, confirm that only approved
templates containing a Request Contact Info button are offered.
### Screenshots
**Chatwoot — BSUID-only contact and pending request**
<img width="2068" height="2086" alt="CleanShot 2026-08-21 at 14 04
43@2x"
src="https://github.com/user-attachments/assets/80a957cd-d8d5-489b-96a4-353a46af4ab3"
/>
**WhatsApp — Share Contact Info request and response**
<img width="1170" height="2532" alt="Screenshot 2026-08-21 at 15 05 00"
src="https://github.com/user-attachments/assets/a8feff39-d265-4658-8ac4-dcbb6b5858eb"
/>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
WhatsApp customers who only expose a business-scoped user ID are
reachable in the inbox, but they should also be classified as CRM leads
once CRM v2 is enabled. This change promotes visitor contacts to leads
when WhatsApp identity sync sees a BSUID, so future CRM v2 contact lists
treat them like real reachable channel contacts.
The change keeps BSUIDs in ContactInbox aliases and does not write them
into contacts.identifier.
### Things to know
- This is scoped to WhatsApp BSUID identities, including Meta Cloud IDs
and Twilio's whatsapp:<BSUID> shape.
- This does not change the legacy resolved_contacts predicate when
crm_v2 is disabled.
- Existing BSUID-only contacts may still need a backfill before enabling
CRM v2 broadly.
- Plain phone source IDs and anonymous widget visitors are unaffected.
### How to test
1. Receive a WhatsApp message where the contact identity is a BSUID and
no phone number is available.
2. Confirm the contact remains attached to the WhatsApp ContactInbox
identity.
3. Confirm the contact is classified as a lead.
4. Enable CRM v2 for the account and confirm the contact appears in the
Contacts list.
5. Repeat with a Twilio WhatsApp BSUID payload and confirm the same lead
classification.
6. Confirm a phone-only WhatsApp source ID does not get promoted by this
BSUID-specific rule.
### What changed
- Promotes visitor contacts to leads when WhatsApp identifier sync sees
a BSUID source ID.
- Supports both native Cloud BSUIDs and Twilio-prefixed WhatsApp BSUIDs.
- Adds focused service coverage for CRM v2 visibility and non-BSUID
behavior.
Related:
https://linear.app/chatwoot/issue/CW-7982/whatsapp-contacts-identified-only-by-a-business-scoped-user-id-are
Related: https://github.com/chatwoot/chatwoot/issues/15530
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
SLA policies could appear missing from existing automation rules after a
hard refresh. The policies were not deleted; the automation editor could
initialize before the account feature flags and SLA options finished
loading. This change reacts when SLA becomes available and waits for the
policy lookup before formatting an existing rule.
## How to reproduce
1. Use an account with SLA enabled and at least one SLA policy.
2. Create an automation rule with an Add SLA action and save it.
3. Open the automation settings page directly and hard refresh it.
4. Open the saved rule after the automation list appears.
5. Observe that the selected SLA can appear empty and the Add SLA
dropdown can show no results.
## What changed
- Load SLA policies when the account feature flag becomes available,
including after the page has mounted.
- Wait for the SLA policy request before formatting an existing
automation for editing.
When a Twilio number is set up through the Voice flow, Chatwoot
registers the voice webhooks but never the messaging one. Since a voice
channel is really an SMS channel with voice enabled, the number ends up
able to receive calls but not SMS, with no way to fix it from the
dashboard. This registers the messaging webhook on the voice path, and
adds a Health tab to Twilio inboxes that shows whether each webhook
Chatwoot expects is actually set on the number, with a button to
re-register them.
## How to reproduce
1. Create a Voice inbox with a Twilio number.
2. In the Twilio Console, open the number: the voice webhook points at
Chatwoot, but "A message comes in" is untouched.
3. Send an SMS to the number, nothing arrives in Chatwoot.
## How to test
1. Create a Voice inbox with a Twilio number, the messaging webhook is
now set automatically and inbound SMS lands in the inbox.
2. Open the inbox, go to Settings > Account Health. Each expected
webhook (messaging, plus voice, voice status and the TwiML app when
voice is on) shows as configured.
3. Point the messaging webhook somewhere else in Twilio and reload the
tab, it shows a mismatch with the reason and a hint. Click Register
webhooks and it goes back to green.
4. Point the inbox at a number that is not in the connected Twilio
account, the tab surfaces Twilio's own message instead of a blank card.
## Screenshots
A number whose voice webhooks drifted to an old tunnel — each webhook is
flagged with why Chatwoot cannot receive on it:
<img width="1120" height="900" alt="health-misconfigured"
src="https://github.com/user-attachments/assets/79af318c-918e-41eb-9210-3ca281a51e70"
/>
After clicking Register webhooks, all four are back on the current
installation URL and the repair button drops away:
<img width="1120" height="900" alt="health-healthy"
src="https://github.com/user-attachments/assets/e9d2cb9f-7978-413b-be1a-c70e0ed47214"
/>
When Twilio itself rejects the lookup, its message is shown rather than
an empty state:
<img width="1120" height="900" alt="health-error"
src="https://github.com/user-attachments/assets/c380185e-b1cc-431b-9c7e-5dc0dcddc6fe"
/>
## What changed
- The voice inbox creation path now registers the messaging webhook
alongside the voice ones.
- `Twilio::HealthService` reports the account, the sender and every
webhook Chatwoot depends on, with a reason per webhook (not set, URL
mismatch, wrong HTTP method, overridden by a trunk / TwiML app / the
number's own webhook, missing TwiML app).
- The health and register-webhook endpoints moved from a WhatsApp-only
concern to a shared `InboxHealthManagement` concern.
- `Twilio::WebhookSetupService` authenticates through
`Channel::TwilioSms#client`, so inboxes on API-key credentials can
repair their webhooks too.
- Inbound MMS media downloads use `api_key_secret` when the channel
stores one, so voice inboxes keep their attachments.
- The voice toggle saves on flip instead of waiting for a separate
Update click.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Admins can now decide, per voice inbox, whether calls are recorded and
whether recordings are transcribed. Both settings live on the inbox's
Voice (Twilio) and Calls (WhatsApp Cloud) configuration pages: **Record
calls** switches recording off entirely for teams operating where call
recording isn't permitted, and **Transcribe recordings** — shown only
while recording is on — controls whether Captain turns each recording
into a transcript. Both default to on, so existing inboxes keep their
current behaviour.
Supersedes #15598, which is closed. Same feature, rebased on current
`develop` and reduced to a single reviewable commit.
## Closes
- https://linear.app/chatwoot/issue/CW-8001
## Screenshots
**Twilio voice inbox → Voice**
**WhatsApp Cloud inbox → Calls**
## How to test
1. Open a Twilio voice inbox → Settings → **Voice**, or a WhatsApp Cloud
inbox with calling enabled → **Calls**. Two new toggles appear below
"Allow incoming calls": Record calls and Transcribe recordings.
2. Turn **Record calls** off. The Transcribe toggle disappears and the
setting saves immediately.
- Twilio: place or receive a call — no recording appears on the call
bubble or the Calls page afterwards.
- WhatsApp: accept or place a call — the browser never starts recording,
and no recording is attached when the call ends.
3. Turn **Record calls** back on and turn **Transcribe recordings** off.
Complete a call: the recording is attached but no transcript is
generated (including when Captain reads the conversation). An ordinary
voice note on the same inbox still transcribes.
4. Turn both back on (the defaults) — recording and transcription behave
exactly as before this change.
5. As an agent (non-admin), the toggles are read-only: the API rejects
changes with 401.
## What changed
**One decision point per setting.** Recording is decided once, when the
`Call` row is created: `before_create` snapshots the inbox's flag into
`meta`, and every consumer — Twilio's per-leg conference TwiML, the ring
broadcast, `/initiate`, `GET /whatsapp_calls/:id` — reads
`call.recording_enabled?`. Because Twilio asks for TwiML separately for
each leg and the agent's browser reads a payload of its own, a live
lookup could hand the same call two different answers; the snapshot
means it can't, and flipping the toggle mid-call never changes a call
already under way.
Transcription is deliberately *not* snapshotted: it is read when a
transcript is actually produced. `Messages::AudioTranscriptionService`
is re-entrant (Captain calls it every time it reads a conversation), so
a snapshot would permanently block transcribing a recording an admin
later decides they want transcribed.
- `Concerns::CallRecordingSettings` mixed into
`Enterprise::Channel::TwilioSms` and `Enterprise::Channel::Whatsapp`:
`recording_enabled?` / `transcription_enabled?` read from
`provider_config` and default on (only an explicit `false` disables).
Kept in the EE overlay since calling is Enterprise-only; exposed on the
inbox payload.
- New admin-only endpoint `POST
/api/v1/accounts/:id/inboxes/:id/set_call_recording`, mirroring
`set_inbound_calls` — including the `validate: false` save so WhatsApp's
remote credential re-check can't reject a toggle. It posts both flags
together, so neither can clobber the other.
- Twilio: `<Conference record>` switches between `record-from-start` and
`do-not-record`. With `do-not-record` Twilio produces no recording at
all, so no status callback fires and there is nothing to download,
attach, or discard.
- WhatsApp: the agent's browser is what records, so the decision rides
the same three payloads `sdp_offer`/`ice_servers` already ride — the
`voice_call.incoming` ring broadcast, the `/initiate` response, and `GET
/whatsapp_calls/:id` (the fallback the accept path already uses when the
ring broadcast was missed). When recording is off the `MediaRecorder` is
never created, so no audio is captured and nothing is uploaded.
- Transcription is gated in `Voice::CallTranscriptionService` (Twilio's
automatic path) and in `Messages::AudioTranscriptionService` (the
WhatsApp recording attachment path, which Captain also calls directly).
The second is scoped to `voice_call` messages, so ordinary voice notes
are unaffected.
- Shared `CallRecordingSettings.vue` used by both settings pages,
following the existing inbound-calls toggle: optimistic update, rollback
on failure.
- `WhatsappCallsController#upload_recording` refuses audio for a call
whose snapshot says no. The browser gate ships in JS, so a tab loaded
before the setting changed would otherwise still be able to store a
recording — the client gate avoids *capturing* audio, this one enforces
the policy.
## Verified against a running instance
Beyond the specs, this was exercised end to end on a local server:
- Both toggles render on the Twilio **Voice** and WhatsApp **Calls**
pages, default to on for an inbox whose `provider_config` is `{}`, and
survive a reload. Turning Record calls off hides the Transcribe toggle.
- Toggling writes both flags together (`{"recording_enabled" => true,
"transcription_enabled" => false}`) — neither clobbers the other.
- The real Twilio webhook returns `record="do-not-record"` with
recording off and `record="record-from-start"` with it on. **Snapshot
confirmed:** a call created while recording was off keeps
`do-not-record` even after the inbox is switched back on, while a call
created afterwards gets `record-from-start`.
- `Messages::AudioTranscriptionService` returns the disabled error for a
`voice_call` message when transcription is off, and does *not* block an
ordinary voice note on the same inbox, nor a `voice_call` message when
transcription is on.
- Endpoint authorization: agent → 401, admin → 200, non-voice inbox →
422 `Inbox does not support calling`.
- `upload_recording` → 422 `Call recording is disabled for this inbox`
for a call snapshotted off, 200 `uploaded` for one snapshotted on.
LINE webhook jobs currently stop silently when signature verification
fails, making it difficult to distinguish an invalid signature from
failures later in message processing.
This change adds a warning when a LINE webhook signature is rejected.
Existing webhook validation and message-processing behavior remain
unchanged.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
On installations that override `FRONTEND_URL` through installation
config, SAML login broke: the SP entity ID was built from the overridden
value while the assertion consumer service URL was built from the raw
env var, so the two pointed at different hosts and the IdP posted its
assertion to the wrong place.
The SAML setup proc now reads `FRONTEND_URL` via `GlobalConfigService`,
matching how `AccountSamlSettings#set_sp_entity_id` builds the SP entity
ID.
## How to reproduce
1. Set `FRONTEND_URL` in the environment, then override it with a
different value in Super Admin installation config.
2. Configure SAML for an account and compare the generated SP entity ID
with the ACS URL sent to the IdP. Before this change they use different
hosts.
## Note
`sp_entity_id` is only generated on create, so accounts that configured
SAML under an older `FRONTEND_URL` keep a stale value and still need a
re-save. `OmniAuth.config.full_host` in
`config/initializers/omniauth.rb` also reads the raw env var, but that
affects OSS Google OAuth too and is left alone here.
Improves the Google OAuth signup error shown when someone uses a
personal email address. The message now explains that a work email is
required and stays visible for six seconds.
WhatsApp username is already captured from BSUID-aware webhook payloads,
but agents could not see or preserve it consistently while editing
contacts. This change exposes the stored WhatsApp username in the
contact social links UI and keeps it intact when contact details are
saved.
The conversation contact panel also shows the username as read-only
identity metadata because that compact panel does not expose the
social-links editor. Routing and outbound addressing remain unchanged;
username remains display metadata in this PR.
### Related
Related:
https://linear.app/chatwoot/issue/CW-7804/add-bsuid-and-whatsapp-username-search-and-contact-identity-ui
### Things to know
- WhatsApp username is shown and stored under
`social_profiles.whatsapp`.
- Existing `social_whatsapp_user_name` values are preserved by both
contact edit forms.
- This does not add BSUID or WhatsApp username search yet.
### How to test
1. Open a WhatsApp contact that has
`additional_attributes.social_profiles.whatsapp` or
`additional_attributes.social_whatsapp_user_name`.
2. Confirm the conversation contact panel shows the WhatsApp username
and allows copying it.
3. Open the contact details page and confirm WhatsApp appears under Edit
social links.
4. Update another contact field and save.
5. Reload the contact and confirm the WhatsApp username is still
present.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Dashboard apps now receive custom attribute definitions and the resolved
Chatwoot theme in their context. The context stays synchronized as
attributes and theme change, and refresh requests are routed to the
requesting iframe.
Automation rules containing consecutive label conditions, or an assignee
condition followed by a label condition, can now execute regardless of
condition order.
### What caused the failure
The automation condition filter builds a SQL expression by concatenating
the fragment generated for each condition. Label conditions recently
began using the shared `tag_filter_query` helper, whose fragments do not
include surrounding whitespace.
When a label condition followed an assignee condition or another label
condition, the concatenated SQL contained tokens such as `andEXISTS` or
`andNOT EXISTS`. PostgreSQL rejected the query with a syntax error. The
condition service rescued that error and returned `false`, so the
automation silently appeared not to match. Some condition orders
happened to produce valid SQL, which made reordering look like a
workaround.
This change pads label fragments at the automation filter boundary so
adjacent SQL tokens remain separated for every condition order.
### Closes
- [Support conversation
93445](https://app.chatwoot.com/app/accounts/1/conversations/93445)
- [Support conversation
93437](https://app.chatwoot.com/app/accounts/1/conversations/93437)
### How to reproduce
Create a message-created automation combining assignee presence and
label conditions, then trigger it with the label condition in different
positions. The automation should execute for every logically equivalent
ordering.
When using WhatsApp Coexistence, a message sent from the native WhatsApp
app can create a duplicate contact and a separate conversation for a
customer who already exists in Chatwoot. This happens for Brazilian
numbers when WhatsApp delivers the number without the mobile 9th digit
while the existing contact is stored with the normalized number.
Chatwoot previously deduplicated incoming WhatsApp identifiers mostly at
the `contact_inbox.source_id` level. When no matching `contact_inbox`
existed, contact creation fell back to an exact `phone_number` lookup
using the raw provider number, so an existing normalized contact could
be missed. This change makes contact lookup try safe phone-number
candidates so the same customer resolves to the existing contact and
conversation history stays intact.
### Closes
-
https://linear.app/chatwoot/issue/CW-6724/duplicate-contacts-created-in-brazil-9th-digit-issue-when-using
- Closes https://github.com/chatwoot/chatwoot/issues/13986
### How to reproduce
1. Enable WhatsApp Coexistence on a self-hosted instance.
2. Ensure a contact exists with a Brazilian number including the mobile
9th digit, for example `+5511912345678`.
3. From the native WhatsApp Business app, send a message to that
customer so Chatwoot receives an echo event with the number without the
9th digit, for example `+551112345678`.
4. Before this change, Chatwoot creates a duplicate contact and a
separate conversation.
5. After this change, Chatwoot reuses the existing contact and the
message lands in the existing conversation context.
### Things to know
- Exact phone-number matches still win before generated candidates, so
existing contacts stored in the provider-delivered format are preserved.
- Brazil candidate matching is limited to legacy mobile ranges so
landlines are not rewritten into mobile-looking numbers.
- The same contact candidate logic is applied to WhatsApp Cloud,
WhatsApp Coexistence echo events, Twilio WhatsApp, and Enterprise
WhatsApp calls.
### What changed
- Added safe contact phone-number candidate lookup to
`ContactInboxWithContactBuilder`.
- Centralized candidate generation through
`Whatsapp::PhoneNumberNormalizationService#phone_number_candidates`.
- Added Brazil-specific contact candidate rules and regression coverage
for raw, normalized, landline, profile-name, Twilio, and Enterprise call
paths.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com>
Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
## Description
Message deletions were not recorded anywhere. This adds an enterprise
audit log entry when a message is deleted, capturing who deleted it, the
conversation and inbox context, and the original content before it is
replaced with the deleted placeholder.
The audit write lives in an enterprise controller module that prepends
the core messages controller `destroy` action, keeping the core change
to a single line. The deletion and the audit entry are written in the
same transaction, so a deletion that cannot be audited is not committed.
This does not change who is allowed to delete a message.
Part of https://linear.app/chatwoot/issue/CW-7852
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
Added a request spec asserting the soft-delete still works and that an
audit log entry is created with the deleting user, request IP,
conversation/inbox context, and original content; plus a frontend helper
spec for the new entry. Existing message controller specs pass.
## 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 feature works
- [x] New and existing unit tests pass locally with my changes
WhatsApp Embedded Signup inboxes can now be reconfigured without
requiring the deprecated `whatsapp_reconfigure` account feature. This
keeps the existing reconfigure action available for admins while
preserving the separate Cloud gate for creating new Embedded Signup
inboxes.
The old `whatsapp_reconfigure` flag remains in the feature list as a
deprecated entry so existing `feature_flags_ext_1` bit positions stay
stable.
### Things to know
- New WhatsApp Embedded Signup inbox creation on Chatwoot Cloud still
requires `whatsapp_embedded_signup_inbox_creation`.
- The deprecated `whatsapp_reconfigure` feature should not be used for
runtime behavior.
- The Reconfigure UI copy remains unchanged.
### How to test
1. Open an existing WhatsApp Cloud inbox that was connected through
Embedded Signup.
2. Go to Settings -> Inboxes -> the inbox -> Configuration.
3. Confirm the WhatsApp Embedded Signup section shows the Reconfigure
action even when `whatsapp_reconfigure` is disabled for the account.
4. Click Reconfigure as an admin and complete the Meta flow for the same
phone number.
5. Confirm the existing inbox is updated successfully.
6. On Chatwoot Cloud, try creating a new WhatsApp Embedded Signup inbox
from an account without `whatsapp_embedded_signup_inbox_creation`;
confirm creation is still blocked.
### What Changed
- Removed `whatsapp_reconfigure` from frontend feature constants.
- Removed the backend reconfigure authorization dependency on
`whatsapp_reconfigure`.
- Marked `whatsapp_reconfigure` as deprecated in `config/features.yml`.
- Added request and component coverage for ungated reconfigure and
still-gated Cloud inbox creation.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
# Pull Request Template
## Description
This PR fixes the "Initiated at" field in the conversation sidebar
showing the visitor's local time for website conversations and UTC for
email conversations. It now shows the time in the agent's timezone and
dashboard language, with the timezone label included to avoid ambiguity.
For example: `Nov 27, 2025, 9:05 PM (GMT+5:30)` or `27/11/2025، 9:05 م
(غرينتش+5:30)`.
## How to reproduce
1. Start a conversation from the live-chat widget with the visitor's
timezone different from the agent's, or use an email conversation.
2. Open the conversation in the dashboard and check Conversation
Information → Initiated at.
3. Before: the visitor's local time or UTC. After: the agent's local
time with the timezone label.
## What changed
* `ConversationInfo.vue` now parses and formats the stored timestamp
instead of displaying it as-is.
* `useExactTimestamp` now supports an opt-in `showTimeZone` flag. The
existing default formatting is reused, with the localized timezone label
appended in parentheses.
* Specs cover UTC, DST abbreviations (PST/PDT), whole and fractional
offsets, date-line rollover, localized and RTL timezone labels, and the
default format.
Fixes
https://linear.app/chatwoot/issue/CW-7983/initiated-at-in-conversation-information-is-not-shown-in-the-agents
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Screenshots
**Before**
<img width="357" height="125" alt="image"
src="https://github.com/user-attachments/assets/5861d67d-d802-4938-8c35-7e7874fb2e84"
/>
<img width="357" height="125" alt="image"
src="https://github.com/user-attachments/assets/2039da42-d152-4043-b5c3-847e2b9fdb1e"
/>
**After**
<img width="357" height="125" alt="image"
src="https://github.com/user-attachments/assets/13c538ba-a2b2-4982-940a-fbe5514c262f"
/>
<img width="357" height="125" alt="image"
src="https://github.com/user-attachments/assets/dbcc145e-10a0-4683-8e8d-03e39ba4ef41"
/>
## 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
The first message sent in a new Copilot thread is used verbatim as the
thread's `title`, a string column capped at 255 characters. Messages
longer than that raised `RecordInvalid` and the send silently failed,
but only for the first message: follow-up messages are stored in a
`jsonb` column with no such cap, so the limit was invisible,
undocumented, and inconsistent between the first and later messages in
the same thread.
Separately, the Copilot input cleared itself immediately on send, before
the server confirmed success. Combined with the above, a rejected first
message's text was gone with no way to recover it.
## What changed
- Truncate the derived thread `title` instead of validating the raw
message against the column length limit, so the message itself is never
rejected for length.
- Thread an `onSend`/`onSendMessage` callback through `CopilotInput` →
`Copilot` → `CopilotContainer` that resolves to whether the send
succeeded, and only clear the input on success. On failure the typed
message is preserved so the user can retry or edit it.
## How to reproduce
1. Open any conversation and expand the Copilot panel in the right
sidebar (Captain/Copilot enabled).
2. Type more than 255 characters as the first Copilot message in that
conversation and send.
3. Before this fix: request fails with `Title is too long`, input is
cleared, message text is lost.
4. After this fix: message sends successfully, thread title is a
truncated version of the message.
Closes#15045
---------
Signed-off-by: ajuijas <189517297+ajuijas@users.noreply.github.com>
Co-authored-by: ajuijas <189517297+ajuijas@users.noreply.github.com>
Co-authored-by: aakashb95 <aakashbakhle@gmail.com>
Co-authored-by: Aakash Bakhle <48802744+aakashb95@users.noreply.github.com>
When a business links an existing WhatsApp Business App number through
Embedded Signup coexistence, Chatwoot no longer attempts to re-register
the phone number or run the immediate post-signup health check —
preventing redundant/failing registration calls and false "disconnected"
reauthorization prompts right after a successful coexistence signup.
## How to reproduce
Meta's embedded signup popup ends with one of two events depending on
what the user selects: `FINISH` for a fresh/new number, or
`FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING` when linking a number already
active on the WhatsApp Business App (coexistence).
- New-inbox creation already recognized both events, but had no way to
tell the backend which one occurred — so coexistence signups still
redundantly called `/register` (silently swallowed) and could still run
the immediate health check, which can flag a fresh coexistence number as
"pending" (Meta's health data can lag behind the FINISH event) and
wrongly trigger reauthorization.
- The reauthorize flow (`Reauthorize.vue`) only recognized `FINISH` at
all, so completing a coexistence reauth there would silently stall.
- A third "configured reauth" shortcut (used when the inbox already has
a stored `business_account_id`/`phone_number_id`, e.g. completing a
pending registration) calls the reauthorize API immediately after
`FB.login` resolves and never looked at the postMessage event, so it had
no way to know a coexistence signup had occurred either.
## What changed
- The frontend now tracks `is_coexistence` from the
`FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING` event across all three entry
points above and passes it through to the backend.
- `Whatsapp::WebhookSetupService` skips phone registration when
`is_coexistence` is set, with a fallback check on Meta's `is_on_biz_app`
health field for callers that don't have the explicit signal.
- `Whatsapp::EmbeddedSignupService` skips the immediate post-signup
health check for coexistence signups.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
WhatsApp now reports BSUID lifecycle changes as `system` messages on the
existing `messages` webhook subscription. Chatwoot currently ignores
those events, so the next message under a rotated identifier can create
a second contact and split the customer’s history.
This change records the current BSUID and parent BSUID as additional
aliases of the contact that owns the previous identifiers. Existing
aliases and conversations remain untouched. For a `user_changed_number`
event, Chatwoot also records the new phone alias and updates the contact
phone when that can be done without claiming an identifier owned by
another contact.
### Closes
Fixes
https://linear.app/chatwoot/issue/CW-7801/handle-bsuid-lifecycle-updates-and-identifier-rotation
### Things to know
- This PR is stacked on the routing foundation in #15175.
- No new webhook-field subscription is required. Meta sends both
`user_changed_user_id` and `user_changed_number` inside
`messages[].system`.
- The handler reads only Meta’s typed identifier fields; it does not
parse the human-readable system-message body.
- Previous aliases are retained so delayed webhooks still resolve
safely.
- Conversations are never repointed between `ContactInbox` rows.
- The lifecycle event does not create an agent-visible message or
conversation.
- Identifier collisions are logged and left unmerged for review.
- The new-identifier locks are shared with normal inbound routing. If a
lock cannot be acquired, the webhook job retries instead of writing
without protection.
### How to test
1. Create a WhatsApp Cloud contact with a `ContactInbox` whose source ID
is the previous BSUID.
2. Post a normal WhatsApp `messages` webhook whose message has `type:
"system"`, `system.type: "user_changed_user_id"`, and the documented
`previous_user_id` / `user_id` values.
3. Confirm the same contact now owns both source IDs, its existing
conversation still points to the original `ContactInbox`, and no visible
system message was created.
4. Repeat with `previous_parent_user_id` / `parent_user_id` and confirm
both regular and parent aliases are retained.
5. Repeat with `system.type: "user_changed_number"` and `system.wa_id`;
confirm the phone and phone alias update when unclaimed.
6. Pre-create the current identifier or phone on a different contact and
repeat. Confirm Chatwoot does not merge or move either identity and
records the conflict in logs.
7. Deliver the same event twice and confirm no duplicate aliases are
created.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Chatwoot Cloud accounts without TikTok access can now contact support
directly from the TikTok channel card. Accounts with the existing
`channel_tiktok` feature continue through the current connection flow.
Related: https://github.com/chatwoot/chatwoot/pull/13628
## Why
TikTok access is being reviewed manually for now. Paid plans should not
enable it automatically while this temporary process is in place.
## What this change does
- Removes TikTok from automatic paid-plan feature reconciliation.
- Keeps the channel card available as a support-chat entry point when
`channel_tiktok` is disabled.
- Hides TikTok from onboarding until the existing feature is enabled.
- Leaves self-hosted and enabled-account OAuth behavior unchanged.
## How to test
1. On Chatwoot Cloud, open Settings → Inboxes → Add inbox with
`channel_tiktok` disabled.
2. Confirm the TikTok card asks the customer to contact support.
3. Select the card and confirm the support chat opens.
4. Enable `channel_tiktok` and reload.
5. Confirm the card opens the existing TikTok connection flow.
6. Confirm TikTok is hidden from onboarding while disabled and visible
when enabled.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Paid Chatwoot Cloud accounts now receive access to WhatsApp Embedded
Signup automatically when their plan features are reconciled. This
removes the support approval step for Startups, Business, and Enterprise
plans while leaving the Hacker plan's automatic entitlement unchanged.
The installation-wide Meta inbox creation switch remains independent of
plan entitlement, so the existing incident control continues to take
precedence in the product UI.
### Things to know
- This PR does not include a data migration. Existing paid accounts
require a one-time manual backfill.
- Hacker accounts are not granted the feature automatically.
Support-approved exceptions can be recorded as manually managed and will
survive plan reconciliation.
- Existing Hacker accounts approved through a direct feature toggle must
be recorded as manually managed before their next reconciliation.
### How to test
1. Reconcile features for a Startups, Business, or Enterprise account.
2. Open Settings -> Inboxes -> Add Inbox -> WhatsApp.
3. Confirm WhatsApp Embedded Signup is available without requesting
support access.
4. Reconcile a Hacker account and confirm it does not receive Embedded
Signup automatically.
5. Add Embedded Signup as a manually managed feature for a Hacker
account, reconcile it, and confirm access remains enabled.
6. Enable `DISABLE_META_INBOX_CREATION` and confirm the existing Meta
inbox creation restriction remains active in the UI.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
The contact and Captain buttons in the conversation view now toggle
their sidebar — clicking the active button closes the panel instead of
being a no-op. Previously you could only dismiss either panel via its
internal close button or the Alt+O shortcut.
## How to test
1. Open any conversation.
2. Click the contact (person) icon in the right-edge button group →
contact sidebar opens.
3. Click it again → contact sidebar closes.
4. Click the Captain icon → copilot panel opens (closing contact if
open).
5. Click it again → copilot panel closes.
6. Press Alt+O → contact sidebar toggles (unchanged from before).
## What changed
- `SidepanelSwitch.vue`: replaced the two click handlers with toggle
logic matching the existing keyboard-shortcut helper (which is now the
single source of truth and is also bound to the contact button click).
The Captain button gets equivalent toggle behavior.
- Mutual exclusion is preserved: opening one panel still closes the
other.
Co-authored-by: Devi R <devi@chatwoot.com>
## Pull Request Description
The Help Center portal settings "Social links" section (documentation
layout) crashes for **pt_BR** users the moment a network is added. The
`pt_BR` value of
`HELP_CENTER.PORTAL_SETTINGS.LAYOUT_CONTENT.SOCIAL_LINKS.PLACEHOLDER` is
`"@usuario"`. vue-i18n treats a leading `@` as the linked-message
marker, so compiling that message throws `SyntaxError: Invalid linked
format` when the input field renders (i.e. right after a platform is
added), which unmounts the whole settings section.
English is unaffected (`PLACEHOLDER: "handle"`); pt_BR is the only
locale whose placeholder starts with `@`. This drops the leading `@`
(`"usuario"`) — the network prefix (e.g. `facebook.com/`) is already
shown next to the field, so the `@` wasn't needed.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How to reproduce
With the dashboard in Portuguese: Help Center → Settings →
"Documentation" layout → "Add social link" → click a network → the
section disappears (console: `Invalid linked format`).
## Checklist
- [x] My code follows the style guidelines of this project
- [x] New and existing unit tests pass locally with my changes
---------
Co-authored-by: Devi R <devi@chatwoot.com>
WhatsApp can send both the customer phone number and BSUID in the same
webhook. When the phone-backed conversation already exists, agents and
customers expect that conversation to continue instead of seeing a
second BSUID-backed conversation created only because the webhook also
carried an identifier.
This PR routes mixed phone+BSUID webhook payloads to the identity that
preserves existing conversation history. Phone-backed history wins when
present, BSUID-only history is preserved when that is the only existing
thread, and brand-new mixed customers still start on the phone identity.
BSUID-only webhooks continue to create or reuse the BSUID ContactInbox.
The same ordering is shared by Meta Cloud messages, message echoes, and
inbound WhatsApp calls.
Related: https://github.com/chatwoot/chatwoot/pull/15175
Related: https://github.com/chatwoot/chatwoot/pull/15546
### Things to know
- This does not repoint existing conversations or merge conflicting
ContactInbox rows.
- BSUID aliases are still synced to the same contact when a mixed
payload resolves through the phone identity.
- If the phone is absent, Chatwoot still routes through the BSUID
identity.
- This directly covers the production shape where Meta sent both `from`
and `from_user_id` for an inbound WhatsApp call.
### How to test
1. Receive a Meta Cloud WhatsApp message or inbound call webhook that
includes both `from`/`wa_id` and `from_user_id` for a contact with an
existing phone-backed conversation.
2. Confirm the new message/call is added to the existing phone-backed
conversation and no new BSUID-backed conversation is created.
3. Confirm a BSUID ContactInbox is still created for the same contact.
4. Send a BSUID-only follow-up and confirm it creates or reuses the
BSUID-backed conversation.
5. Start with a BSUID-only conversation, then receive a mixed
phone+BSUID webhook, and confirm Chatwoot keeps the existing BSUID
conversation instead of creating a new phone thread.
6. Repeat with conflicting phone and BSUID ContactInbox records and
confirm Chatwoot does not merge or repoint either contact.
### What changed
- Added a shared WhatsApp source-ID orderer for message and call
routing.
- Updated Meta Cloud message and echo routing to prefer existing
conversation continuity.
- Updated inbound WhatsApp call identity ordering to use the same rule.
- Updated specs for mixed phone+BSUID, BSUID-only, existing phone
history, existing BSUID-only history, and conflict safety.
Validation:
```bash
bundle exec rspec spec/services/whatsapp/incoming_message_whatsapp_cloud_service_spec.rb spec/enterprise/services/whatsapp/inbound_call_identity_builder_spec.rb spec/enterprise/services/whatsapp/incoming_call_service_spec.rb spec/enterprise/services/voice/inbound_call_builder_spec.rb
bundle exec rubocop --cache false app/services/whatsapp/identity_source_id_orderer.rb app/services/whatsapp/incoming_message_identifier_helper.rb enterprise/app/services/whatsapp/inbound_call_identity_builder.rb spec/services/whatsapp/incoming_message_whatsapp_cloud_service_spec.rb spec/enterprise/services/whatsapp/inbound_call_identity_builder_spec.rb spec/enterprise/services/whatsapp/incoming_call_service_spec.rb spec/enterprise/services/voice/inbound_call_builder_spec.rb
```
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Facebook and X inboxes now keep the editable inbox name as the visible
label without appending opaque provider IDs in the sidebar or inbox
settings. This follows the same behavior introduced for Instagram and
TikTok in [#15611](https://github.com/chatwoot/chatwoot/pull/15611).
## Closes
[CW-7245](https://linear.app/chatwoot/issue/CW-7245/show-phone-numberchannel-identifier-consistently-in-inbox-ui)
## How to reproduce
1. Open a workspace with connected Facebook and X inboxes.
2. Check the Channels section in the conversation sidebar.
3. Open Settings → Inboxes, then open either inbox settings page.
4. On `develop`, the inbox name is followed by an opaque page or profile
ID. On this branch, only the inbox name remains visible.
## What changed
- Stop resolving Facebook page IDs and X profile IDs as display
identifiers.
- Keep both IDs in the inbox payload for routing and provider
operations.
- Preserve identifier display and search behavior for every other
supported channel.
Adds a guided manual setup flow for WhatsApp inboxes so administrators
can prepare their Meta app, enter the required IDs and permanent token,
review the number returned by Meta, create the inbox, and verify webhook
setup without relying on Embedded Signup.
Fixes
https://linear.app/chatwoot/issue/CW-7634/add-guided-whatsapp-manual-inbox-setup
**Preview**
<img width="2672" height="1472" alt="CleanShot 2026-07-20 at 14 24
44@2x"
src="https://github.com/user-attachments/assets/f9912939-0899-43dc-a442-63d0d10439f1"
/>
## Things to know
- Meta App ID and App Secret are not requested or stored. Payload
signature verification remains unchanged for customer-owned manual apps.
- The committed walkthrough media is neutral placeholder content.
Replace it with the final sanitized videos and posters before merge.
## How to test
1. Start creating a WhatsApp inbox and choose Manual setup.
2. Complete the Meta app, phone and WABA ID, and permanent-token steps.
3. Confirm Chatwoot retrieves the verified name and phone number, then
create the inbox.
4. Verify the webhook URL and individual connection checks are
displayed.
5. Confirm you can retry webhook setup or continue to agent assignment
while a check is pending.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
# Pull Request Template
## Description
This PR fixes the Templates page using different "Know more" link copy
and a hardcoded chatwoot.com URL, which also remained visible on
custom-branded installs. It now uses the shared settings header link,
matching the copy used across the product ("Learn more about WhatsApp
templates") and automatically hiding the link on custom-branded
instances.
It also fixes the "Last sync attempt" line appearing between the
description and the link. It now renders below the link as a secondary
line.
Fixes
https://linear.app/chatwoot/issue/CW-8056/remove-hyperlink-from-templates-page-header
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Screenshots
**Before**
<img width="1249" height="338" alt="image"
src="https://github.com/user-attachments/assets/23bc3b21-07c8-45c4-843e-d64928a5171b"
/>
**After**
<img width="1249" height="338" alt="image"
src="https://github.com/user-attachments/assets/8c5878f9-44c2-4fe4-837e-c7b57bb26aec"
/>
## 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
## Description
This PR fixes Telegram callback query handling for standard and Business
chats.
### What was wrong
- Inline button callbacks were not acknowledged, so Telegram clients
could keep showing a loading spinner.
- Business callbacks could be attributed to the wrong contact or
classified with the wrong message direction.
- Callback queries from unsupported group chats could bypass the
private-chat guard.
### What changed
- Acknowledge callbacks immediately in the webhook JSON response using
Telegram's `answerCallbackQuery` method, before background processing
starts.
- Treat `callback_query.from` as the user who pressed the button and
compare it with `message.chat.id` to distinguish customer clicks from
Business-account-owner clicks.
- Preserve the customer contact and conversation routing for outgoing
Business callbacks.
- Validate callback payload shape and ignore unsupported inline-mode,
game, malformed, group, and supergroup callbacks during message
ingestion while still acknowledging them at the webhook boundary.
### Tests
- Standard callback ingestion and response-only acknowledgement.
- Incoming customer and outgoing Business-account-owner callback
classification.
- Customer contact attributes and conversation routing.
- Group, supergroup, inline-mode, game, mismatched-participant, and
malformed payload filtering.
- Webhook parameter forwarding and immediate `answerCallbackQuery`
response.
Fixes#13677
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update required
---------
Co-authored-by: Artur Saakyan <artur@Arturs-MacBook-Air-2.local>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Sony Mathew <ynos1234@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
## Description
Twilio and WhatsApp Cloud API send multiple webhook callbacks for
message status updates (queued → sent → delivered → read), but delivery
order is not guaranteed. When webhooks arrive out of order, message
status can regress (e.g., `delivered` → `sent`), causing incorrect
status display and potentially breaking downstream integrations that
rely on status accuracy.
**Root cause**: `Twilio::DeliveryStatusService` and
`Whatsapp::IncomingMessageBaseService` were directly assigning status
without validating if the transition was a regression. The existing
`Messages::StatusUpdateService` had partial validation but wasn't being
used.
**Solution**:
- Enhanced `Messages::StatusUpdateService` to enforce forward-only
status transitions based on the Message status enum priority (`sent=0 →
delivered=1 → read=2`)
- Refactored both Twilio and WhatsApp services to use
`StatusUpdateService` instead of direct assignment
- `failed` status is allowed from any state (errors can happen at any
point)
Fixes N/A (internal bug report from production logs)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
**Unit tests added:**
- `spec/services/messages/status_update_service_spec.rb` - Tests for
forward transitions, regression prevention, and failed state handling
- `spec/services/twilio/delivery_status_service_spec.rb` - Out-of-order
webhook scenarios for Twilio
- `spec/services/whatsapp/incoming_message_service_spec.rb` -
Out-of-order webhook scenarios for WhatsApp
**Manual verification:**
1. Identified the bug via production logs showing `delivered → sent`
regression
2. Traced the timeline: message 94393 received `delivered` at 19:31:52,
then `sent` at 19:31:53 (~800ms late)
3. Confirmed the fix prevents regression by checking `new_priority >=
current_priority`
**To reproduce the original bug:**
```ruby
# Rails console - simulate out-of-order webhook
message = Message.find(id)
message.update!(status: 'delivered')
# Late "sent" webhook arrives
Twilio::DeliveryStatusService.new(params: { MessageSid: message.source_id, MessageStatus: 'sent', ... }).perform
# Before fix: status = 'sent' (wrong)
# After fix: status = 'delivered' (correct)
```
## 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: Pedro Lis French <pedrolis@lahaus.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
> **The direction of this PR changed mid-flight.** The first version
repointed the existing conversation onto the BSUID `ContactInbox`. After
the discussion in chatwoot/chatwoot#14931 and the production report in
chatwoot/chatwoot#15359, Chatwoot decided **not** to re-anchor the phone
conversation. This version implements the agreed direction instead. The
Linear slug below still reads "repoint" for historical reasons.
When a WhatsApp Cloud contact starts messaging under a BSUID, Chatwoot
resolves whichever `ContactInbox` already exists — normally the
phone-backed one — and, since chatwoot/chatwoot#15098, looks for a
conversation across the whole contact. Two problems follow from that:
the first BSUID payload stays on the stale phone identity, and a contact
that was merged in the dashboard can have a reply answered through a
different person's `source_id`.
This change makes the business scoped user id the identity a Cloud
payload lands on, and scopes conversation reuse to the `ContactInbox`
that resolved the message. The phone conversation is left untouched and
stays reachable under **Previous conversations**.
Fixes chatwoot/chatwoot#14931<br>Fixes chatwoot/chatwoot#15359
Related: chatwoot/chatwoot#14931 <br>Related: chatwoot/chatwoot#15098
<br>Related: chatwoot/chatwoot#15150 <br>Related:
chatwoot/chatwoot#15359
## What changed
**Identifier ordering — parent BSUID, regular BSUID, phone.** On
`whatsapp_cloud` the parent identifier leads. Meta documents it as
addressable through `recipient` for messages and calls alike, and an
event carrying both identifiers and a later parent-only event describe
the same sender — leading with the parent keeps them on one
`ContactInbox` instead of anchoring each on a row of its own. This also
matches the precedence `Webhooks::WhatsappEventsJob` already uses when
it picks the mutex key. Every other provider keeps the previous order,
phone first.
Applied to the three entry points so they resolve the same row:
*
`Whatsapp::IncomingMessageIdentifierHelper#incoming_message_source_ids`
*
`Whatsapp::IncomingMessageIdentifierHelper#outgoing_message_source_ids`
(echoes)
* `Whatsapp::InboundCallIdentityBuilder`
`ContactInboxSourceIdResolver` **— new opt-in**
`prefer_first_source_id:`**,** default `false`. When a caller opts in
and the existing row is not the preferred identifier, the `ContactInbox`
for the preferred identifier is created on the same contact, rescuing
`RecordNotUnique`. Nothing is repointed or destroyed. The insert runs in
a savepoint, because inbound calls resolve identity inside an outer
transaction and on PostgreSQL a unique violation would otherwise abort
it. `Twilio::WhatsappIdentifierHelper` does not opt in and is unchanged.
**Conversation lookup scoped to the exact** `ContactInbox`**.**
`Whatsapp::IncomingMessageBaseService#set_conversation` uses
`@contact_inbox.conversations` instead of `@contact.conversations`, only
where identifiers are addressable.
**WhatsApp calls now follow the same identity behaviour.**
`Voice::InboundCallBuilder` no longer looks up conversations
contact-wide for WhatsApp, and no longer repoints a reused conversation
— both could route a call to another identity after a dashboard contact
merge. Twilio voice keeps its existing behaviour.
## How to reproduce
1. On a Meta Cloud inbox, receive a message carrying a phone number and
a business scoped user id. Chatwoot creates the contact and the
conversation against the phone-backed `ContactInbox`.
2. Receive a later message from the same contact carrying only the
identifier.
**Before:** the conversation is reused but stays attached to the phone
identity, so an agent reply can be addressed to a number that is no
longer reachable.
**After:** the payload anchors on the business scoped user id — the
parent one when present — a conversation opens on that `ContactInbox`,
and the phone conversation remains unchanged under **Previous
conversations**.
## How to test
* Send a message carrying phone, regular and parent identifiers on a
Meta Cloud inbox. Confirm the conversation anchors on the **parent**
`ContactInbox`, and that the phone conversation, if one existed, is
intact under *Previous conversations*.
* Follow it with a **parent-only** payload and confirm it reuses that
same conversation rather than opening another.
* Reply from the conversation and confirm it goes out through the
`recipient` path from chatwoot/chatwoot#15150.
* Place an inbound WhatsApp call from the same contact and confirm it
lands on the same `ContactInbox` a message would, without repointing
anything.
* Repeat on a `default` (360Dialog) inbox and confirm a BSUID-only
follow-up **keeps the single existing conversation** — the identifier is
not addressable there.
* Confirm ordinary phone-backed Cloud traffic, Twilio conversations and
Twilio voice are unchanged.
## Behaviour change worth a line in the release notes
A contact whose **first** message already carries the identifier is
unaffected: it is created on that `ContactInbox` and nothing splits.
A contact that already had a phone-backed conversation gains one extra
conversation, once. Because that is a real new conversation:
* SLA and first-response timers restart
* assignee and team are not inherited
* `conversation_created` automations fire again
* conversation-level `custom_attributes` do not carry over
* integrations that key state on `conversation_id` lose the thread
None of these are defects — they follow directly from "new identity, new
conversation". They are listed because they are what operators notice
first.
## Provider note
The ordering and the scoping both sit behind `addressable_identifiers?`
(`provider == 'whatsapp_cloud'`).
`Whatsapp::Providers::WhatsappCloudService` is the only provider that
builds `recipient_params`; `default` (360Dialog) always sends `to:` and
cannot address one of these identifiers, so anchoring a thread there
would create a conversation that can never be replied to — Meta answers
`200` and drops the message, the failure mode chatwoot/chatwoot#15150
fixed. A spec pins this.
## Out of scope
This PR does not implement BSUID rotation, `user_id_update`, or campaign
addressing.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
WhatsApp call recordings made from the dashboard are captured by the
browser's MediaRecorder, which produces a WebM file whose duration
header is never filled in. The file plays on the web (browsers buffer
the whole file and infer the length), but on the mobile apps the missing
duration breaks playback — on Android the seek slider never moves and
playback stops the moment it starts, and the format compounds a separate
iOS decode limitation. Recordings are now remuxed to OGG/Opus in the
browser before upload, so the file carries an exact, standards-based
duration that mobile players read natively — and matches the format
voice notes already use.
## Screenshots
After conversion: (Audio playable)
<img width="1071" height="1440" alt="IMG_6834"
src="https://github.com/user-attachments/assets/b951d124-3da5-4720-beb3-e89a439a297c"
/>
Before conversion state: (Audio not playable)
<img width="1064" height="1594" alt="IMG_6835"
src="https://github.com/user-attachments/assets/0984fa32-ba90-4555-b37d-176d5a8450a2"
/>
## Closes
-
[CW-7926](https://linear.app/chatwoot/issue/CW-7926/whatsapp-call-audio-is-not-working-on-mobile-application)
## How to reproduce
1. On a WhatsApp inbox with calling enabled, make a call from the
dashboard and hang up.
2. Open the resulting conversation in the Android app and play the call
recording: the slider doesn't move and playback ends immediately. On iOS
the recording doesn't play at all.
3. Inspect the attachment: it is `call-recording.webm` with no duration
in the container.
## What changed
- `stopRecorderAndUpload` in `useWhatsappCallSession.js` now passes the
recorded blob through the existing `remuxWebmToOgg` utility (the same
in-repo, dependency-free remuxer voice notes use) and uploads it as
`call-recording.ogg`.
- This is a pure container rewrite — the Opus audio bytes are copied
unchanged, so there is no re-encode cost (milliseconds at hangup, in the
agent's browser). OGG granule positions give the file an exact duration
readable without downloading the whole file.
- If remuxing fails for any reason, the raw WebM is uploaded under the
old name, preserving today's behavior; OGG input (Firefox records real
OGG) passes through untouched.
- No backend changes — the upload endpoint and attachment handling are
format-agnostic.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Makes connected Captain assistants explicit conversation owners through
the unified AI-assignee association. Builds on the merged ownership
foundation in [#15419](https://github.com/chatwoot/chatwoot/pull/15419).
## Closes
-
https://linear.app/chatwoot/issue/CW-7451/add-explicit-captain-ownership-backend
## Why
Captain-handled conversations currently rely on `pending` plus inbox
configuration to imply ownership. Explicit ownership lets assignment,
takeover, live updates, filters, and future UI controls distinguish
Captain-handled conversations from ordinary pending conversations.
## What this change does
- Reconciles AgentBot ownership changed during the discriminator rollout
before typed reads become authoritative.
- Assigns eligible new Captain-handled conversations to the connected
assistant while leaving out-of-audience conversations open.
- Supports assigning the connected Captain through the existing
conversation assignment API.
- Clears human ownership and moves Captain-assigned conversations to
pending.
- Clears Captain ownership and opens the conversation when a human takes
over through assignment or a public reply.
- Returns Captain as the typed assignee in assignment, conversation, and
live-update payloads.
- Excludes AgentBot- and Captain-owned conversations from human-assignee
ID filters.
- Keeps AgentBot and Captain ownership isolated when their numeric IDs
overlap.
- Preloads typed AI owners when rendering conversation lists.
- Omits stale Captain ownership metadata safely when the referenced
assistant no longer exists.
## Review guide
1. Typed AI-owner reconciliation, authoritative reads, and preloading.
2. Captain assignment and conversation lifecycle.
3. API serialization and live assignment updates.
4. Human takeover and client-side assignee filtering.
## Validation
Assign the connected Captain to an open, resolved, or snoozed
conversation and confirm it becomes pending with Captain shown as owner.
Assign a human or send a public human reply and confirm Captain
ownership clears and the conversation opens. Apply human-assignee equal
and not-equal filters and confirm Captain-owned conversations are
excluded. Attempt to assign a Captain that is not connected to the inbox
and confirm ownership does not change.
Agent bots can now fetch team-assigned conversations without the
response failing while rendering team membership metadata.
## Closes
https://linear.app/chatwoot/issue/CW-8042/actionviewtemplateerror-undefined-method-teams-for-an-instance-of
## Why
Agent-bot access tokens are allowed to fetch conversation details. When
the conversation had a team, the shared team serializer assumed the
authenticated resource was always a user and called `teams` on the agent
bot, returning a 500 response.
## What this change does
- Reports `is_member` only for authenticated users.
- Returns `is_member: false` for agent-bot requests.
- Covers fetching a team-assigned conversation with an agent-bot token.
## How to test
1. Assign a conversation to a team.
2. Fetch the conversation details using an agent-bot access token.
3. Confirm the request succeeds and the team metadata includes
`is_member: false`.
Instagram and TikTok inboxes now keep their provider account name as the
visible label without appending opaque provider IDs in the sidebar or
inbox settings. This is a follow-up to
[#15527](https://github.com/chatwoot/chatwoot/pull/15527) and
[#15528](https://github.com/chatwoot/chatwoot/pull/15528).
## Closes
[CW-7245](https://linear.app/chatwoot/issue/CW-7245/show-phone-numberchannel-identifier-consistently-in-inbox-ui)
## How to reproduce
1. Open a workspace with connected Instagram and TikTok inboxes.
2. Check the Channels section in the conversation sidebar.
3. Open Settings → Inboxes, then open either inbox settings page.
4. On `develop`, the provider account name is followed by a large opaque
Instagram or TikTok ID. On this branch, the account name remains visible
without the opaque ID.
## What changed
- Stop resolving Instagram account IDs and TikTok business IDs as
display identifiers.
- Keep both IDs in the inbox payload for matching, reauthorization, and
provider operations.
- Preserve identifier display and search behavior for every other
supported channel.
## Description
Adds Slack signing-secret verification to the Slack events webhook
(`POST /api/v1/integrations/webhooks`) so inbound events are confirmed
to originate from Slack before they are processed. The
`X-Slack-Signature` HMAC is checked against the request body with a
timestamp-freshness window.
Verification only runs when `SLACK_SIGNING_SECRET` is configured; when
it is not set, requests are processed as before so existing
installations are not affected. **To enable verification, set
`SLACK_SIGNING_SECRET`** (via env or the super-admin config) to the
Slack app's signing secret.
Ref https://linear.app/chatwoot/issue/CW-7465
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## Description
Inbound SMS media is downloaded from URLs contained in the webhook
payload. For hosts other than the provider, this change routes the
download through `SafeFetch`, which resolves the host and rejects
private/internal addresses (revalidating each redirect hop).
Provider-hosted media continues to be fetched directly.
Stacked on #15463 (same method); please review/merge that first.
Ref https://linear.app/chatwoot/issue/CW-7469
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## Summary
Delayed automations can now include additional conditions joined with
`AND`, including a Pending status condition. The form keeps these
conditions inside the wait section and uses the existing automation
controls.
Delayed jobs recheck all saved conditions before running an action. The
action is skipped when a condition no longer matches.
Saved delayed rules are not normalized merely by opening the editor.
API-created operators such as `inbox_id not_equal_to` remain unchanged
until an administrator edits a wait control.
The Captain timer conflict warning is split into the stacked follow-up
#15482.
## Validation
- 39 focused frontend tests passed.
- 75 focused backend examples passed.
- ESLint, Prettier, RuboCop, JSON parsing, and `git diff --check`
passed.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
## Description
Inbound SMS media is downloaded from URLs contained in the webhook
payload. This change attaches the channel's provider credentials only
for media on the provider's own host (derived from the channel's API
base path), and does not follow redirects on that request. Media on
other hosts is downloaded without credentials.
Ref https://linear.app/chatwoot/issue/CW-7469
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added specs in `spec/services/sms/incoming_message_service_spec.rb`
covering credential handling by media host and redirect behaviour. Full
spec file green (9 examples, 0 failures), rubocop clean.
Greeting messages currently fire when an `activity` message (status
change, label added, assignee change, resolve, etc.) is created on a
conversation that has a prior incoming message but no outgoing message
yet. The agent appears to send a greeting for an action they didn't
take.
Closes#3657
## What changed
`should_send_greeting?` in
`app/services/message_templates/hook_execution_service.rb` did not check
whether the triggering message is incoming. The existing guards
(`campaign`, `tweet`) and `first_message_from_contact?` were not enough:
an `activity` message on a conversation that has never had an outgoing
reply still satisfied `first_message_from_contact?`, so the greeting
fired.
The fix adds one line:
```ruby
return false unless message.incoming?
```
This mirrors the existing pattern in
`should_send_out_of_office_message?` in the same file, which already
guards on `message.incoming?` for the same reason.
## Why a single guard, not a refactor
`first_message_from_contact?` is a property of the conversation as a
whole, not of the triggering message. Pushing the incoming check into
that helper would conflate two concepts. Adding the guard at the
`should_send_greeting?` level keeps each method's responsibility clean
and matches the pattern already used by the sibling
`should_send_out_of_office_message?` method.
## Alternatives considered
- **Guard at the top of `perform`.** Would also affect `EmailCollect`
and `OutOfOffice`, broadening scope. Rejected — `OutOfOffice` already
has its own incoming guard, and `EmailCollect` has different semantics
around web-widget contact email collection.
- **Tighten `first_message_from_contact?` to also check
`message.incoming?`.** Reasonable but conflates message-level and
conversation-level logic.
## Tests
Two new specs in
`spec/services/message_templates/hook_execution_service_spec.rb`
covering the missing cases:
1. An activity message on a conversation with a prior incoming reply
does not retrigger the greeting.
2. An outgoing agent message also does not retrigger the greeting.
Both tests construct the bug's preconditions explicitly: greeting is
enabled *after* the prior incoming message exists, simulating the
realistic scenario where greetings were toggled on after the
conversation was already underway. Without that detail the bug would be
masked by the real `Greeting` service running during the incoming
message's `after_commit` and creating a `template` message.
The first new test fails on `develop` and passes with the fix —
confirming the regression coverage.
## How to verify
```bash
bundle exec rspec spec/services/message_templates/hook_execution_service_spec.rb
```
All 16 specs (14 existing + 2 new) pass.
Manually:
1. Enable greeting on an inbox in a fresh local Chatwoot
2. Open an existing conversation with prior incoming messages and zero
outgoing replies
3. Trigger any activity (resolve, label, assignee change)
4. Before this change: greeting message appears in the conversation
immediately after the activity. After this change: no greeting fires.
## Notes
- Comment wording on the new guard line matches the existing
`should_send_out_of_office_message?` line for consistency, even though
`incoming?` filters more than just "outbound" (it also excludes
`activity` and `template` messages).
- This issue was filed by a maintainer (`pranavrajs`) in Dec 2021 with
severity 4 — included for context, not because the original report needs
anything more than what's here.
On conversations that were auto-resolved (the 10-minute inactivity
flow), a customer's CSAT rating showed up in CSAT reports but the
survey/rating never appeared in the conversation itself. This makes
agents unable to see feedback that reports are counting, and reads like
a reporting bug. This PR makes the survey render in the conversation
again.
Fixes
https://linear.app/chatwoot/issue/CW-7520/csat-rating-shows-in-reports-but-not-in-the-conversation-survey-bubble
## How to reproduce
1. On a web-widget inbox with CSAT enabled, let a conversation
auto-resolve via the inactivity automation (so the `input_csat` survey
and the "resolved by system" activity note are created in the same
second).
2. Have the customer submit a rating.
3. Open the conversation in the dashboard: the CSAT star bubble is
missing, even though the rating appears in the CSAT report.
Appending any newer message (e.g. reopening and re-resolving the
conversation) makes the rating reappear — which pointed straight at the
root cause.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Earlier, every reply posted there was delivered to the customer. Teams
that use the channel for alerts had to remember a `note:` prefix on
every message, and a single slip reached the customer.
The integration now has a thread behavior setting. 2-way sync keeps the
current behavior and stays the default, so existing installs are
untouched. Alerts only makes the integration one way: conversations are
still pushed to Slack, but nothing posted in the thread is synced back,
leaving the thread free for internal discussion.
Inbox names now include their channel's public identifier everywhere
agents and administrators choose or configure an inbox, making similarly
named phone, email, website, and social channels easy to distinguish.
This PR is stacked on
[#15527](https://github.com/chatwoot/chatwoot/pull/15527). Review and
merge that contract PR first; this PR then contains only the visible UI
and search changes.
## Closes
[CW-7245](https://linear.app/chatwoot/issue/CW-7245/show-phone-numberchannel-identifier-consistently-in-inbox-ui)
## What changed
- Show `Inbox name · identifier` in compact sidebar channel rows without
changing their height or displacing unread/reauthorization badges.
- Show `Channel type · identifier` in the inbox settings list and use
the same identifier in the settings detail header.
- Search inbox settings by full public identifier in addition to inbox
name and channel type.
- Truncate long values, expose the full value on hover, and isolate
identifier direction for mixed RTL/LTR content.
- Preserve the existing UI whenever a channel has no identifier.
Implementation plan and channel mockups: [CW-7245 design
document](https://linear.app/chatwoot/document/cw-7245-channel-identifiers-in-inbox-ui-414ae118c964).
## How to test
1. Open the Channels section in the conversation sidebar and compare two
similarly named inboxes across phone, email, website, or social
channels.
2. Confirm each supported row shows its identifier on the same line and
unread/reauthorization badges remain visible.
3. Open Settings → Inboxes and confirm the channel type and identifier
appear beneath each inbox name.
4. Search by a complete phone number, email address, URL, social ID,
Telegram handle, LINE ID, or API inbox identifier.
5. Open an inbox's settings and confirm its header uses the same
identifier.
6. Check an inbox with a missing identifier and confirm the original
name-only/channel-only presentation remains.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
The empty participant message no longer renders with both an exclamation
point and a trailing period.
Closes: [Crowdin editor
issue](https://chatwoot.crowdin.com/editor/2/all/en-it/24?view=comfortable&filter=basic&value=17)
## Why
The English source string ended with `!.`, which produced incorrect
punctuation and triggered a Crowdin source-string issue.
## What this change does
Removes the redundant trailing period from the no-participants message.
## Validation
Open a conversation with no participating agents and confirm the empty
state reads `No one is participating!`.
## Description
Administrators can now enable or disable Captain scenarios and custom
tools directly from their cards, while agents retain read-only
visibility of each item's status. Disabled records remain available for
management, but are excluded from Captain prompts, handoff agents,
editor tool selection, and runtime execution as appropriate.
## Closes
-
[CW-7770](https://linear.app/chatwoot/issue/CW-7770/enable-or-disable-scenario-and-tools)
## What changed
- Return enabled and disabled scenarios from the management API so
disabled scenarios can be searched, edited, deleted, and re-enabled.
- Add localized status labels and administrator-only inline switches for
scenarios and custom tools, with per-record saving states and success or
failure feedback.
- Keep disabled custom tools valid as saved scenario references while
excluding them from runtime-enabled tool collections.
- Cover management visibility, toggle persistence, and disabled
custom-tool reference validation in request and model specs.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How to test
1. As an administrator, open Captain scenarios and disable a scenario.
Confirm its status changes, remains visible, and stays disabled after
reload.
2. Re-enable the scenario and confirm it becomes available to Captain
again.
3. Open Captain custom tools and disable a custom tool referenced by a
scenario. Confirm the scenario remains editable and enabled while the
tool disappears from the scenario editor picker and Captain runtime
toolset.
4. Re-enable the custom tool and confirm it becomes available again.
5. Sign in as an agent and confirm scenario and custom-tool statuses are
visible without interactive switches.
6. Simulate a failed update request and confirm the previous state is
preserved with an error alert.
## 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 the feature works
- [x] New and existing focused tests pass locally with my changes
All eligible paid plans now enable Captain V2 during plan
reconciliation. The Hacker or configured default plan still disables V2.
Captain V1 runtime and the captain_integration_v2 feature flag remain in
place.
## Closes
No linked issue.
## How to test
1. Reconcile an existing or new cloud account on a Startups, Business,
or Enterprise plan.
2. Confirm that captain_integration and captain_integration_v2 are
enabled.
3. Reconcile an account on the Hacker plan.
4. Confirm that captain_integration_v2 is disabled.
## What changed
1. Removed the transitional captain_v2_default_eligible account
attribute and its new account write.
2. Enabled captain_integration_v2 for every non-default paid plan
without checking account attributes.
3. Kept the default plan and self-hosted Enterprise behavior unchanged.
4. Updated the focused account and billing reconciliation specs.
Inbox payloads now expose the safe public identifiers needed to
distinguish TikTok, X, and LINE inboxes, and the dashboard has one
canonical helper for resolving identifiers across every supported
channel.
## Closes
Part of
[CW-7245](https://linear.app/chatwoot/issue/CW-7245/show-phone-numberchannel-identifier-consistently-in-inbox-ui).
## What changed
- Expose TikTok `business_id`, X `profile_id`, and LINE
`line_channel_id` in the application inbox payload.
- Add a single identifier mapping for website, email, WhatsApp, Twilio,
SMS, Facebook, Instagram, TikTok, X, Telegram, LINE, and API inboxes.
- Normalize display-only Twilio WhatsApp and Telegram prefixes without
changing stored values.
- Document the safe identifier fields in the inbox API schema.
Implementation plan and channel mockups: [CW-7245 design
document](https://linear.app/chatwoot/document/cw-7245-channel-identifiers-in-inbox-ui-414ae118c964).
## How to test
1. Open inboxes for several channel types as an assigned agent.
2. Confirm the inbox API returns each channel's public identifier.
3. Confirm Twilio WhatsApp numbers omit the `whatsapp:` display prefix
and Twilio SMS falls back to its messaging service SID when no phone
number is configured.
4. Confirm missing identifiers resolve to an empty value and do not
expose channel credentials.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
The WhatsApp Account Health page currently exposes provider-oriented
values without enough context for customers to understand what they
mean. In particular, `AVAILABLE_WITHOUT_REVIEW` can sound like an
approved state even though Meta treats the display-name string and its
approval status separately, and starts display-name verification only
after the business reaches a higher messaging limit.
Tech Provider numbers also have customer-facing profile information in
Meta that is not visible in Chatwoot. Showing that read-only profile
alongside phone health gives admins one place to verify what customers
can see, reduces dependency on external diagnostic tools, and provides
better context before opening WhatsApp Manager.
Related:
https://linear.app/chatwoot/issue/PLA-199/manage-whatsapp-business-profile-fields-for-tech-provider-numbers
### What changed
- Fetch the current WhatsApp business profile from Meta together with
phone-number health.
- Show the profile image, About text, description, address, email, and
websites in Account Health.
- Hide the generic `OTHER` business category because it does not add
useful context.
- Present display-name states in customer language and explain what each
review state means.
- Rename the messaging tier to “Business messaging limit” and explain
its business-portfolio scope.
- Keep the profile lookup optional so a profile API failure does not
hide the existing phone and business-account health data.
### Things to know
- This is a read-only view; it does not edit the Meta business profile.
- Profile data is fetched when Account Health loads and is not stored in
`phone_number_health`.
- The profile picture URL is used to render the avatar but is not
exposed as raw text.
- Existing WhatsApp health persistence, transition warnings, and error
handling remain unchanged.
### How to test
1. Open **Settings → Inboxes** and select a direct WhatsApp Cloud API
inbox.
2. Open **Account Health** and confirm the Meta business profile appears
above the phone-number section.
3. Confirm missing optional profile values show **Not available** and a
profile lookup failure still leaves the core health sections usable.
4. For `AVAILABLE_WITHOUT_REVIEW`, confirm the page shows **Not reviewed
yet** with the explanation about Meta’s review process.
5. Confirm a profile category of `OTHER` is not shown, while specific
categories remain visible.
6. Confirm the messaging limit is labelled **Business messaging limit**
with its scope explained.
### Screenshots
Business profile details:
<img width="2530" height="1878" alt="CleanShot 2026-08-21 at 13 19
14@2x"
src="https://github.com/user-attachments/assets/5f29d9c8-5b82-4713-950d-f9112a79c123"
/>
Display-name guidance and health capacity:
<img width="2576" height="1860" alt="CleanShot 2026-08-21 at 13 19
38@2x"
src="https://github.com/user-attachments/assets/93866424-1a2a-46de-a8ec-0be937a57bc3"
/>
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Automation rules with a `content` condition do not match messages that
contain commas. The condition value is split on `,` before being sent to
the API, so a rule configured for `hello, world` is stored as two
separate tokens and never matches the original message.
Closes#13785
## What changed
`generateValues` in
`app/javascript/dashboard/helper/filterQueryGenerator.js` had a
special-case branch:
```js
if (item.attribute_key === 'content') {
const values = item.values || '';
return values.split(',');
}
```
This was already flagged with a `FIX ME: Make this generic option
instead of using the key directly here` comment in `generatePayload`.
The fix removes the branch entirely. String values already fall through
to the existing `return [item.values]` path, which produces the correct
single-element array. Arrays continue to flow through `setArrayValues`.
The stale `FIX ME` comment is also removed.
## Before / After
For an automation rule with content `hello, world`:
**Before**
```json
{ "values": ["hello", " world"] }
```
**After**
```json
{ "values": ["hello, world"] }
```
## Alternatives considered
- **Keep the special-case but escape commas (e.g. `\,`).** Rejected —
adds UX complexity (users would need to learn an escape syntax) and
there is no UI affordance for multi-value content conditions in the
first place. The split was solving a problem that doesn't actually exist
for this attribute.
- **Add server-side normalisation in
`AutomationRules::ConditionsFilterService`.** Considered as
defense-in-depth, but rejected to keep this PR scoped. The frontend is
the source of the malformed payload; the backend already (correctly)
expects an array. Adding server-side coercion here would conflate two
concerns.
## Cross-stack check
I read `app/services/automation_rules/conditions_filter_service.rb` and
`app/services/automation_rules/condition_validation_service.rb` to
confirm the backend contract. The service treats `values` as an array
throughout (e.g. `query_hash['values'].first` for label conditions,
array operators in SQL building), so producing a correct array on the
frontend is sufficient — no Rails change is needed.
## How to verify
Automated:
```bash
pnpm test app/javascript/dashboard/helper/specs/filterQueryGenerator.spec.js
```
All tests should pass, including the two new cases covering content with
and without commas.
Manual:
1. Create an automation rule: condition `Message → Content → equal_to →
hello, world`, action `Send Email`
2. Send an incoming message with body `hello, world`
3. Confirm the rule fires (before this change it would not, because the
stored condition was `["hello", " world"]`)
## Notes
- The same helper is consumed by `ChatList`, `ContactsIndex`, segment
exports and conversation getters. The fix transparently improves comma
handling in all of these — no consumer code changes were needed.
- No translation strings touched.
---------
Co-authored-by: Shivam Mishra <scm.mymail@gmail.com>
Meta deprecated part of the existing Instagram Business Login flow,
which could prevent customers from reaching the login page even when
their app configuration was correct. This hotfix updates the
authorization flow to use Metas current endpoint and reauthentication
parameter.
The callback URL, requested permissions, and token exchange remain
unchanged.
### How to reproduce
1. Configure an Instagram app with valid credentials and callback URL.
2. Start the Instagram inbox connection flow.
3. Observe that the previous authorization flow can show a page
unavailable error before login.
### How to test
1. As an administrator, start connecting a new Instagram inbox.
2. Confirm the browser opens the current Instagram Business Login page.
3. Complete authorization and confirm the callback returns to Chatwoot
successfully.
### Things to know
This is limited to the Instagram authorization endpoint and
reauthentication parameter.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Customers building on the API channel could not find how to push message
read status into Chatwoot. Two endpoints are involved, one was entirely
missing from the API reference and one was undocumented in what it
actually does:
- `PATCH
/api/v1/accounts/{account_id}/conversations/{conversation_id}/messages/{message_id}`
accepts `status` (`sent`/`delivered`/`read`/`failed`, plus
`external_error` for failures) and is restricted to API channel inboxes.
The path previously documented only DELETE; this adds the PATCH
operation.
- The public `update_last_seen` endpoint marks agent messages sent
before the contact's last seen time as read, but its description only
mentioned updating the timestamp, so searching the docs for read
receipts found nothing. The summary and description now state the
read-receipt behavior.
Derived swagger files regenerated via `rake swagger:build`.
Fixes https://linear.app/chatwoot/issue/CW-7937
## Description
sent_from_chatwoot_app? compared the echo payload's app_id (a String
from the JSON webhook) against GlobalConfigService's FB_APP_ID cast with
`.to_i` (an Integer). String == Integer is always false in Ruby, so the
check always failed regardless of the actual app_id.
As a result, every Facebook Messenger echo of an agent's own Chatwoot
reply was treated as "agent replied from the native FB app" and
MessageCreator created a second, duplicate message row for it.
Compare app_id and FB_APP_ID as strings instead, and drop the two stale
TODO comments now that the behavior is confirmed and covered by a spec.
## 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
---------
Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com>
Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
Merging two contacts doesn't move the mergee's calls over to the base
contact. Conversations, messages, notes and contact inboxes all get
reassigned, but calls were missed when the Call model was added later. A
call requires a contact, so once the mergee is deleted its calls point
at a contact that no longer exists, and the account Calls dashboard 500s
as soon as it pages to one of them.
This adds the missing reassignment, plus a couple of guards so calls
that were already orphaned before this fix don't blow up either.
## Closes
Closes#15087
## How to reproduce
1. Create two contacts and add a call to the second one.
2. Merge the second contact into the first.
3. Open the Calls dashboard and page to where that call shows up.
You hit a 500 from `_call.json.jbuilder` (`undefined method 'id' for
nil`). Fixing only the backend then moves the crash to
`CallListItem.vue`, which reads `call.contact.avatar` without a null
check.
## What changed
- `ContactMergeAction` now reassigns calls. `Call` lives under
`enterprise/`, so OSS only has an empty `merge_calls` hook and
`Enterprise::ContactMergeAction` does the actual update.
- `_call.json.jbuilder` returns `contact: null` instead of raising when
the contact is gone.
- `CallListItem.vue` falls back to "Deleted contact" when `call.contact`
is missing.
- Added specs for the reassignment and for the null-contact API
response.
---------
Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com>
# Pull Request Template
## Description
The user payload rendered by `api/v1/models/_user.json.jbuilder` (shared
by sign-in, token validation, and profile endpoints) iterates the user's
account memberships and previously issued one `accounts` lookup per
membership, one `custom_role` lookup per membership on enterprise, and
re-ran the unmemoized `active_account_user` ordering query three times
per render. For users belonging to many accounts this makes the auth
response cost linear in membership count and can push `/auth/sign_in`
and `/auth/validate_token` past the request timeout.
This change preloads the memberships once (`includes(:account)`, plus
`:custom_role` on enterprise) and derives the active account in memory
from the preloaded rows, keeping full timestamp precision and `NULLS
LAST` semantics.
Measured by counting SQL queries per request at increasing membership
counts:
| Memberships | `GET /auth/validate_token` on develop | with this change
|
|---|---|---|
| 1 | 10 | 9 |
| 10 | 19 | 9 |
| 100 | 109 | 9 |
| 500 | 509 | 9 |
`POST /auth/sign_in` drops from 2016 to 1516 queries at 500 memberships;
its remaining growth comes from the per-account audit writes addressed
in #15572. With both changes applied, sign-in settles at 19 queries and
token validation at 9, independent of membership count.
Fixes https://linear.app/chatwoot/issue/INF-103
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Tested locally with users in 1, 10, 100, and 500 accounts; the query
counts above are from those runs.
- New request spec asserts the SQL query count for
`/auth/validate_token` does not grow with the number of account
memberships (fails on develop, passes with this change).
- Existing specs covering all render sites of the partial (devise
sessions/token validations, profiles, enterprise profiles) pass locally.
## 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
# Pull Request Template
## Description
Enterprise sign-in and sign-out create one audit event per account the
user belongs to. Each of those went through a separate `create`, costing
three queries per account (a version lookup, the insert, and a username
update from the after_save hook). For users belonging to many accounts
this makes authentication cost scale linearly with membership count and
contributes to request timeouts.
This change writes the same audit rows with a single bulk insert. Row
contents are unchanged: sequential versions continue from the current
max, username and user attribution are identical, and all rows share the
request uuid and remote address as before.
Measured by counting SQL queries per request at increasing membership
counts:
| Memberships | `POST /auth/sign_in` on develop | with this change |
|---|---|---|
| 1 | 21 | 21 |
| 10 | 56 | 29 |
| 100 | 416 | 119 |
| 500 | 2016 | 519 |
The remaining growth is the response rendering addressed in #15570. With
both changes applied, sign-in settles at 19 queries and token validation
at 9, independent of membership count.
Fixes https://linear.app/chatwoot/issue/INF-103
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Tested locally with users in 1, 10, 100, and 500 accounts; the query
counts above are from those runs.
- New request spec: sign-in for a user in multiple accounts creates one
audit per account using a single insert statement, with sequential
versions, correct association fields, username, and a shared request
uuid.
- Existing enterprise session specs (single account sign-in, sign-out,
SAML, invalid credentials) pass unchanged: 7 examples, 0 failures.
- Old and new attribution compared empirically on develop: rows produced
by the previous per-account loop match the batched rows column for
column.
## 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
This PR introduces a redesigned Captain Overview behind the localStorage
flag `captain_overview_v2: true`. It expands the Captain layout and adds
a rotating AI summary, key performance metrics, conversation resolution
flow with handoff reasons, weekly resolution trends, Captain CSAT,
usage, and knowledge coverage.
The resolution trend can switch between conversation counts and
current-versus-previous resolution rates using the same reporting
granularity. Metrics include concise, plain-language explanations, and
the supporting outcome reporting and seed data are updated accordingly.
Enable it using the following command in console, and reload the page
```js
localStorage.setItem('captain_overview_v2', 'true');
```
<img width="2880" height="2896"
alt="localhost_3000_app_accounts_1_captain_18_overview"
src="https://github.com/user-attachments/assets/a10f4f0a-1392-4432-9cd4-667d236178fa"
/>
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
This PR reduces the web SDK's gzipped bundle size by about 30%, lowering
the amount of JavaScript downloaded and parsed on uncached SDK loads. It
also serves precompressed Brotli or gzip from the existing SDK URL and
adds repeatable bundle-analysis tooling to help catch future size
regressions.
## What changed
### Use a lightweight synchronous user fingerprint
The SDK used MD5 only as a local fingerprint for detecting whether
`setUser` data had changed. It was not used as a conversation
identifier, authentication mechanism, or part of the server API
contract. This PR replaces the MD5 dependency with a small inline
128-bit [FNV-1a](https://www.rfc-editor.org/rfc/rfc9923.html)
implementation.
FNV-1a is synchronous and works in both secure and insecure embedding
pages. This preserves the previous latest-call-wins behavior when
integrations call `setUser` repeatedly, without relying on
`SubtleCrypto`, which is unavailable on plain HTTP origins. The 128-bit
output prevents practical 32-bit collisions from causing distinct
identities to be treated as unchanged; regression coverage includes a
known pair of identifiers that collide under FNV-1a 32-bit. Existing
hash cookies produce a one-time mismatch, causing `setUser` to be sent
once before the cookie is replaced with the new fingerprint.
The ESLint environment now declares ES2020, matching the SDK's Vite
build target and allowing the implementation to use `BigInt` directly.
The SDK also used `date-fns` only to add one hour to the current time.
Native timestamp arithmetic provides the same behavior for this fixed
duration without bundling the associated date utilities.
### Minify inline SDK styles
SDK styles now pass through [Vite's inline CSS
pipeline](https://v6.vite.dev/guide/features#disabling-css-injection-into-the-page).
Vite minifies the stylesheet at build time and returns it as a string,
while the SDK continues injecting it into the embedding page as before.
### Serve precompressed bundles from the same URL
The SDK build now emits Brotli and gzip sidecars. Rails 7.2
[automatically negotiates precompressed
assets](https://api.rubyonrails.org/v7.2.3.1/classes/ActionDispatch/FileHandler.html)
and serves the best format supported by the browser from the existing
`/packs/js/sdk.js` URL. No embed-code or application URL changes are
required.
## Bundle size
| Metric | Before | After | Reduction |
|---|---:|---:|---:|
| Raw | 29.20 kB | 21.75 kB | 25.5% |
| Gzip | 9.73 kB | 6.89 kB | 29.2% |
| Brotli | — | 6.08 kB | — |
## How to test
1. Load the widget from `/packs/js/sdk.js` in a browser that supports
Brotli or gzip and confirm the same URL is returned with the
corresponding `Content-Encoding` header.
2. Embed the widget on HTTPS and plain HTTP pages, call
`$chatwoot.setUser`, and confirm the user is identified in both
contexts.
3. Call `setUser` several times consecutively with different identities
and confirm the final call remains the active widget identity.
4. Reload the embedding page with unchanged user data and confirm the
SDK does not send a redundant `setUser` update.
5. Confirm the widget layout and styles remain unchanged.
## Staging test
#### Before
<img width="2192" height="710" alt="CleanShot 2026-08-12 at 16 23 27@2x"
src="https://github.com/user-attachments/assets/b60cf6dc-bb12-460c-9bed-d8720010ccf6"
/>
#### After
<img width="2192" height="1014" alt="CleanShot 2026-08-12 at 16 57
53@2x"
src="https://github.com/user-attachments/assets/4ce97fab-35a8-44cc-8add-20a0d59d5755"
/>
Ensures Captain reply-suggestion usage tests run in cloud mode, matching
the production guard introduced by #15465.
Related: https://github.com/chatwoot/chatwoot/pull/15465
## Why
Captain response usage is now intentionally disabled for self-hosted
installations, but three cloud usage expectations were not updated. This
left the backend test suite on `develop` failing.
## What this change does
Runs the reply-suggestion usage scenarios with Chatwoot Cloud enabled,
consistent with the existing Copilot chat coverage.
## Validation
- Reproduced all three failures on a clean `develop` checkout before the
change.
- All 18 reply-suggestion scenarios pass after the change.
- Ruby lint passes.
Captain response usage is a Chatwoot Cloud billing counter. Self hosted
installations use their own model credentials, so their responses should
not increase this counter.
## Root cause
`Account#increment_response_usage` increased `captain_responses_usage`
on every installation.
Self hosted installations do not receive the Cloud billing reset. Their
stored usage could therefore keep growing even though they do not buy
model credits from Chatwoot.
## What changed
`increment_response_usage` now returns without changing the counter
unless the installation is Chatwoot Cloud.
No credit limits, routing rules, pricing plan checks, Community
behavior, document behavior, crawling behavior, or frontend behavior
changed.
Existing self hosted accounts with a high stored counter need a one time
counter reset after deployment. Future self hosted responses will not
increase it again.
## Checks
The focused backend suite passed 176 examples.
RuboCop inspected 6 files and found no offenses. `git diff --check`
passed.
Adds the typed AI-assignee foundation and makes the polymorphic
association authoritative for existing AgentBot ownership writes, while
preserving current conversation behavior.
## Closes
- Part of
https://linear.app/chatwoot/issue/CW-7451/add-explicit-captain-ownership-backend
## Why
AgentBot and Captain ownership should share one typed association
instead of accumulating provider-specific ownership columns and write
paths. This establishes that common ownership surface before Captain
becomes assignable.
## What changed
- Adds the AI owner type discriminator and backfills existing
AgentBot-owned conversations.
- Adds the polymorphic `ai_assignee` association using the existing
AgentBot owner ID column.
- Routes AgentBot assignment, handoff, human takeover, automatic inbox
assignment, and ownership clearing through the typed association.
- Keeps existing AgentBot reads, API responses, queues, and user-facing
behavior unchanged.
Typed reads, inverse cleanup, event notifications, delayed rollout
reconciliation, and Captain assignment behavior follow in stacked PR
#15421.
## Validation
- Assign an AgentBot and confirm the conversation becomes pending with
AgentBot ownership.
- Assign a human or take over the conversation and confirm AI ownership
clears while the conversation opens when applicable.
- Unassign the conversation and confirm its status is not changed
implicitly.
Starting the tunnel workflow could immediately stop Rails and Sidekiq
when Vite Ruby found the frontend build already up to date. This keeps
the Vite build watcher alive so the Overmind tunnel stack remains
available.
### How to reproduce
1. Ensure the Vite build is already current.
2. Run `make force_run_tunnel`.
3. Observe Vite skip the build and exit, which causes Overmind to stop
the remaining processes.
### Things to know
The `--force` option is handled by Vite Ruby to bypass its freshness
check. Vite still runs in build watch mode, so no development server
port is exposed.
### How to test
1. Run `make force_run_tunnel` with an existing frontend build.
2. Confirm Vite completes the build and continues watching for changes.
3. Open the configured tunnel URL and confirm the Chatwoot login page
renders while Rails and Sidekiq remain running.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Updates the web widget user fingerprint to include contact information
supported by setUser. Existing contacts now sync when phone, company,
location, description, or social profiles change, while custom
attributes remain handled separately.
## Closes
Closes#13448
## How to reproduce
1. Identify a contact with setUser.
2. Change only phone_number, country_code, city, company_name,
description, or social_profiles.
3. Call setUser again and confirm the existing contact is updated.
## Summary
Captain now reads the conversation label list through the model accessor
when it builds runner state. The regression coverage reloads a labeled
conversation before building state, which matches the background job
path.
## Why
`label_list` is a virtual attribute backed by conversation tags. The
runner previously sliced it from `record.attributes`, where it is nil on
a persisted and reloaded conversation. Captain therefore omitted active
conversation labels from the model prompt even though the labels were
present on the conversation.
The change keeps the existing runner state shape and ensures the current
label list reaches the prompt.
## Testing
- `bundle exec rspec
spec/enterprise/services/captain/assistant/agent_runner_service_spec.rb`
- `bundle exec rubocop --cache-root /tmp/codex-rubocop-aa05
enterprise/app/services/captain/assistant/runner_state_helper.rb
spec/enterprise/services/captain/assistant/agent_runner_service_spec.rb`
## Summary
Captain now places `reasoning` before `response_parts` in its structured
response schema. The focused test checks the property order so a later
refactor cannot silently reverse it.
## Why
OpenAI Structured Outputs generates fields in the order declared by the
schema. Captain previously generated the customer response before
generating the reasoning that was meant to support it.
A controlled GPT-5.2 replay of a production language adherence failure
returned German in three of three runs with the current response-first
schema. With the same prompt and a reasoning-first schema, it returned
English in two of two runs. The sample is small, so this change is an
adherence improvement rather than deterministic enforcement.
OpenAI also documents reasoning before the final answer as a way to
improve final response quality:
https://openai.com/index/introducing-structured-outputs-in-the-api/#separating-a-final-answer-from-supporting-reasoning-or-additional-commentary
## Testing
- `bundle exec rspec spec/enterprise/models/concerns/agentable_spec.rb`
- `bundle exec rubocop --cache-root /tmp/codex-rubocop-aa05
enterprise/lib/captain/response_schema.rb
spec/enterprise/models/concerns/agentable_spec.rb`
Agent and company names could be interpreted as sanitized HTML in
conversation activity and widget identity labels. These fields are
plain-text identity data, so rendering markup can alter trusted UI and
trigger external resources.
This change renders activity content and widget identity labels through
Vue text interpolation. Rich message-body formatting remains unchanged.
Fixes
https://linear.app/chatwoot/issue/CW-7979/stored-html-injection-via-agent-profile-name-in-conversation-activity
### Things to know
Existing stored markup is neutralized at render time. This does not
change how regular message content is formatted.
### How to test
1. Set an agent name to text containing HTML-like markup.
2. Resolve or reopen a conversation and confirm the activity entry
displays the markup literally without creating an element or loading an
image.
3. Send a message to the web widget and confirm the agent and company
labels display as plain text.
4. Confirm regular message-body formatting still works.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
# Pull Request Template
## Description
Friendly sender names in outgoing emails now follow the sending user's
selected profile language. When the sender is not a user or has no
explicit locale preference, the sender name falls back to the account
locale.
This keeps the delivered sender name consistent with the localized
preview without changing the locale used for the email subject or body.
Both the legacy reply mailer and the migrated email builder path use the
same locale precedence.
### Closes
https://linear.app/chatwoot/issue/CW-7940/friendly-sender-name-shows-english-format-instead-of-selected-locale
## Description
On the super admin user show page, the actions area renders an Edit link
next to a Resend confirmation email button. The resend control is a
`button_to`, which Rails wraps in a block-level `<form>`. That form
dropped onto its own line instead of sitting beside Edit, stretching the
header and pushing the page content down. It only renders for
unconfirmed users, so the confirmed-user view looked fine and the
regression was easy to miss.
This makes the actions container a flex row and takes the form out of
the box flow (`display: contents`) so its button aligns inline next to
Edit. No behavior change.
Related to https://linear.app/chatwoot/issue/CW-7527
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Verified locally on the super admin user show page for an unconfirmed
user (Edit + Resend now inline) and a confirmed user (Edit only,
unchanged).
When a conversation transitioned to Open on an inbox using legacy (V1)
auto-assignment, the assignment write ran as a second save on the same
conversation inside the same transaction. That second save replaced
`saved_changes`, so the commit callbacks only saw the assignee change:
`conversation.opened` and `conversation.status_changed` were never
emitted — no "Conversation opened" activity message, no
`conversation_opened` reporting event, and automations triggered on
Conversation Opened silently never ran. Since this happened exactly when
auto-assignment succeeded, it was the dominant path on V1 inboxes, not
an edge case (in a concurrency test, 58 of 60 open transitions lost the
event). The most visible instance: an agent replying to a Captain
Pending conversation, which opens it — but the same loss happened from
the UI open button or any other open transition.
## Closes
-
[CW-7967](https://linear.app/chatwoot/issue/CW-7967/conversation-opened-event-not-emitted)
## How to reproduce
1. On an inbox with auto-assignment enabled and Assignment V2 off, have
at least one available agent.
2. Take an unassigned Pending conversation (e.g. one Captain is
handling) and send a public agent reply, or open it via the status
toggle.
3. The agent gets assigned, but the conversation shows no "Conversation
opened" activity, reporting records no `conversation_opened` event, and
Conversation Opened automations don't fire.
## What changed
- Legacy (V1) auto-assignment for status transitions now runs in a
`before_save` and sets the assignee on the in-flight save, so status and
assignee commit as a single change-set and both stay visible to the
`after_commit` callbacks. Rails only surfaces one change-set per row per
transaction to commit callbacks, so a follow-up save can never preserve
both — folding the assignment into the same UPDATE is the shape that
fixes this without touching the event layer.
- The lock-then-recheck semantics from #15275 are preserved and now
genuinely serialize: `AgentAssignmentService#assign_under_lock` takes
the row lock, re-checks `reassignment_still_needed?` against committed
state, then sets the assignee — with the lock now acquired before our
own write (previously the status UPDATE had already locked the row
before the service's lock ran). Verified under concurrent load: opens
racing manual assignment writes produce exactly one assignment write, no
assignee bouncing, and no deadlocks, matching current behavior.
- New conversations keep the post-save assignment path (`perform`, now
built on `assign_under_lock`): their status is only finalized by
`before_create` callbacks, which run after `before_save`, and creates
don't emit `conversation.opened` in the first place.
- Adds a regression spec asserting the open transition with V1
auto-assignment dispatches both `conversation.opened` and
`assignee.changed`, with `status` and `assignee_id` in the same set of
committed changes.
## Description
The source-only fallback in
`Api::V1::Accounts::ConversationsController#contact_inbox`
resolved a `ContactInbox` globally by `source_id`, unlike the sibling
lookups in the
controller which scope through an inbox or the current account. This
scopes the fallback
to the current account's inboxes (and to the supplied inbox when
`inbox_id` is present),
keeping it consistent with the rest of the controller and deterministic
when the same
`source_id` exists in more than one inbox.
Fixes https://linear.app/chatwoot/issue/CW-7966
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added request specs for bot-authenticated conversation creation: a
create for a
`source_id` that belongs to another account no longer resolves (returns
404), and a
create for a `source_id` in the bot's own account still succeeds. Full
conversations_controller_spec passes (93 examples, 0 failures); RuboCop
clean.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
## Description
Bumps the `mail` gem from 2.8.1 to 2.9.1 to resolve
[GHSA-mvxr-6m87-mv2q](https://github.com/mikel/mail/security/advisories/GHSA-mvxr-6m87-mv2q)
(email address spoofing via malformed RFC 2047 encoded-words), which is
currently failing the bundle-audit CI check on develop ([example failing
run](https://github.com/chatwoot/chatwoot/actions/runs/32226134705/job/95986093102?pr=15521)).
`mail` is a transitive dependency (via actionmailer), so this is a
lockfile-only change done with `bundle update mail --conservative`. The
only dependency change is the new explicit `logger` dependency, which is
already in the bundle.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `bundle exec bundle-audit check --update` passes (no vulnerabilities
found)
- Verified mail 2.9.1 loads and renders a basic message correctly
- All email specs pass
## 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] New and existing unit tests pass locally with my changes
## Description
Adds filtering, search and sorting to the audit logs page. The endpoint
previously supported only pagination, so finding a specific event meant
paging through everything.
- Keyword search by the acting user name or email: auto-searches 800ms
after typing pauses (3+ characters), enter searches immediately; stale
responses are discarded
- Event type filter, grouped by category; only event types that are
actually logged are offered
- Date range filter with presets and custom range, applied only on an
explicit choice
- Sort by date (newest or oldest first)
Filters live in the URL query params so filtered views are shareable and
survive refresh. All params are optional, so existing clients are
unaffected. A composite index on `audits (associated_type,
associated_id, created_at)` supports account-scoped filtering and
sorting; it is created concurrently.
Two small shared-component changes were needed:
- `DatePicker` gains a `defaultOpen` prop and now clamps its calendar
popup within the viewport (triggers that sit mid-row pushed the 880px
popup off screen). Reports pages keep their existing behavior.
- `SettingsWrapper` keys routed pages by `route.path` instead of
`route.fullPath` when a route opts in via `meta.reuseOnQueryChange`, so
query-param filter changes no longer remount the page (which stole input
focus and refetched on every change). Only the audit logs route opts in.
Part of https://linear.app/chatwoot/issue/CW-7852
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Request specs covering each filter, combinations, sorting, and
malformed params
- Vitest specs for the API client, store action, route query helpers,
and the filter bar component
- Manual pass on a dev instance seeded with 1000+ audit rows across all
event types, including narrow-viewport checks
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
WhatsApp campaign analytics currently groups queued recipients and
messages awaiting a WhatsApp delivery update under “Pending,” which
makes it difficult to understand whether those messages have been
submitted.
This change makes the processing state explicit. The summary now uses
“Submitted to WhatsApp,” sent recipients are labeled “Awaiting delivery
update,” and the processing banner shows the live queued and
awaiting-update counts.
Related:
https://linear.app/chatwoot/issue/CW-4627/ee-basic-analytics-for-whatsapp-campaigns
### Things to know
- This only changes the analytics presentation; delivery states and API
calculations remain unchanged.
- The banner continues to refresh with the existing analytics polling.
- Singular, queued-only, awaiting-only, initial-loading, and completing
states have dedicated copy.
### How to test
1. Open analytics for a processing WhatsApp campaign with queued and
sent recipients.
2. Confirm the banner shows both counts: “X messages are queued, and Y
are awaiting a delivery update from WhatsApp.”
3. Confirm the summary says “Submitted to WhatsApp,” the sent filter
says “Awaiting delivery update,” and the breakdown says “Queued or
awaiting update.”
4. Confirm the banner adapts when either count reaches zero and updates
as campaign statuses change.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Updates Chatwoot to use the newly migrated `@chatwoot/pico-search`
package at version `0.6.2`. This follows the repository ownership move
and picks up the latest published bug fix without changing how search is
called in the application.
## What changed
- Replaced `@scmmishra/pico-search` with `@chatwoot/pico-search`.
- Updated all application imports to the new package scope.
- Refreshed the pnpm lockfile for version `0.6.2`.
Validation: `pnpm install --frozen-lockfile`, staged ESLint, and the
repository pre-push validation completed successfully.
## Summary
Copilot's **Suggest a reply** action now uses the selected Captain
Assistant's knowledge and instructions. Support agents can review and
edit the generated reply before sending it to the customer.
The action uses the same FAQ knowledge, response guidelines, guardrails,
citation settings, and conversation context as the selected Assistant.
Regular Copilot conversations keep their existing behavior.
## Scope
The new behavior applies only when a support agent clicks **Suggest a
reply** in Copilot.
The reply can use:
* The selected Assistant's description, response guidelines, and
guardrails.
* The full public conversation history up to the latest customer
message.
* The Assistant's FAQs.
* Custom tools that use GET requests.
* Raw links from FAQs, response guidelines, and generated answers.
* Citations when citations are enabled for the Assistant.
The action uses one Captain credit after a reply is generated and saved.
If the public conversation changes while Copilot is drafting, the reply
is discarded and no credit is used.
## Not included
* Assistant scenarios.
* Human handoff, conversation resolution, private notes, or other
actions that change conversation data.
* Custom tools that use POST requests.
* Prompts typed into Copilot, including prompts such as "suggest a
reply."
* Changes to the Assistant Playground, the customer facing Assistant, or
regular Copilot conversations.
[AI-195](https://linear.app/chatwoot/issue/AI-195/copilot-suggest-a-reply-should-read-assistant-instructions)
## Description
PR #15317 moved conversation completion to FeatureRouter as an internal
feature. Internal features were then missing from Super Admin model
routing, and FeatureRouter ignored any internal account override.
The change adds separate Customer features and Internal features
sections to the Super Admin account show and edit pages. It allows known
internal model keys in account settings and makes valid account
overrides work for internal features. Customer Captain preferences still
hide internal features.
Conversation completion now uses the same model list as the Assistant
feature. A per-account override takes priority over
CAPTAIN_OPEN_AI_MODEL on self-hosted Enterprise. The installation model
still takes priority over the YAML default when no account override
exists.
Follow-up to #15317.
<img width="738" height="414" alt="CleanShot 2026-08-13 at 16 42 01@2x"
src="https://github.com/user-attachments/assets/08444805-1a0e-4085-a5fc-b3e60e2e2597"
/>
## Type of change
- [x] New feature
- [ ] Bug fix
- [ ] Breaking change
- [ ] Documentation update
## How has this been tested?
- Ran the FeatureRouter, Super Admin account, conversation completion
service, model catalog, account validation, and customer Captain
preferences specs.
- Ran RuboCop on the changed Ruby files.
- Checked the changed ERB, Ruby, YAML, and Git diff syntax.
- Used Playwright against the Cook UI to expand the account routing
panel and confirm the Conversation completion card appears under
Internal features.
- Inspected the Playwright screenshot for layout, clipping, and readable
selected values.
## Checklist
- [x] My code follows the project style guidelines.
- [x] I reviewed the complete diff.
- [x] I added tests that prove the change works.
- [x] New and existing focused tests pass locally.
- [x] Internal features remain hidden from customer Captain preferences.
## Description
Adds optional publishing of Sidekiq queue metrics (queue latency, queue
size, enqueued jobs, worker utilization) to AWS CloudWatch, so
background-worker capacity can be autoscaled on queue backlog rather
than CPU/memory, which are weak signals for I/O-bound job workloads.
Uses the `speedshop-cloudwatch` gem. It is off by default and opt-in via
`ENABLE_SIDEKIQ_CLOUDWATCH`. The gem is loaded with `require: false` and
wired only inside the Sidekiq server lifecycle, so web and other
processes are unaffected (no Rack middleware is inserted). Namespace and
interval are configurable.
Credentials: by default it uses the EC2 instance role, which must allow
`cloudwatch:PutMetricData`. This avoids picking up the shared
`AWS_ACCESS_KEY_ID` used for object storage, which is not scoped for
CloudWatch. Dedicated credentials can be supplied via
`SIDEKIQ_CLOUDWATCH_AWS_ACCESS_KEY_ID` /
`SIDEKIQ_CLOUDWATCH_AWS_SECRET_ACCESS_KEY` /
`SIDEKIQ_CLOUDWATCH_AWS_REGION` to override the instance role where one
is not available.
This supersedes the earlier #12087, which had the same goal with a
different gem. This one is purpose-built for autoscaling and reports on
a background thread.
Fixes https://linear.app/chatwoot/issue/INF-98
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
Verified end to end on a staging environment:
- Wiring: with the flag enabled, config resolves to the
`Chatwoot/Sidekiq` namespace, only the allow-listed metrics publish,
per-queue `QueueLatency`/`QueueSize` are emitted with a `QueueName`
dimension, and no Rack middleware or Puma collector is loaded (Sidekiq
only). Rubocop clean.
- Live at idle: deployed with `ENABLE_SIDEKIQ_CLOUDWATCH=true`; metrics
published every 60s to CloudWatch via the instance role (no dedicated
keys needed).
- Under load: enqueued ~110k jobs to an unconsumed test queue;
`EnqueuedJobs` and per-queue depth/latency rose accordingly, then
returned to baseline once the queue was cleared.
- Autoscaling usability: the published metric drove an ASG
target-tracking policy that scaled the worker fleet out under backlog
and back in once drained.
Twilio can briefly return a 404 for valid inbound WhatsApp media while
the asset propagates. Chatwoot currently skips that attachment, so the
conversation keeps its text but permanently loses the image or file.
This change adds bounded authenticated retries for verified Twilio media
URLs and safely follows Twilio's normal redirect to its signed CDN.
Credentials are restricted to the original trusted Twilio request and
are stripped when the download crosses origins.
### How to reproduce
1. Receive a Twilio WhatsApp message whose media endpoint returns a
transient 404.
2. Observe that the current flow skips the attachment immediately.
3. A previous attempt to disable redirects avoided credential forwarding
but also blocked Twilio's expected secure-CDN redirect, causing valid
downloads to fail.
### What changed
- Validate the Twilio API host, account SID, message SID, and media SID
before sending Basic Auth.
- Retry authenticated 404 responses after 1 and 3 seconds, sharing one
retry-delay budget across all attachments in the message.
- Download through `SafeFetch`, which follows safe redirects and removes
authorization across origins.
- Resolve Twilio media through IPv4 so dual-stack CDN DNS cannot
randomly select an unreachable IPv6 route.
- Keep non-Twilio media downloads anonymous.
- Preserve the inbound text when media retries are exhausted and emit
structured download outcome logs.
### Things to know
- Retry applies only to verified Twilio media URLs and only to 404
responses.
- The maximum added wait per inbound message is four seconds, regardless
of attachment count.
- Other download failures retain the existing skip-attachment behavior.
### How to test
1. Send an inbound Twilio WhatsApp message with an image to a Chatwoot
inbox.
2. Confirm the text and image appear in the conversation after Twilio
redirects the media request to its signed CDN.
3. Simulate a media endpoint that returns 404 once and then succeeds;
confirm the attachment appears after retry.
4. Simulate persistent 404 responses; confirm the text message is
created without the attachment after the bounded retries.
5. Send a message containing a non-Twilio media URL; confirm it
downloads without Twilio credentials.
Fixes
https://linear.app/chatwoot/issue/PLA-206/retry-transient-twilio-whatsapp-media-404s-before-skipping-attachments
Related: #15499
Related: #15502
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Summary
When an inbound email (e.g. Apple Mail with
DisableInlineAttachmentViewing set) marks an image part as
Content-Disposition: inline with a Content-Id but does NOT reference
that CID via cid: in the HTML body (instead emitting Apple's proprietary
<attachment> tag), the image is silently dropped.
Fixes#14633
---------
Co-authored-by: Shivam Mishra <scm.mymail@gmail.com>
Fixes an issue where filtering conversations using **Labels → Is not
present** caused the conversation list to remain empty and repeatedly
reload. This affected both the Conversations view and saved folders,
preventing teams from reliably finding unlabeled conversations for
supervision and quality assurance.
## Closes
-
[CW-7861](https://linear.app/chatwoot/issue/CW-7861/bug-labels-is-not-present-filter-triggers-an-infinite-flickering)
## How to reproduce
1. Open the Conversations page.
2. Open advanced filters.
3. Select **Labels**.
4. Select **Is not present**.
5. Apply the filter.
6. Observe that no conversations are displayed and the conversation list
repeatedly flickers while loading additional pages.
The same behavior can be reproduced by creating or opening a folder that
uses this filter.
## What caused the issue
The backend correctly returned unlabeled conversations with `labels:
[]`. The frontend then reapplied the filter locally but only treated
`null` and `undefined` as absent.
As a result, an empty labels array was incorrectly considered present,
and every conversation returned by the backend was removed from the
displayed list. The empty list kept the infinite-scroll observer
visible, causing it to request additional pages repeatedly and produce
the flickering reload loop.
## What changed
The frontend filter matcher now treats an empty labels array as absent
when evaluating label presence operators. This aligns frontend filtering
with the backend:
- `labels: []` matches **Is not present**
- A non-empty labels array matches **Is present**
The change is scoped specifically to labels, preserving the existing
presence semantics for other attributes and custom fields.
## Description
Adds a "Resend confirmation email" button to the super admin user detail
page. When an unconfirmed user's confirmation email fails to reach them,
an admin can re-trigger it from the panel instead of using the Rails
console. The action sends the standard Devise confirmation email to the
user's own registered address, and is only available while the user is
unconfirmed. No confirmation token or link is exposed in the UI.
Related to https://linear.app/chatwoot/issue/CW-7527
Captain outcome reporting is now available through dedicated assistant
stats endpoints. The new overview summary analyzes outcome,
resolution-flow, and trend data to surface up to three specific,
evidence-backed insights using rounded approximations suited to an
hourly cached summary.
## Closes
Follow-up to https://github.com/chatwoot/chatwoot/pull/15425
## How to test
1. Select an assistant with recorded conversation outcomes.
2. Request the overview, resolution flow, and resolution trend endpoints
for different reporting ranges.
3. Confirm the overview summary returns no more than three distinct
points backed by rounded, softened report values rather than exact
figures.
4. Confirm low-volume reports qualify rate-based conclusions and reports
without meaningful activity return no points.
5. Request the overview summary again with the same assistant, range,
timezone, and locale, and confirm the successful summary is reused from
the one-hour cache.
6. Confirm raw statistics remain uncached and continue reflecting the
selected reporting range and timezone.
## Chatwoot CLI
View the 30-day statistics for assistant ID `1` using a UTC+5:30 viewer
timezone:
```bash
chatwoot api "/captain/assistants/1/stats/overview?range=30&timezone_offset=5.5" -o json
chatwoot api "/captain/assistants/1/stats/resolution_flow?range=30&timezone_offset=5.5" -o json
chatwoot api "/captain/assistants/1/stats/resolution_trend?range=30&timezone_offset=5.5" -o json
chatwoot api "/captain/assistants/1/stats/overview_summary?range=30&timezone_offset=5.5" -o json
```
## What changed
- Added a dedicated assistant stats controller for overview,
resolution-flow, and resolution-trend data.
- Added a server-generated overview summary based on all three reporting
datasets.
- Added a structured LLM response schema and a focused prompt for up to
three standout insights.
- Rounded and softened metric values in generated insights so cached
summaries do not present stale figures as exact.
- Cached successful LLM summaries for one hour while leaving raw
statistics uncached and avoiding caching generation failures.
- Added a frontend API client for the new endpoints.
- Preserved the existing assistant metrics and summary endpoints for
compatibility.
WhatsApp campaigns gain a dedicated analytics view for completed and
processing campaigns. Teams can monitor live delivery progress, review
campaign-level delivery metrics, and inspect recipient-level statuses
and failure reasons.
This PR contains only the frontend experience and uses the analytics
APIs and campaign execution fields introduced in #15276.
Related:
https://linear.app/chatwoot/issue/CW-4627/ee-basic-analytics-for-whatsapp-campaigns
### What changed
- Shows audience, sent, delivered, read, failed, and skipped metrics.
- Adds a delivery breakdown and recipient-level delivery table with
status filters and pagination.
- Exposes analytics while a campaign is processing and identifies live
data with an in-progress banner.
- Shows a waiting state when a processing campaign has not produced
delivery records yet.
- Shows an unavailable state for completed campaigns that do not have
stored recipient data.
- Prevents invalid analytics requests when navigating back to the
campaign list.
### Things to know
- Historical campaigns sent before recipient tracking was introduced may
not have analytics data.
- This PR does not change campaign sending, recipient tracking, or
webhook processing.
- Analytics visibility currently follows the Enterprise installation
check; subscription-plan entitlement is not included in this PR.
### How to test
1. Open Campaigns → WhatsApp.
2. Open a processing WhatsApp campaign and confirm the analytics action
is available.
3. Confirm the processing banner and live metrics are shown.
4. Open a completed campaign with recipient data and verify its metrics,
delivery breakdown, status filters, and pagination.
5. Open a completed historical campaign without recipient data and
confirm the unavailable state is shown instead of zero-valued metrics.
6. Filter the recipient table and confirm contact, message, status,
failure reason, and error code render correctly.
7. Return to the campaign list from the analytics breadcrumb and confirm
the page loads without an error.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
This PR replaces the Chart.js-based reporting charts with our internal
`@chatwoot/viz` library. The primary motivation is to support our native
Sankey visualization while maintaining a reusable charting package that
can be shared across Chatwoot projects.
## Preview
### Dashboard
#### Conversation Stats
<img width="2114" height="1696" alt="CleanShot 2026-08-13 at 15 48
08@2x"
src="https://github.com/user-attachments/assets/88ada023-818a-4f2a-b574-1361ff3a55c1"
/>
<img width="2052" height="1598" alt="CleanShot 2026-08-17 at 17 18
17@2x"
src="https://github.com/user-attachments/assets/e88480fe-4663-4d24-9dae-d23e6ed61ccc"
/>
#### CSAT
<img width="2042" height="632" alt="CleanShot 2026-08-17 at 17 09 14@2x"
src="https://github.com/user-attachments/assets/610b2fc6-f67e-40b4-8607-a3ae690150fe"
/>
<img width="2064" height="640" alt="CleanShot 2026-08-17 at 17 18 00@2x"
src="https://github.com/user-attachments/assets/e5d18ec2-4215-4b8f-8e85-0d5a0f6fa999"
/>
#### Heatmap
<img width="2106" height="796" alt="CleanShot 2026-08-17 at 17 17 50@2x"
src="https://github.com/user-attachments/assets/f0943665-843e-40ae-8a93-b1c4acaafcf5"
/>
<img width="2106" height="796" alt="CleanShot 2026-08-17 at 17 17 40@2x"
src="https://github.com/user-attachments/assets/2b3824da-a70c-46e3-a2fd-1339173eadbf"
/>
## What changed
- Migrated report and Super Admin bar charts from Chart.js to
`@chatwoot/viz`.
- Migrated reporting heatmaps to the shared visualization library.
- Removed `chart.js` and `vue-chartjs`.
- Preserved report drill-down interactions, responsive behavior,
accessibility, and theme support.
- Improved duration axes with human-friendly tick intervals.
- Added contextual tooltip descriptions for first response, resolution,
and waiting-time metrics.
## How to test
1. Open Reports and verify conversation, message, first-response,
resolution, and waiting-time charts.
2. Check different date ranges and grouping options.
3. Hover over duration bars and verify the formatted value and
supporting conversation or reply count.
4. Click report bars and confirm drill-down navigation still works.
5. Verify conversation and resolution heatmaps, including their
tooltips.
6. Open the Super Admin dashboard and verify its conversation chart.
7. Check the charts at narrow and wide widths and in both light and dark
themes.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Twilio can briefly return a 404 for valid inbound WhatsApp media while
the attachment is still propagating. Chatwoot previously followed the
initial authenticated request with an unauthenticated retry, so the
attachment could still be skipped even after it became available.
This change keeps retries authenticated for trusted Twilio media URLs,
waits for bounded intervals, and preserves the inbound message when
media remains unavailable. Other media URLs retain the existing
anonymous download behavior.
Fixes
https://linear.app/chatwoot/issue/PLA-206/retry-transient-twilio-whatsapp-media-404s-before-skipping-attachments
### What changed
- Validate the HTTPS Twilio API host and exact account, message, and
media path before sending channel credentials.
- Retry Twilio media 404 responses after 1 and 3 seconds using
authentication on every attempt.
- Stop retrying on other download failures and log retry, success, and
skipped outcomes with message and inbox context.
- Keep the inbound text message when all attachment attempts are
exhausted.
### How to reproduce
1. Receive an inbound Twilio WhatsApp message with media.
2. Make the Twilio media endpoint return 404 for the first authenticated
request and succeed shortly afterward.
3. Before this change, the follow-up request is unauthenticated and the
attachment is skipped.
4. With this change, the authenticated retry downloads and attaches the
media.
### How to test
1. Open the affected Twilio WhatsApp conversation.
2. Trigger an inbound message whose valid Twilio media URL returns 404
once, then succeeds.
3. Confirm the message appears with its attachment after the retry.
4. Repeat with persistent 404 responses and confirm the text message
remains without an attachment.
The focused RSpec suite passes with 46 examples, and the changed Ruby
files pass RuboCop.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
# Pull Request Template
## Description
Restores Rails migrations and local worktree database preparation after
the Rails 7.2 upgrade. The lockfile now resolves a Rails 7.2-compatible
`hairtrigger` release and a `ruby_parser` release that understands Ruby
3.4, allowing the post-migration schema dump to complete while
preserving Chatwoot's database triggers.
Closes
[CW-7968](https://linear.app/chatwoot/issue/CW-7968/fix-dbschemadump-after-rails-72-upgrade)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Reproduced the failure using a disposable PostgreSQL database loaded
from the schema immediately before the campaign-recipient migration. The
repaired worktree setup applied the migration, completed the schema
dump, and retained the account, conversation, and campaign trigger
definitions. Focused trigger behavior specs, dependency audit, bundle
verification, and lint checks also passed.
## 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
## Description
**The bug:** When searching in the dashboard, the same message could
show up twice in the results list.
**Why it happens:** Search results load 15 at a time. When you click
"Load more", the next 15 are fetched by asking the server to skip the
first 15 and return the rest. The catch: if new messages were created
between the two fetches, everything shifts down. A message that was in
position 14 during the first fetch may now be in position 16, so the
second fetch returns it again. The UI appended everything it received
without checking, so that message appeared twice on screen.
A smaller variant of the same problem: results are sorted by
`created_at`, and two messages can share the same timestamp. The
database and OpenSearch are free to return such tied rows in any order,
so the order can differ between two fetches and a row can slip from one
page into the next.
**The fix:**
- The store now skips records that are already in the list when
appending a page, so a re-served record can never render twice
- Whether "Load more" is shown is now based on the size of the raw API
response instead of the on-screen count, so pagination keeps working
when overlapping records get dropped
- Ties are now broken by message `id` on every search path (LIKE, GIN,
OpenSearch), making the sort order stable between fetches
- For OpenSearch this needs `id` in the index. No reindex is required:
new documents pick the field up automatically, and `unmapped_type` keeps
existing indexes working unchanged
Fixes https://linear.app/chatwoot/issue/CW-7856
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Reproduction
Verified on `develop` using the SQL search path.
1. Seeded 100 conversations with normal non-matching messages.
2. Added 20 matching messages containing `assignment handoff message`,
spread across separate conversations.
3. Opened dashboard advanced search and searched for `assignment
handoff`.
4. The Messages tab loaded page 1 with 15 results, starting with
conversation `#569`.
5. While page 1 was still open, inserted 15 newer matching messages in
separate conversations.
6. Clicked **Load more**.
### Result on `develop`
The second page appended the same page-1 rows again. In the screenshot,
page 1 starts with `#569`, and after Load more the list reaches `#499`
then appends `#569` again.
This confirms the offset-pagination bug: new matching rows inserted
between page 1 and page 2 shift the offset, so page 2 re-fetches rows
that were already rendered.
<img width="1120" height="1455" alt="image"
src="https://github.com/user-attachments/assets/987652da-2eda-4c63-a3ae-48becee87e43"
/>
### Fix verification
Verified the same repro on `fix/cw-7856-search-pagination-tiebreaker`.
1. Seeded 100 conversations with non-matching messages.
2. Added 20 matching messages spread across separate conversations.
3. Opened the Messages search page and loaded page 1.
4. While page 1 was open, inserted 15 newer matching messages.
5. Clicked **Load more**.
### Result on fix branch
No duplicate rows were rendered.
The raw page-2 API window still overlapped with page 1, which is
expected with offset pagination after newer rows are inserted. The
frontend store dropped the already-rendered records during append, so
the visible list stayed unique.
`Load more` also remained available after the overlapped page, and the
next page returned the remaining older results.
WhatsApp campaigns now store delivery data for every intended recipient
so delivery performance can be inspected after a campaign runs. The
backend records the actual campaign start and completion times, captures
sent, delivered, read, failed, and skipped outcomes, and exposes metrics
and recipient-level results for the analytics UI.
The analytics APIs and recipient tracking are available for one-off
WhatsApp campaigns on Enterprise installations when the
`whatsapp_campaign` account feature is enabled. The shared campaign
lifecycle records and exposes actual start and completion timestamps for
all one-off campaigns.
Related:
https://linear.app/chatwoot/issue/CW-4627/ee-basic-analytics-for-whatsapp-campaigns
### What changed
- Create a campaign recipient record for every contact selected by the
campaign audience.
- Store rendered message content, provider message ID, delivery
timestamps, and provider failure details.
- Update recipient status from WhatsApp delivered, read, and failed
webhooks without allowing status downgrades.
- Store `started_at` when campaign processing begins and `completed_at`
when it finishes.
- Add metrics and paginated, status-filtered recipient analytics
endpoints.
### Things to know
- This PR contains the backend implementation only. The analytics UI is
in #15369 and is based on this branch.
- Recipient analytics currently cover one-off WhatsApp campaigns only;
`started_at` and `completed_at` are shared by all one-off campaign
types.
- Access is controlled by the existing `whatsapp_campaign` account
feature. Plan entitlement configuration is outside this PR.
- The migration creates `campaign_recipients` and adds `started_at` and
`completed_at` to campaigns.
- Retry, automatic reattempt, and campaign-specific reply attribution
are not included.
### How to test
1. Enable `whatsapp_campaign` for an Enterprise account.
2. Create a one-off WhatsApp campaign with a label-based audience that
includes valid contacts and at least one contact without a phone number.
3. Trigger the campaign and confirm it records `started_at`,
`completed_at`, and one campaign recipient per audience contact.
4. Confirm successful sends store the provider message ID and skipped or
failed recipients store the corresponding reason.
5. Process delivered, read, and failed WhatsApp status webhooks and
confirm recipient states and timestamps update.
6. Request the campaign metrics endpoint and confirm the audience and
delivery counts.
7. Request the contacts endpoint with status and page parameters and
confirm filtering and pagination.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
## Summary
Adds an agent-facing UI for the Click-to-WhatsApp (CTWA) referral data
that #12560 / #14121 captures on
`conversation.additional_attributes.referral`.
When a contact starts a WhatsApp conversation by clicking on a
Facebook/Instagram CTWA ad, Meta sends a `referral` object with the ad's
metadata (source URL, headline, body, media, the welcome message that
was pre-filled in the customer's WhatsApp). #14121 stores this on the
conversation. This PR surfaces it in the dashboard so the agent can see
exactly which ad brought the lead — replicating the "lead source"
pattern that Kommo and similar CRMs offer for WhatsApp.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## Closes / depends on
- Depends on #14121 (backend referral capture).
- Addresses the UX side of #12560.
## What this adds
- **`components-next/Conversation/ReferralBubble.vue`** — a standalone,
additive card rendered at the top of the conversation. It shows:
- the ad's poster/image (or video player for video ads),
- the headline and body,
- a **View ad** link that opens `source_url` in a new tab,
- the welcome message that was pre-filled in the customer's WhatsApp,
and
- a discreet "Customer replied below" hint so the agent reads the
conversation top-down with full context.
- Visual treatment: dashed amber border, megaphone icon, "Ad" / "Post"
label — intentionally distinct from message bubbles so it can't be
mistaken for something the customer sent.
- **`components-next/Conversation/ReferralBubble.story.vue`** — Histoire
story with four variants (image ad, video ad, text-only post, minimal
payload).
- Integration into `MessagesView.vue` via the existing `beforeAll` slot
on `MessageList` — no changes to `MessageList` or `Message` components.
- i18n keys in `en/conversation.json` only (other locales via Crowdin).
## How it behaves when referral data is absent
The bubble renders strictly when
`currentChat.additional_attributes.referral` is present. For all
non-CTWA conversations the component is never instantiated, so this is
inert for everything else. No feature flag is necessary.
## How Has This Been Tested?
- Lint: `pnpm eslint
app/javascript/dashboard/components-next/Conversation/ReferralBubble.vue
app/javascript/dashboard/components-next/Conversation/ReferralBubble.story.vue`
— clean.
- Manual:
1. Inject a sample referral on a WhatsApp conversation:
```ruby
conv = Conversation.find_by(display_id: <id>, account_id: <id>)
conv.update!(additional_attributes: {
referral: {
source_url: 'https://fb.me/sample-ad',
source_type: 'ad',
headline: 'Sample Ad',
body: 'Sample body text.',
media_type: 'image',
image_url: 'https://picsum.photos/seed/ad1/800/420.jpg',
welcome_message: { text: 'Hi, more info please' }
}
})
```
2. Open the conversation in the dashboard — the bubble renders above the
messages.
3. Click **View ad** — opens `source_url` in a new tab.
4. Switch the payload to `media_type: 'video'` with a `video_url` — the
bubble renders a poster with a play overlay; clicking it opens the ad.
5. Drop `welcome_message` — the bubble omits the pre-filled hint
cleanly.
6. Drop `image_url` and `video_url` — the bubble renders text-only.
7. Open any non-CTWA conversation — no bubble is rendered.
## Screenshots
<img width="1372" height="1328" alt="CleanShot 2026-08-16 at 14 46
29@2x"
src="https://github.com/user-attachments/assets/d65aeb9f-d390-465f-9728-c03491949e7b"
/>
## 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] Any dependent changes (#14121) have been merged or are mentioned
above
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
## Summary
When an agent has multiple tabs/windows open and picks up (or ends) a
Twilio voice call in one of them, the other tabs never find out — they
keep ringing and showing the call as still incoming, even though it's
already been answered or has ended elsewhere.
Chatwoot already broadcasts this kind of accept/end state for WhatsApp
calls so every other tab clears its ringing UI, but the equivalent never
existed for Twilio — neither the backend event nor the frontend
listener.
## How to reproduce
1. Log into the same agent account in two browser tabs.
2. Receive an inbound Twilio call (rings in both tabs).
3. Accept the call in one tab.
4. The other tab keeps ringing and shows the call as still incoming.
Same issue in reverse when discarding/ending a call from one tab — the
others keep showing it as active/ringing.
## What changed
- `Api::V1::Accounts::ConferenceController#create`/`#destroy` now
broadcast `voice_call.accepted`/`voice_call.ended` account-wide for
Twilio calls, mirroring the existing `Whatsapp::CallService` broadcast
shape.
- `onVoiceCallAccepted`/`onVoiceCallEnded` in `actionCable.js` no longer
ignore non-WhatsApp providers — they now route through the right
local-ownership check per provider before deciding whether to tear the
call down in the current tab.
- Added a Twilio-side `markLocalCall`/`isLocalCall`/`clearLocalCall` (in
`dashboard/helper/voice.js`), the equivalent of WhatsApp's
`activeCallId`, set synchronously before the join API call so the
account-wide broadcast can't race ahead of the joining tab's own state
and tear down its live call.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Keeps the inbox conversation and contact sidebar within the available
viewport at desktop breakpoints.
## Preview
https://github.com/user-attachments/assets/aba1e25e-8741-4544-8659-a6024ad1e887
## How to reproduce
1. Open an inbox notification with the contact sidebar visible.
2. Resize the viewport around the 1536px breakpoint or expand the main
navigation.
3. Confirm the inbox list, conversation, and contact sidebar remain
visible.
## Description
Adds a composite index `(account_id, status, created_at)` on
`conversations`.
Sorting an account's conversation list by `created_at` ("newest first")
across all inboxes has no supporting index today, so Postgres falls back
to a backward scan of the global `index_conversations_on_created_at`
filtered by `account_id`. On large databases the planner estimates a
very deep scan and the query can exceed the statement timeout. The
composite index lets the ordered limit be served directly from the
`account_id`/`status` prefix. The default `last_activity_at` sort and
inbox-filtered views are unaffected (already indexed).
The index is created with `algorithm: :concurrently` (no table lock). On
very large installations, create it out-of-band concurrently before
deploying so the migration doesn't run a long build.
Fixes https://linear.app/chatwoot/issue/CW-7888
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
This PR adds outcome-based reporting builders for the redesigned Captain
overview, resolution flow, and resolution trend. These builders are not
wired to controllers or the frontend yet, so the existing Captain
metrics remain unchanged.
## AssistantOverviewStatsBuilder
Builds current and previous reporting-window metrics, including the
comparison trend, for the overview and CSAT cards.
| Statistic | Description |
| --- | --- |
| Conversations handled | Counts outcome episodes in which Captain
replied or performed a non-usage-limit handoff. |
| Auto-resolution rate | Shows autonomous resolutions as a percentage of
conversations handled. |
| Autonomous resolutions | Counts episodes resolved by Captain without a
handoff or an earlier human reply. |
| Handoff rate | Shows involved handoffs as a percentage of
conversations handled. |
| Handoff count | Counts involved handoffs while excluding demand
blocked by usage limits. |
| Hours saved | Estimates displaced agent effort from Captain's public
replies at two minutes per reply. |
| Reopen rate | Shows the share of autonomous resolutions followed by
another episode. |
| Conversation depth | Shows the average number of public Captain
replies per replied-to conversation. |
| Durable resolution rate | Shows autonomous resolutions that remained
closed for at least seven days among resolutions old enough to assess. |
| Autonomous CSAT score | Averages CSAT ratings from conversations
resolved autonomously by Captain. |
| Assisted CSAT score | Averages CSAT ratings from resolved
conversations where Captain participated alongside a human. |
| Human-only CSAT score | Averages account CSAT from conversations where
Captain never participated. |
| Median resolution time | Reports the median elapsed seconds from
demand start to resolution for handled episodes. |
## AssistantResolutionFlowBuilder
Builds the current-window Sankey data and a matching handoff-reason
distribution from the same outcome cohort.
| Statistic | Description |
| --- | --- |
| Conversations handled | Provides the Sankey entry count for episodes
where Captain participated. |
| Resolved by Captain | Counts handled episodes resolved autonomously by
Captain. |
| Handed off | Counts handled episodes transferred to a human for a
non-usage-limit reason. |
| Closed with team | Counts handled episodes outside the
autonomous-resolution and handoff branches. |
| Reopened within seven days | Counts Captain resolutions followed by a
new episode before the seven-day durability boundary. |
| Stayed closed | Counts Captain resolutions with no reopen inside seven
days. |
| Handoff reason nodes | Shows the two largest handoff categories and
combines the remainder as other reasons. |
| Handoff distribution | Returns every involved handoff category with
its count and percentage, including unclassified handoffs. |
## AssistantResolutionTrendStatsBuilder
Builds a zero-filled, timezone-aware resolution series in one outcome
query, using daily buckets for windows of 15 days or less and weekly
buckets for longer windows.
| Statistic | Description |
| --- | --- |
| Granularity | Identifies whether the response contains daily or weekly
buckets. |
| Bucket range | Returns the start and end date represented by each
bucket. |
| Conversations handled | Counts Captain-involved outcome episodes whose
demand started in each bucket. |
| Resolved by Captain | Counts autonomously resolved outcome episodes
whose demand started in each bucket. |
## Description
Contact export builds its CSV with the standard library `CSV`, which
writes user-supplied values (name, email, phone, custom attributes)
verbatim. When a cell begins with a formula character (`=`, `+`, `-`,
`@`, and tab/CR), spreadsheet applications interpret it as a formula on
open. This switches the export to `CSVSafe` (the `csv-safe` gem already
used by the v2 report exports), which prefixes such fields so they are
treated as text.
No new dependency, no behavioural change beyond neutralising
formula-leading cells. Note: phone numbers stored with a leading `+` are
now prefixed with a single quote in the exported file, consistent with
how the report exports already behave.
Ref https://linear.app/chatwoot/issue/CW-7473
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
`bundle exec rspec spec/jobs/account/contacts_export_job_spec.rb` —
added a case asserting a formula-leading contact value is neutralised on
export; existing cases updated for the phone-number prefix.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
## Summary
Adds conversation usage to Captain documents and user created FAQs. Only
knowledge used in a Captain answer sent to the contact is counted.
Lookups that end in a handoff are excluded.
Administrators can see how many distinct conversations used a knowledge
record. Document usage appears in the Usage tab inside document details.
User created FAQ usage appears on each FAQ card and opens in a
conversation panel.
Deleted conversations are excluded from counts, sorting, and
conversation lists.
Usage shown in side panel
<img width="2342" height="1502" alt="CleanShot 2026-08-12 at 18 29
02@2x"
src="https://github.com/user-attachments/assets/67301051-6df5-4eb6-9b8d-e1fc75bb02f2"
/>
Sorting options
<img width="580" height="241" alt="image"
src="https://github.com/user-attachments/assets/078566b7-481b-491b-b484-c2fef481f1b1"
/>
## Access
Conversation usage is available only to administrators. Agents can still
view documents and FAQs, but they cannot see usage counts, the Usage
tab, the "Most used" sort, or conversation usage details.
The API applies the same rule. An agent request for `sort=most_used` is
rejected.
## Performance and pagination
Document and FAQ lists return 25 records per page. Usage counts are
calculated only for the records in each page.
Conversation usage panels load 25 conversations at a time and show a
"Load more" action when more conversations are available. The generated
FAQs tab also keeps its existing 25 item pagination.
The count queries use the JSON indexes on `document_ids` and
`used_faq_ids`. The "Most used" sort aggregates one assistant's sessions
once before it sorts and returns the requested document page.
## How to test
1. Sign in as an administrator and open the Captain documents page for
an assistant with tracked document usage.
2. Open a document and confirm that the Usage tab shows the distinct
conversation count and the matching conversations.
3. Select "Most used" and confirm that documents are ordered by distinct
conversation usage.
4. Open the user created FAQs page and confirm that FAQ cards show their
usage count and open the matching conversations.
5. Confirm that usage panels show 25 conversations first and can load
the next page.
6. Trigger a knowledge lookup that ends in a handoff and confirm that it
does not increase document or FAQ usage.
7. Sign in as an agent and confirm that usage counts, usage details, and
the "Most used" sort are not available.
## Closes
[CW-7498](https://linear.app/chatwoot/issue/CW-7498/fe)
Message pagination now constrains client-provided cursors to the
PostgreSQL integer range used by `messages.id`, preventing oversized
values from raising database errors while preserving before/after
pagination semantics.
## Closes
-
[CW-7922](https://linear.app/chatwoot/issue/CW-7922/harden-backend-paths-causing-production-sentry-errors)
- [Sentry 7663397140](https://chatwoot-p3.sentry.io/issues/7663397140/)
- [Sentry 7663397546](https://chatwoot-p3.sentry.io/issues/7663397546/)
- [Sentry 7663464772](https://chatwoot-p3.sentry.io/issues/7663464772/)
## How to reproduce
Request conversation messages with an extremely large `before` or
`after` cursor, such as `4611686018427387903`. PostgreSQL previously
rejected the value as outside the range for the integer `messages.id`
column.
## What changed
- Normalize message cursors before they reach the query.
- Clamp them to the valid signed 32-bit integer ID range.
- Cover oversized `before` and `after` cursors with finder specs.
Contact and conversation filters now reject malformed numeric/date
custom-attribute values and dangling query operators during validation,
returning the existing invalid-filter response instead of failing later
while building SQL.
## Closes
-
[CW-7922](https://linear.app/chatwoot/issue/CW-7922/harden-backend-paths-causing-production-sentry-errors)
- [Sentry 7663920842](https://chatwoot-p3.sentry.io/issues/7663920842/)
- [Sentry 7663378104](https://chatwoot-p3.sentry.io/issues/7663378104/)
## How to reproduce
Submit a custom numeric attribute filter with an empty value, or end a
filter payload with a nonblank `query_operator`. These inputs previously
reached coercion/query construction and raised production exceptions.
## What changed
- Validate numeric and date custom-attribute values before query
construction.
- Preserve presence operators, which do not require a comparison value.
- Reject a query operator on the final filter condition.
- Add contact and conversation service regression coverage.
Round-robin queue resets now leave the Redis queue empty when an inbox
has no members, avoiding an invalid sorted-set write while keeping
normal queue population unchanged.
## Closes
-
[CW-7922](https://linear.app/chatwoot/issue/CW-7922/harden-backend-paths-causing-production-sentry-errors)
- [Sentry 7663380084](https://chatwoot-p3.sentry.io/issues/7663380084/)
## How to reproduce
Run round-robin assignment for an inbox with no inbox members. Resetting
the queue previously attempted a Redis sorted-set write without any
member/score pairs.
## What changed
- Clear the existing queue as before.
- Skip queue population when there are no eligible user IDs.
- Add service coverage for an inbox with no members.
## Description
The CSAT survey response CSV export builds rows with the standard
library `CSV`, writing values verbatim, including the feedback message,
which is free text submitted by end users. When a cell begins with a
formula character (`=`, `+`, `-`, `@`, and tab/CR), spreadsheet
applications interpret it as a formula on open. This switches the three
`CSV.generate_line` calls in the export template to
`CSVSafe.generate_line` (the `csv-safe` gem already used by the v2
report exports), which prefixes such fields so they are treated as text.
No new dependency, no behavioural change beyond neutralising
formula-leading cells.
Ref https://linear.app/chatwoot/issue/CW-7473
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
`bundle exec rspec
spec/controllers/api/v1/accounts/csat_survey_responses_controller_spec.rb`
— added a case asserting a formula-leading feedback value is neutralised
in the downloaded CSV.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
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.
Captain now treats consecutive customer messages as one request before
it asks a question, searches the knowledge base, or suggests a solution.
It uses the full message burst to identify the customer's goal and
current state. It checks conflicting details before relying on them.
## How to test
1. Send several customer messages in a row that describe one issue. Add
a short correction in a later message.
2. Confirm Captain uses all the messages before it asks a question,
searches the knowledge base, or suggests a solution.
3. Send another message with a detail that conflicts with information
Captain already checked. Confirm Captain checks the detail again before
relying on it.
## Description
The shared duration input enforced its minimum after every keypress.
When the minimum was 10, typing `45` changed the first digit to `10`, so
the second digit produced `105`.
This change lets people finish typing before the input applies its
minimum and maximum. The input now normalizes the value when it loses
focus or when the person presses Enter.
## Type of change
- [x] Bug fix
## How has this been tested?
- Added a component test that types `4`, then `5`, and confirms that the
value stays `45`.
- Confirmed that values below 10 and above 100 are normalized when the
input loses focus.
- Ran the focused Vitest file and ESLint.
- Ran a local deterministic Playwright test through the delayed
automation form. The test typed `45`, saved the rule, confirmed
`execution_delay: 45` in the API response, confirmed `Runs after 45m` in
the list, and removed the test rule.
## 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 fix works.
- [x] The focused unit and browser tests pass locally.
# Pull Request Template
## Description
This PR fixes the reply editor staying at its default height when
Copilot generates a suggestion, causing longer suggestions to be clipped
after a line or two.
The editor now automatically grows to fit the suggestion, up to a
maximum of 350px, and returns to the height it had before the suggestion
when it is accepted or discarded. Manual resizing continues to work as
expected and always takes priority.
### How to reproduce
1. Open a conversation and generate a Copilot suggestion (✨ → Summarize
the conversation).
2. The reply editor stays at its default height and the suggestion gets
clipped after a line or two.
3. Resize the reply editor, generate another suggestion, and discard it.
The editor no longer returns to the height you set.
### What changed
* `CopilotEditor` measures the rendered suggestion and requests enough
space to display it, capped at 350px. The requested height is released
when the suggestion is gone.
* `ResizableEditorWrapper` handles this requested height separately from
the manually dragged height, so the suggestion can grow the editor
without overriding the user's preferred height.
* The loading and suggestion states now cross-fade in place while the
editor resizes, instead of briefly switching through an empty card.
### Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Screencast
https://github.com/user-attachments/assets/d9a5dab9-6206-4333-92d1-d3f710f9022e
## 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
## 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>
Failed messages on external provider-delivery channels can appear sent
after an agent selects Retry even though the retry never reaches the
provider. This change clears the stale provider delivery ID before
retrying the existing message, allowing the channel service to create a
fresh provider attempt and store its new ID.
API and WebWidget messages are excluded because their `source_id` values
may be client-supplied correlation identifiers and their retry jobs do
not assign replacement provider IDs. Concurrent or stale retry requests
are also guarded so only the request that successfully claims a failed
message can enqueue delivery.
Fixes https://github.com/chatwoot/chatwoot/issues/14120
Related:
https://linear.app/chatwoot/issue/CW-6896/retrying-a-failed-whatsapp-message-silently-succeeds-locally-but-never
### Things to know
- Applies to external provider-delivery channels, including direct
WhatsApp and Twilio WhatsApp.
- Preserves `source_id` for `Channel::Api` and `Channel::WebWidget`.
- Reuses the existing Chatwoot message record while allowing the
provider to return a new message ID.
- Logs the cleared provider ID and Chatwoot message ID when a stale
provider ID is removed.
### How to reproduce
1. Send a message that the provider accepts and later marks as failed
through a status callback.
2. Select Retry on the failed message.
3. Observe that Chatwoot changes the message to sent but does not
contact the provider because the previous provider message ID remains
present.
### How to test
1. In an external provider inbox, retry a failed message that has an
existing provider message ID.
2. Confirm the old provider ID is cleared before delivery and the retry
reaches the provider.
3. Confirm the provider assigns a fresh message ID and subsequent status
callbacks update the retried message.
4. Retry a failed API or WebWidget message and confirm its existing
`source_id` is preserved.
5. Trigger concurrent retry requests for the same failed message and
confirm only one delivery job is queued.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
The WhatsApp health status page fails to render for accounts using
underscore-based regional locales such as `pt_BR`. The browser rejects
that locale when formatting the last-onboarded timestamp, leaving the
page blank even though health data loaded successfully.
This change formats the timestamp with Chatwoot’s shared resolved
locale, which normalizes and validates the locale before passing it to
the browser. Other health status behavior remains unchanged.
### How to reproduce
1. Set the dashboard language to Portuguese (Brazil).
2. Open an inbox’s WhatsApp health status page when the response
includes `last_onboarded_time`.
3. Observe that the page remains blank with `RangeError: Invalid
language tag: pt_BR` in the browser console.
### How to test
1. Use an account with Portuguese (Brazil) selected.
2. Open the WhatsApp health status page for an inbox with onboarding
data.
3. Confirm the complete health status page loads and the last-onboarded
timestamp is formatted in the selected locale.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
After a successful super admin login, redirect to the super admin
dashboard (`super_admin_root_path`) instead of the users list. The
dashboard is a lighter, overview-first landing page, while the users
index does an exact count over the full users table on every load and
can be slow on large instances.
This only changes the post-login landing page. The users list is still
reachable from the navigation.
Fixes https://linear.app/chatwoot/issue/CW-7928
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added request specs for `SuperAdmin::Devise::SessionsController#create`:
- successful login redirects to `super_admin_root_path`
- invalid credentials redirect back to the login page
`bundle exec rspec
spec/controllers/super_admin/devise/sessions_controller_spec.rb` -> 3
examples, 0 failures.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
Captain can now use each assistant's saved setting when a customer stops
replying. Captain can review the conversation and resolve or hand it
off, resolve it after the selected time without review, or leave it
pending until the customer replies.
The job checks the conversation again while holding a database lock
before it changes the status. A new customer reply or another worker
cannot cause an outdated resolve or handoff.
## Closes
[AI-163](https://linear.app/chatwoot/issue/AI-163)
## What changed
- Added assistant modes for review, always resolve, and wait for the
customer.
- Kept the account setting as the fallback for assistants that do not
have a saved mode.
- Skipped scheduling when resolution is disabled on the assistant or
through the older account setting.
- Rechecked the conversation status and activity time before each
resolve or handoff.
- Recorded events only after a status change succeeds.
- Kept out of office messages out of campaign conversations.
## How to test
1. Set an assistant to review conversations. Run the inactivity job with
complete and incomplete decisions. Confirm the first conversation is
resolved and the second is handed off.
2. Set the assistant to always resolve. Confirm an eligible pending
conversation is resolved after the selected time.
3. Set the assistant to wait for the customer. Confirm the scheduler
does not enqueue the inactivity job and the conversation remains
pending.
4. Add a customer reply while the review is running. Confirm the job
does not resolve or hand off the updated conversation.
5. Run two workers for the same conversation. Confirm only one status
change and one event are recorded.
---------
Co-authored-by: iamsivin <iamsivin@gmail.com>
## Description
Fixes account scoping for Captain assistant responses.
Create and update accepted an `assistant_id` from the request. The model
then set the response account from that assistant. The controller lookup
read the top level parameter, while the API sends the ID inside
`assistant_response`, and create did not use the lookup result.
The controller now resolves the nested assistant ID through
`Current.account`, removes `assistant_id` before assigning request
fields, and assigns the scoped assistant directly. The model now fills
the account only when it is blank and rejects a response when its
account and assistant do not match.
Linear issue:
[CW-7913](https://linear.app/chatwoot/issue/CW-7913/ghsa-phpm-m2mf-r8r9-captain-assistant-responses-writes-into-another)
## Type of change
- [x] Bug fix
## How has this been tested?
- Ran `bundle exec rspec
spec/enterprise/controllers/api/v1/accounts/captain/assistant_responses_controller_spec.rb
spec/enterprise/models/captain/assistant_response_spec.rb`. All 19
examples passed.
- Ran the two new account isolation examples against the original code.
Both failed and reproduced the create and update issue. Both pass with
this fix.
- Ran RuboCop on the five changed Ruby files. It found no offenses.
## 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 fix is effective
- [x] New and existing unit tests pass locally with my changes
Twilio voice calls now get an AI transcript alongside the recording.
Once a call ends and its recording is stored, we transcribe it and show
the text under the audio player in the call bubble — the same experience
WhatsApp voice notes already have. Transcription runs on Captain and
consumes Captain response credits, so it only kicks in for accounts with
Captain enabled and audio transcriptions turned on.
## How to test
1. On an account with Captain enabled and Settings → Account → Audio
transcriptions on, make a call on a Twilio voice inbox and hang up.
2. Open the conversation. The voice call bubble shows the recording
player once Twilio delivers the recording.
3. Shortly after, the transcript appears under the player — no refresh
needed.
4. Turn audio transcriptions off (or exhaust Captain credits) and
repeat: the recording still appears, the transcript does not.
## What changed
- `Llm::SpeechToTextService` (new) — blob-in/text-out transcription
engine extracted from `Messages::AudioTranscriptionService`: size limit,
temp-file download, model resolution via `Llm::FeatureRouter`, the
OpenAI call, and Captain credit accounting. `.available_for?` holds the
shared gate.
- `Messages::AudioTranscriptionService` — now a thin wrapper over that
engine; its public contract is unchanged, so
`Captain::OpenAiMessageBuilderService` is unaffected.
- `Voice::CallTranscriptionService` / `Voice::CallTranscriptionJob`
(new) — transcribe `call.recording` into `calls.transcript`, then
rebroadcast the message so clients pick it up over the wire.
- `Voice::Provider::Twilio::RecordingAttachmentService` — enqueues the
job after the recording is attached.
The API and frontend needed no changes: `calls.transcript` already
existed, `_call.json.jbuilder` already serialized it, and
`VoiceCall.vue` already fed it to the audio chip. Nothing had ever
written the column.
Also wires `instrument_audio_transcription`, which existed but was never
called, so both transcription paths now emit LLM spans.
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)
WhatsApp click-to-chat ad referrals are already stored on incoming
messages, but agents only see the customer’s text. This displays the
originating ad preview directly in the message bubble, including
available media, headline, body, and source link. Attribution
identifiers remain hidden.
### Things to know
- The card renders only when `content_attributes.referral` is present.
- Invalid or non-HTTP media and source URLs fall back safely.
- Existing messages without referral metadata are unchanged.
### How to test
1. Open a WhatsApp conversation containing an incoming message with
`content_attributes.referral`.
2. Confirm the ad preview appears above the customer text.
3. Confirm the source opens in a new tab and missing or invalid media
does not break the message bubble.
Fixes
https://linear.app/chatwoot/issue/CW-6206/add-whatsapp-ad-preview-support-in-chatwoot-inbox
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## 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>
# Pull Request Template
## Description
This PR fixes the mention picker staying open when switching between
Reply and Private Note, or when switching conversations while a picker
is open. The picker could keep a stale range from the previous editor
state, and selecting an agent from it would crash the editor with
`RangeError: Position N out of range`.
The pickers now close whenever the editor content is rebuilt, and the
stored suggestion range is cleared before creating the new editor state.
This is a pre-existing issue and not a regression from the picker PR.
For the mention picker to open, `@` needs to be at the start of a line
or preceded by whitespace, so the repro uses `hello @` instead of
`abc@`.
#### What changed
Rebuilding the editor state creates new plugin instances, so the old
suggestion plugin is removed without calling `onExit`. This leaves the
picker's stored range pointing to a document that no longer exists.
`reloadState` now clears the stored suggestion range and closes all open
pickers before rebuilding the editor state.
This is a pre-existing issue and not a regression from the picker PR.
Fixes
https://linear.app/chatwoot/issue/CW-7919/mention-picker-opens-on-an-empty-private-note-and-crashes-when-an
## Type of change
- [x] Breaking change (fix or feature that would cause existing
functionality not to work as expected)
## How Has This Been Tested?
### Steps to reproduce
1. Open a conversation and stay in Reply mode.
2. Type `hello @` to open the mention picker.
3. Switch to Private Note.
4. Click any agent from the still-open picker.
5. The editor crashes with `RangeError: Position N out of range`.
6. The same issue can be reproduced by switching to another conversation
while a picker is open.
## 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
# Pull Request Template
## Description
This PR bumps lettersanitizer to 1.0.8, because that release includes a
[patch][1] that fixes an [issue][2] affecting Chatwoot: in some cases,
if you receive a malformed email with deeply-nested tags considered
unvalid by `lettersanitizer`, just selecting the email in your inbox
causes the browser tab or even the whole computer to freeze, due to RAM
exhaustion.
[1]: https://github.com/mat-sz/lettersanitizer/pull/10
[2]:
https://github.com/mat-sz/lettersanitizer/security/advisories/GHSA-hhw2-373g-hx77
Edit: also bump `vue-letter` to 0.2.2 to update its own
`lettersanitizer` dependency
(https://github.com/mat-sz/vue-letter/pull/3), per
https://github.com/chatwoot/chatwoot/pull/14959#discussion_r3546868353.
## Type of change
Please delete options that are not relevant.
- [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?
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:
- [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
- [ ] 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
- [x] Any dependent changes have been merged and published in downstream
modules
Canned response search now removes NUL bytes from user-provided search
text before passing it to PostgreSQL, so malformed input returns normal
search results instead of a database encoding error.
## Closes
-
[CW-7922](https://linear.app/chatwoot/issue/CW-7922/harden-backend-paths-causing-production-sentry-errors)
- [Sentry 7663466064](https://chatwoot-p3.sentry.io/issues/7663466064/)
## How to reproduce
Call the canned responses endpoint with a search parameter containing a
NUL byte. PostgreSQL previously raised `PG::UntranslatableCharacter`
while evaluating the search query.
## What changed
- Strip NUL bytes once at the controller boundary.
- Reuse the sanitized value for matching and result ranking.
- Add request coverage for a search term containing a NUL byte.
Bumps [dompurify](https://github.com/cure53/DOMPurify) from 3.4.11 to
3.4.13.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/cure53/DOMPurify/releases">dompurify's
releases</a>.</em></p>
<blockquote>
<h2>DOMPurify 3.4.13</h2>
<ul>
<li>Fixed an issue with hook removal during <code>IN_PLACE</code>
sanitization, thanks <a
href="https://github.com/koyokr"><code>@koyokr</code></a></li>
<li>Fixed an issue with hooks potentially bypassing the clone guard,
thanks <a
href="https://github.com/AkshayjainG"><code>@AkshayjainG</code></a></li>
<li>Fixed an issue with DOM clobbering via <code>ownerDocument</code>
during <code>IN_PLACE</code>, thanks <a
href="https://github.com/AkshayjainG"><code>@AkshayjainG</code></a></li>
<li>Bumped several dependencies where possible</li>
</ul>
<h2>DOMPurify 3.4.12</h2>
<ul>
<li>Fixed an issue where a hook would not get called for custom
elements, thanks <a
href="https://github.com/Rikuxx0"><code>@Rikuxx0</code></a></li>
<li>Hardened the handling of hooks removing elements, <a
href="https://github.com/mkrause-bee360"><code>@mkrause-bee360</code></a></li>
<li>Added support for a few new SVG attributes, thanks <a
href="https://github.com/cbn-falias"><code>@cbn-falias</code></a> &
<a
href="https://github.com/Develop-KIM"><code>@Develop-KIM</code></a></li>
<li>Hardened the handling of declarative partial updates</li>
<li>Updated the documentation is several spots, README, wiki, etc.</li>
<li>Bumped several dependencies where possible</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="3067f77467"><code>3067f77</code></a>
release: 3.4.13 (<a
href="https://redirect.github.com/cure53/DOMPurify/issues/1562">#1562</a>)</li>
<li><a
href="a9ca1e5374"><code>a9ca1e5</code></a>
release: 3.4.12 (<a
href="https://redirect.github.com/cure53/DOMPurify/issues/1537">#1537</a>)</li>
<li>See full diff in <a
href="https://github.com/cure53/DOMPurify/compare/3.4.11...3.4.13">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/chatwoot/chatwoot/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
## Description
`SearchService#filter_conversations` matches conversations on the
display id and on the contact name, email, phone number and identifier.
It never looks at message content, so a conversation with no messages is
a valid result whenever its contact matches.
The search views did not account for that. They rendered
`conversation.messages.try(:first)`, which is `nil` for such a
conversation, and `api/v1/models/_message` calls `message.id` on it:
```
ActionView::Template::Error (undefined method 'id' for nil):
1: json.id message.id
app/views/api/v1/models/_message.json.jbuilder:1
app/views/api/v1/accounts/search/_message.json.jbuilder:1
app/views/api/v1/accounts/search/conversations.json.jbuilder:8
```
A single conversation without messages is enough to turn the whole
search request into a 500 for that query, so the agent loses
conversation search entirely until that conversation gets a message.
Both views that render a conversation search result were affected, so
this applies to `GET /search/conversations` and to the combined `GET
/search`.
The fix guards the message partial the same way the neighbouring
`contact`, `inbox` and `agent` partials in those same views are already
guarded. When there is no message the key is rendered as an empty
object, which is what already happens for a missing contact, inbox or
assignee.
**How to reproduce**
1. Create a conversation without any message (for example via `POST
/api/v1/accounts/{id}/conversations` without a `message`).
2. Search for the contact's name or phone number: `GET
/api/v1/accounts/{id}/search/conversations?q=<phone>`.
3. The request returns 500.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added one spec per affected endpoint in
`spec/controllers/api/v1/accounts/search_controller_spec.rb`, each
creating a conversation with no messages whose contact matches the query
and asserting that it is returned. Both fail with a 500 before the
change.
Also reproduced manually on a running instance: searching a contact that
had a conversation with no messages returned 500, and returns 200 with
`"message": {}` after the change.
## 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] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] Any dependent changes have been merged and published in downstream
modules
---
Related: #15289 documents the atomic `POST /conversations` with an
inline `message`, which avoids creating conversations without messages
in the first place. This fix is independent of it — it protects the
search regardless of how the conversation ended up without messages
(created by an agent before replying, by an API integration, by campaign
tooling, or by a flow that did not complete).
Co-authored-by: Sojan Jose <sojan@pepalo.com>
Contact avatars could be skipped when an avatar job was enqueued while
the contact record was still inside an open database transaction. A fast
worker could pick up the job before the record became visible and
discard it after deserialization failed.
This change makes avatar URL jobs wait for the surrounding transaction
to commit before they enter the queue. Avatar jobs scheduled outside a
transaction continue to enqueue immediately, and the existing download,
validation, and rate-limiting behavior remains unchanged.
Fixes
https://linear.app/chatwoot/issue/CW-7917/facebook-contact-avatars-never-sync-avatarfromurljob-is-enqueued
### How to reproduce
1. Receive a Facebook message from a sender who does not yet exist as a
contact.
2. Let the message flow create the contact and schedule its avatar job
within the same transaction.
3. Observe that a worker can attempt to deserialize the contact before
the transaction commits, causing the avatar job to be discarded.
### How to test
1. Receive a Facebook message from a new sender with a profile picture.
2. Confirm the contact and conversation are created successfully.
3. Confirm the avatar job is enqueued after the transaction commits and
the profile picture is attached.
4. Create a contact with an avatar through the Contacts API and confirm
the same behavior.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
# Pull Request Template
## Description
This PR adds search and preview support to the mention, variable, and
emoji pickers, bringing them in line with the canned response picker.
All editor pickers now use the same component with their own search
field, keyboard navigation, caret-anchored placement, and a preview
pane.
Variables show their description and the value resolved for the current
conversation, emojis show the glyph, name, shortcode, and category, and
mentions show relevant agent or team details such as availability, role,
auto-assign, and membership.
This also fixes company custom attributes incorrectly appearing as
contact custom attributes in the variable picker. They could create
duplicate entries and insert variables that always resolved to an empty
value, so they are now excluded.
The old `MentionBox` component has also been removed since the variable
and emoji pickers were its only remaining users.
Fixes
https://linear.app/chatwoot/issue/CW-7854/inconvenient-canned-response-picker-and-lack-of-personal-canned
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Screenshots
**Emoji Picker**
<img width="1302" height="527" alt="image"
src="https://github.com/user-attachments/assets/a491b149-d547-4ab4-b990-a054faf38ac1"
/>
**Variables Picker**
<img width="1305" height="487" alt="image"
src="https://github.com/user-attachments/assets/42a6d334-4f70-47e2-ada4-531cf8619454"
/>
<img width="444" height="556" alt="image"
src="https://github.com/user-attachments/assets/bccd15e1-e5af-4362-b1b5-27877910670c"
/>
**Tag agents/teams Picker**
<img width="1308" height="502" alt="image"
src="https://github.com/user-attachments/assets/547d9142-a6e5-4606-a9b7-01e824868b29"
/>
<img width="1308" height="502" alt="image"
src="https://github.com/user-attachments/assets/28cd4919-5875-462a-adc8-90c0fd8e8a3f"
/>
<img width="444" height="556" alt="image"
src="https://github.com/user-attachments/assets/33eaa131-c033-49e4-aa93-343c2a976d5b"
/>
### Steps
1. Type `@` in a private note. Verify agents and teams appear under
separate headings, and the preview shows availability and role for an
agent, and auto-assign and membership status for a team.
2. Type `{{` in a reply. Verify the preview shows the variable
description and the value resolved for the current conversation. Also
verify that a variable with no value clearly indicates that no value is
available.
3. Verify company custom attributes no longer appear in the variable
picker.
4. Type `:` followed by at least two characters. Verify emojis can be
searched by name and shortcode, and the preview shows the glyph, name,
and category.
5. For each picker, navigate with the arrow keys or Tab, insert with
Enter or a click, and close with Escape.
6. Reopen a conversation with a draft containing `@name`, `/shortcode`,
or `{{contact`. Verify the corresponding picker opens with the existing
text populated in its search field.
## 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
## Description
This systemd unit is installed on every self-hosted Linux install
(copied by `deployment/setup_18.04.sh` / `setup_20.04.sh`) as well as
our own worker hosts, so the memory cap has to be correct across a wide
range of box sizes.
It is currently a fixed `MemoryMax=1.2G`, chosen when workers ran on 2GB
hosts (#12915). On larger hosts that fixed cap sits at a high fraction
of the limit under normal load, so transient spikes hit the hard limit
and the worker is OOM-restarted more often than necessary (each restart
drops the jobs in-flight at that instant).
Switching to `MemoryMax=60%` makes the cap scale with the host's
physical memory instead of being fixed:
- 2GB host: 60% = 1.2G, identical to today (no regression for small
installs)
- 4GB host: 60% = ~2.4G, room to absorb spikes without a premature
restart
- larger hosts scale proportionally
`MemoryHigh=infinity` is unchanged, so the worker is still never
throttled by cgroup reclaim (kept intentionally since #12871 to avoid
reclaim-induced worker stalls). Only the hard cap changes, and only its
scaling.
Fixes https://linear.app/chatwoot/issue/INF-100
## Type of change
- [x] Performance (non-breaking change which improves performance)
MFA-authenticated users now remain signed in across browser restarts,
matching the session lifetime of password-authenticated users.
## Closes
-
[CW-7898](https://linear.app/chatwoot/issue/CW-7898/mfa-users-are-logged-out-when-the-browser-session-ends)
## How to reproduce
1. Enable MFA for a user.
2. Sign in and complete OTP or backup-code verification.
3. End the browser session, then reopen the browser and return to
Chatwoot.
4. Before this change, the user is sent back to the login page.
## Root cause and evidence
Before this change, successful MFA verification wrote
`cw_d_session_info` directly through `document.cookie` without an
`Expires` or `Max-Age` attribute. This makes it a session cookie:
- [MFA cookie creation on the base
commit](a4eae9710a/app/javascript/dashboard/components/auth/MfaVerification.vue (L70-L87))
- [MDN session-cookie
behavior](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie)
- [Chromium cookie persistence
documentation](https://chromium.googlesource.com/chromium/src/+/master/net/cookies/README.md)
Password login already uses `setAuthCredentials`, which derives a
persistent cookie expiry from the authentication response:
- [Existing credential
helper](a4eae9710a/app/javascript/dashboard/store/utils/api.js (L28-L36))
- [Configured two-month token
lifetime](a4eae9710a/config/initializers/devise_token_auth.rb (L8-L10))
This change routes successful MFA verification through the same
credential helper and existing verified event. The regression test
asserts that MFA credentials use this shared persistence path.
Session-cookie restoration is browser and profile dependent. Chromium
may persist session cookies when restoring a previous browsing session,
so the problem can be masked on some restarts. This PR does not rely on
a desktop-versus-mobile distinction.
## How to verify
1. On `develop`, complete an MFA login.
2. Inspect `cw_d_session_info` in browser developer tools. Its expiry is
shown as `Session`.
3. Repeat on this branch.
4. Confirm that `cw_d_session_info` has a concrete expiry derived from
the authentication response instead of `Session`.
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.
## Description
Captain Copilot's `get_conversation` tool returned any conversation in
the account, without checking whether the agent asking for it could open
that conversation from the inbox view. An agent who belongs to a single
inbox, or who holds a narrow custom role, could therefore read the
message history of conversations outside their access, including the
private notes on them.
The tool now runs the same permission filter that the conversation list
endpoint and Copilot's own `search_conversation` tool already use, so it
returns only the conversations the agent can already open.
Administrators see no change, because the filter returns the whole
account scope for them.
The Copilot chat service had the same gap. When an agent opened Copilot
while viewing a conversation, the service looked that conversation up by
account alone and wrote its ID and contact ID into the system prompt. It
now resolves the conversation through the same filter, and leaves the
context out when the agent cannot access it.
## Closes
https://linear.app/chatwoot/issue/CW-7768
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How to reproduce
1. Create two inboxes in one account, for example Inbox A and Inbox B.
2. Add an agent to Inbox A only, then start a conversation in Inbox B
and leave a private note on it.
3. Sign in as that agent, open Copilot, and ask it for the Inbox B
conversation by its ID.
4. Before the change Copilot returns the full message history including
the private note. After the change it reports that the conversation was
not found.
Opening the same conversation from the inbox view as that agent is
rejected both before and after the change, so the inbox view and Copilot
now agree on what the agent can read.
## 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
Automations that send an email transcript now let you insert the
conversation contact's email directly into the recipient field, instead
of only accepting a hardcoded address typed in by hand.
## Closes
https://linear.app/chatwoot/issue/CW-7535/allow-automation-to-send-conversation-transcripts-to-user-emails
## How to test
1. Go to **Settings → Automation → Create Automation** (or edit an
existing rule).
2. Add the **Send an Email Transcript** action.
3. Click **Use contact's email** next to the recipient field — it
inserts `{{contact.email}}` into the field, appending to any address
already typed rather than replacing it.
4. Save the rule and trigger it on a conversation with a contact that
has an email address; confirm the transcript is delivered to that
contact.
## What changed
- `AutomationActionInput.vue`: added a "Use contact's email"
quick-insert action next to the recipient field for the
`send_email_transcript` action, and switched the input from
`type="email"` to `type="text"` so the dynamic token isn't fought by
native email-format validation.
- No backend changes were needed — `send_email_transcript` already
resolves `{{contact.email}}` via the existing Liquid templating support
in `ActionService#send_email_transcript`; this change only exposes that
capability in the UI.
- This also benefits the Macros editor, which shares the same input
component.
---------
Co-authored-by: iamsivin <iamsivin@gmail.com>
Facebook inbox creation failures in Settings could leave users on the
same screen without explaining what went wrong. This change preserves
the backend error response and displays it through the existing toast
mechanism, making account-limit and other creation failures visible and
actionable.
The shared action now passes the original API error through, so the
newer onboarding flow also receives the specific backend message.
Successful Facebook inbox creation remains unchanged.
### How to reproduce
1. Use an account that has reached its inbox limit.
2. Go to Settings → Inboxes → Add Inbox → Facebook.
3. Select a Facebook Page and create the inbox.
4. Previously, the loading state ended without any visible error.
### How to test
1. Attempt Facebook inbox creation while the backend returns an HTTP 402
account-limit error.
2. Confirm the returned error appears as a toast message.
3. Retry after increasing the account limit and confirm inbox creation
continues normally.
### Things to know
The toast falls back to a generic localized creation error when the API
response does not contain a displayable message.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Improves SAML user handling for users associated with multiple accounts.
Restricts cross-account invitations and skips provider updates for
multi-account users.
Aligns SAML authentication and provider reset behavior with these
eligibility rules.
# Pull Request Template
## Description
This PR reworks the canned response picker to make it easier to search,
browse, and preview canned responses before inserting them. Typing `/`
now opens a larger picker with its own search field and a preview pane.
Previously, only a few responses were visible at a time, there was no
way to preview the full content, and searching relied on typing into the
composer, which stopped working for multi-word queries.
Search is now handled entirely inside the picker, so the composer stays
untouched while searching. Results match both the canned response
shortcut and its content, and each result shows a snippet centered
around the matched text instead of always displaying the beginning of
the response. The preview renders the response exactly as it will be
inserted, with variables resolved against the current conversation and
formatting unsupported by the channel already stripped.
The picker is positioned relative to the current typing line and
teleported to `body`, so it is no longer clipped by the composer. It
behaves consistently across the reply editor, the New Conversation
composer, and narrower editors such as Contact Notes, where the preview
moves below the list instead of disappearing.
This also fixes a pre-existing bug where variables without a value were
removed from the inserted text instead of being left for the backend to
resolve. In the New Conversation composer, where no variables are
available, all `{{ }}` placeholders were previously being silently
removed.
Fixes
https://linear.app/chatwoot/issue/CW-7854/inconvenient-canned-response-picker-and-lack-of-personal-canned
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Screenshots
<img width="1135" height="576" alt="image"
src="https://github.com/user-attachments/assets/b5f27b94-eeb5-4ac6-b6d9-da7dfd8c2306"
/>
<img width="393" height="490" alt="image"
src="https://github.com/user-attachments/assets/779f88b1-4958-41f5-9f51-c2eb8db7e53c"
/>
### Steps
1. Open a conversation and type `/` in the reply editor.
2. Search using a multi-word phrase that appears within a canned
response. Verify the matching response appears with a snippet centered
around the matched text.
3. Navigate the results with the arrow keys or Tab and verify the
preview updates.
4. Press Enter or click a response to insert it, and press Escape to
close the picker.
5. Repeat in a narrow editor such as Contact Notes and verify the
preview pane moves below the list.
6. In the New Conversation composer, insert a canned response containing
variables and verify the `{{ }}` placeholders are kept rather than
removed.
## 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
Captain V2 assistants can now persist a configurable inactivity timer
and choose whether inactivity resolution sends the saved closing message
or resolves silently. This PR contains only the API, persistence,
runtime behavior, and backend specs.
## Closes
[AI-163](https://linear.app/chatwoot/issue/AI-163)
## Depends on
Stack 2 of 5. Based on the assistant-policy foundation in #15299. The
frontend follows in #15308.
## What changed
- Added per-assistant inactivity duration and resolution-message
settings with safe defaults.
- Restricted the Part 2 settings API to Captain V2 while keeping the
Part 1 policy mode available without V2.
- Updated inactivity handling to use the assistant timer and skip the
public resolution message when disabled.
- Serialized the effective timer and message settings for the frontend.
- Added model, request, and job coverage, including the explicit Captain
V2 boundary.
## How to test
1. Enable Captain V2 and update `auto_resolve_after` and
`send_inactivity_resolution_message` through the assistant API.
2. Run the inactivity job and confirm it uses the assistant timer.
3. Disable the resolution message and confirm the conversation resolves
silently.
4. Disable Captain V2 and confirm timer/message updates are ignored
while `auto_resolve_mode` remains updateable.
---------
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>
Improves the WhatsApp template listing so account admins can understand
template state and refresh templates from one place. Templates that have
not entered the WhatsApp approval flow now use clearer wording, the
latest sync attempt appears once at page level, and templates can be
filtered by content type.
The page can now start a template sync across all active WhatsApp
inboxes in the account and reports complete or partial failures. The New
template action is removed for now; provider-side template management
remains unchanged.
### Related
Related: https://github.com/chatwoot/chatwoot/pull/15312
### How to test
1. Open **Settings → Templates** in an account with WhatsApp templates.
2. Confirm the latest sync attempt appears below the page description
and is no longer repeated on every template.
3. Confirm an unsubmitted template displays **Not submitted for WhatsApp
approval**.
4. Filter templates by content type and verify the list updates.
5. Click **Sync templates** and confirm sync starts for the account's
active WhatsApp inboxes.
6. Confirm the **New template** button is not displayed.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
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>
## 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.
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.
Assigning a conversation to an Agent Bot now moves it to pending.
Assigning a bot-owned pending conversation to a human opens it again,
while other assignment changes preserve the existing status. This makes
existing Agent Bot ownership behave like an AI handoff without depending
on the assignment dropdown UI work.
Closes:
https://linear.app/chatwoot/issue/CW-7448/apply-agent-bot-assignment-behavior
## Why
Agent Bot ownership should remove conversations from the main open queue
while the bot is handling them. Explicit human takeover should bring a
bot-owned pending conversation back to the open queue and clear the bot
owner.
## What changed
- Agent Bot assignment clears the human assignee and marks the
conversation pending.
- Human assignment clears the Agent Bot owner and opens the conversation
only when it was bot-owned and pending.
- Ordinary human assignment, non-pending bot takeover, and unassignment
preserve the existing conversation status.
- Manual human takeover uses the existing assignment and status events.
Bot-initiated handoffs continue to use the existing bot-handoff event
path.
## Validation
- Assign an open conversation to an Agent Bot through the assignment API
and verify it becomes pending.
- Assign that bot-owned pending conversation to a human and verify it
becomes open.
- Verify ordinary human assignment, non-pending bot takeover, and
unassignment do not force a status change.
WhatsApp inbox responses now return an empty template list when the
stored `message_templates` value is not an array. This prevents mobile
clients from receiving the legacy/default object shape that can crash
the WhatsApp reply box.
Valid template arrays remain unchanged.
Related: https://github.com/chatwoot/chatwoot-mobile-app/pull/1127
### Things to know
- No database migration or backfill is included.
- This does not change the web template-button behavior; that can be
handled separately.
### How to reproduce
1. In a local environment, set a WhatsApp inbox's `message_templates`
value to `{}`.
2. Load the inbox API response and open one of its conversations in the
mobile app.
3. Confirm the response contains `message_templates: []` and the reply
box does not crash.
4. Repeat with a valid template array and confirm the templates are
preserved.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Captain assistants now support **audience** and **schedule** controls,
so you can decide *who* an assistant replies to and *when* it's on duty.
By default nothing changes, an assistant still responds to every
conversation in its connected inboxes but you can now narrow that down.
- **Audience**: build a condition tree (contact attributes, conversation
attributes, and custom attributes) with and/or groups, mirroring the
contact-segment filter semantics. Only conversations whose contact
matches the audience get a Captain reply.
- **Schedule**: choose when Captain replies — *Anytime*, *During
business hours*, or *Outside business hours* (based on each inbox's
configured working hours; inboxes without business hours are always
covered).
When an assistant opts out of a conversation (contact outside the
audience, or off-schedule), the conversation is routed to the human
queue instead of being parked pending on a silent bot — both on initial
creation and on reopen.
Fixes
https://linear.app/chatwoot/issue/CW-7414/audience-and-availability-controls
|Audience|Availability|
|--|--|
| <img width="1132" height="627" alt="Screenshot 2026-06-30 at 5 52
09 PM"
src="https://github.com/user-attachments/assets/866910e0-e1d7-4248-8630-d91afc758688"
/> | <img width="1131" height="539" alt="Screenshot 2026-06-30 at 5 52
13 PM"
src="https://github.com/user-attachments/assets/aad0d6f7-ceb7-4546-a049-095c5b46b483"
/> |
## How to test
1. Open **Captain → Assistants → (an assistant) → Settings**.
2. Under **Audience**, add a condition or condition group (e.g. `Contact
language equal_to en`) and save. Start a conversation from a contact
that does *not* match — Captain should stay silent and the conversation
should land in the human (open) queue instead of pending.
3. With a matching contact, Captain should respond as before.
4. Under **Schedule**, pick **During business hours** (or **Outside
business hours**) on an inbox that has working hours configured, and
confirm Captain only engages within/outside that window. An
empty/`Anytime` schedule always responds.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Aakash Bakhle <48802744+aakashb95@users.noreply.github.com>
Co-authored-by: aakashb95 <aakashbakhle@gmail.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
An agent who is removed from an inbox could still see that inbox's
conversations under the **Participating** filter. Removing an agent from
an inbox does not delete the conversation participant records they
already had, and the participating filter was ignoring inbox access
entirely — so those conversations stayed visible indefinitely. The
filter now respects inbox access like every other conversation filter.
## Linear Ticket
- https://linear.app/chatwoot/issue/CW-6923
## How to reproduce
1. Add an agent to two inboxes, A and B.
2. As that agent, become a participant on a conversation in inbox B
(open it, or get added as a participant).
3. Remove the agent from inbox B in Settings → Inboxes → Collaborators.
4. Log in as the agent and open Conversations → Participating.
5. The inbox B conversation is still listed, and is openable.
## What changed
`ConversationFinder#filter_by_conversation_type` **replaced**
`@conversations` with `current_user.participating_conversations` for the
`participating` type, discarding the inbox/permission-filtered scope
built up by `Conversations::PermissionFilterService` immediately before
it. It now narrows the existing scope by participating ids instead, so
permission filtering survives.
Data Imports is now part of the shared paid-plan entitlement set.
Startups, Business, and Enterprise accounts receive the feature through
billing reconciliation, while Hacker/default accounts remain gated and
the existing API/UI feature checks stay unchanged.
### Closes
-
[CW-7878](https://linear.app/chatwoot/issue/CW-7878/enable-data-imports-for-all-paid-cloud-plans)
## 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?
1. Reconcile a Hacker account and confirm Data Imports remains disabled.
2. Reconcile Startups, Business, and Enterprise accounts and confirm
Data Imports is enabled for each paid tier.
3. Exercise the Stripe subscription update path and confirm the same
plan hierarchy is applied.
## Rollout
Existing paid accounts need a one-time reconciliation after deployment.
Run the following in the Rails console:
```rb
paid_plan_names = InstallationConfig.find_by!(name: 'CHATWOOT_CLOUD_PLANS').value.drop(1).pluck('name')
paid_accounts = Account.where("custom_attributes ->> 'plan_name' IN (?)", paid_plan_names)
puts "Reconciling #{paid_accounts.count} paid accounts"
paid_accounts.find_each do |account|
Enterprise::Billing::ReconcilePlanFeaturesService.new(account: account).perform
end
```
Future plan changes and subscription renewals are handled by the normal
Stripe reconciliation path.
## 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
## Linear Ticket
-
https://linear.app/chatwoot/issue/CW-6884/nudge-users-with-a-dashboard-banner-when-2fa-backup-codes-run-low
## Description
Shows a dashboard-wide banner when the signed-in user has 3 or fewer
unused backup codes left (amber), turning to an alert style at 0
remaining. Clicking "Generate codes" takes the user to the MFA settings
page so they can regenerate codes before they get locked out. Inspired
by Google's post-backup-code-use nudges.
## How to test
1. Sign in as a user with MFA enabled.
<img width="1512" height="824" alt="Screenshot 2026-08-05 at 4 52 15 PM"
src="https://github.com/user-attachments/assets/08138f3e-cc15-451e-bbcc-7772dc2a875c"
/>
<img width="1507" height="701" alt="Screenshot 2026-08-05 at 4 54 02 PM"
src="https://github.com/user-attachments/assets/580051fa-cbb5-47c1-81a3-258b7c5b5a03"
/>
2. In a Rails console, simulate a low state by marking most backup codes
as used:
```ruby
u = User.find_by(email: '<your user>')
codes = u.otp_backup_codes.dup
(0...8).each { |i| codes[i] = 'XXXXXXXX' }
u.otp_backup_codes = codes
u.save!
```
3. Reload any dashboard page — the amber banner should appear with a
"Generate codes" CTA.
4. Click the CTA — it should route to **Profile → Two-Factor
Authentication**, where you can regenerate codes.
5. Set the count to 0 (mark all 10 as `'XXXXXXXX'`) — banner should
switch to the red/alert style.
6. Regenerate codes — banner should disappear on the next dashboard page
load.
## 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
> Base is the [disable-with-backup-code PR
branch](https://github.com/chatwoot/chatwoot/pull/14102) so CTAs around
recovery are consistent; rebase onto `develop` once that merges.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
When an agent has multiple tabs or windows open on the same account, an
inbound WhatsApp call rings in all of them, as expected. But once the
call is answered in one tab, the others never found out — they kept
showing the incoming-call popup and playing the ringtone indefinitely,
as if the call were still waiting to be picked up.
## How to reproduce
1. Log into the same agent account in two browser tabs.
2. Receive an inbound WhatsApp call (rings in both tabs).
3. Accept the call in one tab.
4. The other tab keeps ringing and shows the call as still incoming.
## What changed
- The backend already broadcasts a `voice_call.accepted` event
account-wide when a call is answered, but the dashboard never had a
listener registered for it — the event was silently dropped. Added the
missing handler in `actionCable.js` so every tab except the one that
owns the now-active call clears its ringing state.
- Added `root: true` to `.eslintrc.js` so ESLint config resolution stops
at the project root instead of also picking up a parent directory's
config (this repo's git-worktree layout nests worktrees under the main
checkout, which was causing an ambiguous plugin-resolution error for
anyone linting from a worktree).
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
## Description
**Problem.** The default Active Storage upload route, `POST
/rails/active_storage/direct_uploads`, is mounted automatically by Rails
and requires no authentication. Chatwoot doesn't rely on it, our
dashboard and widget uploads all use scoped, authenticated endpoints, so
the route just sits there letting anyone create blobs anonymously.
**Fix.** Block the built-in route so it returns `403`. Chatwoot's own
upload controllers inherit from the same Rails class but are left
working, an `instance_of?` check makes the block apply only to the bare
route, not to the subclasses that call `super`.
Fixes https://linear.app/chatwoot/issue/INF-94
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added a request spec asserting the bare route returns `403` and creates
no blob. Existing widget and conversation direct-upload specs still
pass, confirming the scoped endpoints are unaffected.
13 examples, 0 failures across the three direct-upload specs; rubocop
clean.
## 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 or that my
feature works
- [x] New and existing unit tests pass locally with my changes
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
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
When an agent starts a new conversation, the WhatsApp template picker in
the composer only shows templates that were already loaded into the
frontend store — it doesn't refresh when the composer opens. If a
template sync completed after the store was last populated, the newly
synced template shows up on the inbox's Settings > Templates page (which
always refetches on load) but not in the New Conversation composer,
since that view relied solely on the account-cache-invalidated websocket
event, which doesn't always reach an already-open session in time.
## What changed
- `ComposeConversation.vue` now dispatches a cache-aware `inboxes/get`
refetch every time the composer popover opens, so the WhatsApp template
list is current before an agent picks a template to message a customer.
The refetch checks the account's cache key first and only re-pulls the
full inbox list when it's actually stale, so it stays cheap in the
common case.
## How to reproduce
1. Sync/update WhatsApp templates for an inbox (e.g. via Settings >
Inboxes > [WhatsApp inbox] > Sync Templates).
2. Without reloading the page, open the New Conversation composer for
that inbox and check the WhatsApp template picker — a newly synced
template may be missing until this fix.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
# Pull Request Template
## Description
The unsaved changes panel in the Help Center article editor now uses the
shared `SidePanel` component instead of its own custom drawer. It now
matches the rest of the dashboard, with the same slide-in animation,
backdrop, and close button for a consistent experience.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Screenshots
**Before**
<img width="1530" height="879" alt="image"
src="https://github.com/user-attachments/assets/4ef7eafb-0cd6-455f-a970-e1411a24ef25"
/>
**After**
<img width="1530" height="879" alt="image"
src="https://github.com/user-attachments/assets/be99ee0d-1906-4a49-967b-3ba1f4fa40b6"
/>
## 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
# Pull Request Template
## Description
This PR fixed the conversation list was incorrectly rendering the avatar
upload overlay on every conversation card, even though uploads aren't
supported there. Clicking it could throw a `TypeError: Cannot read
properties of null (reading 'click')`. Conversation cards now only show
the selection checkbox, while avatar uploads continue to work everywhere
they're supported.
### Cause
`ConversationCard` always passed the `#overlay` slot, but the checkbox
inside it was wrapped in `v-if`. When the checkbox wasn't rendered, Vue
treated the slot as empty and fell back to the default upload overlay
from `Avatar`.
That overlay's click handler expects a file input, but the file input is
only rendered when `allowUpload` is enabled. Since conversation cards
never enable uploads, clicking the overlay could dereference a null file
input and throw.
### How to reproduce
This isn't reliably reproducible manually. It only happens when the
upload overlay becomes visible while the card's internal hover state is
out of sync with the browser's CSS `:hover` state. In normal
interaction, entering the card immediately updates the hover state and
shows the checkbox instead, so the issue effectively self-recovers.
The new test reproduces this state directly and verifies the fix.
## What changed
* Moved `v-if="allowUpload"` from the hidden file input to the upload
overlay itself, so the overlay and file input are always mounted
together.
* Added `Avatar.spec.js` coverage for the overlay slot, including the
empty-slot case that triggered this bug, along with the existing upload,
delete, badge, sizing, initials, and image fallback behavior.
Fixes
https://linear.app/chatwoot/issue/CW-7726/typeerror-cannot-read-properties-of-null-reading-clickhttps://chatwoot-p3.sentry.io/issues/7291677410/?project=4507182691975168&referrer=Linear
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Screenshots
**Before**
<img width="1683" height="847" alt="image"
src="https://github.com/user-attachments/assets/1b746be4-0425-4a68-953b-193e70411032"
/>
**After**
<img width="1683" height="847" alt="image"
src="https://github.com/user-attachments/assets/e0c78aba-6053-442c-905a-373c8d2be123"
/>
## 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
## Description
Follow-up to #15319, addressing the non-blocking review notes and the
Ito QA finding there.
The `days_before` filter value went straight through `to_i`, which never
fails: `-1` moves the cutoff into the future and matches every
conversation, and a non-numeric string becomes `0`. The value is now
parsed as a base-10 integer and must fall within the UI-supported
`1..998` range; anything else raises the existing
`CustomExceptions::CustomFilter::InvalidValue`, which the controller
already turns into a client error.
Also corrects an existing weak spec that sent `3` days but computed its
expectation with `2` days, passing only because the seeded data made
both counts equal. It now sends `2` and exercises the exclusive
boundary.
Refs https://linear.app/chatwoot/issue/CW-7832
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- New specs: invalid values (`-1`, `abc`, `0`, `999`) raise
`InvalidValue`; string values parse as base 10 (`'02'` means 2 days, not
octal).
- `bundle exec rspec spec/services/conversations/filter_service_spec.rb`
(36 examples, 0 failures).
## 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
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>
Cloud accounts without access to WhatsApp Quick setup currently fall
directly into manual configuration, with no explanation of how to
request the easier Meta flow.
This adds a compact access-request card above manual setup. It explains
that Quick setup with Meta can connect either a new number or an
eligible existing number from the WhatsApp Business app, then opens the
existing support widget so the account can be reviewed. The enabled
state now uses the same customer-facing language.
Related: https://github.com/chatwoot/chatwoot/pull/15318
<img width="1428" height="1110" alt="CleanShot 2026-08-05 at 14 12
31@2x"
src="https://github.com/user-attachments/assets/914e5fd7-eb5a-438c-9706-0ecd8e004fbf"
/>
### Things to know
- The access card is Cloud-only and appears when the account-level
WhatsApp Quick setup feature is disabled.
- The global Meta incident restriction still takes precedence and
continues to show the existing incident warning.
- Manual setup remains available, and self-hosted behavior is unchanged.
- Requesting access opens Chatwoot support; it does not automatically
enable the account feature.
- Meta documents the existing WhatsApp Business app number path as
coexistence onboarding:
https://developers.facebook.com/documentation/business-messaging/whatsapp/embedded-signup/onboarding-business-app-users
### How to test
1. On Chatwoot Cloud, set `DISABLE_META_INBOX_CREATION` to `false`.
2. Open WhatsApp inbox creation for an account without
`whatsapp_embedded_signup_inbox_creation`.
3. Confirm the Quick setup with Meta request card appears above the
unchanged manual configuration form.
4. Select **Request access** and confirm the support widget opens.
5. Enable `whatsapp_embedded_signup_inbox_creation` for the account and
reload.
6. Confirm the enabled Quick setup with Meta screen appears and
describes both new numbers and eligible existing WhatsApp Business app
numbers.
7. Set `DISABLE_META_INBOX_CREATION` to `true` and confirm the incident
warning appears instead of the access-request card.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
WhatsApp Business app Coexistence inboxes currently see the manual
migration prompt even though they cannot move to the generic manual
setup flow without losing the supported Coexistence path.
This change waits for WhatsApp health data and shows manual transfer
only when Meta confirms the number is not connected to the WhatsApp
Business app. Other eligible Embedded Signup inboxes continue to see the
migration prompt.
### Things to know
- This is frontend-only gating; the migration API behavior is unchanged.
- The prompt remains hidden while the WhatsApp Business app state is
unknown or unavailable.
### How to test
1. Enable `whatsapp_manual_transfer` for an account with an Embedded
Signup WhatsApp inbox.
2. Open an inbox whose health response reports `is_on_biz_app: true`;
confirm the migration banner and dialog are unavailable.
3. Open an inbox whose health response reports `is_on_biz_app: false`;
confirm the migration banner appears and opens the existing manual
migration dialog.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
WhatsApp Flow submissions currently reach Chatwoot as
`interactive.nfm_reply` messages, but their structured answers are
discarded. Agents see an empty message and outbound webhooks cannot
access the submitted data.
This change preserves the Flow response in message content attributes
and renders a readable response card in the conversation. Existing
WhatsApp messages and other interactive message types remain unchanged.
Fixes https://github.com/chatwoot/chatwoot/issues/13970
<img width="1234" height="1350" alt="CleanShot 2026-08-04 at 00 40
14@2x"
src="https://github.com/user-attachments/assets/884b3a5c-bab3-4196-8037-776e6c41ab2a"
/>
### How to reproduce
1. Send an approved WhatsApp template containing a Flow button.
2. Complete and submit the Flow from WhatsApp.
3. Open the conversation in Chatwoot.
4. Observe that the incoming message has no visible content and the
submitted fields are absent from the message webhook.
### What changed
- Parse `interactive.nfm_reply.response_json` for incoming WhatsApp
Cloud messages.
- Store the Flow name, body, and structured response under
`content_attributes.whatsapp_flow_response`.
- Add a dedicated conversation bubble that formats submitted field names
and values.
- Preserve original response keys while converting message attributes to
the frontend shape.
- Keep `flow_token` available in stored/webhook data while omitting it
from the agent-facing card.
- Add focused backend, helper, and component regression coverage.
### How to test
1. Send a WhatsApp Flow template to a contact.
2. Submit the Flow with multiple field types, including free text and a
selection.
3. Confirm the incoming conversation message displays each submitted
field and value.
4. Confirm an empty-answer Flow still renders a visible “Submitted a
flow response” message.
5. Inspect the `message_created` webhook and confirm the structured
response is present in
`content_attributes.whatsapp_flow_response.response_json`.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## 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
## Description
Every conversation filter request runs three separate unbounded COUNT
queries over the filtered set (mine, unassigned, all) and eager-loads
every message of every conversation on the page. On large accounts this
adds a fixed 1-2s of latency per request regardless of the filter.
This PR trims both:
- The three counts are now computed in a single pass using `COUNT(*)
FILTER (...)` aggregates. Response shape and count semantics are
unchanged.
- The `:messages` eager-load is removed from the filter base relation.
The list payload fetches messages through scoped queries (last message,
last non-activity message, unread messages), which never read the
preloaded collection, so it was loaded and discarded on every request.
Fixes https://linear.app/chatwoot/issue/CW-7830
## Description
When `POST /api/v1/accounts/:id/conversations/filter` fails (for example
a 500 or a server-side timeout), the conversation list spinner never
clears because the Vuex action's catch block was empty. The user is
stuck on an infinite loader with no way to retry.
This change:
- Clears the list loading state (`CLEAR_LIST_LOADING_STATUS`) and
rethrows in `fetchFilteredConversations`, matching how sibling actions
in the module handle errors. Both applied filters and saved filters
(custom views) go through this action.
- Catches the rejection in `ChatList.vue` and shows an alert ("Couldn't
load conversations. Please try again.") so the user can retry.
- Guards the reconnect flow in `ReconnectService` so a failed filtered
fetch on websocket reconnect does not abort cache revalidation.
- Fixes the existing spec for the success path, which passed no
`dispatch` and was silently exercising the error path.
No client-side request timeout was added since the dashboard API layer
has no per-request timeout convention; the fix is scoped to error
handling.
Fixes https://linear.app/chatwoot/issue/CW-7831
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Added a spec asserting the loading state clears and the error is
rethrown when the filter request rejects: `pnpm test
app/javascript/dashboard/store/modules/specs/conversations/actions.spec.js`
(49 passed).
- `pnpm test
app/javascript/dashboard/helper/specs/ReconnectService.spec.js` (24
passed).
## 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
## Description
The `days_before` filter operator in
`FilterService#days_before_filter_query` calls `with_indifferent_access`
directly on the query hash. In production the filter payload arrives as
`ActionController::Parameters` (the controller passes `params.permit!`),
which does not respond to `with_indifferent_access`, so every
conversation filter request using `days_before` raises `NoMethodError`
and returns a 500.
Existing specs pass plain hashes with `with_indifferent_access`, which
is why this was never caught. This PR normalizes the query hash via
`to_h` first (permitted parameters convert to a
`HashWithIndifferentAccess`, plain hashes are unaffected) and adds a
regression spec that builds the payload as
`ActionController::Parameters`, mirroring the controller.
Fixes https://linear.app/chatwoot/issue/CW-7832
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Added a regression spec that passes the filter payload as permitted
`ActionController::Parameters` with the `days_before` operator. It
reproduces the `NoMethodError` on the current develop branch and passes
with this change.
- `bundle exec rspec spec/services/conversations/filter_service_spec.rb`
(31 examples, 0 failures)
- `bundle exec rspec
spec/services/conversations/filter_service_frontend_alignment_spec.rb`
(10 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
- [ ] 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
## Description
Agent notification emails (new conversation, assignment, mention, new
message, SLA misses) currently carry no indication of why the recipient
received them or how to turn them off. When recipients cannot easily
manage these emails, some mark them as spam, which hurts sender
reputation and overall deliverability.
This adds a short footer line to agent notification emails only:
> You're receiving this email because email notifications are enabled
for your account. **Manage notification preferences**.
The link points the recipient to their dashboard profile notification
settings page (`/app/accounts/:account_id/profile/settings`) so they can
disable notifications instead of marking the email as spam. This is a
navigational link only, not a one-click unsubscribe (a real unsubscribe
flow is a separate future change).
Scoping: the mailer layout (`app/views/layouts/mailer/base.liquid`) is
shared by all mailers via `ApplicationMailer`. To keep the footer on
agent notification emails only,
`AgentNotifications::ConversationNotificationsMailer` exposes a
`notification_settings_url` liquid local (built from the existing
`app_account_url` route helper), and the layout renders the footer line
only when that local is present. Transactional and other emails do not
set it, so they are unaffected. The enterprise SLA notification methods
prepend into the same mailer class, so they inherit the footer
automatically.
Part of https://linear.app/chatwoot/issue/CW-7752
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- `bundle exec rspec
spec/mailers/agent_notifications/conversation_notifications_mailer_spec.rb
spec/mailers/confirmation_instructions_spec.rb` — 26 examples, 0
failures. Asserts the footer link and settings URL are present in an
agent notification email and absent from a non-notification
(confirmation) email.
- `bundle exec rspec
spec/enterprise/mailers/enterprise/agent_notifications/conversation_notifications_mailer_spec.rb`
— 6 examples, 0 failures (SLA notification emails).
## 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
CI no longer fails when the AppliedSla scope spec runs after Rails
reloads model classes. The spec now compares record IDs, so it checks
which SLA records the scope returns without depending on Ruby class
identity.
## How to reproduce
Run the report builder and assignment policy controller specs before
`spec/enterprise/models/applied_sla_spec.rb` in the same RSpec process.
Before the fix, the scope returns records with the expected IDs, but the
assertion rejects them because FactoryBot and Rails use different
`AppliedSla` class objects after the reload.
## What changed
The spec reads the IDs returned by `with_sla_applicable_conversation`
and checks the normal conversation, missing contact, and blocked contact
cases with those IDs.
The affected CircleCI shard passes locally after the change.
## Summary
This fixes WhatsApp phone number normalization for Mexico numbers when
using Twilio as a provider.
Twilio may send incoming Mexico WhatsApp phone numbers with an extra `1`
after the country code, for example:
- stored contact inbox source: `whatsapp:+525512345678`
- incoming message source: `whatsapp:+5215512345678`
Before this change, Chatwoot could treat these as different source IDs
and create a duplicate contact/conversation path instead of matching the
existing one.
## What changed
- added a Mexico-specific phone normalizer
- normalize `+521...` to `+52...` for contact matching
- kept the original incoming source ID when creating a brand new contact
inbox
## Why this approach
Chatwoot already has country-specific normalization for WhatsApp numbers
in the normalization service. This follows the same pattern and keeps
the change small and isolated.
## Tests
Added specs covering:
- matching an existing Mexico WhatsApp contact inbox when Twilio sends
`+521...`
- preserving the original source ID when no matching contact inbox
exists and a new one is created
Fixes
https://linear.app/chatwoot/issue/CW-6844/fix-normalize-mexico-whatsapp-phone-numbers-on-twilio-to-prevent
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Captain V2 now adds FAQ citations from a structured model response. The
model returns ordered response parts with citation indexes, and Chatwoot
turns only trusted indexes into customer links.
## Before
Captain V2 asked the model to copy text markers such as `[[faq:1]]`.
Chatwoot used one regular expression to replace those markers with links
in the outgoing message and another regular expression to remove the
rendered links before the next model turn. Long conversations depended
on parsing the customer message to recover plain model context.
## After
The FAQ lookup tool now gives each eligible source document a numeric
index and never gives the model a URL. FAQ results from the same
document reuse the same index. The model returns `response_parts`, where
each part contains customer text and the supporting citation indexes.
Chatwoot checks every index against the document IDs registered during
the current run.
Only stored HTTP or HTTPS web-document links without embedded
credentials can appear in the customer reply. Blank links, PDF sources,
attachments, non-HTTP storage links, and unknown indexes do not create
links. Sources receive display numbers in the order they first appear,
and repeated sources keep the same display number.
Chatwoot saves the structured response parts with each newly generated
Captain message. Later Captain V2 turns use the saved plain text for
those messages, so they never need to parse rendered links. Existing
messages remain unchanged and continue to use their stored content. When
citations are disabled, Chatwoot clears citation indexes before it
returns or saves the response.
Captain V1, Copilot, legacy prompts, legacy tools, and the playground
response contract are unchanged. The playground continues to show the
plain `response` field.
## Closes
[AI-138](https://linear.app/chatwoot/issue/AI-138/faq-citation-fix)
## How to test
1. Open a conversation handled by a Captain V2 assistant and turn
citations off. Ask a greeting, an FAQ question, a code question, and a
follow up question. Confirm that the assistant answers normally and
shows no source links.
2. Turn citations on and ask a question that matches one public web
document. Confirm that the reply shows the stored public link after the
supported text.
3. Ask a question that needs two public web documents. Confirm that the
response order stays correct, each link appears after the supported
text, and repeated sources keep the same display number.
4. Ask a question that retrieves several FAQ results from one document.
Confirm that the reply shows the document once at each supported
response part rather than exposing separate FAQ sources.
5. Ask a question supported by a PDF, attachment, blank link, or
non-HTTP storage link. Confirm that Captain can use the information but
does not show a customer link.
6. Ask for a fenced code example with a citation. Confirm that the code
block stays complete and the citation appears after the closing fence.
7. Continue the conversation with a follow up question. Confirm that
Captain uses the earlier plain response text and does not receive or
repeat rendered citation links.
8. Test a scenario handoff in a conversation. Confirm that the handoff
and final response still work.
SLA is a premium feature, but several SLA surfaces never checked the
account's `sla` flag. An account without SLA — or one whose plan was
downgraded and had the flag revoked — could still read SLA breach
reporting, attach an SLA policy to a conversation through the
conversation update endpoint, and keep applying SLA policies from
automation rules. All three paths now require the feature, matching the
SLA policies API which already checked it.
## How to reproduce
1. Disable the `sla` feature for an account that has SLA policies and
applied SLAs.
2. `GET /api/v1/accounts/{id}/applied_slas/metrics` (also `index` and
`download`) — returns the account's SLA breach data instead of denying.
3. `PATCH /api/v1/accounts/{id}/conversations/{display_id}` with
`sla_policy_id` — the policy is attached.
4. Trigger an automation rule with an "Add SLA" action — the SLA is
applied and starts tracking.
## What changed
- `Api::V1::Accounts::AppliedSlasController` gains the same
`ensure_sla_feature_enabled` guard the SLA policies controller uses,
covering `index`, `metrics` and `download`.
-
`Enterprise::Api::V1::Accounts::ConversationsController#permitted_update_params`
only permits `sla_policy_id` when the feature is enabled. When it is off
the parameter is dropped, so an existing SLA association is preserved
rather than cleared.
- `Enterprise::ActionService#add_sla` returns early when the feature is
off, so automation rules stop applying SLAs on revoked accounts.
Captain auto-resolve policy is now owned by each assistant. Existing
assistants first read an assistant-level setting, fall back to the
current account setting during rollout, and are backfilled
asynchronously so behavior is preserved.
## Closes
[AI-163](https://linear.app/chatwoot/issue/AI-163)
## How to test
1. Configure different auto-resolve modes on two assistants in the same
account through the API.
2. Confirm each assistant follows its own mode when the inactivity job
runs.
3. Confirm an assistant without the new setting follows the existing
account mode.
4. Run the migration job and confirm the account mode is copied without
overwriting an existing assistant mode.
5. Confirm evaluated mode falls back to time-based resolution when the
`captain_tasks` capability is unavailable.
## What changed
- Added assistant-level `disabled`, `legacy`, and `evaluated` policy
storage and validation.
- Updated scheduling and resolution runtime reads to use the assistant
policy.
- Added a compatibility fallback and asynchronous backfill from the
account setting.
- Preserved the account-level `captain_tasks` capability gate for
evaluation.
- Kept this foundation independent of the Captain V2 guard; the timer
and advanced settings in stacks 2–5 are Captain V2-only.
Stack 1 of 5. This is the base for #15303.
Conversations could get reassigned repeatedly in quick succession —
bouncing between agents with several "Assigned to X" activity messages
in a row — whenever an assignment write raced against another assignment
write on the same conversation (an automation rule vs. Assignment V2's
auto-assign, two manual assignment clicks, two concurrent status
transitions triggering legacy round-robin, etc). This was reproducible
with or without Assignment V2 enabled; it wasn't a V2-specific issue,
just more visible under message bursts. Assignment V2's own job-vs-job
race was already fixed separately (#14495) — this PR covers the other
writers that don't check the conversation's current state before
overwriting it.
## How to reproduce
Configure an automation rule that assigns an agent/team on
`message_created`, then send a burst of messages on one conversation
from a channel/inbox with concurrent message delivery (or race it
against another assignment source — a manual assignment click, or a
status change that triggers legacy auto-assignment). The conversation's
assignee flips between agents multiple times, each producing its own
activity message, even though later writes were often redundant (setting
the assignee to a value it already had, from the writer's stale point of
view).
## What changed
Three assignment write paths now take a row lock (`with_lock`) before
writing, so a concurrent writer re-reads the conversation's true current
state before deciding whether a write is actually needed:
- `ActionService#assign_agent`/`#assign_team` (and the corresponding
unassign methods) — used by automation rules, macros, and delayed
automations.
- `Conversations::AssignmentService#assign_agent`/`#assign_agent_bot` —
the dashboard's assignee dropdown (human agent or AgentBot).
- `AutoAssignment::AgentAssignmentService#perform` — the legacy (non-V2)
round-robin auto-assignment path.
A write that would just reapply an already-current value becomes a
genuine no-op instead of producing a redundant `UPDATE` and duplicate
activity message. Legitimate reassignment (a real change in target, or
reassignment away from an agent who lost inbox access) is unaffected.
This restores the temporary Meta incident safeguards with two
independent runtime controls for Chatwoot Cloud. Super admins can now
re-enable Instagram messaging first and keep new Meta inbox creation
disabled until onboarding is stable.
When messaging is disabled, Instagram conversations show the incident
notice and remain in private-note mode. The separate inbox-creation
control disables Facebook, Instagram, and WhatsApp Embedded Signup entry
points. Self-hosted installations remain unchanged.
Related: https://github.com/chatwoot/chatwoot/pull/15210
Related: https://status.chatwoot.com/incident/976975
### Things to know
- `DISABLE_META_MESSAGE_SENDING` affects Instagram messaging only.
- `DISABLE_META_INBOX_CREATION` affects Facebook, Instagram, and
WhatsApp Embedded Signup inbox creation.
- Both controls default to `true` for the active incident and are
editable from Super Admin installation configs.
- The Cloud-only boundary is enforced by the dashboard configuration
getters.
### How to test
1. Open Super Admin → Installation Configs and set
`DISABLE_META_MESSAGE_SENDING` to `false`.
2. Reload an Instagram conversation and confirm the incident banner
disappears and the runtime restriction no longer forces private-note
mode.
3. Set the flag back to `true`, reload, and confirm the banner and
restriction return.
4. Set `DISABLE_META_INBOX_CREATION` to `false`, reload the Facebook,
Instagram, or WhatsApp Embedded Signup setup flow, and confirm
connection is enabled.
5. Set the flag back to `true`, reload, and confirm the incident notice
appears and connection is disabled.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Account administrators can now browse synced WhatsApp message templates
inside Settings without opening a provider dashboard. The page combines
native WhatsApp and Twilio WhatsApp templates, with channel and language
filters, search, a template preview drawer, and links to manage
templates at the provider.
Creating, updating, and deleting templates in Chatwoot remains out of
scope for this first version.
Related:
https://linear.app/chatwoot/issue/PLA-193/add-whatsapp-template-listing-to-account-settings
<img width="2742" height="1460" alt="CleanShot 2026-08-03 at 20 23
27@2x"
src="https://github.com/user-attachments/assets/5d0b7a98-f882-425a-b9ec-7d631371959c"
/>
### Things to know
- This is stack 2 of 2 and depends on API draft #15311.
- Review this PR against `codex/whatsapp-template-api`; after the API PR
lands, this branch can be rebased and retargeted to `develop`.
- Both native WhatsApp and Twilio WhatsApp template caches are
supported.
- Template management remains in Meta Business Portfolio or Twilio
Console.
### How to test
1. Open Settings → WhatsApp templates for an account with native and
Twilio WhatsApp inboxes.
2. Confirm templates from each inbox are listed with their status,
language, category, channel, and last-updated metadata.
3. Filter by channel and language, and search by template name or
content.
4. Open a template and confirm its preview renders in the drawer.
5. Use the provider action and confirm it opens the appropriate Meta or
Twilio template-management page.
6. Confirm loading, empty, and error states remain usable.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Moves Captain conversation outcomes from one row per conversation to one
row per **engagement episode**: a new row each time demand for Captain
(re)starts - first eligible message, a reopen after resolution, or
(reserved) explicit assignment. Each episode has its own demand anchor,
window, and trigger, so returning customers count as new demand and
later cycles can't overwrite an earlier episode's handoff reason,
resolution, or CSAT. Also adds `conversation_outcomes` associations on
Account, Inbox, Conversation, and Captain::Assistant.
## Why this wasn't in #15233
The episode design came out of reviewing the wiring PR: per-conversation
grain couldn't answer per-cycle questions without a patch per field. The
table is unreleased with no writers, so changing the grain now is a pure
schema swap - and landing it first means the tracker gets reviewed
against the final model.
## What changed
- Adds `episode_trigger`, `started_at`, `ended_at`
- Drops `reopen_count` and `last_reopened_at` - reopens are episode rows
now
- Uniqueness moves from `(account, assistant, conversation)` to
per-boundary `(account, conversation, started_at)`
- Two partial unique indexes: one open episode per conversation, one
initial episode per stream
- Model: trigger enum, `started_at` uniqueness validation,
`chronological`/`covering` scopes
The cached inbox template endpoint currently serves only native WhatsApp
channels. This draft extends the same read-only endpoint to Twilio
WhatsApp inboxes and adds last-sync metadata for both providers, so the
template listing can use one stable contract without making provider
requests.
Non-WhatsApp inbox behavior remains unchanged.
Related:
https://linear.app/chatwoot/issue/PLA-193/add-whatsapp-template-listing-to-account-settings
### Things to know
- This is stack 1 of 2 and contains only the API contract needed by the
settings UI in #15312.
- Template data remains cache-only; the endpoint does not call Meta or
Twilio.
- Native WhatsApp templates are filtered by `name`; Twilio Content
Templates are filtered by `friendly_name`.
### How to test
1. Request the message templates endpoint for a native WhatsApp inbox
and confirm it returns the cached templates plus `meta.last_updated_at`.
2. Request it for a Twilio WhatsApp inbox and confirm it returns cached
Content Templates plus `meta.last_updated_at`.
3. Pass a template name and confirm only the matching provider template
is returned.
4. Request it for a non-WhatsApp inbox and confirm the endpoint returns
an unprocessable entity response.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Telegram inbound attachments were stored under a generic, renamed
filename (e.g. `file_5.pdf`) instead of the name the sender actually
uploaded (e.g. `Quarterly-Report-2025.pdf`).
**Root cause:** In `Telegram::IncomingMessageService#attach_files`, the
attachment filename was taken from the `Down`-downloaded file's
`original_filename`, which `Down` derives from the Telegram file-server
download URL. That URL is built from Telegram's `getFile` response,
whose `file_path` is Telegram's *internal* storage path — not the
sender's chosen name. The real name is present in the webhook payload as
`file_name` on the `document` / `audio` / `video` object, but it was
never read.
Because `Attachment#set_extension` derives the stored `extension` from
the filename, this also corrupted the recorded extension for documents
whose Telegram path lacked a proper one.
**Fix:** Prefer the payload's `file_name`, falling back to the
downloaded name when it's absent (photos, stickers, voice notes — which
Telegram sends without a `file_name`). This mirrors how the Line channel
(`message['fileName']`) and WhatsApp Cloud channel already handle
inbound attachment filenames.
```ruby
filename: file[:file_name].presence || attachment_file.original_filename,
```
Fixes#15070
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Added/updated specs in
`spec/services/telegram/incoming_message_service_spec.rb`:
- Extended the existing document-message example to assert the stored
attachment retains the original payload filename (`Screenshot 2021-09-27
at 2.01.14 PM.png`) rather than Telegram's internal download name.
- Added a fallback example (a `photo` payload, which carries no
`file_name`) asserting the attachment is still created and the filename
falls back to the downloaded name — guarding the `.presence || …` branch
and confirming no regression for media types without a `file_name`.
> Note: my local machine does not have the Ruby/Redis toolchain to run
the suite, so I have not run RSpec/RuboCop locally — I'm relying on CI
to validate. Suggested command for reviewers: `bundle exec rspec
spec/services/telegram/incoming_message_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
- [x] I have added tests that prove my fix is effective
- [ ] New and existing unit tests pass locally with my changes (unable
to run locally — see note above; relying on CI)
## Description
Label-based conversation filters (custom views / folders) can time out
for non-admin agents on large accounts. The permission scoping adds
`conversations.inbox_id IN (subquery)` to the filter query, and Postgres
misestimates the row count for the account+inbox combination by several
orders of magnitude. It then drives the query through an inbox index
scan over the account's entire conversation set instead of starting from
the label's taggings, which are often only a handful of rows. The query
exceeds the request timeout and the folder never loads.
This change adds a planner hint to
`Conversations::PermissionFilterService`: when enabled, the inbox
scoping condition is written as `(conversations.inbox_id + 0) IN
(subquery)`, which returns identical rows but is not indexable, so the
planner cannot choose the misestimated path.
`Conversations::FilterService` enables the hint only when the filter
payload contains a `labels` condition. All other callers of the
permission service are unchanged, since the bare condition is the right
plan for unfiltered conversation lists.
Observed on a ~365k-conversation account (worst case, cold cache): label
filter for an agent went from exceeding 60s to ~2ms. Popular labels
(~154k taggings) show no regression. Admin queries are untouched.
Fixes https://linear.app/chatwoot/issue/CW-7787
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Specs for row-equivalence of the hinted scoping, admin behavior, and
hint application scoped to label filters only
- `EXPLAIN (ANALYZE, BUFFERS)` comparison on a production-scale dataset
for rare-label, popular-label, and no-label query shapes, agent and
admin, with generic plans matching prepared-statement behavior
Adds the `Captain::ConversationOutcome` model and its table: one row per
(account, assistant, conversation) that folds Captain lifecycle events
into flat facts for the upcoming value metrics report. This is the
second PR in the outcomes stack, on top of the lifecycle event layer
(#15213); the tracker and listener that populate it come next.
The table deliberately stores only timestamps, counts, and the handoff
reason. Every classification and duration (coverage, autonomous vs
assisted, durable resolution, resolution time) is derived at query time
in the stats layer, so definitions can change later without backfills.
The row is created on the first qualifying customer message, making
`created_at` the demand-start anchor. Commit messages carry the
field-by-field rationale for what was left out.
| Field | Meaning |
| --- | --- |
| `account_id`, `assistant_id`, `conversation_id`, `inbox_id` |
Reporting dimensions; unique on the first three |
| `first_captain_reply_at` / `last_captain_reply_at` | First and latest
public Captain reply |
| `captain_reply_count` | Public Captain replies in the conversation |
| `first_human_reply_at` | First public human agent reply, used to
classify assisted resolutions |
| `handoff_at` | When Captain handed the conversation to a human |
| `handoff_reason_category` | Why it handed off (customer_request,
missing_knowledge, unsupported_request, policy_restriction,
tool_failure, pending_clarification, usage_limit) |
| `resolved_at` | When the conversation was resolved |
| `last_reopened_at` / `reopen_count` | Reopen facts backing reopen rate
and durable-resolution checks |
| `csat_rating` / `csat_received_at` | CSAT for Captain-involved
conversations |
Fixes the three `FullEditor.spec.js` slash-menu failures that appeared
after #15291 and #15296 crossed on develop: #15296 added slash-menu
specs that assert real translated labels ("Divider", "Heading 1"), while
#15291 emptied the global i18n catalogue in the vitest setup, so `t()`
started returning raw keys like `SLASH_COMMANDS.DIVIDER`.
The spec now calls `withFullI18n()` from the `test-i18n` helper
introduced in #15291, opting into the full message catalogue the same
way `MacroProperties.spec.js` does. Test-only change, no production code
touched.
Related: https://github.com/chatwoot/chatwoot/pull/15291
## Description
`vitest.setup.js` runs for every spec file and builds the i18n instance
from the full message catalogue, so each of the 389 spec files resolves
and transforms the 2537 JSON files under
`app/javascript/dashboard/i18n/locale/`. With `pool: 'threads'`, that
cost is paid per worker. The result is that `setup` takes about **60x
longer than the tests themselves**.
Only one spec in the suite asserts on translated copy. This PR leaves
the global i18n instance without messages and adds `withFullI18n`, an
opt-in helper for the specs that need the real catalogue.
**On this repository's own CI, `setup` drops from ~629s to ~71s (-89%)
and total Vitest duration from ~388s to ~196s (-49%).**
This is a performance and testability change, not a cosmetic one. It
touches only how the test harness loads messages — **no translatable
string and no locale file is modified**, so nothing changes for Crowdin
contributors.
Worth noting: `vitest.config.ts` already excludes `**/i18n/**/*` from
coverage, so loading the catalogue in every spec was not serving any
metric.
Fixes#15290
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### On this repository's CI
The numbers below come from the `test` job of `frontend-fe.yml` on
GitHub Actions — this repo's own runners, not a local machine. Baseline
is **60 successful `develop` runs** (23–31 Jul 2026), parsed from the
Vitest summary line in each job log.
| Vitest metric | `develop` (n=60) | This PR | Delta |
|---|---|---|---|
| **setup** | median **629s** (min 329 / p25 607 / p75 641 / max 680) |
**71s** | **-559s (-89%)** |
| **duration** | median **388s** (min 205 / p25 371 / p75 393 / max 418)
| **196s** | **-192s (-49%)** |
None of the 60 `develop` runs beat this PR on either metric.
Same commit, both on this repo's CI:
```
develop @ bc7ae88 Test Files 389 passed (389)
Duration 323.35s (transform 13.75s, setup 522.48s, collect 42.53s,
tests 9.02s, environment 187.05s, prepare 32.77s)
this PR Test Files 389 passed (389)
Duration 196.20s (transform 18.18s, setup 70.67s, collect 65.97s,
tests 12.22s, environment 251.28s, prepare 43.90s)
```
`setup` is the metric that isolates this change: it is a sum of work, so
it is not distorted by how fast a given runner happens to be. `duration`
improves less because it also covers transform, collect and environment,
which this change does not touch.
One caveat if you compare total job times instead: on this PR's run,
`ruby/setup-ruby` took 130s versus 11s on the baseline (an unrelated
cache miss), which hides most of the gain at job level.
### Locally
`pnpm exec vitest run`, twice per scenario, on `develop` at `bc7ae88`
(Node 24.18.1, macOS arm64):
| | setup | duration |
|---|---|---|
| before | 373s / 412s | 60.8s / 67.8s |
| after | 40.5s / 42.8s | 28.1s / 28.5s |
Identical pass/fail counts before and after. Locally there is one
failure in both scenarios, pre-existing on `develop` and unrelated to
this change: `useReportMetrics.spec.js` expects `'5,000'` and receives
`'5.000'`, a thousands-separator difference that depends on the machine
locale. It does not occur on CI, where the suite is fully green
(389/389).
`MacroProperties.spec.js` was the only spec that depended on the global
catalogue — it asserts the real copy from `macros.json`. It now calls
`withFullI18n()` and keeps asserting the same strings, so coverage of
that copy is preserved.
## Notes for reviewers
- The `test-i18n` alias was added to `vitest.config.ts` rather than to
`vite.shared.ts`, to keep it out of the production build.
- `missingWarn: false` and `fallbackWarn: false` were added to the
global instance so specs that render translated components without
opting in do not flood the output with missing-key warnings.
- Any future spec that needs the real copy just calls `withFullI18n()`
at the top of the file.
## 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 (no new test: this is a performance change, verified by
the CI measurements above and by the unchanged pass/fail counts)
- [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: Shivam Mishra <scm.mymail@gmail.com>
Custom Roles is a premium feature, but the account's `custom_roles` flag
was never checked by the API. An account on a plan without Custom Roles
— or one whose plan was downgraded and had the flag revoked — could
still list, create, edit and delete custom roles, and could still attach
a `custom_role_id` to an agent through the agents API. Both paths now
require the feature.
## How to reproduce
1. Disable the `custom_roles` feature for an account (Super Admin →
Account → Features, or a plan downgrade).
2. `GET /api/v1/accounts/{id}/custom_roles` — returns 200 with the
account's roles instead of denying.
3. `PATCH /api/v1/accounts/{id}/agents/{agent_id}` with `custom_role_id`
— the role is assigned.
## What changed
- `Api::V1::Accounts::CustomRolesController` gains a
`ensure_custom_roles_feature_enabled` guard, matching the shape already
used by the SLA policies controller.
-
`Enterprise::Api::V1::Accounts::AgentsController#associate_agent_with_custom_role`
ignores `custom_role_id` when the feature is off, rather than writing
it.
Existing custom role assignments are deliberately left untouched — they
are evaluated at request time by `Enterprise::AccountUser#permissions`
and the conversation policy, where custom roles mostly *narrow* an
agent's scope. Dropping them on revocation would widen conversation
visibility for restricted agents, which is a separate product decision.
---------
Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com>
External integrations can send WhatsApp template messages, but they do
not have a focused API to discover the templates available for an inbox.
This adds an authenticated endpoint that lists the inbox's cached
WhatsApp templates and optionally filters them by exact template name.
Existing inbox responses and template synchronization behavior remain
unchanged.
Fixes https://github.com/chatwoot/chatwoot/issues/13959
### Things to know
- The endpoint returns templates already synchronized and cached for a
direct WhatsApp inbox; it does not make a new provider request.
- Non-WhatsApp inboxes return an unprocessable entity response.
### How to test
1. Authenticate as a user assigned to a WhatsApp inbox.
2. Request `GET
/api/v1/accounts/:account_id/inboxes/:id/message_templates` and verify
the response contains the inbox's templates under `payload`.
3. Repeat the request with `?name=<template_name>` and verify only the
exact matching template is returned.
4. Request the endpoint for a non-WhatsApp inbox and verify it returns
an unprocessable entity response.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
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>
This adds a reusable side drawer component
(`components-next/drawer/Drawer.vue`), similar in spirit to Dialog and
Popover, so drawers across the app share one implementation. The drawer
renders as a floating card anchored to the inline-end edge with a
slide-in/slide-out animation, and handles the backdrop, Escape key,
click-outside, and focus restore. The layout inside is fully
slot-driven, with a `close` function passed through the slot.
The Captain overview and report drilldown drawers now use this
component, and the Captain document details view moved from a centered
dialog to this drawer.
## Closes
CW-7757
## What changed
- New `Drawer.vue`: teleported floating card with backdrop, RTL-aware
slide transition, focus management, and a default slot receiving
`close`; emits `afterLeave` so consumers mounted with `v-if` can unmount
after the exit animation
- `AssistantDrilldownDrawer` and `ReportDrilldownDrawer` refactored to
consume it, keeping their own headers and content
- `DocumentDetails` migrated from Dialog to the drawer, dropping the
imperative `dialogRef.open()` plumbing and fixed-height inner scroll
areas
- Shared `DRAWER.CLOSE` i18n key replaces the per-drawer close labels
https://github.com/user-attachments/assets/58db6c34-8b6f-46e2-bdb1-f2d3675f1a94
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
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
## Description
Adds `VIPS_BLOCK_UNTRUSTED=1` to `.env.example`. This tells libvips to
only use its trusted, well-tested loaders when Active Storage generates
image variants, hardening image processing against untrusted uploads.
The setting requires libvips >= 8.13 and is silently ignored on older
versions.
Related to https://linear.app/chatwoot/issue/INF-92
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Verified locally that thumbnail/variant generation for the common raster
formats (JPEG, PNG, GIF, WebP, TIFF, HEIC) is unaffected with the flag
enabled.
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
Paid Chatwoot Cloud accounts now receive Captain V2 during plan
reconciliation unless they are explicitly held on Captain V1. Older
accounts could otherwise start on V1 when they became paid after the V2
rollout because only newly created accounts carried the rollout
eligibility value.
## Closes
No linked issue.
## How to reproduce
1. Start with a cloud account created before the Captain V2 rollout.
2. Upgrade the account from the default plan to a paid plan.
3. Reconcile the Stripe subscription.
4. Confirm that Captain is enabled but Captain V2 remains disabled.
## What changed
1. Treat a missing rollout eligibility value as eligible for Captain V2
on paid plans.
2. Keep Captain V2 disabled when the rollout eligibility value is
explicitly set to false.
3. Keep the default plan behavior unchanged.
4. Update the billing reconciliation specs to cover existing paid
accounts, new accounts, and explicit V1 exceptions.
## Summary
`Api::V1::Widget::BaseController#conversation_params` had a `FIXME: typo
referrer in additional attributes, will probably require a migration`
comment. On investigation, `additional_attributes[:referer]` is used
consistently across the whole codebase — automation rules,
conversation/contact filters, `ConversationInfo.vue`, and the widget
SDK's `referer_url` param — matching the historical (if misspelled) HTTP
`Referer` header convention. There is no actual inconsistency to fix,
and renaming the key would require a data migration and would break
existing customer automations built on the `referer` key, for no
functional benefit.
## What changed
- Removed the misleading FIXME comment. No behavior change.
Required checkbox fields in the pre-chat form now remain invalid unless
they are checked. Other required field types keep their existing
validation behavior, and the existing localized required message is
reused.
## Closes
Closes https://github.com/chatwoot/chatwoot/issues/15128
## How to reproduce
1. Add a required checkbox custom attribute to the pre-chat form.
2. Check and then uncheck it.
3. Submit the form; submission is now blocked until the checkbox is
checked.
## What changed
- Use the FormKit accepted rule for required checkbox fields.
- Map accepted validation failures to the existing pre-chat required
message.
---------
Co-authored-by: Nazmus Samir <nazmussamir@Nazmuss-MacBook-Pro.local>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
When an agent loops a new address into an ongoing email thread and then
adds a private note, the reply currently goes out with no Cc, and with
To falling back to the conversation contact. The newly added person
never receives the mail. This change makes an outgoing email keep the
To/Cc/Bcc that were entered on that reply, no matter what is added to
the conversation afterwards.
Closes#15193
## How to reproduce
1. Open a conversation on an Email inbox.
2. Add a new address to **Cc** and send a reply.
3. Immediately add a private note to the same conversation.
4. Inspect the delivered mail: `Cc` is empty and `To` is the
conversation contact instead of the addresses entered on the reply.
## What changed
`ConversationReplyMailer#cc_bcc_emails` and
`#to_emails_from_content_attributes` read the addresses from
`@conversation.messages.outgoing.last` rather than from the message they
were handed. Replies are delivered asynchronously
(`SendReplyJob.perform_later`, and `wait: 2.seconds` when the message
has attachments), so any outgoing message created in that window
replaces the recipients of a mail that is already queued. A private note
is the easiest way to hit it: private notes are outgoing messages, and
on an Email inbox `Messages::MessageBuilder#process_emails` stores them
with empty `to_emails` / `cc_emails` / `bcc_emails`.
Both lookups now go through the existing `current_message` helper
(`@message || @conversation.messages.outgoing.last`), which the `from`
and `reply_to` builders already use. `email_reply` sets `@message`, so
it resolves the recipients of the message being delivered;
`reply_with_summary` and `reply_without_summary` leave `@message` nil
and keep their current behaviour.
Added a spec covering the private-note case in
`spec/mailers/conversation_reply_mailer_spec.rb`.
## Note
I could not run the Ruby test suite locally — there is no Ruby toolchain
in the environment I worked in, so the new spec has not been executed on
my side. The change and the spec were verified by reading the code paths
(`Message#send_reply`, `Email::SendOnEmailService`,
`Messages::MessageBuilder#process_emails`,
`ConversationReplyMailerHelper#prepare_mail`). Deferring to CI for the
actual run.
Adds a dashboard-only takeover path for pending conversations currently
handled by an assistant/bot. Agents see the warning by default, stay in
private-note mode while the conversation is pending, and can use Take
over to move the conversation back to human handling.
## Related
- Original scope:
https://linear.app/chatwoot/issue/CW-7450/block-replies-and-add-takeover-for-agent-bot-ownership
- Backend follow-up:
https://linear.app/chatwoot/issue/CW-7779/enforce-backend-reply-blocking-for-agent-bot-owned-conversations
## Why
We want to prevent accidental parallel handling from the dashboard while
an assistant is managing a pending conversation, without expanding this
PR into API-level enforcement. Backend blocking is tracked separately in
CW-7779.
## What changed
- Locks the dashboard composer to private-note mode while the
conversation status is `pending`.
- Shows the takeover banner by default for pending conversations.
- Uses the Agent Bot assignee name when the conversation payload exposes
one, otherwise falls back to `a bot`.
- Simplifies the banner action copy to `Take over`.
- Reopens and self-assigns the conversation from the takeover action.
- Clears stale local `AgentBot` assignee type when assigning the
conversation back to a human in the store.
## How to test
- Open a pending conversation assigned to an Agent Bot and verify the
banner says it is handled by that bot name.
- Verify the reply editor stays in private-note mode and public reply
mode cannot be selected while the conversation is pending.
- Click Take over and verify the conversation moves to open and is
assigned to the current agent.
- Open a pending Captain/Dialogflow-style conversation without an Agent
Bot assignee payload and verify the banner falls back to `a bot`.
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
Adds lifecycle log lines across the IMAP email fetch pipeline so we can
trace where a fetch run spends time or silently stops. Some IMAP inboxes
showed increasingly sparse fetch runs in production without matching
errors; existing logs did not cover job start, lock acquisition,
connection setup, or early-exit paths.
## What changed
- `Inboxes::FetchImapEmailInboxesJob`: log when a fetch job is enqueued
per inbox (temporary instrumentation).
- `Inboxes::FetchImapEmailsJob`: log job start, skip reason on early
return, lock attempt/acquisition, fetched count, processing completion,
job completion, and unexpected errors.
- `Imap::BaseFetchEmailService`: log successful IMAP connection and the
start of each header batch fetch.
All lines share the `[IMAP::FETCH_EMAIL_SERVICE]` tag for searchability.
No behavior changes.
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
## 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>
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>
`bundle-audit` in CI flags an Active Storage advisory with no patched
release on the Rails 7.1 line, failing lint on every open PR. Adds it to
the existing `.bundler-audit.yml` ignore list. Mitigated locally; remove
once on Rails 7.2.3.1+.
Related to https://linear.app/chatwoot/issue/INF-92
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
This is phase one of a rolling deployment for Captain burst handling.
The job now accepts an optional third argument named
`responding_to_message_id`. The job does not use the argument yet, and
no enqueue call changes in this PR. The change lets old workers accept
the future three argument payload while versions overlap during
deployment.
There is no behavior change.
This is a pre-requisite for
https://github.com/chatwoot/chatwoot/pull/15133 because if we introduce
another argument, and post deployment, older jobs will fail with
argument error and result in no captain replies
## Validation
* `bundle exec rspec
spec/enterprise/jobs/captain/conversation/response_builder_job_spec.rb`
* `bundle exec rubocop
enterprise/app/jobs/captain/conversation/response_builder_job.rb`
WhatsApp templates with variables in both a text header and body
currently show inputs only for the body. Agents therefore cannot provide
the header value in the template composer, even though the API and
backend support the corresponding `processed_params.header` payload.
The composer now displays text-header variables separately, previews
their substituted values, and sends them alongside body parameters.
Templates using media headers remain unchanged.
Related: https://github.com/chatwoot/utils/pull/65
### Things to know
This PR consumes the released `@chatwoot/utils@0.0.57`, which adds
text-header parameter construction and completeness validation.
### How to reproduce
1. Open a WhatsApp template containing text header `Welcome {{1}}` and
body variables `{{1}}` and `{{2}}`.
2. Observe that the current composer displays only two body inputs and
omits the header input.
### How to test
1. Open the same template in the conversation composer.
2. Confirm one header input and two body inputs are displayed.
3. Fill the values and confirm both the header and body previews update.
4. Send the template and confirm `processed_params` contains `header.1`,
`body.1`, and `body.2`.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Resolved conversations now preserve historical SLA misses without
allowing their displayed duration to keep growing. Applied SLAs record a
stable completion timestamp that is shared through REST and realtime
payloads, and the dashboard freezes FRT, NRT, and RT misses at that
point.
Legacy completed SLAs without a reliable timestamp remain visible as a
static missed state. Terminal SLAs remain frozen when a conversation is
reopened; a reopen before finalization continues the same SLA without
resetting its deadlines.
### Closes
[CW-7597](https://linear.app/chatwoot/issue/CW-7597/freeze-sla-miss-durations-after-conversation-resolution)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How to reproduce
1. Apply an SLA with a resolution-time threshold to a conversation.
2. Let the threshold breach, then resolve the conversation.
3. Observe that the recorded miss duration continues increasing every
minute even though the conversation is resolved.
## What changed
- Added nullable `applied_slas.completed_at` and exposed it as
`sla_completed_at` in conversation, report, and websocket payloads.
- Captured completion before broadcasting resolution and preserved it
for terminal applied SLAs.
- Frozen recorded FRT, NRT, and RT durations in classic and
next-generation conversation labels, including a static fallback for
legacy rows.
- Added a dry-run-first, resumable Rails runner for account-scoped or
explicitly global historical repair without enqueuing jobs or touching
`updated_at`.
Account-scoped production rollout starts with:
```sh
ACCOUNT_ID=168154 bundle exec rails runner script/backfill_applied_sla_completed_at.rb
ACCOUNT_ID=168154 APPLY=true bundle exec rails runner script/backfill_applied_sla_completed_at.rb
```
## How Has This Been Tested?
- Verified resolution stamping, nonterminal reopen clearing, and
terminal reopen preservation.
- Verified dry-run, apply, account/global scope, resume, skip,
idempotency, and timestamp-preserving backfill behavior.
- Verified all three miss types freeze and existing conversation-card
behavior remains intact.
- 71 focused RSpec examples and 37 focused Vitest examples pass.
- RuboCop, ESLint, and diff checks pass.
## 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>
Captain now keeps v2 replies within each conversation channel's delivery
limit, preventing generated responses from being rejected by providers
such as Instagram, Facebook, and WhatsApp.
## Closes
-
https://linear.app/chatwoot/issue/AI-188/captain-should-respect-whatsapp-character-limits
## How to reproduce
1. Enable Captain v2 on an Instagram inbox.
2. Ask a question that produces a response longer than 1,000 characters.
3. Observe that Meta rejects the outgoing message with error 100 because
it exceeds Instagram's character limit.
## What changed
- Resolve the outbound character limit from the conversation channel,
including provider-specific Twilio limits.
- Add the resolved limit to the assistant and scenario prompts.
- Apply the same limit to the v2 structured response schema so the model
output conforms before delivery.
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
## Description
Article edits now ignore an `author_id` that does not belong to the
current account, retain the existing author, and still apply other valid
article changes. Article creation continues to reject cross-account
authors with a generic validation error and without creating a record.
The authenticated article serializers still omit authors without a
current-account membership so existing forged or stale records cannot
expose agent profile fields. The guard now checks `current_account_user`
directly to make that intent explicit.
## Closes
Follow-up to [CW-7665](https://linear.app/chatwoot/issue/CW-7665) and
[#15191](https://github.com/chatwoot/chatwoot/pull/15191).
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Creating an article with a cross-account author returns `422` and does
not create an article.
- Updating an article with a cross-account author retains the previous
author while applying other valid attributes.
- Articles whose previous author is no longer an account member can
still be edited without exposing that author's agent profile.
- Existing OSS and Enterprise article request coverage passes locally.
## 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 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: Vishnu Narayanan <iamwishnu@gmail.com>
## Description
Backend CI no longer flakes when the conversation FAQ grouping-lock spec
runs after Rails has reloaded application constants.
The job already raises the intended lock-acquisition error and prevents
concurrent suggestion generation. This updates the assertion to compare
the error class name, preserving that behavior without depending on a
reload-sensitive Ruby `Class` object.
The failure was reproduced in [CircleCI backend job
171299](https://app.circleci.com/pipelines/github/chatwoot/chatwoot/116560/workflows/efcee2f1-5af8-4121-82c3-920002dc420b/jobs/171299).
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
The isolated job spec passes, the exact 18-way CircleCI shard selection
passes all 442 examples, and the changed spec passes Ruby lint.
## 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] New and existing unit tests pass locally with my changes
# Pull Request Template
## Description
Adds API-key authorization support for Searchkick/OpenSearch so Elastic
Cloud deployments can configure advanced search with an Elastic API key
instead of embedding basic auth in the URL.
The initializer now accepts `OPENSEARCH_API_KEY` or
`ELASTICSEARCH_API_KEY` and forwards it as an `Authorization: ApiKey
...` header. `.env.example` also documents the
OpenSearch/Elasticsearch-compatible search variables.
Refs
https://linear.app/chatwoot/issue/CW-7511/populate-test-data-set-and-run-experiments
## 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?
- `bundle exec ruby -c config/initializers/searchkick.rb`
- `bundle exec ruby -c spec/config/searchkick_spec.rb`
- `bundle exec rspec spec/config/searchkick_spec.rb`
- `bundle exec rubocop config/initializers/searchkick.rb
spec/config/searchkick_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
- [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
- [ ] Any dependent changes have been merged and published in downstream
modules
## Description
Consolidates all widget API throttles under the single
`ENABLE_RACK_ATTACK_WIDGET_API` flag, each with its own independent kill
switch and configurable limit, with defaults tuned from real prod
traffic.
Fixes https://linear.app/chatwoot/issue/INF-83
Related to https://linear.app/chatwoot/issue/INF-77
Parent flag stays default-true; installs that disabled it keep today's
behavior (no widget throttling). Each endpoint adds
`ENABLE_RACK_ATTACK_WIDGET_<X>` + `RATE_LIMIT_WIDGET_<X>`.
- **conversations create**: keyed on (IP, website_token), 30/min (was
per-IP 6/12h)
- **messages create**: new throttle, (IP, website_token), 60/min (was
unthrottled)
- **contact update**: fixes a dormant bug. `resource :contact` gives the
singular URL `/api/v1/widget/contact`, but the throttle checked plural
`/api/v1/widget/contacts` so it never fired. Now active (60/1h per IP).
- **widget load**: 5 to 200/1h, tuned from prod (real per-IP loads top
out ~50/hr; the higher tail is crawlers/scrapers)
- **transcript**: 5/1h retained
Token precedence: the (IP, website_token) throttles read `website_token`
via ActionDispatch (query wins), matching the controller, so a
body-supplied token cannot fork the throttle bucket.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
`ruby -c` and rubocop clean. No spec added, matching this file's
existing no-spec convention for throttles.
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
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>
## Description
The dashboard "update to vX.Y.Z is available" banner is a self-hosted
upgrade nudge, but nothing gates it to self-hosted installs. On a
managed cloud instance the banner can still appear:
`latest_chatwoot_version` is populated in Redis from the hub's
advertised latest stable release, and the frontend compares it
(`semver.lt`) against the per-request `appVersion` baked into the
dashboard HTML. When a browser session is holding HTML rendered before
the current deploy, `appVersion` lags the hub's advertised version and
the banner fires, even though the managed instance is already on the
newest build.
This gates the value at the source: `api/v1/accounts#show` no longer
sets `latest_chatwoot_version` when running on cloud, so
`hasAnUpdateAvailable` short-circuits (`semver.valid(null)` is false)
and the banner never renders there. Self-hosted behaviour is unchanged.
Fixes https://linear.app/chatwoot/issue/CW-7763
An API-level issue on Meta’s side is preventing Chatwoot Cloud customers
from completing some Meta inbox setup flows and can affect actions in
existing Instagram conversations. This draft temporarily gates the
affected Facebook, Instagram, and WhatsApp flows behind one incident
flag and gives users clear guidance with a link to the current status
incident.
Self-hosted installations remain unchanged. While WhatsApp Embedded
Signup is unavailable, selecting WhatsApp Cloud takes eligible users
directly to manual setup and explains the current limitations.
Related: https://status.chatwoot.com/incident/976975
Fixes
https://linear.app/chatwoot/issue/CW-7771/guide-users-through-meta-api-incident
### Things to know
- `IS_META_INBOX_CREATION_DISABLED` is the single temporary rollout flag
and is currently enabled.
- The incident behavior applies only to Chatwoot Cloud.
- Facebook, Instagram, and WhatsApp Embedded Signup are removed from the
new onboarding suggestions while the incident is active.
- Existing Instagram inbox settings and conversations show incident
guidance with a status link.
- The WhatsApp Cloud provider routes to manual setup while the flag is
enabled.
- Manual setup works only for numbers already connected to WhatsApp
Cloud API; numbers using WhatsApp Business app coexistence are not
supported by this flow yet.
- The flag should be disabled or removed after the incident is resolved.
### How to test
1. Run Chatwoot with the Cloud installation configuration and open the
new inbox flow.
2. Confirm Facebook and Instagram authentication actions are disabled
and display the amber incident banner.
3. Open the WhatsApp provider selector and confirm WhatsApp Cloud is
described as manual setup with Cloud API credentials.
4. Select WhatsApp Cloud and confirm it opens the manual setup form with
the incident warning and links to the current status incident.
5. Open WhatsApp Embedded Signup directly and confirm the signup action
is disabled while the eligible manual setup option remains available.
6. Open the initial account onboarding flow and confirm Meta channels
are not offered while other configured channels remain available.
7. Open an existing Instagram inbox and conversation and confirm the
incident guidance links to the current status incident.
8. Run the same flows as a self-hosted installation and confirm they
remain available.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
The help center article endpoints permit `author_id` and render the
author through the agent serializer (`_agent.json.jbuilder`), which
exposes `email` plus name, role, and availability. `author_id` was never
scoped to the current account, so a forged or stale author disclosed the
profile of a user in another account. This is the article path of the
same serializer disclosure class as the conversation participants fix.
The fix has two parts:
- **Serializer guard (the disclosure fix).** The article partials now
render the author only when they are a member of the current account
(`article.author&.account`). This closes the leak on every read and for
every row, including articles that already carry a forged or stale
out-of-account author, and mirrors how the conversation assignee is
already handled.
- **Create-only validation.** `author_id` is checked against the
account's users on create, so a new article cannot be forged with an
out-of-account author. Update needs no guard: a non-member author is
simply never rendered, so editing an article whose author has left the
account continues to work.
Fixes https://linear.app/chatwoot/issue/CW-7665
Related: https://github.com/chatwoot/chatwoot/pull/15180
(https://linear.app/chatwoot/issue/CW-7746).
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>
## Description
Follow-up to #15147. The migration missed `if_not_exists`, so it fails
with `index already exists` on a re-run or when the index is pre-built.
Makes it idempotent, matching recent concurrent-index migrations.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
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.
The Captain agents overview now defaults to the last 7 days instead of
this month, so the page opens on a more recent and actionable window.
## What changed
- Overview page, range selector, and welcome card default to `7`.
- Backend `Captain::AssistantStatsWindow::DEFAULT_RANGE` changed from
`30` to `7`, so requests without a `range` param (or with invalid
values) also resolve to the last 7 days.
## How to test
- Open Captain → Overview: the range selector should show "Last 7 days"
by default and metrics should reflect that window. Other ranges continue
to work as before.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Adds an opt-in merge flag to the conversation custom attributes endpoint
so integrations can update only the keys they send instead of replacing
the whole hash, matching how the contacts endpoint already behaves. Also
adds a destroy_custom_attributes endpoint to remove specific keys,
mirroring the contacts convention. Replace stays the default, so
existing integrations are unaffected.
How to test
POST /conversations/:id/custom_attributes com { "custom_attributes":
{"a":1} }, then { "custom_attributes": {"b":2}, "merge": true } results
in {a:1, b:2}; no merge, results in {b:2}.
POST /conversations/:id/destroy_custom_attributes with {
"custom_attributes": ["a"] } removes only a.
---------
Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com>
WhatsApp phone-number health could be discarded when the separate WABA
business-information request failed due to missing business-management
permissions. This left the health snapshot empty even though Meta
successfully returned the phone’s status, quality, capacity, and other
operational fields.
This change treats WABA information as optional enrichment after a
successful phone-number request. Available phone health is persisted and
returned, while the enrichment failure remains recorded in
`phone_number_health_error`. Failures from the primary phone-number
request continue to follow the existing error path.
Related: https://github.com/chatwoot/chatwoot/pull/15100
### How to reproduce
1. Configure a WhatsApp Cloud API inbox whose token can read its
phone-number node but cannot access `owner_business_info` on the WABA.
2. Open Settings → Inbox → Account Health or run the scheduled health
sync.
3. Observe that the phone-number request succeeds while the WABA request
returns a permission error.
### How to test
1. Refresh Account Health for the affected inbox.
2. Confirm the available phone status, quality rating, messaging limit,
verification state, throughput, and coexistence information are
populated.
3. Confirm unavailable business-account and portfolio fields remain
absent.
4. Confirm the WABA permission failure is retained in the channel’s
health error field.
5. Confirm a failure from the phone-number endpoint still records the
error without replacing the last successful health snapshot.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
WhatsApp's migration to usernames / **Business-Scoped User IDs (BSUID)**
means a contact can become addressable only by a BSUID (format
`CC.<id>`, e.g. `BR.1393...`) when no phone number is exposed. Per
Meta's Cloud API, a BSUID recipient must be sent in the **`recipient`**
field (with `recipient_type: "individual"`), **not** in `to`.
Today `Whatsapp::Providers::WhatsappCloudService` always places the
recipient in `to`. When `to` carries a BSUID, the Graph API returns
**HTTP 200 with a message id** but **silently drops the message**: it
strips the country prefix and treats the remainder as a phone number
(`wa_id`), which never resolves, so nothing is delivered and **no error
is surfaced**. In the username-only era this means agents reply into the
void — Chatwoot marks the message as sent while the customer receives
nothing.
This PR adds a small helper, `recipient_params`, that routes the
outgoing identifier to the correct field:
- a **BSUID** → `{ recipient_type: "individual", recipient: <bsuid> }`
- a **phone number** → `{ to: <phone> }` (unchanged behaviour)
It is applied to all four Cloud send paths: text, attachment, template
and interactive. BSUID detection reuses the existing
`RegexHelper::WHATSAPP_BSUID_REGEX`. No Graph API version bump is
required (see testing below).
Related to #13837 (this covers the **outbound sending** part).
### References
- Meta — *Business-scoped user IDs*:
https://developers.facebook.com/documentation/business-messaging/whatsapp/business-scoped-user-ids/
— "set `recipient` to the user's BSUID or parent BSUID"; when both `to`
and `recipient` are present, `to` takes precedence.
- BSUIDs began appearing in webhooks in April 2026; sending **to** a
BSUID was enabled by Meta in July 2026.
## 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 to not work as expected)
- [ ] This change requires a documentation update
## How Has This Been Tested?
Verified **live** against a real, Meta-registered WhatsApp Cloud number,
sending to a real BSUID captured from an inbound webhook, on **both
Graph API v13.0 (the current default in this service) and v22.0**:
| # | API version | recipient field | Meta response | delivered? |
|---|-------------|-----------------|---------------|:----------:|
| 1 | v22.0 | `recipient` = BSUID | `200` · `contacts[].user_id` echoed
| ✅ |
| 2 | v22.0 | `to` = BSUID | `200` · `contacts[].wa_id` (prefix
stripped) | ❌ |
| 3 | v13.0 | `recipient` = BSUID | `200` · `contacts[].user_id` echoed
| ✅ |
- When the API echoes `user_id`, the BSUID is accepted and the message
**is delivered**; when it echoes `wa_id` (prefix stripped), it is
**not** — confirmed on the receiving handset.
- **v13.0 already accepts `recipient`**, so no Graph API version bump is
needed.
- Added unit specs asserting the request body uses `recipient` +
`recipient_type` for a BSUID and `to` for a phone number, across the
send paths.
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [x] I have commented 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
- [ ] 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>
## Description
When a WhatsApp Cloud inbox is deleted,
`Whatsapp::WebhookTeardownService` clears the phone-level webhook
override and unsubscribes the app from the WABA (when it's the last
inbox), but it **never deregisters the phone number**.
Because the number stays registered to the app, Meta reports that the
number is **"already registered to a partner app"** when the user later
tries to re-add it under a different app/BSP — leaving the number
effectively stuck.
This adds a deregister step so the number is released on deletion:
- New `Whatsapp::FacebookApiClient#deregister_phone_number` → `POST
/{phone_number_id}/deregister`.
- `WebhookTeardownService` calls it during teardown (alongside the
existing override-clear and app-unsubscribe), guarded on
`phone_number_id` and wrapped so a failure is logged and never blocks
the channel delete.
Docs:
https://developers.facebook.com/docs/whatsapp/cloud-api/reference/registration
(deregister)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How has this been tested?
Unit specs for both the new API client method and the teardown service
(Meta API stubbed with WebMock), mirroring the existing
`register_phone_number` / teardown coverage.
## Checklist
- [x] My code follows the style guidelines of this project
- [x] I have added tests that prove my fix is effective
- [x] New and existing unit tests pass locally with my changes
---------
Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com>
When an outbound WhatsApp call could not be placed, agents sometimes saw
a completely empty error (`{"error":""}`) with no indication of what
went wrong. This makes an outbound call that is blocked at Meta (for
example, a WhatsApp Business Account with a billing/eligibility problem)
look like a generic, unexplained failure. Agents now see the actual
reason Meta returned.
## Closes
No linked issue — found via a customer support investigation (outbound
calling returning `422 {"error":""}`).
## How to reproduce
1. On an account with WhatsApp calling enabled, place an outbound call
to a contact whose WhatsApp Business Account is not eligible for calling
(Meta returns error code `131044`, "Business eligibility payment issue
for calling").
2. Before: the call fails with `422 {"error":""}` — an empty message.
3. After: the call fails with Meta's actual message (e.g. "Business
eligibility payment issue for calling"), so the agent/admin knows it is
a Meta-side eligibility issue to resolve, not a Chatwoot bug.
## What changed
Meta's error responses can contain an **empty** `error_user_msg` (`""`)
while the real reason lives in `error.message` / `error_user_title` —
notably error `131044`. The previous code used `parsed.dig('error',
'error_user_msg') || 'Failed to initiate call'`, but an empty string is
truthy in Ruby, so the blank message was surfaced instead of the
fallback.
- Added a small `meta_error_message(parsed, default)` helper that
prefers the first **non-blank** field: `error_user_msg` → `message` →
`error_user_title` → default.
- Used it in both `process_initiate_call_response` (outbound call
initiate) and `update_calling_status`, which had the same pattern.
The `[WHATSAPP CALL] initiate_call failed: status=… body=…` server log
(with the full Meta body) is unchanged and remains the source of truth
for debugging.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Prevents the conversation participants endpoints from returning profile
details for users who cannot be assigned to the conversation's inbox.
Invalid participant IDs are now rejected before any participant records
are changed, so mixed valid and cross-account payloads fail atomically
without exposing user data.
## 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>
Administrators of suspended accounts can now reach the billing page to
settle payment and restore their account, instead of being fully locked
out on the suspended screen. The suspended screen shows a subtle
**Manage billing** link below the contact support button (admins on
Cloud only). Agents remain restricted to the suspended screen.
## How to test
1. On Cloud, suspend an account from Super Admin.
2. Log in as an administrator of that account — you land on the
suspended screen with a "Manage billing" link below contact support.
3. Click it — the billing settings page opens; subscription, Stripe
portal, and top-ups all work.
4. Log in as an agent — no billing link, and navigating to
`/settings/billing` manually redirects back to the suspended screen.
## What changed
- Router guard allows `billing_settings_index` for administrators when
the account is not active.
- Suspended screen gets a billing link gated by admin role and Cloud
installation.
<img width="3024" height="1718" alt="CleanShot 2026-07-24 at 12 25
56@2x"
src="https://github.com/user-attachments/assets/1905d070-5e67-4283-9c8d-6e9936bba9a3"
/>
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
## 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
# 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
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>
Stabilizes the Intercom transport-error spec when Rails reloads
application constants during the full backend suite. The production
client behavior is unchanged; the expectation now compares the exception
class name while continuing to verify its message and metadata.
## Closes
- Follow-up to
[CW-7615](https://linear.app/chatwoot/issue/CW-7615/optimize-intercom-import-reliability-and-bulk-message-ingestion)
- Follow-up to #15050
## How to reproduce
1. Run the backend shard containing the Intercom client spec after specs
that trigger Rails constant reloading.
2. Observe that the old matcher can reject an exception whose printed
class is still `DataImports::Intercom::Client::Error` because it
references a different class object.
3. Confirm the updated expectation accepts the reloaded class by name
and still verifies the transport error message and body.
## What changed
- Compare the raised Intercom client error using `error.class.name`.
- Preserve assertions for the user-facing error message and transport
error metadata.
## Checklist
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [x] New and existing focused unit tests pass locally with my changes
Captain now groups recurring questions from resolved conversations into
FAQ suggestions and orders them by the number of source conversations.
Agents can view suggestions and open source conversations they can
access. Administrators can edit, approve, or dismiss suggestions.
The old pending FAQ flow is removed. The Captain overview and FAQ page
now use open suggestion counts and link to the same review page.
Approved FAQs remain unchanged.
## Depends on
#14979
## Closes
https://linear.app/chatwoot/issue/CW-7496/fe-and-ux
## How to test
1. Open Captain and choose an assistant with open FAQ suggestions.
2. Open FAQ suggestions from the overview or the FAQ banner. Confirm
that suggestions are ordered by conversation count.
3. Switch assistants without leaving the page. Confirm that the previous
results clear and the new assistant results load.
4. Search for suggestions and move between pages. Change the search or
page again before the first request finishes, and confirm that the
latest request controls the results and loading state.
5. Open a suggestion and review its source conversations.
6. Make the source conversation request fail. Confirm that the dialog
keeps the error visible and that Retry loads the sources.
7. Sign in as an agent. Confirm that you can read suggestions and source
conversations you can access, but cannot edit, approve, or dismiss
suggestions.
8. Sign in as an administrator. Edit and save a suggestion, approve one
suggestion, and dismiss another.
9. Confirm that the approved suggestion appears in the assistant FAQ
list.
10. Open the old pending FAQ URL and confirm that it redirects to FAQ
suggestions.
## What changed
1. Added the FAQ suggestion list, cards, search, pagination, and empty
state.
2. Added a review dialog with source conversation links, a clear error
message, and a Retry button.
3. Added edit, approve, and dismiss actions for administrators.
4. Removed the old pending FAQ status, count, page, and bulk approval
action.
5. Updated the Captain overview and FAQ banner to use open suggestion
counts and link to FAQ suggestions.
6. Made each FAQ page load data for the selected assistant and ignore
results from older requests.
7. Kept the old pending FAQ URL as a redirect so saved links continue to
work.
---------
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>
## 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
Agents can review recurring FAQ suggestions when they can access at
least one supporting conversation. The detail view returns only source
conversations the agent can access. Administrators can review every
suggestion and can edit, approve, or dismiss it. Approval creates one
approved Captain FAQ and removes the stored source observations.
This is the third PR in the CW-7495 stack. It is built on
[#14978](https://github.com/chatwoot/chatwoot/pull/14978), which adds
the FAQ suggestion models and generation flow.
## Closes
Closes
[CW-7495](https://linear.app/chatwoot/issue/CW-7495/backend-llm-changes-to-make-conversation-faqs-as-signalssuggestions).
## What changed
1. Added a paginated suggestion list with assistant, status, and search
filters.
2. Limited agents to suggestions that have at least one source
conversation they can access.
3. Limited the detail response to the 50 most recent source
conversations the current user can access.
4. Allowed administrators to edit, approve, and dismiss open
suggestions.
5. Added approval that creates one approved Captain FAQ, closes the
suggestion, and removes its source observations.
6. Rejected approval when the suggestion language does not match the
account language.
7. Added row locking so an edit or dismissal cannot overwrite an
approval.
8. Prevented FAQ generation from attaching a new observation after a
suggestion has closed.
## How to test
1. Sign in as an agent who has access to one inbox but not another.
2. Confirm the agent sees only suggestions with at least one source
conversation from an accessible inbox.
3. Open a suggestion and confirm the source list does not contain
conversations from restricted inboxes.
4. Sign in as an administrator and confirm all account suggestions are
available.
5. Edit an open suggestion and approve it. Confirm one approved FAQ is
created and the suggestion no longer has source observations.
6. Try to approve a suggestion in a different language from the account
language. Confirm the request is rejected.
7. Dismiss another open suggestion and confirm it leaves the open review
queue.
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
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>
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.
Adds E2E UI tests for two core Phase 2 flows, building on the Playwright
setup from #13578.
**Agent onboarding** — validates the Agents settings page, Add Agent
modal elements, form validation (name + email required, submit disabled
until valid), and cancel behaviour.
**Inbox creation** — walks through the full API channel inbox creation
journey: channel selection → form fill → agent assignment → finish
screen.
## What changed
New UI component objects (`tests/playwright/components/ui/`):
- `agent-page.component.ts`
- `add-agent-modal.component.ts`
- `add-agents-form.component.ts`
- `settings-inbox-page.component.ts`
- `channel-selector.component.ts`
- `api-channel-form.component.ts`
- `finish-setup.component.ts`
New test specs (`tests/playwright/tests/e2e/ui/`):
- `agent-onboarding-flow-ui-validation.spec.ts`
- `inbox-creation-flow.spec.ts`
Updated `components/ui/index.ts` barrel export to include all new
components.
## How to test
```bash
cd tests/playwright
npx playwright test tests/e2e/ui/
```
All 5 tests pass locally (3 login + 2 new flows).
Closes part of the Phase 2 scope from the [Playwright E2E discussion
#13500](https://github.com/orgs/chatwoot/discussions/13500).
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
This improves the Captain overview by loading reporting metrics and FAQ
stats from separate endpoints. Range changes now refresh only the
metrics, while reopen-rate calculation reuses the resolved conversation
count to avoid redundant database queries.
## What changed
- Split Captain overview metrics and FAQ stats into separate APIs.
- Fetch FAQ stats independently from range-based metrics.
- Reuse resolved conversation totals when calculating reopen rate.
- Skip the reopen query when there are no resolved conversations.
# Pull Request Template
## Description
Locks the agent quota check to the account row while creating account
users. This fixes a race where concurrent agent-create requests could
all observe the same remaining seat before any `account_users` row was
inserted.
The API continues to return the existing `402 Account limit exceeded.
Please purchase more licenses` response when the limit is reached. Bulk
create now preflights the requested email count while holding the
account lock, then creates each agent through the same locked builder
path. The Enterprise custom-role hook now no-ops when create did not
produce an agent.
Fixes:
[CW-7039](https://linear.app/chatwoot/issue/CW-7039/race-condition-in-agent-creation-bypasses-plan-agent-seat-limit)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `POSTGRES_DATABASE=chatwoot_test_c20f_agent_quota REDIS_DB=9 bundle
exec rspec spec/builders/agent_builder_spec.rb
spec/enterprise/builders/agent_builder_spec.rb
spec/controllers/api/v1/accounts/agents_controller_spec.rb
spec/enterprise/controllers/api/v1/accounts/agents_controller_spec.rb
spec/enterprise/controllers/enterprise/api/v1/accounts/agents_controller_spec.rb`
- `bundle exec rubocop app/builders/agent_builder.rb
app/controllers/api/v1/accounts/agents_controller.rb
enterprise/app/controllers/enterprise/api/v1/accounts/agents_controller.rb
spec/builders/agent_builder_spec.rb
spec/enterprise/controllers/api/v1/accounts/agents_controller_spec.rb`
- `git diff --check`
- One-off threaded Rails validation with 8 concurrent `AgentBuilder`
calls against an account with one remaining seat: `created: 1`,
`limited: 7`, final `count=2`, `limit=2`.
## 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: Muhsin Keloth <muhsinkeramam@gmail.com>
Non-admin agents could delete an account's Linear, Notion, or Shopify
integration through the dedicated integration endpoints, which — unlike
the generic hooks endpoint — never checked the caller's role. This
restores the intended admin-only boundary for removing an integration.
## Closes
- https://linear.app/chatwoot/issue/CW-7383
- https://linear.app/chatwoot/issue/CW-7384
- https://linear.app/chatwoot/issue/CW-7189
## How to reproduce
As a non-admin **agent**, `DELETE
/api/v1/accounts/:id/integrations/{linear,notion,shopify}` returned
`200` and removed the account-wide integration. After this change it
returns `401` and the integration is preserved; administrators can still
remove it.
## What changed
- Route integration-hook deletion through `HookPolicy` (admin-only) via
a shared `Integrations::BaseController`, matching the generic hooks
controller.
Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com>
## Description
The widget email-transcript button (`ChatFooter.vue`) had no client-side
guard. Its visibility depends only on whether the contact has an email,
and the click handler fired a request on every click with no in-flight
lock, no disabled state, and no post-send handling. A user could
therefore trigger a large number of duplicate transcript emails from a
single conversation just by clicking repeatedly.
This adds a re-entry guard in the handler, disables the button while a
send is in flight, and applies a short cooldown (15s) after a successful
send. Normal use is unaffected: the button sends once, shows the success
toast, then briefly disables and automatically re-enables so a genuine
later re-request still works. On failure the button stays enabled so the
user can retry immediately. The cooldown timer is cleared on unmount.
Using a timed cooldown (rather than a permanent post-send lock) also
avoids the button getting stuck disabled if a resolved conversation is
reopened and later re-resolved.
This is the client-side complement to the server-side rate limit added
in #15085.
Fixes https://linear.app/chatwoot/issue/CW-7640
# Pull Request Template
## Description
This PR fixes a crash where opening a conversation threw `TypeError:
Cannot read properties of null (reading 'localeCompare')` and prevented
the agent assignment dropdown from rendering.
Since #14866, agent bots are included in the assignable agents list.
`AgentBot#name` is not presence-validated, so system bots (account-less,
global) can have a `null` name. Those nameless bots flowed into
name-based operations that assumed a string, causing crashes and
warnings across multiple surfaces:
* **Assignment dropdown sort:** `getAgentsByAvailability` called
`a.name.localeCompare(b.name)`, causing a `localeCompare` `TypeError`.
* **Dropdown search:** `MultiselectDropdownItems` called
`option.name.toLowerCase()`, causing a `toLowerCase` `TypeError`.
* **Agent Bots settings:** `Avatar` received `name=null` for a `String`
prop, triggering a Vue prop validation warning.
### What changed
* Keep nameless agent bots in the assignment dropdown and render a `-`
fallback label in `useAgentsList`. These are still valid,
assignable-by-ID records: the assignable agents API includes accessible
bots, and `Conversations::AssignmentService` assigns them by ID.
Preserving them avoids hiding valid assignment targets. Bots are still
included only when `includeAgentBots` is enabled.
* Make the sort in `getAgentsByAvailability` null-safe by coercing
missing names to an empty string (defense in depth).
* Make the search filter in `MultiselectDropdownItems` null-safe
(defense in depth).
* Pass a null-safe `name` prop to `Avatar` in the Agent Bots settings
list to eliminate the Vue prop validation warning.
Fixes
https://linear.app/chatwoot/issue/CW-7670/agent-assignment-dropdown-crashes-with-cannot-read-properties-of-null
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
1. Have a system agent bot (`name: null`) that is assignable to an
inbox.
2. Open any conversation in that inbox.
* The agent assignment dropdown renders without console errors.
* The nameless bot is listed with a `-` label and can be assigned.
3. Go to **Settings → Agent Bots**.
* The page renders without the `Avatar` prop validation warning.
## 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
WhatsApp automations now fail locally when they attempt to send a
free-form message after the 24-hour customer service window has closed.
This avoids sending an invalid template request to Meta and gives users
a clear, actionable error instead of “Template not found or invalid
template name.”
Template messages continue to be sent whenever template parameters are
present. Free-form messages continue to be sent normally while the
conversation is replyable.
Fixes
https://linear.app/chatwoot/issue/PLA-183/prevent-whatsapp-automations-outside-the-24-hour-window-from-producing
### How to reproduce
1. Create a WhatsApp automation that sends a message without template
parameters.
2. Trigger it on a conversation whose 24-hour customer service window is
closed.
3. Observe that the message previously reached the template send path
and failed with a misleading provider error.
### How to test
1. Trigger an automation with template parameters and confirm it sends
as a template message.
2. Trigger an automation without template parameters inside the 24-hour
window and confirm it sends as a free-form message.
3. Trigger an automation without template parameters outside the 24-hour
window and confirm it fails locally with a clear error and makes no
request to Meta.
### Things to know
This changes only the invalid closed-window, no-template path. Existing
template and in-window message behavior remains unchanged.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Fixes
https://linear.app/chatwoot/issue/PLA-99/whatsapp-messages-dropped-for-brazilargentina-numbers-due-to-phone
Fixes https://github.com/chatwoot/chatwoot/issues/14492
Meta's WhatsApp Cloud API includes `display_phone_number` in webhook
payloads, but its format can differ from the number stored in Chatwoot's
channel record.
In Brazil, Meta omits the mobile 9 prefix. For example, it sends
55419XXXXXXX (12 digits) instead of 554199XXXXXXX (13 digits). In
Argentina, Meta adds an extra 9 after the country code. For example, it
sends 549XXXXXXXXXX instead of 54XXXXXXXXXX.
The whatsapp event job uses `display_phone_number` for an exact-match
channel lookup. When the formats do not match, the lookup returns nil
and the incoming message is silently dropped, logging:
`Inactive WhatsApp channel: unknown - <phone_number>.`
The fix extends `get_channel_from_wb_payload` to fall back to normalized
phone number matching using the existing PhoneNumberNormalizationService
normalizers (Brazil, Argentina), which were previously only used for
contact-level lookups.
---------
Co-authored-by: Sojan Jose <sojan@pepalo.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
Agents can now place a WhatsApp call to a contact straight from the
contacts screen, even if that contact has never messaged in. Previously
the call only worked once a conversation already existed, so a freshly
added contact would fail with "Unable to start the call. Please try
again." — the only workaround was to get the contact to message the
channel first.
## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Manually via UI
## 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: Muhsin Keloth <muhsinkeramam@gmail.com>
WhatsApp embedded signup now uses
`whatsapp_embedded_signup_inbox_creation` as the single Chatwoot Cloud
rollout gate for inbox creation, proactive reconfiguration, and
disconnected inbox reauthorization. The authorization endpoint enforces
the same gate, so the UI and backend remain consistent.
Self-hosted installations keep their existing behavior.
## Things to know
- This reuses the existing feature flag; there is no migration or schema
change.
- The feature is shown as “WhatsApp Embedded Signup Flow” in feature
management.
- `whatsapp_reconfigure` remains visible and honored for self-hosted
proactive reconfiguration to preserve existing accounts. It can be
deprecated after the self-hosted dependency is removed or migrated.
## How to test
1. On Chatwoot Cloud, enable `whatsapp_embedded_signup_inbox_creation`
for an account.
2. Confirm that new WhatsApp inbox creation, proactive reconfiguration,
and disconnected inbox reauthorization are available.
3. Disable the flag and confirm those entry points are hidden and
authorization requests are rejected.
4. On self-hosted, confirm proactive reconfiguration remains controlled
by the existing `whatsapp_reconfigure` account setting.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
WhatsApp contacts using coexistence are identified by more than one
source ID (a phone `wa_id` and a `BR.`/BSUID identity), so a single
contact ends up owning multiple `contact_inbox` records. The "reopen the
same conversation" feature scoped conversation reuse to a single
`contact_inbox`, so messages arriving under a different identity of the
same contact started a brand-new conversation — even with reopen enabled
— producing duplicate conversations.
This scopes reuse to the contact across all of its `contact_inbox`
records in the inbox instead of a single `contact_inbox`.
## Closes
- [CW-7651
](https://linear.app/chatwoot/issue/CW-7651/duplicate-conversations)
## How to reproduce
1. On a WhatsApp Cloud inbox with "reopen the same conversation" (lock
to single conversation) enabled.
2. Have a coexistence contact whose webhooks alternate between carrying
the phone `wa_id` and only the BSUID identity.
3. Before: each identity opens its own conversation → duplicates. After:
incoming messages reopen the contact's existing conversation regardless
of which identity the webhook carried.
## What changed
- `Whatsapp::IncomingMessageBaseService#set_conversation` now looks up
reusable conversations via `@contact.conversations.where(inbox_id:
@inbox.id)` instead of `@contact_inbox.conversations`.
- Updated existing specs to wire the conversation's `contact` to the
contact_inbox's contact, mirroring production data.
## Linear Ticket
-
https://linear.app/chatwoot/issue/CW-7276/bsuid-support-to-whatsapp-voice-calling
## Description
Keeps WhatsApp voice calls in the same thread as the chat when a caller
has adopted a **WhatsApp username** and hidden their phone number.
This makes the inbound-call path BSUID-aware, reusing the same
identifier the messaging pipeline keys on so calls land on the existing
`ContactInbox`/conversation.
## Type of change
- [ ] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Locally via UI
## 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: Muhsin Keloth <muhsinkeramam@gmail.com>
Captain now saves agent session records when a user message includes an
image. The saved record keeps the image URL and excludes downloaded
image bytes, so image replies no longer report a JSON serialization
error after delivery.
Fixes:
https://chatwoot-p3.sentry.io/issues/7618423184/?alert_rule_id=13673680&alert_type=issue¬ification_uuid=d22a7ab9-95d6-4bba-85e0-733a28466775&project=6382945
## Root cause
RubyLLM downloads image attachments and caches the binary bytes inside
`RubyLLM::Content`. `SessionCaptureService` passed the live object to
the `run_context` JSON column. Rails then tried to encode the cached
JPEG bytes as UTF-8 and raised `JSON::GeneratorError`.
The error did not block replies, handoffs, or credit updates because
session capture rescues its own failures. The failed write meant that
Chatwoot lost the agent session record for the response.
## How to reproduce
1. Send an image to a Captain V2 assistant.
2. Let RubyLLM load the image during the model request.
3. Save the resulting conversation history in an agent session.
4. Observe the JSON encoding error when Rails reaches the cached image
bytes.
## What changed
`SessionCaptureService` now converts `RubyLLM::Content` to its JSON safe
hash before saving the current turn. The hash contains the message text
and attachment URL without the cached bytes. Other message content is
unchanged.
The focused service spec covers a cached JPEG byte payload and passes
with 12 examples. RuboCop reports no offenses in the changed service and
spec.
# Pull Request Template
## Description
Moves the WhatsApp & Twilio content-template logic to the shared
[`@chatwoot/utils`](https://github.com/chatwoot/utils)
([PR](https://github.com/chatwoot/utils/pull/62)) package so web and
mobile share one implementation. The neutral core takes the raw template
and returns `processed_params`, the same shape the web parsers already
use, so it's a drop-in with no behavior change.
- `templateHelper.js` / `URLHelper.js` → source `MEDIA_FORMATS`,
`findComponentByType`, `processVariable`, `buildTemplateParameters`,
`extractFilenameFromUrl` from the package
- `inboxes.js` → filters with shared `isSendableTemplate`
- `WhatsAppTemplateParser.vue` / `ContentTemplateParser.vue` →
`isFormInvalid` and Twilio media helpers now use the shared
`isWhatsAppComplete` / `isTwilioComplete` / `applyTwilioMediaFilename`
> Depends on the `@chatwoot/utils` release adding the shared template
API, bump `package.json` from `^0.0.55` to the published version before
merge.
Fixes
[CW-7540](https://linear.app/chatwoot/issue/CW-7540/web-templates-integration-with-utils)
## Type of change
- [x] Breaking change (Refactor)
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Description
The widget conversation transcript endpoint (`POST
/api/v1/widget/conversations/transcript`) has no rate limit. Every other
comparable endpoint does: the agent-facing transcript API and the widget
conversation-create and contact-update endpoints are all throttled. This
gap lets a single client trigger a large burst of transcript emails from
one conversation.
This adds an IP-based throttle (5 requests/hour) for the endpoint,
placed inside the existing widget-API throttle block so it inherits the
`ENABLE_RACK_ATTACK_WIDGET_API` opt-out used by embedded/iframe clients.
The limit is generous for legitimate use (a visitor emailing themselves
a transcript) while stopping abusive loops. Throttled requests get the
standard 429 the widget already handles.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
`config/initializers/rack_attack.rb` throttles have no existing specs in
this file, so this follows the established convention (no new spec).
Verified `ruby -c` and `rubocop` pass on the file. The new throttle
mirrors the sibling widget throttles directly above it (same IP key,
path guard, and structure).
## 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
---------
Co-authored-by: Sojan Jose <sojan@pepalo.com>
Token-authenticated requests to Agent Bots, Labels, and affected Captain
endpoints return normal responses again. The regression was caused by
duplicate `current_account` callbacks in subclasses moving account
resolution behind the API entitlement check, leaving `Current.account`
unset.
## Closes
- https://linear.app/chatwoot/issue/CW-7641/5xx-errors-in-agent-bot-apis
## How to reproduce
1. Send `GET /api/v1/accounts/:account_id/agent_bots` with a valid
administrator API access token.
2. Observe a `500` from `validate_token_api_access` because
`Current.account` is `nil`.
3. With this change, account resolution runs in the base-controller
order and the request succeeds.
## What changed
- Removed redundant `current_account` callbacks from account-scoped
controllers that already inherit the callback from
`Api::V1::Accounts::BaseController`.
- Kept the standalone direct-upload controller callback unchanged.
- Added regression coverage for administrator API-token access to Agent
Bots.
Enables Uzbek as a selectable Chatwoot language and wires the `uz`
locale into the dashboard, widget, and survey translation loaders.
## Closes
Closes https://github.com/chatwoot/chatwoot/issues/15030
## Why
Uzbek is now available in the Chatwoot Crowdin project. The widget
translation has been proofread and is 100% translated and approved.
## What changed
- Adds Uzbek to the supported language registry
- Registers the `uz` locale with the dashboard, widget, and survey i18n
loaders
## Validation
- Proofread the Uzbek widget translation in Crowdin
- Verified placeholder preservation and corrected wording where needed
- Confirmed the widget file is 100% translated and 100% approved
This draft intentionally remains blocked until the Crowdin sync adds the
generated Uzbek locale files. It should only be marked ready and merged
after that sync lands.
Updates the vulnerable Ruby dependencies reported by bundle audit so the
application resolves to patched versions.
## Why
The latest Ruby advisory database reports known vulnerabilities in
Datadog, Loofah, and Rails HTML Sanitizer on `develop`, including a
high-severity denial-of-service advisory in Datadog.
## What changed
- Updates `datadog` from 2.19.0 to 2.38.0
- Updates `loofah` from 2.23.1 to 2.25.2
- Updates `rails-html-sanitizer` from 1.6.1 to 1.7.1
- Refreshes Datadog's required native packages
## Validation
Verified the resolved bundle is satisfied, bundle audit reports no known
vulnerabilities, and Datadog 2.38.0 loads successfully.
## Description
Adds Swagger API documentation for branded email layouts, including the
account-level layout endpoint, Email inbox update field, and generated
API schemas. This stacked PR keeps the implementation review in #14936
focused on the product change.
Related:
[CW-7514](https://linear.app/chatwoot/issue/CW-7514/branded-html-email-templates-per-inboxbrand)
Depends on #14936
## Type of change
- [x] This change requires a documentation update
## How to test
1. Run `bundle exec rake swagger:build`.
2. Start Chatwoot locally and open `http://localhost:3000/swagger`.
3. Verify the branded email layout account endpoint and Email inbox
`branded_email_layout` field appear in the API reference.
## Checklist
- [x] I have performed a self-review of my changes
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
WhatsApp inbox creation now shows Embedded Signup for Chatwoot Cloud
accounts only when the new `whatsapp_embedded_signup_inbox_creation`
feature flag is enabled. Cloud accounts without the flag go directly to
manual WhatsApp Cloud API setup, while self-hosted installations with a
configured WhatsApp App ID retain their existing Embedded Signup flow.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## 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
Restores the Inbox Channels dialog’s Facebook-gating test coverage by
isolating account feature dependencies that are unrelated to these
cases. This keeps the onboarding checks focused on whether Facebook is
configured and avoids initializing router and account-store state.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Suspended accounts no longer participate in scheduled WhatsApp template
syncs. This avoids unnecessary external API calls while keeping the
existing refresh behavior unchanged for active accounts.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Instagram inbox creation is available again on Chatwoot Cloud. Users can
discover and connect Instagram during onboarding or from Add Inbox,
while WhatsApp restrictions and existing-inbox Instagram advisories
remain unchanged.
Closes https://linear.app/chatwoot/issue/CW-7549/enable-instagram
## How to test
1. On Chatwoot Cloud, open Add Inbox and confirm Instagram can be
selected.
2. Confirm **Continue with Instagram** is enabled and starts the OAuth
flow.
3. In onboarding, confirm Instagram is displayed and can start OAuth.
4. Confirm WhatsApp embedded signup remains restricted.
## What changed
- Removed the Cloud-only Instagram filter and OAuth guard from
onboarding.
- Re-enabled the regular Instagram inbox creation action on Cloud.
- Removed the obsolete “Instagram inbox creation is temporarily
unavailable” copy.
- Updated the onboarding expectation for Chatwoot Cloud.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Records a `Captain::Session` row for every Captain V2 assistant response
delivered in a conversation, so we can show how a response was generated
and report on credit, FAQ, and document usage. Stacked on #14970 (the
`captain_sessions` model).
## What changed
- `FaqLookupTool` now records the retrieved FAQ ids (and their backing
document ids) into the shared run state, accumulated across tool calls.
- `AgentRunnerService` exposes the raw ai-agents run result via
`last_run_result`; the `generate_response` return shape is unchanged, so
the playground path is unaffected.
- New `Captain::Assistant::SessionCaptureService` builds the session:
scenario resolved from the answering agent name, model from
`assistant.agent_model`, token usage plus the trimmed current-turn
conversation history stored in `run_context`.
- `ResponseBuilderJob` captures after delivery: `credits_consumed`
mirrors the actual charge (1.0 for a billed response, 0.0 for handoffs,
where the session points at the customer-facing handoff message).
Capture runs outside the delivery transaction and swallows its own
failures, so a logging bug can never block or roll back a customer
reply.
V1 responses and copilot are out of scope; copilot capture comes next.
## How to test
On an account with `captain_integration_v2` enabled and an inbox
connected to an assistant with approved FAQs, send a customer message on
a pending conversation. After the assistant replies, a
`Captain::Session` row should exist with the conversation as subject,
the reply message as result, the FAQs/documents used, and the run
context for that turn. Asking for a human agent should produce a
zero-credit session pointing at the handoff message.
<img width="2428" height="1058" alt="CleanShot 2026-07-15 at 17 25
40@2x"
src="https://github.com/user-attachments/assets/d8e44923-c17b-494f-8c33-c8fa4219438c"
/>
Conversation attachment uploads now go through the same authentication
that every other account-scoped API endpoint uses. Agents continue to
attach files exactly as before, and the upload request is now tied to
the agent's dashboard session instead of a separately serialized access
token.
Because the upload request is now authenticated, the dashboard proves
the agent's session directly instead of passing
`currentUser.access_token`. This keeps uploads working alongside the
profile access-token changes in #14973, including on accounts where that
token is serialized as empty.
## What changed
- `Api::V1::Accounts::Conversations::DirectUploadsController` now runs
the standard account auth stack: API access token when the
`api_access_token` header is present, dashboard session
(devise-token-auth) otherwise, with agent-bot tokens rejected.
Previously it inherited `ActiveStorage::DirectUploadsController`
directly and did not run any authentication.
- `EnsureCurrentAccountHelper#ensure_current_account` now returns `401`
when a request has neither an authenticated user nor a bot resource,
instead of continuing. This closes the same gap for any controller that
relies on the helper.
- The dashboard direct-upload paths (`useFileUpload.js` and the legacy
`fileUploadMixin.js`) now attach the agent's session headers to the
upload request via a new `directUploadsHelper.js`, instead of sending
`currentUser.access_token`.
## How to test
1. As a logged-in agent, open a conversation and attach a file. Upload
should succeed as before, on installs with direct uploads enabled.
2. Confirm attachments still work for an agent on an account whose
profile access token is not serialized (e.g. a Cloud plan without
`api_and_webhooks`).
3. Send a `POST` to
`/api/v1/accounts/:account_id/conversations/:conversation_id/direct_uploads`
with no credentials, an empty `api_access_token`, or an invalid token,
and confirm it returns `401`.
4. Confirm a valid agent of the account (via API token or session) gets
`200`, while an agent of a different account gets `401`.
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>
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>
Show the reauthorization banner whenever an embedded signup inbox has a
reauthorization error instead of suppressing it when the manual
migration flow is enabled. Reword the manual migration banner and dialog
as a recommendation to reconnect with your own Meta app, and switch
their styling from amber warning to blue info.
# Pull Request Template
## Description
This PR fixes the white background bleed visible in the widget, article
viewer, and Help Center when dark mode is active.
This change was previously merged but later reverted due to a background
being added for the unread bubble.
Reverted PR: https://github.com/chatwoot/chatwoot/pull/13955,
https://github.com/chatwoot/chatwoot/pull/13981
**What was happening**
While scrolling, the `<body>` element retained a white background in
dark mode. This occurred because dark mode classes were only applied to
inner container elements, not the root.
**What changed**
* **Widget:** Updated the `useDarkMode` composable to sync the `dark`
class to `<html>` using `watchEffect`, allowing `<body>` to inherit dark
theme variables. Also added background styles to `html`, `body`, and
`#app` in `woot.scss`.
* **Help center portal:** Moved `bg-white dark:bg-slate-900` from
`<main>` to `<body>` in the portal layout so the entire page background
responds correctly to dark mode, including within the widget iframe.
* **ArticleViewer:** Replaced hardcoded `bg-white` with `bg-n-solid-1`
to ensure better theming.
Fixes
https://linear.app/chatwoot/issue/CW-6704/widget-body-colour-not-implemented
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Screencasts
### Before
**Widget**
https://github.com/user-attachments/assets/e0224ad1-81a6-440a-a824-e115fb806728
**Help center**
https://github.com/user-attachments/assets/40a8ded5-5360-474d-9ec5-fd23e037c845
### After
**Widget**
https://github.com/user-attachments/assets/dd37cc68-99fc-4d60-b2ae-cf41f9d4d38c
<img width="347" height="265" alt="image"
src="https://github.com/user-attachments/assets/89460b36-c8ed-4579-9737-c258c6fe5da5"
/>
**Help center**
https://github.com/user-attachments/assets/bc998c4e-ef77-46fa-ac7f-4ea16d912ce3
## 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>
## Description
The conversation sidebar counts (`GET /conversations/meta`) are polled
on a debounced cadence selected from the last known conversation count
(`allCount` in the `conversationStats` store).
`allCount` starts at `0` and is only set after a **successful** meta
response. When the meta query is slow or failing under load, `allCount`
stays `0`, which selected the fastest cadence, so every client polled as
aggressively as possible exactly when the endpoint was already
struggling. On large accounts with many concurrent agents this
multiplies into sustained load that keeps the query slow, a
self-reinforcing loop.
This PR makes two changes:
1. **Treat an unknown count (`0`) as a large account** and poll at the
slowest cadence instead of the fastest (`getMetaDebounceKey`, extracted
as a pure, testable function). This breaks the failure loop.
2. **Raise the debounce intervals across all tiers** so counts are
polled less frequently under sustained activity:
- fast: max 1 poll / 2s -> 1 / 5s
- mid: 1 / 10s -> 1 / 20s
- slow (large/unknown accounts): 1 / 20s -> 1 / 30s
First-load counts still render immediately (the debounce fires on the
leading edge for the very first call), so the higher intervals only
affect the sustained poll rate, not initial render.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
# 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>
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.
Improves Captain V1 → V2 migration for complex legacy instructions so
mandatory triggers, workflows, language rules, and escalation behavior
remain active while query-dependent product knowledge is prepared as
pending FAQ candidates.
## What changed
- Added explicit preservation rules for mandatory triggers, verification
steps, escalation conditions, exceptions, and language behavior.
- Added an auditor that checks the draft and fixes any issues before
manual review.
- Kept the existing migration application contract and schema limits
unchanged
- Added focused regression coverage for the complex-prompt classifier
contract.
## How to reproduce
Generate a migration draft for an assistant with dense legacy
instructions containing mandatory handoff triggers, verification rules,
product facts, and multi-step workflows. The resulting draft should keep
actions active, place query-dependent facts in FAQ candidates, and avoid
silently dropping or reversing source requirements.
Focused Captain migration specs and RuboCop checks pass locally.
Captain V2 assistants can now use every enabled custom tool from their
account through the main assistant. The change keeps existing custom
tool access when an assistant has no migrated scenarios, so switching
from V1 does not remove the capability without warning.
## How to reproduce
1. Create and enable an account custom tool.
2. Use an assistant with no custom instructions and no generated
scenarios.
3. Enable Captain V2 for the account.
4. Before this change, the main assistant receives only FAQ lookup and
handoff. After this change, it also receives the enabled account custom
tool.
## What changed
The main V2 assistant now loads enabled custom tools through its account
association. Scenario agents still load only the tools named in their
scenario instructions. The account custom tool limit keeps the added
tool count bounded.
Focused model coverage verifies enabled tools, disabled tools, account
isolation, FAQ lookup, and handoff. Existing V1 assistant, V2 scenario,
and V2 runner coverage passes. RuboCop passes.
## Summary
Restricts account-wide Dashboard App creation, updates, and deletion to
administrators while keeping read access available to authenticated
account users.
## Why
Dashboard Apps are account-level integrations displayed in conversation
views. Agents should be able to use them, but only administrators should
be able to change their configuration.
## What changed
- authorize Dashboard App actions through `DashboardAppPolicy`
- allow index and show access for authenticated account users
- restrict create, update, and destroy actions to administrators
- add request coverage for administrator and agent mutation behavior
## Validation
`bundle exec rspec
spec/controllers/api/v1/accounts/dashboard_apps_controller_spec.rb`
17 examples, 0 failures.
`bundle exec rubocop
app/controllers/api/v1/accounts/dashboard_apps_controller.rb
app/policies/dashboard_app_policy.rb`
2 files inspected, no offenses detected.
---------
Co-authored-by: Gaurav Singhal <gauravsinghal@Gauravs-Mac-mini.local>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
## Summary
Keeps Agent Bot list and show access available to agents while
restricting account bot access tokens to administrators.
## Why
Agents need Agent Bot metadata for existing product workflows, but the
bot access token can be replayed against bot-authorized APIs and should
not be exposed to them.
## What changed
- serialize `access_token` only for administrators
- verify agents can read Agent Bot metadata without receiving the token
- verify administrators still receive the token from index and show
responses
## Validation
`bundle exec rspec
spec/controllers/api/v1/accounts/agent_bots_controller_spec.rb`
27 examples, 0 failures.
Related follow-up:
[CW-7595](https://linear.app/chatwoot/issue/CW-7595/standardize-one-time-credential-disclosure-across-chatwoot-apis)
---------
Co-authored-by: Gaurav Singhal <gauravsinghal@Gauravs-Mac-mini.local>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
Ensures Captain follows explicit mandatory-transfer rules from active
Response Guidelines and Guardrails instead of allowing the generic
consent-first fallback to override those rules.
## What changed
- Made explicit transfer requirements take precedence over generic
consent-first handoff defaults only when their condition matches.
- Added explicit Response Guideline and Guardrail transfer rules to the
human-handoff protocol.
- Added focused prompt regression coverage.
## How to reproduce
Configure a Response Guideline or Guardrail that requires immediate
transfer for a specific condition, then send a request matching that
condition. Captain should invoke the human-handoff path without asking
the user to consent again. Unmatched requests continue to use the
existing consent-first fallback.
The assistant prompt renderer, agent prompt context, and focused
regression specs pass locally.
Deleting a manually-configured WhatsApp Cloud inbox left its
phone-number-level webhook override still pointing at Chatwoot on Meta's
side. The number kept routing inbound events to us after the inbox was
gone, which blocked the customer's own app — subscribed separately on
the same WABA — from receiving messages, since the phone-level override
takes priority over the app-level subscription. Deleting the inbox now
releases the override, as it already did for embedded-signup inboxes.
## What changed
The setup and teardown paths gated on opposite halves of the same
condition. `Channel::Whatsapp#should_auto_setup_webhooks?` sets the
override for `whatsapp_cloud` inboxes where `source !=
'embedded_signup'` (i.e. manual ones), while
`Whatsapp::WebhookTeardownService#should_teardown_webhook?` only cleared
it when `source == 'embedded_signup'`. The two sets are disjoint, so
manual inboxes were exactly the ones that set an override on create and
never cleared it on destroy. Embedded-signup inboxes were unaffected
because `EmbeddedSignupService` calls `setup_webhooks` explicitly.
Dropping the `source` check from the teardown guard is the whole fix.
Manual `whatsapp_cloud` channels can't persist without `api_key`,
`phone_number_id` and `business_account_id` (`validate_provider_config`
verifies all three against Meta), so the remaining presence guards and
both API calls have everything they need. The WABA-level `DELETE
/subscribed_apps` now also fires for manual inboxes when the last one on
a WABA is removed, which is symmetric with manual setup subscribing the
app in the first place; the token only unsubscribes the app it belongs
to, so a customer's separate app subscription is untouched.
This fixes the leak going forward. Numbers already stranded still need
the override cleared with the customer's own token, since we no longer
hold their `api_key` once the inbox is deleted.
## How to reproduce
1. Create a WhatsApp Cloud inbox using manual API keys (not embedded
signup).
2. Confirm the override is set: `GET
/v22.0/{phone_number_id}?fields=webhook_configuration` shows
`phone_number` pointing at your Chatwoot install.
3. Delete the inbox.
4. Before this change, the override still points at Chatwoot. After it,
`webhook_configuration` no longer carries the phone-level override and
events fall back to the WABA/app-level subscription.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
WhatsApp Cloud API template sync currently fails silently — if the Graph
API call errors (expired token, rate limit, permission issue), the
channel simply keeps its stale templates with no trace in the logs. This
adds a warning log when the template fetch fails, so failed syncs are
visible and debuggable.
## What changed
- `Whatsapp::Providers::WhatsappCloudService#fetch_whatsapp_templates`
now logs a warning with the account id, inbox id, HTTP status code, and
Meta's error message when the response is not successful.
- The inbox id uses safe navigation since sync also runs from the
channel's `after_create` callback, before the inbox record exists.
- The request URL is intentionally not logged, as it contains the access
token as a query param.
## How to reproduce
1. Set up a WhatsApp Cloud inbox with an invalid/expired `api_key`.
2. Trigger a template sync (Inbox settings → sync templates, or wait for
the scheduler).
3. Previously nothing was logged; now a `[WHATSAPP] Template sync failed
for account ... inbox ...` warning appears in the Rails logs.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Agents can no longer send replies in Instagram conversations on Chatwoot
Cloud while the temporary Meta platform restriction is active. The reply
box locks into Private Note mode — the same behavior as an expired
24-hour reply window — so teams can still collaborate internally, with
the existing amber restriction banner above the conversation explaining
why. Self-hosted installations are unaffected.
Follow-up to #14974.
## How to test
1. On a Chatwoot Cloud environment (`isOnChatwootCloud` true), open any
Instagram conversation.
2. The composer should be locked to Private Note mode: the Reply/Private
Note toggle is disabled, and sending creates a private note — even for
conversations within the 24-hour reply window.
3. Switching between conversations should keep the composer in Private
Note mode for Instagram conversations.
4. On a self-hosted environment, Instagram conversations should behave
as before (reply allowed within the messaging window).
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Resolved conversations need a separate suggestion layer so repeated FAQ
signals can be grouped without creating untrusted knowledge entries.
This PR adds the persistence foundation only; it introduces no
user-facing behavior by itself.
## Closes
-
[CW-7495](https://linear.app/chatwoot/issue/CW-7495/backend-llm-changes-to-make-conversation-faqs-as-signalssuggestions)
(stacked PR 1/3; the issue is complete after the full stack lands)
## What changed
- Added `captain_faq_suggestions` with question, answer, embedding,
source count, and review status.
- Added `captain_faq_observations` to retain conversation-level signals.
- Added Captain assistant, account, and conversation associations.
- Added vector and lookup indexes for semantic grouping.
## How to test
This layer has no standalone UI behavior. Apply the migration and
confirm Captain assistants can persist open FAQ suggestions with
attached conversation observations.
# Pull Request Template
## Description
Please include a summary of the change and issue(s) fixed. Also, mention
relevant motivation, context, and any dependencies that this change
requires.
Fixes
https://linear.app/chatwoot/issue/AI-136/check-conversation-status-while-auto-resolving
- After 60mins of inactivity, we run a job that decides if pending
conversations are resolvable or need handoff
- the prompt was a bit conservative and didn't have conversation state
context
## 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.
locally ran a sample eval
## 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>
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}"
```
This adds a `captain_sessions` table to log every Captain run, starting
with Assistant Responses and Copilot Responses. Each session records the
assistant, model, credits consumed, the FAQs/documents/scenario that
contributed to the response, and the full run context — giving customers
visibility into how a response was generated and giving us durable stats
on credit, FAQ, and document usage (which today only exist as ephemeral
trace metadata and an aggregate account counter).
## What changed
- New `Captain::Session` model with a `session_type` enum (`assistant`,
`copilot`). The subject (`Conversation` / `CopilotThread`) and result
(`Message` / `CopilotMessage`) classes are inferred from the session
type, so the table stores plain `subject_id` / `result_id` ids.
`result_id` is nullable so failed runs that still consumed credits can
be logged.
- Composite indexes on `[session_type, subject_id]`, `[session_type,
result_id]`, and `[account_id, session_type, created_at]` for lookup and
usage-stats queries.
- Factory and model specs.
This PR is schema + model only; the writer/instrumentation that records
sessions from the assistant and copilot flows will follow.
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
## Description
`Imap::BaseFetchEmailService#email_already_present?` used
`find_by(source_id:)`, which inherits `Message`'s `default_scope {
order(created_at: :asc) }`, adding an `ORDER BY created_at ASC LIMIT 1`
to what is only a presence check.
On inboxes with a large message history, that `ORDER BY` lets Postgres
satisfy the sort by walking `index_messages_on_created_at` instead of
the selective `index_messages_on_source_id`. For a not-yet-seen
`source_id` (every new email) it can scan the whole table before
returning, taking seconds per message. The dedup loop runs with no IMAP
activity in between, so the idle socket is dropped by the mail server
and the fetch job aborts with `closed stream`. The inbox then stops
ingesting mail entirely, while smaller inboxes on the same server keep
working.
`exists?` issues `SELECT 1 ... LIMIT 1` with no `ORDER BY`, so the
planner uses `index_messages_on_source_id` regardless of table size. No
schema change is required. The fix lives in the shared base class, so it
covers both the IMAP and Microsoft fetch paths.
Fixes#14682
- Add a document details view that surfaces crawled content, source
metadata, and generated FAQ counts.
- Rename the document card action to open details and show the FAQ count
inline in the list.
- Return `responses_count` from the documents API efficiently and expose
document content in the show payload.
- Update related Captain copy to reflect the new details-oriented flow.
**Preview**
<img width="1640" height="1596" alt="CleanShot 2026-06-26 at 09 25
15@2x"
src="https://github.com/user-attachments/assets/0c408fae-7d37-422a-8869-ece466292cb1"
/>
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
## 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>
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>
CI runs were failing because the CircleCI Node orb's pnpm auto-install
step matches the wrong "version" field in pnpm's package.json, producing
an invalid install command since pnpm 11.12.0.
Ref: https://github.com/CircleCI-Public/node-orb/issues/262
### What changed
- Pinned `pnpm-version: 10.2.0` (matching `packageManager` in
`package.json`) on all three `node/install-pnpm` steps in
`.circleci/config.yml`, bypassing the orb's broken version
auto-detection.
## 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
Contact custom attributes filled in the pre-chat form (e.g. a CPF field)
were silently lost when the visitor's email or phone matched an existing
contact. The widget sent the attributes in a separate request that raced
the conversation create: creating the conversation merges the widget
contact into the existing contact, so the attribute update landed on the
destroyed contact and vanished without an error. New visitors were
unaffected, which made the bug hard to spot.
The fix sends contact custom attributes inside the same request that
identifies the contact. The widget conversation create endpoint now
accepts `contact.custom_attributes` and applies them through
`ContactIdentifyAction` in the same transaction as the merge, so the
submitted values always land on the surviving contact. The campaign path
folds the attributes into the existing contact update call the same way.
<details>
<summary>Reproduction script (rails runner, concurrent
threads)</summary>
```ruby
# Concurrent reproduction of the pre-chat form race that loses contact
# custom attributes when the visitor's email matches an existing contact.
#
# The old widget fired two unawaited requests on pre-chat submit. Each
# iteration replays them as real concurrent threads:
# - create thread = POST /widget/conversations: resolves the widget contact,
# then runs ContactIdentifyAction (which merges the widget contact into the
# existing contact) inside a transaction held open while the conversation
# and message are created.
# - patch thread = PATCH /widget/contact: resolves the widget contact via its
# contact inbox and applies the custom attributes through
# ContactIdentifyAction, exactly like Widget::ContactsController#update.
#
# Run with: bundle exec rails runner confirm_prechat_race.rb
# Creates throwaway contacts on Account.first and deletes them afterwards.
ITERATIONS = 20
CPF = '123.456.789-09'.freeze
account = Account.first!
inbox = account.inboxes.first!
losses = 0
ITERATIONS.times do |i|
existing = account.contacts.create!(name: 'Existing Contact', email: "race-existing-#{SecureRandom.hex(6)}@example.com")
temp = account.contacts.create!(name: 'Widget Visitor')
contact_inbox = ContactInbox.create!(contact: temp, inbox: inbox, source_id: SecureRandom.uuid)
begin
create_request = Thread.new do
ActiveRecord::Base.connection_pool.with_connection do
widget_contact = ContactInbox.find(contact_inbox.id).contact # set_contact before_action
ActiveRecord::Base.transaction do
ContactIdentifyAction.new(
contact: widget_contact,
params: { email: existing.email, phone_number: nil, name: 'Widget Visitor' },
retain_original_contact_name: true,
discard_invalid_attrs: true
).perform
sleep(0.02) # conversation + message creation keeps the transaction open
end
end
end
patch_request = Thread.new do
ActiveRecord::Base.connection_pool.with_connection do
sleep(rand * 0.02) # network jitter between the two requests
widget_contact = ContactInbox.find(contact_inbox.id).contact # set_contact before_action
ContactIdentifyAction.new(
contact: widget_contact,
params: { custom_attributes: { cpf: CPF } },
discard_invalid_attrs: true
).perform
end
end
create_request.join
patch_request.join
survivor = existing.reload
if survivor.custom_attributes['cpf'] == CPF
puts "iteration #{i + 1}: CPF survived"
else
losses += 1
puts "iteration #{i + 1}: CPF LOST (survivor custom_attributes: #{survivor.custom_attributes.inspect})"
end
ensure
account.contacts.where(id: [existing.id, temp.id]).find_each(&:destroy!)
end
end
puts
puts "#{losses}/#{ITERATIONS} iterations lost the CPF -- race #{losses.positive? ? 'confirmed' : 'not reproduced in this run'}"
```
Result: **20/20 iterations lose the CPF** (consistent across repeated
runs). The conversation create holds its transaction open across the
contact merge, so the fast attribute update either resolves the
soon-to-be-destroyed widget contact or blocks on its row lock and then
updates 0 rows — silently, with no error. This is why the customer sees
the loss every time, not intermittently.
Note: the script replays the old two-request flow at the service layer,
so it reproduces the loss even with this fix applied — the fix works by
removing the second request from the widget, not by changing the raced
code paths. The new request spec (`saves contact custom attributes on
the surviving contact when merged into an existing contact`) covers the
fixed contract.
</details>
## Closes
- Reported via support conversation:
https://app.chatwoot.com/app/accounts/1/conversations/84465
## How to reproduce
1. Create a website inbox with a pre-chat form that has a contact custom
attribute field (e.g. CPF).
2. Create a contact with a known email address.
3. As a visitor, open the widget and fill the pre-chat form using that
same email plus a value for the custom attribute.
4. Before: the attribute never appears on the contact profile. After: it
is saved on the existing contact, overwriting any stale value.
## What changed
- `POST /api/v1/widget/conversations` now permits
`contact.custom_attributes` and passes it to `ContactIdentifyAction`,
which deep-merges it atomically with the contact merge.
- The widget pre-chat form sends contact custom attributes inside the
conversation create payload instead of a separate `setCustomAttributes`
call; the campaign path includes them in the `contacts/update` payload.
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>
# Pull Request Template
## Description
Increases description for Captain.
Why?
We are planning to include business context in description and 255 char
limit on the column and 200 char limit on the UI are very limiting to
get proper context.
## Type of change
Improvement to accommodate business context
## 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
## 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
Instagram inbox creation and WhatsApp embedded signup on Chatwoot Cloud
now reflect the temporary Meta restriction. Instagram is hidden from
onboarding on Cloud, while the regular Instagram inbox creation page
shows a disabled action with a status-linked amber warning. WhatsApp
embedded signup on Cloud stays visible with its connect action disabled.
WhatsApp Call setup always uses the manual WhatsApp form.
Existing Instagram conversations and Instagram inbox settings on Cloud
also show amber warning banners with the public incident link.
Self-hosted installations keep their existing Instagram, WhatsApp, and
WhatsApp Call setup behavior because the temporary restriction is based
only on the Chatwoot Cloud environment check.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
# Pull Request Template
## Description
This PR makes reply editor variables insert their resolved value (for
example, the contact's name) instead of the raw `{{contact.name}}`
placeholder, matching canned response behavior. This works both when
picking a variable from the `{{` menu and when an agent manually types
out `{{contact.name}}` — it resolves the moment the closing `}}` is
typed.
If a variable has no value, the `{{placeholder}}` is kept so the backend
can still resolve it when the message is sent. Private notes are left
untouched.
For safety, a resolved value that itself contains Liquid syntax `({{ }}`
or `{% %})` also keeps its placeholder, so customer-controlled fields
can never inject Liquid into the outgoing message.
Fixes
https://linear.app/chatwoot/issue/CW-7528/reply-editor-inserts-variable-placeholder-instead-of-the-value
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
1. Open a conversation and add a reply.
2. Type `{{` and pick a variable that has a value (e.g. Contact name) →
it inserts the actual value.
3. Manually type `{{contact.name}}` and close the braces → it
auto-resolves to the value.
4. Insert/type a variable with no value → the `{{placeholder}}` stays;
confirm it resolves correctly on send.
5. Repeat in a private note → placeholders are left as-is.
## 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
Reduces database pressure from filtered unread-count cache rebuilds
during high-traffic account rollouts by serving stale snapshots longer
and limiting inline saved-filter rebuild fanout.
## Closes
None
## What changed
- Increase filtered unread-count refresh throttling from 30 seconds to 5
minutes.
- Increase the stale snapshot window from 30 minutes to 1 hour.
- Reduce inline saved-filter count rebuilds per request from 10 to 3.
- Update unread-count specs to assert refresh and stale behavior through
the shared constants.
## How to test
- Enable `conversation_unread_counts` and `unread_count_for_filters` for
an account with conversation custom filters.
- Open the dashboard and verify unread-count badges still return values.
- Mutate conversations and verify stale filtered counts are served while
rebuilds are throttled, instead of repeatedly rebuilding every 30
seconds.
Re-enables the "WhatsApp Calls" inbox creation option, which disappeared
when embedded signup was disabled on production. The channel card now
only requires the `channel_voice` account feature, and the creation flow
offers the manual WhatsApp Cloud API setup form. Once the channel is
created with manual credentials, calling is enabled automatically — the
same post-setup step the embedded signup flow used to perform.
When an installation has embedded signup configured, the flow still uses
it; the manual form is the fallback (and the effective path on Chatwoot
Cloud today).
## How to test
1. Enable the `channel_voice` feature on the account.
2. Go to Add Inbox → the "WhatsApp Calls" card is visible again → select
it.
3. Fill in the manual Cloud API credentials (inbox name, phone number,
phone number ID, business account ID, API key) and submit.
4. The inbox is created and calling is enabled:
`provider_config.calling_enabled` is true and the Calls tab toggle is
on. If the number isn't enrolled in the Business Calling API, an alert
explains the enable failure but the messaging inbox is still created.
## What changed
- `ChannelItem.vue`: the `whatsapp_call` card is gated only on
`channel_voice` (previously also required the embedded signup app ID).
- `CloudWhatsapp.vue`: new `enableCallingOnComplete` prop that calls the
enable-calling API after channel creation.
- `WhatsappCall.vue`: renders embedded signup when available, otherwise
the manual setup form — both with calling enabled on completion.
Updates the suspended account page with the revised policy copy and adds
a visible Contact support action that opens the embedded Chatwoot
support widget.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Tightens the resolved-conversation FAQ generator so it only proposes
durable, reusable FAQ candidates supported by human support-agent
messages. The implementation now sends a conversation-FAQ-specific
transcript to the LLM: customer messages plus real human support-agent
messages only, excluding bot, private, activity, and template messages.
## Closes
-
https://linear.app/chatwoot/issue/CW-7494/tighten-conversation-faq-generation-prompt
## What changed
- Added a human-only transcript builder in `ConversationFaqService`
instead of using the generic `conversation.to_llm_text` output.
- Excluded bot/agent-bot messages before the LLM call, which removes the
main bot-line leakage class deterministically.
- Preserved native-channel human replies where outgoing messages are
stored as `external_echo` without a `User` sender.
- Kept a prompt decision gate requiring each FAQ to be backed by a
complete public human-agent answer.
- Added generic no-FAQ classes for spam, wrong-service conversations,
private account/payment/order/certificate/troubleshooting cases, support
workflow mechanics, and direct-link/file/quote outputs.
- Added a separate `conversation_faq_generation` model route defaulting
to `gpt-5.2`, while keeping `document_faq_generation` on its existing
`gpt-4.1-mini` default. Conversation FAQ generation passes that feature
default ahead of the legacy global `CAPTAIN_OPEN_AI_MODEL` setting
unless an account-level override is configured.
- Kept the prompt domain-neutral so it can still generate reusable
product, service, policy, setup, and process FAQs outside SaaS contexts.
## Sampling notes
- Production Langfuse traces showed `llm.captain.conversation_faq` calls
using `gpt-4.1` in the sampled account set.
- Locally, `Llm::FeatureRouter.resolve(feature:
'conversation_faq_generation')` now resolves to `gpt-5.2`.
- Reviewed recent production `llm.captain.conversation_faq` traces
across 13+ accounts in compact form.
- Replayed 20 full traces across 10 accounts/domains, including
education, hosting, retail/auto, APIs, logistics, tax/fiscal workflows,
and Chatwoot account 1.
- Explicit `gpt-5.2` replay with human-only conversation history
returned no FAQ for 15/20 traces.
- A comparison replay with `gpt-4.1-mini` returned no FAQ for only 7/20
traces, bringing back several private/order/payment/support-workflow
cases.
- Remaining non-empty `gpt-5.2` outputs are now mostly
borderline/possibly useful human-agent-derived FAQs rather than obvious
bot-sourced answers.
## How to test
- Resolve conversations where the answer came only from the bot; no
pending FAQ should be generated.
- Resolve spam, unrelated, wrong-service, or private
payment/order/account conversations; no pending FAQ should be generated.
- Resolve conversations that require account/order/payment/login/private
verification or a human handoff; no pending FAQ should be generated.
- Resolve a conversation where a human agent gives a stable, reusable
help-center answer; the generated pending FAQ should be general and
self-contained.
Updates the suspended account screen copy to use clearer policy and
safety-oriented language, while giving users a direct support path if
they believe the suspension is a mistake.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
# Pull Request Template
## Description
This keeps the public inbox contact update response on the public
contact inbox serializer shape after applying the contact identify
update.
## 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 to not work as expected)
- [ ] This change requires a documentation update
## How Has This Been Tested?
- `bundle exec rspec
spec/controllers/public/api/v1/inbox/contacts_controller_spec.rb`
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have commented 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
Fixes
[https://linear.app/chatwoot/issue/CW-6937](https://linear.app/chatwoot/issue/CW-6937)
Fixes
[https://linear.app/chatwoot/issue/CW-7464](https://linear.app/chatwoot/issue/CW-7464)
Fixes
[https://linear.app/chatwoot/issue/CW-7457](https://linear.app/chatwoot/issue/CW-7457)
## Description
The Microsoft authorize URL had no `prompt` parameter. With Microsoft's
default behavior, a browser carrying an active Microsoft session is
silently signed in to that account. If the same account is already
attached to an inbox in the same Chatwoot account, the callback treats
the OAuth response as a re-auth and routes the user to the existing
inbox settings page instead of letting them create the new inbox they
intended.
Adding `prompt=select_account` interrupts SSO and always presents the
Microsoft account picker, so the user explicitly chooses the mailbox
they want to connect.
This is distinct from `prompt=consent`, which was removed in
[#13962](https://github.com/chatwoot/chatwoot/pull/13962) to fix the
admin consent loop. `select_account` only interrupts SSO and does not
retrigger the consent dialog.
Closes INF-76
## 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?
`bundle exec rspec
spec/controllers/api/v1/accounts/microsoft/authorization_controller_spec.rb`
(3 examples, 0 failures). The regression test introduced in
[#13962](https://github.com/chatwoot/chatwoot/pull/13962) is updated to
assert `prompt=select_account` instead of asserting absence of the
parameter.
## 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
# Pull Request Template
## Description
Updates `websocket-driver` from `0.7.7` to `0.8.2` to resolve the
bundle-audit findings for CVE-2026-54463, CVE-2026-54464,
CVE-2026-54465, and GHSA-2x63-gw47-w4mm.
This is a lockfile-only transitive dependency update through Rails
Action Cable. No application code changes are included.
Fixes # (issue)
N/A
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `bundle exec bundle audit update && bundle exec bundle audit check -v`
- `bundle check && bundle exec ruby -e 'require "action_cable"; require
"action_cable/connection/client_socket"; require "websocket/driver";
puts "actioncable=#{ActionCable::VERSION::STRING}"; puts
"websocket-driver=#{Gem.loaded_specs["websocket-driver"].version}"; puts
"driver_rack=#{WebSocket::Driver.respond_to?(:rack)}"'`
- `POSTGRES_DATABASE=chatwoot_test_3d6a RAILS_ENV=test bundle exec rails
db:prepare && POSTGRES_DATABASE=chatwoot_test_3d6a bundle exec rspec
spec/listeners/action_cable_listener_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
- [ ] I have commented on my code, particularly in hard-to-understand
areas (not applicable; lockfile-only change)
- [ ] I have made corresponding changes to the documentation (not
applicable; dependency security update)
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works (not applicable; dependency security update)
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules (not applicable)
## 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
# 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
## Description
Adds a backend endpoint that powers an account-wide calls dashboard,
letting users list and filter all calls in the account.
## Linear Ticket
- https://linear.app/chatwoot/issue/UPM-28/voice-call-dashboard-view
## Type of change
- [ ] New feature (non-breaking change which adds functionality)
## 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
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`
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>
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.
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>
## Description
The widget contact update endpoint (`PATCH /api/v1/widget/contact`)
applied updates that set an `identifier` without validating the
`identifier_hash`, unlike `set_user`, which already does. This change
runs the same validation on the update path whenever an `identifier` is
supplied, keeping identity validation consistent across the widget
contact endpoints.
Anonymous updates that don't pass an identifier (prechat
name/email/phone and custom attributes) keep working unchanged,
including on inboxes with mandatory identity validation.
Fixes https://linear.app/chatwoot/issue/CW-7118
---------
Co-authored-by: Shivam Mishra <scm.mymail@gmail.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
# 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
# Pull Request Template
## Description
Message creation API failures caused by PostgreSQL query cancellations
now return a generic retryable error instead of exposing raw database
internals such as `PG::QueryCanceled`, tuple identifiers, or relation
names to customers. Existing validation failures continue to return
their specific validation messages.
Closes
[CW-7538](https://linear.app/chatwoot/issue/CW-7538/do-not-expose-pgquerycanceled-details-in-messages-api-errors)
## 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?
Reproduced the messages API path by raising
`ActiveRecord::QueryCanceled` from `Messages::MessageBuilder` and
verified the response contains the customer-safe localized error without
`PG::QueryCanceled` details.
Validation run locally:
- `bundle exec rspec
spec/controllers/api/v1/accounts/conversations/messages_controller_spec.rb`
- `bundle exec rubocop
app/controllers/concerns/request_exception_handler.rb
spec/controllers/api/v1/accounts/conversations/messages_controller_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
- [ ] 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
This temporarily turns off inbox creation for channels that rely on
Meta's embedded signup — the WhatsApp Cloud signup popup, Instagram
(OAuth-only), and WhatsApp Call. WhatsApp Cloud inbox creation now falls
back to the manual API-key form, while the Instagram and WhatsApp Call
tiles appear disabled. Both channels are also hidden from the
new-account onboarding flow. Existing inboxes are not affected.
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
## Linear ticket
- https://linear.app/chatwoot/issue/CW-7253/billing-brl-pix-new-users
## Description
New accounts that sign up in Brazilian Portuguese are now billed in BRL
instead of USD. Their Stripe customer is created with a Brazil address
and Portuguese locale (so the Stripe portal offers Real prices and PIX),
and the AI credit top-up flow shows packages priced in the account's
billing currency. Currency support is config-driven, so adding another
currency later is a configuration change rather than a code change.
## Type of change
- [ ] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- https://www.loom.com/share/c8d3d08c1b844ed6b820438d4209491a
## Screenshot
<img width="904" height="440" alt="image"
src="https://github.com/user-attachments/assets/6f19fad8-e6af-46ea-b99f-b0265bb9eeec"
/>
## 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
generate_article_search_terms still pulled ENV['OPENAI_API_KEY'], left
over from before the Jan 2025 Captain migration moved the key into
InstallationConfig as CAPTAIN_OPEN_AI_API_KEY. Every other Captain LLM
call site got updated then; this one (used by Portal::ArticleIndexingJob
for help center article embedding search terms) didn't, so it sent a
blank bearer token unless you also happened to have the old env var set.
Also drops the stale OPENAI_API_KEY line from .env.example and points to
where the key actually lives now (Super Admin > App Configs > Captain).
---------
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Help-center onboarding jobs were getting stuck in the `generating` state
indefinitely. `Onboarding::HelpCenterArticleWriterJob` only finalized
the generation counter for two exception types
(`Firecrawl::FirecrawlError`, `ArticleBuildFailed`). Any other error
exhausted Sidekiq's default retries and landed in the dead set without
ever bumping `finished`, leaving state at `total - 1` / `generating`
until the 7-day Redis TTL expired. Observed in production: 4 generations
wedged at exactly `finished = total - 1`, four days after the run, with
no further progress — the onboarding UI showed "generating" the whole
time.
This PR adds a `discard_on StandardError` catch-all to
`HelpCenterArticleWriterJob`, after the existing `retry_on
Firecrawl::FirecrawlError` and `discard_on ArticleBuildFailed` handlers.
ActiveJob matches in declaration order, first match wins, so existing
behavior is unchanged — the catch-all only absorbs errors that
previously fell through to unhandled retry-then-dead-set. It routes
through the same `on_writer_failure` → `finalize` path, so state always
progresses to `completed`.
<details><summary>
##### Script to remove dead jobs
</summary>
<p>
```rb
# One-off: unstick Onboarding::HelpCenterGenerationState keys that are wedged in
# "generating" because a writer job died on an unhandled exception (neither
# FirecrawlError nor ArticleBuildFailed) and exhausted Sidekiq retries without
# ever calling record_article_finished.
#
# These portals have real articles (finished is 1 short of total). Marking them
# "completed" is the honest terminal state: generation is done, one article failed.
#
# Run on a prod box (dry-run first, then REMOVE_DRY_RUN=1):
# RAILS_ENV=production bundle exec rails runner scripts/help_center_investigation/unstick_generating.rb
#
# To actually write, set REMOVE_DRY_RUN=1 in the environment.
pattern = format(Redis::Alfred::HELP_CENTER_GENERATION, id: '*')
dry_run = ENV['REMOVE_DRY_RUN'].blank?
stuck = []
Redis::Alfred.with do |conn|
conn.scan_each(match: pattern, count: 1000) do |key|
h = conn.hgetall(key)
next unless h['status'] == 'generating'
gen_id = key.sub('HELP_CENTER_GENERATION::', '')
stuck << { gen_id: gen_id, total: h['total'], finished: h['finished'], key: key }
unless dry_run
conn.hset(key, 'status', 'completed')
conn.expire(key, Onboarding::HelpCenterGenerationState::TTL)
end
end
end
puts "#{dry_run ? '[DRY RUN] ' : ''}Found #{stuck.size} stuck 'generating' states:"
stuck.each do |s|
puts " gen=#{s[:gen_id]} total=#{s[:total]} finished=#{s[:finished]} -> #{dry_run ? 'would mark completed' : 'marked completed'}"
end
puts
puts 'Re-run with REMOVE_DRY_RUN=1 to apply.' if dry_run
````
</p>
</details>
## Description
Adds drilldown support for report bar charts powered by
`ReportContainer`. Clicking a non-zero report bar now opens a right-side
drawer with the conversations or messages that contributed to that
bucket, with each row linking to the underlying conversation and message
rows linking with `messageId`.
This includes a new `GET /api/v2/accounts/:account_id/reports/drilldown`
endpoint, backend drilldown builders/serializers, generic chart click
emission, local drawer state via `useReportDrilldown`, compact drilldown
cards, pagination, stale-response protection, and validation for
unsupported drilldown dimensions.
Fixes # CW-4497
https://linear.app/chatwoot/issue/CW-4497/drill-down-on-agent-conversations-report
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality not to work as expected)
- [ ] This change requires a documentation update
## How Has This Been Tested?
Ran the focused backend and frontend checks for the drilldown endpoint,
builder, chart click handling, drawer/card UI, API helper, and
stale-response handling.
Here are the screenshots on how it looks like:
<img width="1792" height="1199" alt="Screenshot 2026-06-02 at 11 32
11 PM"
src="https://github.com/user-attachments/assets/6bdb8832-b9df-4bf3-9a2a-beaefe203b6e"
/>
<img width="1791" height="1230" alt="Screenshot 2026-06-02 at 11 32
34 PM"
src="https://github.com/user-attachments/assets/36e92eb7-3208-4855-87f4-0c7f316df54d"
/>
<img width="1784" height="1235" alt="Screenshot 2026-06-02 at 11 32
46 PM"
src="https://github.com/user-attachments/assets/f7a53916-74f2-4622-9305-042e0ac9e877"
/>
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [x] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
---------
Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com>
Co-authored-by: Shivam Mishra <scm.mymail@gmail.com>
Outbound voice calls were being auto-assigned to the wrong agent. When
an agent placed an outbound call, the conversation was created without
an assignee, so inboxes with auto-assignment enabled would round-robin
it to a different agent instead of keeping it with the person who
actually made the call. This made it hard to tell which agent was on an
active call.
## What changed
- Set the calling agent as the conversation's assignee when creating an
outbound voice call conversation.
- This prevents the generic auto-assignment handler from treating the
conversation as unassigned and reassigning it.
- Added specs covering the assignment, including a regression case with
inbox auto-assignment enabled.
**Note:** this applies to newly placed calls; it does not retroactively
fix conversations that were already mis-assigned.
---------
Co-authored-by: Tanmay Deep Sharma <tanmaydeepsharma21@gmail.com>
Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
# 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>
## 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
- Fixes SLA breach computation to respect the "Only during business
hours" setting
- Backend now pre-computes SLA deadlines, simplifying frontend logic
## How it works
Before: SLA deadlines were calculated using wall-clock time, ignoring
business hours.
After: When an SLA policy has "Only during business hours" enabled and
the inbox has working hours configured, the deadline is calculated by
adding threshold time only during business hours.
**How you check if a conversation has a SLA hit or miss?**
<img width="474" height="510" alt="Screenshot 2026-01-28 at 7 06 53 PM"
src="https://github.com/user-attachments/assets/54ec8581-18b8-45c6-a356-de8c778ea78d"
/>
**Example:**
- Conversation created: Friday 4:30 PM
- FRT threshold: 1 hour
- Business hours: Mon-Fri 9 AM - 5 PM
| | Breach time |
|--|--|
| Before | Friday 5:30 PM |
| After | Monday 9:30 AM |
## Test plan
- [x] Create an SLA policy with "Only during business hours" enabled
- [x] Configure inbox with business hours (e.g., Mon-Fri 9-5)
- [x] Conversation created during business hours
- Create a conversation on Wednesday 10:00 AM UTC
- Expected: FRT deadline shows Wednesday 12:00 PM UTC (2 business hours
later)
- [x] Conversation created before business hours
- Create a conversation on Wednesday 7:00 AM UTC
- Expected: FRT deadline shows Wednesday 11:00 AM UTC (counting starts
at 9 AM)
- [x] Conversation created after business hours
- Create a conversation on Wednesday 6:00 PM UTC
- Expected: FRT deadline shows Thursday 11:00 AM UTC (counting starts
next day 9 AM)
- [x] Conversation created on weekend
- Create a conversation on Saturday 10:00 AM UTC
- Expected: FRT deadline shows Monday 11:00 AM UTC (skips weekend)
- [x] Threshold spans weekend
- Create a conversation on Friday 4:00 PM UTC with 2-hour FRT
- Expected: FRT deadline shows Monday 10:00 AM UTC (1h Friday + 1h
Monday)
- [x] SLA without business hours
- Create an SLA policy with only_during_business_hours: false
- Create a conversation on Friday 4:00 PM UTC with 2-hour FRT
- Expected: FRT deadline shows Friday 6:00 PM UTC (wall-clock time)
- [x] All Day marked as closed_all_day
- Create a conversation on Tuesday 4:00 PM UTC with 2-hour FRT
- Expected: FRT deadline shows Thursday 10:00 AM UTC
- [x] All Day marked as open_all_day
- Create a conversation on Saturday 10:00 AM UTC with 2-hour FRT
- Expected: FRT deadline shows Saturday 12:00 PM UTC
- [x] UI displays correct countdown
- Verify conversation card shows correct SLA timer
- Verify timer shows flame icon when breached
- Verify timer shows alarm icon when within threshold
- Time updates automatically when time passes
- [x] Verify the breach with a different timezone than your local
timezone
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
Co-authored-by: Sony Mathew <sony@chatwoot.com>
Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com>
# Pull Request Template
## Description
- Default temperature to 0.5 and remove UI control
- No migrations needed for existing accounts, their current settings are
preserved
## 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 spec
## 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
# Pull Request Template
## Description
This updates the locked `msgpack` gem from `1.8.0` to `1.8.3` so the
bundle-audit check no longer flags CVE-2026-54522. The upgrade stays
within the existing transitive dependency constraints used by `bootsnap`
and `datadog`.
Fixes:
https://app.circleci.com/pipelines/github/chatwoot/chatwoot/114757/workflows/f8c7b37f-27d5-45d4-9f1b-1d1782ebc4e3/jobs/162250
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `eval "$(rbenv init -)" && bundle exec bundle audit update && bundle
exec bundle audit check -v`
- `eval "$(rbenv init -)" && bundle exec rspec
spec/listeners/action_cable_listener_spec.rb`
- `eval "$(rbenv init -)" && RUBOCOP_CACHE_ROOT=tmp/rubocop_cache bundle
exec rubocop --no-server Gemfile`
## 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
**Broaden the Firecrawl `map` search term list so help-center onboarding
doesn't skip sites with non-standard docs paths**
Help-center onboarding was skipping ~70% of new accounts, and ~60% of
those skips came from a single failure: `"map returned no links"`. The
root cause was an overly narrow hardcoded search query passed to
Firecrawl's `map` endpoint.
The curator (`Onboarding::HelpCenterCurator`) calls `Firecrawl.map(url,
search: MAP_SEARCH)` to discover candidate pages before the LLM curation
step. `MAP_SEARCH` was hardcoded to `"docs help support faq"` — a 4-term
list that only matched sites whose help content sat at `/docs`, `/help`,
`/support`, or `/faq`. Sites using `/resources`, `/guides`, `/kb`,
`/articles`, `/handbook`, `/learn`, `/how-to`, `/tutorial`,
`/troubleshooting`, or a docs subdomain found nothing, so the job raised
`CurationSkipped` and left the portal empty.
Firecrawl's `search` param is a grep-style substring filter across URL,
title, and description (not a semantic query), so the fix is to broaden
the term list rather than drop it. The LLM curator downstream
(`Captain::Llm::HelpCenterCurationService`) already filters returned
links by quality — it has the full URL-path-priority prompt and a
25-article hard ceiling — so a wider crawl net is safe and doesn't
change the final article quality bar.
**What changed**
- `enterprise/app/services/onboarding/help_center_curator.rb`:
`MAP_SEARCH` broadened from `"docs help support faq"` to a 13-term list
covering common help-content path hints. Comment added documenting why
the term list exists and that the LLM curator does the real filtering.
# Pull Request Template
## Description
Tightens v2 prompt and config to match v1
## 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.
locally
## 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
# Pull Request Template
## Description
This PR stops new contacts from getting an auto-assigned company name
when the Companies feature is disabled.
Since #14496, email-domain company auto-association also updates a
contact's `company_name`. However, the callback isn't gated behind the
Companies feature flag, so accounts without the feature enabled still
auto-create companies and overwrite any `company_name` provided via the
SDK/`setUser`.
This PR gates `should_associate_company?` behind
`account.feature_enabled?('companies')`, so auto-association only runs
when the Companies feature is enabled.
Fixes
https://linear.app/chatwoot/issue/CW-7462/setuser-overwrites-contact-company-name-for-accounts-that-dont-use
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## 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
LeadSquared sync now recovers automatically when a contact's cached lead
has been deleted or merged on the LeadSquared side. Previously the stale
lead id was never cleared, so every new conversation or contact update
for that contact failed with "Lead not found"
(`MXInvalidEntityReferenceException`) indefinitely.
## What changed
- Activity sync: on a "Lead not found" error while posting a
conversation/transcript activity, clear the cached `leadsquared_id`,
re-resolve the contact to a fresh lead, and retry the activity once
(guarded against loops and duplicate leads).
- Contact sync: on the same error while updating an existing lead, clear
the cached id and create a fresh lead instead.
- Fix `get_lead_id` to actually return early for unidentifiable contacts
(the guard previously fell through).
## How to reproduce
1. For a LeadSquared-enabled account, point a contact's cached lead id
at a lead that no longer exists in LeadSquared.
2. Update the contact, or create/resolve a conversation for it.
3. Before: the sync fails repeatedly with "Lead not found" and never
self-corrects. After: the stale id is cleared, a fresh lead is
resolved/created, and subsequent syncs reuse the healed id.
---------
Co-authored-by: Tanmay Deep Sharma <32020192+tds-1@users.noreply.github.com>
# Pull Request Template
~~Note: merge only after https://github.com/chatwoot/ai-agents/pull/74
has been merged~~
## Description
Before:
<img width="436" height="617" alt="image"
src="https://github.com/user-attachments/assets/fd5be8dc-abab-4e01-b251-366648b998ea"
/>
After:
<img width="446" height="577" alt="image"
src="https://github.com/user-attachments/assets/8d96d2f2-c126-4cca-b3a2-f2a62b204adf"
/>
<img width="441" height="558" alt="image"
src="https://github.com/user-attachments/assets/89da4157-48a5-4fdc-9c67-9bf987e31638"
/>
## 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
---------
Co-authored-by: Sony Mathew <sony@chatwoot.com>
## Description
Updates the transitive `crass` dependency from `1.0.6` to `1.0.7` so the
bundle-audit security check no longer flags the Crass denial-of-service
advisories published on June 25, 2026. `crass` is pulled in through
`rails-html-sanitizer -> loofah`, and this change only updates the
resolved lockfile version.
Fixes # N/A
## 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?
- `bundle exec bundle audit update && bundle exec bundle audit check -v`
- `bundle exec rspec spec/mailboxes/mailbox_helper_spec.rb
spec/mailboxes/reply_mailbox_spec.rb
spec/mailboxes/imap/imap_mailbox_spec.rb
spec/models/channel/telegram_spec.rb
spec/lib/integrations/slack/send_on_slack_service_spec.rb
spec/lib/integrations/slack/update_slack_message_service_spec.rb
spec/presenters/html_parser_spec.rb`
- `bundle exec rubocop Gemfile`
## 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
## Summary
- track cloud plan activation conversions when an attributed account
moves from the configured default cloud plan to a paid plan
- use the Stripe webhook event time as the activation timestamp so the
30-day signup attribution window reflects the actual upgrade event
- send the Stripe subscription amount and currency for the conversion
value
- mark the account attribution after enqueueing so later plan updates do
not send duplicate activation conversions
## Notes
- Marketing tracker: https://linear.app/chatwoot/issue/MAR-113
- Cloud implementation: https://linear.app/chatwoot/issue/LEA-34
- Stripe billing stays responsible for subscription state and value
calculation.
- Cloud plan activation conversion tracking is handled by a small
dedicated service that owns the activation rule, duplicate marker, and
conversion enqueue.
- Website attribution cookie capture remains separate in the marketing
attribution service.
- There is no frontend change and no new user-facing configuration.
- Conversion upload still no-ops outside Chatwoot Cloud and when
attribution has no supported click identifier.
# Pull Request Template
## Description
Adjusts the Captain LLM feature defaults after feature routing so the
defaults stay intentional and avoid unintended high-cost model upgrades.
Assistant, copilot, and onboarding content generation now default to
`gpt-4.1`; audio transcription keeps `gpt-4o-mini-transcribe` as the
default while exposing `whisper-1` as an available account override
option.
Related: https://linear.app/chatwoot/issue/CW-7425/test-new-models
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- `ruby -ryaml -e 'yaml = YAML.load_file("config/llm.yml"); features =
yaml.fetch("features"); models = yaml.fetch("models"); features.each {
|name, cfg| missing = Array(cfg["models"]) - models.keys; raise
"#{name}: missing #{missing.join(",")}" if missing.any?; raise "#{name}:
default not in models" unless
Array(cfg["models"]).include?(cfg["default"]) }'`
- `node -e
"JSON.parse(require('fs').readFileSync('app/javascript/dashboard/i18n/locale/en/settings.json',
'utf8'))"`
- `pnpm exec prettier --check
app/javascript/dashboard/i18n/locale/en/settings.json`
- `bundle exec rspec spec/lib/llm/feature_router_spec.rb
spec/enterprise/services/llm/base_ai_service_spec.rb
spec/enterprise/models/concerns/agentable_spec.rb
spec/enterprise/services/messages/audio_transcription_service_spec.rb
spec/models/concerns/captain_featurable_spec.rb
spec/models/account_spec.rb
spec/controllers/api/v1/accounts/captain/preferences_controller_spec.rb
spec/controllers/super_admin/accounts_controller_spec.rb`
- `bundle exec rspec
spec/enterprise/services/captain/llm/article_translation_service_spec.rb
spec/enterprise/services/messages/audio_transcription_service_spec.rb
spec/enterprise/services/llm/base_ai_service_spec.rb`
- `RUBOCOP_CACHE_ROOT=/private/tmp/rubocop_cache bundle exec rubocop
enterprise/app/services/captain/llm/article_translation_service.rb
enterprise/app/services/messages/audio_transcription_service.rb
spec/enterprise/services/captain/llm/article_translation_service_spec.rb
spec/enterprise/services/llm/base_ai_service_spec.rb
spec/enterprise/services/messages/audio_transcription_service_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
- [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
## 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
## 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
# 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
# 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
## 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
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>
## Description
Move WhatsApp webhook callback override from WABA level to phone number
level, allowing multiple phone numbers on the same WABA to have
independent callback URLs.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Connect a WhatsApp Cloud inbox via embedded signup
- Verify webhook setup succeeds and messages are received
- Connect a second phone number on the same WABA — both should receive
messages independently
- Delete an inbox and verify only that phone number's override is
cleared
## 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] 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
---------
Co-authored-by: tds-1 <tds-1@users.noreply.github.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- enqueue `cloud_signup` conversion tracking after website attribution
is stored on a new cloud account
- keep authenticated add-workspace requests out of
attribution/conversion tracking
- reuse the existing marketing conversion tracking service and config
already available on `develop`
## Notes
- This PR only wires the signup path.
- Billing/plan activation conversion tracking is intentionally left out
for a separate rollout.
- The conversion service still no-ops outside Chatwoot Cloud and when
stored attribution has no supported click identifier.
## Summary
Adds the minimal foundation for Cloud marketing conversion tracking:
- locked internal installation config for conversion tracking
credentials and event mappings
- generic background job and service for uploading conversion events
from stored attribution
- focused coverage for Cloud gating, click-id selection, payload shape,
and optional conversion value
This PR intentionally does not wire signup or plan activation yet. The
next step is to validate the service from Rails console against existing
attributed accounts, then add the event hooks in a follow-up PR.
## Notes
The config remains locked and is surfaced under the Internal settings
group next to the existing Cloud plan configuration. The service assumes
the locked config is present and valid; config mistakes should surface
instead of being silently ignored.
Help centers using the documentation layout now render correctly in two
cases that previously fell back to the wrong output. Opening a portal at
its custom-domain root (e.g. docs.example.com/ ) now shows the full
documentation home
in place instead of the classic layout, and portals whose locale is a
region variant that Chatwoot doesn't ship a
translation for (e.g. th_TH , fr_ML ) now show their categories in the
sidebar on article pages.
Closes
https://linear.app/chatwoot/issue/CW-7437/portal-layout-is-not-properly-working-in-custom-domain
## How to test
1. Create a portal with the documentation layout and a custom domain
(e.g. example.chat.test ), with at least one
category containing a published article.
2. Visit the custom-domain root ( http://example.chat.test:3000/ ) → it
should show the full documentation home
(sidebar, topbar), not the classic layout, with no redirect.
3. Set the portal's locale to a region variant Chatwoot doesn't
translate, e.g. th_TH , with categories/articles
under that locale.
4. Open an article → the sidebar should list the article's category and
sibling articles. Before the fix the sidebar
was empty for these locales.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
Phase 2 of [INF-75](https://linear.app/chatwoot/issue/INF-75). Follows
up on [#14753](https://github.com/chatwoot/chatwoot/pull/14753) (Phase 1
UA pattern fallback, already merged).
When the request carries an \`X-Chatwoot-Client-Name\` header,
\`UserSessionTrackingService\` now prefers the five structured
\`X-Chatwoot-*\` headers over the User-Agent for populating the
\`user_sessions\` row:
| Header | Mapped column |
|---|---|
| \`X-Chatwoot-Client-Name\` | \`browser_name\` |
| \`X-Chatwoot-Client-Version\` | \`browser_version\` |
| \`X-Chatwoot-Device-Model\` | \`platform_name\` |
| \`X-Chatwoot-Platform-Version\` | \`platform_version\` |
| \`X-Chatwoot-Platform\` (+ model) | \`device_name\` (\`iPhone\` /
\`iPad\` / \`Android\`) |
When the header is absent or blank, the existing \`Browser.new\` path
runs, with the Phase 1 legacy UA fallback still acting as the floor.
Real browsers are untouched.
A follow-up PR in
[chatwoot-mobile-app](https://github.com/chatwoot/chatwoot-mobile-app)
will start sending these headers from the React Native build. Until that
ships, this PR is a no-op for production traffic, so it can land
independently.
Fixes INF-75.
# 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
# Pull Request Template
## Description
https://linear.app/chatwoot/issue/AI-179/false-promise-soft-handoff-guard
## 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.
Against negative cases identified by evals
## 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
# Pull Request Template
## Description
Fixes inconsistency by adding a fallback to use `url` instead of
`sourceUrl` when Firecrawl returns empty `sourceUrl` in production.
We switched to v2 endpoints of Firecrawl in
https://github.com/chatwoot/chatwoot/pull/14624 and it worked locally,
but seems to fail for some cases in production.
## 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
## 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
Facebook Messenger messages that share a post no longer break message
ingestion. Following the recent sticker change, Meta now sends a shared
post as a new `post` attachment type. Chatwoot didn't recognise `post`
as a valid attachment file type, so the webhook job crashed and the
message — and any others in the same batch — failed to sync. Shared
posts now appear in the conversation as a fallback link (title + URL),
the same way `share` attachments already do.
This is the same class of bug as #14793 (sticker), just a different
attachment type.
#### Root cause
`post` was neither skipped as unsupported nor mapped to a valid
`file_type`, so `attachment_params` produced `file_type: :post`. The
`Attachment#file_type` enum has no `post` value, so it raised
`ArgumentError: 'post' is not a valid file_type`, crashing
`Webhooks::FacebookEventsJob`.
#### Fix
The Facebook builder already maps `share -> :fallback` because shared
posts point to facebook.com page URLs rather than downloadable media. A
`post` is the same kind of attachment, so map both `share` and `post` to
`fallback` (stores the title/link, no download attempt). Also read the
fallback title from `payload.title`, since the post payload nests it
there rather than at the top level.
## How to reproduce
1. Connect a Facebook Page inbox.
2. Share a Facebook post into Messenger to that page.
3. Before this change: `Webhooks::FacebookEventsJob` raises
`ArgumentError: 'post' is not a valid file_type` and the message is
dropped.
4. After this change: the shared post shows up in the conversation as a
fallback link.
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Linear ticket
-
https://linear.app/chatwoot/issue/CW-7137/assignment-v2-backlog-flush-overloads-agents
## Description
Assignment policies now skip stale unassigned conversations
automatically. Each policy carries an age threshold (defaults to 7
days), so auto-assignment only picks up recent backlog instead of
draining very old, forgotten conversations. The threshold is
configurable per policy and can be cleared to assign conversations
regardless of age. Previously this control existed only on Enterprise
capacity policies (`exclude_older_than_hours`); it now lives on the
assignment policy itself, so every V2 inbox benefits without needing a
capacity policy.
## Type of change
- [ ] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
- Local UI flows
## Screenshots?
<img width="645" height="822" alt="image"
src="https://github.com/user-attachments/assets/ec58db86-c1fa-4f9e-be87-2e24ff02e077"
/>
## 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>
## Linear ticket
-
https://linear.app/chatwoot/issue/CW-7374/agent-declined-voice-calls-miscounted-as-failed
## Description
Agent rejections were stored with status: failed, so call reports lumped
deliberate declines together with real technical failure.
Fix: give declines their own terminal rejected status (Twilio + WhatsApp
paths), keeping end_reason: agent_rejected. Genuine provider/network
failures stay failed. Frontend renders declines exactly as before;
existing rows backfilled via migration.
## Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
- Tested on UI
## 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>
# Pull Request Template
## Description
This PR adds support for custom variables in auto-resolution messages
within Conversation Workflows.
Agents can insert variables (e.g. `{{contact.name}}`) into the custom
auto-resolution message using the variable picker by typing `{{`. These
variables are resolved with actual conversation data when the
auto-resolution message is sent.
The field uses the existing editor with the formatting toolbar hidden,
since auto-resolution messages are delivered across all channels,
including SMS, where formatting isn't supported. Existing message
content is preserved as-is, and typing `{{` opens the variable picker
for quick insertion.
Fixes
https://linear.app/chatwoot/issue/CW-7369/support-custom-variables-in-conversations-workflow-text-fields
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Screenshots
<img width="1262" height="764" alt="image"
src="https://github.com/user-attachments/assets/e43be22c-f86e-436a-9fdd-5bcb73c61ca3"
/>
## 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-06-23 11:35:52 +05:30
4501 changed files with 277264 additions and 29271 deletions
-Ship the happy path first: limit guards/fallbacks to what production has proven necessary, then iterate
-**Database foreign keys**: Prefer Rails associations and callbacks over database foreign-key constraints. Add a database foreign key only when there is a clear need and after checking deletion behavior and production migration/locking risks. Existing foreign keys alone are not a reason to add new ones.
-**Migrations**: Create migrations with `bundle exec rails g migration <Name>` so the version is a real timestamp. Never hand-write or round the version (e.g. `20260925000000`); rounded versions collide across branches and break `db:migrate`.
-Prefer the smallest production-ready change that solves the current problem.
- Build for the expected production path first. Do not add speculative guards, fallbacks, retries, or edge-case handling unless the caller can actually hit that case or production has proven it necessary.
- Enforce eligibility and exclusivity rules at the earliest shared entry point. Do not repeat backup guards across downstream jobs, callbacks, services, or writes unless a proven independent path bypasses that point.
- Validate request parameters at the controller or request boundary, reusing existing errors so invalid input returns `422 Unprocessable Entity` instead of reaching models or Sentry.
- Accept only the documented type, shape, and value. Do not add compatibility coercions for malformed client values; fix official clients instead.
- When an impossible or misconfigured state would indicate a setup/deployment bug, let it fail loudly instead of silently skipping behavior.
- For locked/internal configs that must exist in production, prefer direct reads (`find`, `find_by!`, required hash keys) over silent fallbacks.
- Do not add validation or response checks unless the code uses the result or the check changes behavior meaningfully.
- Prefer existing repo dependencies/client libraries over hand-rolled protocol code for auth, signing, parsing, or API plumbing.
- Avoid one-use private helpers unless they hide real complexity or make the main flow meaningfully easier to read.
- Break down complex tasks into small, testable units
- Iterate after confirmation
- Avoid writing specs unless explicitly asked
- In specs, avoid custom helper methods for setup/data. Prefer `let` values and direct per-example setup; only add a helper when it removes meaningful repeated complexity.
- Remove dead/unreachable/unused code
- Don’t write multiple versions or backups for the same logic — pick the best approach and implement it
- Prefer `with_modified_env` (from spec helpers) over stubbing `ENV` directly in specs
@@ -80,8 +90,10 @@
## Project-Specific
- **Translations**:
-Only update `en.yml` and `en.json`
-Other languages are handled by the community
-For product and source-string changes, only update `en.yml` and `en.json`; other languages are handled through Crowdin and the community
-Crowdin-generated translation sync PRs may update non-English locale files; do not flag those changes solely for modifying translated locale files
- Preserve product and brand names, OAuth scopes, API values, and other machine-readable identifiers unless an official localized form exists
- When reviewing Crowdin syncs, verify protected terms remain unchanged. Add newly introduced product names, brand names, and machine-readable identifiers to the Crowdin glossary as non-translatable, and keep the glossary current
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
