fe6368b42ef2de901dffdc0c1a4d1b84a112db5d
6301
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
fe6368b42e |
feat: Add sidebar unread counts for filters (CW-7262) (#14726)
## Description Extends the conversation unread-count system so the left sidebar can show unread badges for Mentions, Participating, Unattended, and saved conversation folders. Folder badges reuse the existing `custom_filters` conversation filter semantics, store user-scoped Redis sets lazily, and skip unsupported folder filters so invalid saved folders continue to render without a badge. The Unattended badge counts all visible unread open conversations that match the existing unattended conversation scope. Closes - [CW-7262](https://linear.app/chatwoot/issue/CW-7262/unread-counts-for-filters-folders) ## What changed - Added user-scoped unread-count Redis keys and cache builders for mentions, participating conversations, unattended conversations, and saved folder filters. - Reused `Conversations::FilterService` through a relation-returning path so folder counts match the folder conversation list behavior. - Invalidated user filter caches from mention, participant, custom-filter, and relevant conversation update events. - Extended the unread-count endpoint payload and sidebar Vuex/sidebar rendering for the new badge counts, including the Unattended sidebar item. - Added Ruby, Enterprise, request, listener, and frontend store coverage for the new unread-count dimensions. ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - Created local validation folders for `john@acme.inc` and confirmed the unread-count payload includes open, resolved, and high-priority folder badges while excluding the invalid unsupported folder. - Added coverage for the Unattended badge rule: all visible unread open conversations matching `Conversation.unattended`. - Ran focused unread-count Ruby specs, including service, listener, request, and Enterprise counter coverage. - Ran frontend unread-count store specs. - Ran RuboCop on the touched Ruby files. - Ran ESLint through the project script; it completed with warnings in existing unrelated files and no errors. <img width="369" height="525" alt="Screenshot 2026-06-13 at 10 51 39 PM" src="https://github.com/user-attachments/assets/36b1d2c4-dac1-4f6f-9c0e-7ef5a6cc2975" /> ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have commented on my code, particularly in hard-to-understand areas - [x] Documentation changes are not required for this internal unread-count behavior - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [x] No dependent downstream changes are required --------- Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> |
||
|
Sivin VargheseandGitHub
|
352f120c6a |
feat: add dedicated color tokens for voice call widget (#14745)
# Pull Request Template ## Description This PR introduces dedicated color tokens for the floating voice call widget instead of reusing generic design tokens. This allows the widget to maintain a distinct dark-card appearance across both light and dark themes. Adds the following tokens and applies them to `CallCard`: * `--call-widget` * `--call-widget-border` * `--call-widget-text` * `--call-widget-sub-text` Fixes https://linear.app/chatwoot/issue/CW-7353/call-notification-window-theme-update-design ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? ### Screenshots **Light mode** <img width="1466" height="815" alt="Screenshot 2026-06-16 at 3 47 32 PM" src="https://github.com/user-attachments/assets/732164b1-5488-4cc1-8c71-01245d906842" /> **Dark mode** <img width="1466" height="815" alt="Screenshot 2026-06-16 at 3 46 54 PM" src="https://github.com/user-attachments/assets/536ab632-4c7c-486b-8fc4-a061ee40b22a" /> ## 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 |
||
|
Vishnu NarayananandGitHub
|
a585853690 |
chore: expose advanced_search flag in super_admin UI for self-hosted (#14750)
## Description Removes `chatwoot_internal: true` from the `advanced_search` feature flag so self-hosted enterprise userss can toggle it from the super_admin UI instead of going through a rails console. |
||
|
|
64b0ebd8dc |
feat: Script to migrate images between providers (#9117)
# Pull Request Template ## Description Storage migration functionality, which allows the transfer of images from one on-premises provider to another (e.g. AWS, Google, etc.) using Active Storage. I ran the unit and integration tests and they all passed correctly. **The command to execute the migration is `FROM=from_service TO=to_service rake storage:migrate`** Fixes #7907 ## Type of change Please delete options that are not relevant. - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? I have tested the storage migration functionality by running the provided unit and integration tests. Additionally, I manually tested the migration process in a local development environment by following these steps: Set up two storage services (e.g., AWS S3 and Google Cloud Storage) with valid configurations. Execute the `FROM=local TO=amazon rake storage:migrate` task with appropriate FROM and TO arguments to migrate blobs between the services. Verified that the blobs were successfully transferred to the target storage service. Checked for any error messages or unexpected behavior during the migration process. ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have commented on my code, particularly in hard-to-understand areas - [x] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [x] Any dependent changes have been merged and published in downstream modules --------- Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
Vishnu NarayananandGitHub
|
cf6ee13665 |
feat: scale email rate limits by agent count for paid plans (#13966)
Paid plan accounts with many agents were hitting the flat daily email rate limit cap. This multiplies the plan base limit by the account's agent seat count, so larger teams get proportionally higher limits. Free/hacker plan keeps the flat limit unchanged. Fixes https://linear.app/chatwoot/issue/CW-6664 ## How to test 1. Set up `ACCOUNT_EMAILS_PLAN_LIMITS` config with plan limits (e.g., `{"hacker": 10, "startups": 20, "business": 30, "enterprise": 40}`) 2. Create an account on a paid plan (e.g., startups) with multiple agent seats 3. Verify `account.email_rate_limit` returns `base_limit × agent_seats` (e.g., 20 × 5 = 100) 4. Create an account on the hacker plan — verify limit stays flat (10) 5. Set a per-account override via super admin `limits.emails` — verify it takes priority over the multiplied limit ## What changed - `plan_email_limit` now multiplies the base plan limit by agent seat count for paid plans - Added `free_plan?` helper to skip the multiplier for the default/free plan |
||
|
|
41a3ab6dfa |
feat(companies): add contact company selector (#14496)
Adds a company selector to the contact details form so agents can associate a contact with an existing company directly from the contact page. Closes - None Why Contacts already expose company information through the CRM fields, but the form only accepted free-text company names. As we split company CRM work into smaller PRs, this keeps the contact page aligned with the structured company model while preserving the existing company-name behavior used by automations. What changed - Shows a company dropdown in the contact details form when the Companies feature is enabled. - Keeps legacy free-text company names editable when a contact has no structured `company_id`. - Allows Enterprise contact create/update APIs to accept account-scoped `company_id`. - Syncs `additional_attributes.company_name` when a contact is associated with a company, including the existing email-domain auto-association path. - Serializes `company_id` in the contact model payload so the form can show the current association. How to test 1. Enable Companies for an account and open a contact details page. 2. In Edit contact details, use the Company field to select an existing company. 3. Save the contact and refresh the page. 4. Confirm the selected company remains visible and the contact is associated with that company. 5. Confirm contacts with only a legacy free-text company name still show the text input instead of an empty selector. --------- Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> Co-authored-by: iamsivin <iamsivin@gmail.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
|
de137e8297 |
feat: Capture CTWA referral metadata for WhatsApp conversations (#14681)
Adds support for capturing Click-to-WhatsApp ad referral metadata from incoming WhatsApp messages. This stores Meta Cloud API `referral` payloads on the incoming message `content_attributes` and normalizes Twilio `Referral*` callback fields into the same shape. The UI display is intentionally deferred until Instagram, Messenger, and TikTok referral payloads are captured as well, so we can design one cross-channel referral surface instead of a WhatsApp-only sidebar block. Why message-level storage Meta sends CTWA referral details as part of the inbound message payload, not as a stable conversation-level webhook. The referral represents the exact ad click that produced that specific customer message, and later messages in the same conversation may not carry the same context. Storing the normalized referral on the message preserves the original webhook semantics, avoids adding conversation-level attribution that could become stale or ambiguous, and keeps support for both Cloud API and Twilio payloads aligned behind `content_attributes.referral`. Fixes https://linear.app/chatwoot/issue/CW-7090/surface-meta-ctwa-referral-on-incoming-whatsapp-messages-cloud-api Closes https://github.com/chatwoot/chatwoot/issues/13995, https://github.com/chatwoot/chatwoot/issues/12560, https://github.com/chatwoot/chatwoot/issues/13006 Related community PRs - https://github.com/chatwoot/chatwoot/pull/13130 - https://github.com/chatwoot/chatwoot/pull/14180 - https://github.com/chatwoot/chatwoot/pull/14121 Related follow-ups - https://linear.app/chatwoot/issue/CW-7301/capture-instagram-ad-referral-metadata-on-incoming-messages - https://linear.app/chatwoot/issue/CW-7302/capture-messenger-ad-referral-metadata-on-facebook-page-conversations - https://linear.app/chatwoot/issue/CW-7303/capture-tiktok-ad-referral-metadata-from-im-referral-msg-events How to test 1. Send or replay a WhatsApp Cloud API inbound message that contains a `messages[0].referral` payload from a Click-to-WhatsApp ad. 2. Confirm the generated incoming message stores the payload under `content_attributes.referral`. 3. Repeat with a Twilio WhatsApp callback containing `Referral*` fields and confirm the stored message has the same normalized `content_attributes.referral` structure. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> |
||
|
Sivin VargheseandGitHub
|
a3d05ef55d | chore: Update emoji picker in widget (#14741) | ||
|
|
dda25c0b51 |
fix(portal): emit valid BCP 47 html lang attribute (#14680)
Locales are stored with underscores (e.g. pt_BR), but the HTML lang attribute requires hyphens (pt-BR). Convert via a helper in the public portal layouts. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> |
||
|
Sivin VargheseandGitHub
|
1713cabdf2 | feat: Add emoji & icon picker for Help Center categories (#14702) | ||
|
|
d8a16278b9 |
fix: added ordering capability for sidebar sections folders, teams, channels and labels (CW-7193) (#14609)
## Description * Added the ability to sort for 4 sub-sections under conversations folders, teams, channels and labels. * the sort options are basically created at, alphabetical and unread counts along with both directions. * for folders we don't have an unread count, so we sort it by only created and alphabetical. * all the sort preferences are stored on the frontend - easiest implementation for now. Fixes # CW-7193 ## Type of change Please delete options that are not relevant. - [ ] 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? Tested this locally by visually verifying the changes. Also ran the newly added tests for component level changes. Here is the screenshot of the changes: Added the sort option to sub sections in the conversation sidebar: <img width="282" height="848" alt="Screenshot 2026-06-02 at 1 58 12 AM" src="https://github.com/user-attachments/assets/4a7c6061-86e3-438a-92ae-ee643a0128b6" /> The sort options looks like this: <img width="783" height="698" alt="Screenshot 2026-06-02 at 1 58 49 AM" src="https://github.com/user-attachments/assets/a15bb0a7-b810-4423-a88c-fbd84d0476c0" /> ## 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: iamsivin <iamsivin@gmail.com> |
||
|
Sony MathewandGitHub
|
4816e923b6 |
chore: added a new sort by unread option for conversations (CW-7152) (#14512)
## Description Added a new option for the sort by option in conversation filters called unread. This is to filter out unread conversations. Fixes # CW-7152 ## Type of change Please delete options that are not relevant. - [ ] 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? Tested manually in local. <img width="1397" height="603" alt="Screenshot 2026-05-20 at 10 40 20 PM" src="https://github.com/user-attachments/assets/6c60263e-907b-419f-a7ed-06010bbe8736" /> ## 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 |
||
|
|
396631ad7d |
feat: enforce concurrent session limit with login picker (CW-7169) (#14621)
## Description Cap active sessions at `MAX_USER_SESSIONS` which defaults to existing value of `25` per user. This ensure existing user login behavior is not affected for self-hosted installations. Browser users at the cap see a session picker (409 response) to choose which session to end. Non-browser clients and partially-tracked users get silent oldest-session eviction. Depends on #14556. ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? Specs cover: under limit, at limit (browser picker, non-browser eviction), partial tracking fallback, revoke single/all sessions during login, session row creation on successful login. --------- Co-authored-by: Sony Mathew <sony@chatwoot.com> |
||
|
Vishnu NarayananandGitHub
|
ba0ba46c9c |
fix: skip session tracking and use short-lived token for impersonation (CW-7169) (#14622)
## Description SuperAdmin impersonation SSO logins no longer create UserSession rows visible to the customer. Impersonation tokens use a 2-day lifespan instead of ~2 months, so they naturally evict first and don't linger in the user's token list. Server-side detection via Redis value (`'impersonation'` vs `'normal'`) without changing the `valid_sso_auth_token?` signature. Backward compatible with in-flight tokens. Depends on #14556. ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? Specs cover: impersonation login skips UserSession creation, impersonation token has short lifespan, normal SSO login still creates UserSession row. ## 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 - [x] Any dependent changes have been merged and published in downstream modules |
||
|
Vishnu NarayananandGitHub
|
ee6382109a |
feat: prevent deleted email conversations from syncing again (#14612)
# Pull Request Template ## Description Prevent deleted email conversations from being synced into Chatwoot again while they are still within the IMAP sync window. When an admin explicitly deletes an email conversation, the incoming email message IDs are stored temporarily in Redis. IMAP sync checks these recently deleted message IDs in addition to existing message records. Each Redis key expires automatically after two days. This applies only to explicit conversation deletion. Individual message deletion, inbox deletion, and account deletion keep their existing behavior. Fixes [CW-7214](https://linear.app/chatwoot/issue/CW-7214/deleted-mails-in-gmail-inbox-gets-synced-again) |
||
|
Sivin VargheseandGitHub
|
35bef21f83 | feat: add media view for contacts (#14393) | ||
|
|
e5c140158e |
fix(new-conversation): stop writing literal "undefined" as mail_subject (#14383)
## Description This PR fixes a data-corruption bug in the new conversation flow that surfaces in conversation search results as `Subject: undefined`. ### The Problem When creating a conversation through the "New conversation" modal without typing a subject (every non-email channel never shows the subject input, and email channels can be left blank), the conversation gets persisted with `additional_attributes.mail_subject = "undefined"` (the literal string). The bogus value shows up in conversation search results as `Subject: undefined`, which started rendering after #10843. ### Root Cause `createConversationPayload` in `app/javascript/dashboard/store/modules/contactConversations.js` appends the `mail_subject` field unconditionally: ```js payload.append('additional_attributes[mail_subject]', mailSubject); ``` `composeConversationHelper.js` only sets `payload.mailSubject` when `subject` is truthy, so when no subject is provided, `mailSubject` is destructured as `undefined` in `createConversationPayload`. `FormData.append` coerces `undefined` to the string `"undefined"`, and the backend persists it as-is into the JSONB column. ### The Fix Skip the append when `mailSubject` is falsy. The backend already treats a missing key the same as an empty subject (the email mailer falls back to a default subject when `mail_subject` is `nil`), so omitting the field is safe across channels. ### Key Changes - Guarded the `additional_attributes[mail_subject]` append in `createConversationPayload`. - Added a spec covering the case where `mailSubject` is omitted. > Note: existing rows persisted before this fix will continue to show `Subject: undefined` in search until cleaned up. A simple SQL cleanup for non-email inboxes: > > ```sql > UPDATE conversations > SET additional_attributes = additional_attributes - 'mail_subject' > FROM inboxes > WHERE conversations.inbox_id = inboxes.id > AND inboxes.channel_type <> 'Channel::Email' > AND conversations.additional_attributes->>'mail_subject' = 'undefined'; > ``` > > I'm leaving any data-cleanup migration out of this PR since it's a maintenance concern that may be handled differently per installation. ## Type of change - [X] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? 1. Open the "New conversation" modal on a non-email inbox (e.g., WhatsApp, SMS, API). 2. Create a conversation without filling any subject (field is not present on those, so regular flow). 3. Open the global search and search for the conversation. 4. **Before:** the result card shows `Subject: undefined`. **After:** the subject row is hidden. 5. Repeat on an email inbox leaving the subject blank — same result. 6. On an email inbox, type a subject and verify it still persists and renders correctly. 7. Run the new spec: `pnpm test contactConversations`. ## 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: Sojan Jose <sojan@pepalo.com> Co-authored-by: Sony Mathew <sony@chatwoot.com> |
||
|
|
274e92e0e4 |
chore: collapse conversation sidebar sections (folders, teams, inboxes and labels) - CW-7059 (#14509)
## Description Added ability to collapse conversation sidebar sections (folders, teams, inboxes and labels) Fixes #CW-7059 ## Type of change Please delete options that are not relevant. - [ ] 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? Tested locally. Added specs. Attaching the loom for them same. https://github.com/user-attachments/assets/40d613e7-6c82-4078-abf4-79739a00f718 ## 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: iamsivin <iamsivin@gmail.com> |
||
|
|
27404b4a27 |
fix: redact sensitive integration secrets from API responses (#14147)
## Summary The `GET /api/v1/accounts/:id/integrations/apps` endpoint returns raw secret values (OpenAI API keys, Google service account private keys, Linear refresh tokens, etc.) in hook settings within the JSON response. Although gated behind an administrator check, these secrets are visible in the browser network tab. This PR filters hook settings through the existing `visible_properties` whitelist defined in `config/integration/apps.yml`, and adds explicit whitelists to integrations that were missing them. Closes #14042 ## Bug reproduction **Setup:** Created an OpenAI integration hook with a fake API key (`sk-test-secret-12345`). **Step 1 — Browser Network tab shows raw secrets:** <img width="1676" height="869" alt="Screenshot 2026-04-24 at 14 32 28" src="https://github.com/user-attachments/assets/6fc69463-365e-458b-b216-98a7390bf528" /> Navigate to Settings > Integrations as an admin. Open DevTools Network tab and observe the response from `GET /api/v1/accounts/:id/integrations/apps`. The hook settings contain the full API key in plaintext: ```json "hooks": [ { "id": 1, "app_id": "openai", "settings": { "api_key": "sk-test-secret-12345", "label_suggestion": false } } ] ``` **Step 2 — API call confirms the leak:** ```bash curl -s "http://localhost:3000/api/v1/accounts/2/integrations/apps" \ -H "access-token: <token>" \ -H "client: <client>" \ -H "uid: user@test.com" \ | jq '.payload[] | select(.id == "openai") | {id, name, hooks: [.hooks[] | {id, app_id, settings}]}' ``` Response: ```json { "id": "openai", "name": "OpenAI", "hooks": [ { "id": 1, "app_id": "openai", "settings": { "api_key": "sk-test-secret-12345", "label_suggestion": false } } ] } ``` Any admin user can extract the raw API key from the response. The same applies to other integrations — Dialogflow exposes full Google service account credentials, Linear exposes refresh tokens, etc. ## After fix After applying this change, the GET /api/v1/accounts/:id/integrations/apps endpoint no longer returns sensitive secret values in hook settings. Instead, the response is filtered using each integration’s visible_properties whitelist, ensuring only safe, user-facing fields are exposed. For example, OpenAI integrations return non-sensitive fields like label_suggestion while excluding raw API keys. This prevents secrets from being exposed in the browser network tab or API responses, even for authenticated admin users. ```bash curl -X GET "http://localhost:3000/api/v1/accounts/2/integrations/apps" \ -H "Accept: application/json" \ -H "Authorization: Bearer eyJhY2Nlc3MtdG9rZW4iOiJqZG5jOWg4TnljaWFJa3JlZkxGQzRnIiwidG9rZW4tdHlwZSI6IkJlYXJlciIsImNsaWVudCI6Ik81bjVnTDFEOVVhbGpwbWxjaHZNanciLCJleHBpcnkiOiIxNzgyMzMyNTA4IiwidWlkIjoidXNlckB0ZXN0LmNvbSJ9" \ -H "access-token: jdnc9h8NyciaIkrefLFC4g" \ -H "client: O5n5gL1D9UaljpmlchvMjw" \ -H "uid: user@test.com" \ | jq '.payload[] | select(.id == "openai") | {id, name, hooks: [.hooks[] | {id, app_id, settings}]}' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 10174 100 10174 0 0 33232 0 --:--:-- --:--:-- --:--:-- 33357 { "id": "openai", "name": "OpenAI", "hooks": [ { "id": 1, "app_id": "openai", "settings": { "label_suggestion": false } } ] } ``` ## What changed - Added `visible_properties` accessor to `Integrations::App` model to expose the whitelist from config - Updated `_hook.json.jbuilder` to filter `resource.settings` through the associated app's `visible_properties` instead of returning the full hash - Added `visible_properties` to integrations that were missing it: - Linear: `[]` (settings contain refresh_token) - Notion: `[]` (OAuth-based, no user-facing settings) - Slack: `['channel_name']` (UI needs this to display connected channel) - Shopify: `[]` (no settings) App config metadata (`_app.json.jbuilder`) is left unchanged — hook_type, settings_form_schema, etc. are not secrets and the frontend depends on them. ## How to test 1. Create an OpenAI integration hook with an API key 2. As an admin, call `GET /api/v1/accounts/:id/integrations/apps` 3. Verify hook settings include `api_key` (whitelisted) but not raw credential objects 4. For Dialogflow hooks, verify `credentials` (private key JSON) is excluded while `project_id` is included 5. For Slack hooks, verify `channel_name` is still returned 6. For Linear hooks, verify `refresh_token` is not returned --------- Co-authored-by: Botshelo Nokoane (Konstruktors) <botshelo@entersekt.com> Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
dependabot[bot]GitHubdependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>Sony MathewSony Mathew |
006b529918 |
chore(deps): bump net-imap from 0.4.24 to 0.6.4.1 (#14688)
Bumps [net-imap](https://github.com/ruby/net-imap) from 0.4.24 to 0.6.4.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/ruby/net-imap/releases">net-imap's releases</a>.</em></p> <blockquote> <h2>v0.5.15</h2> <h2>What's Changed</h2> <h3>🔒 Security</h3> <p>This release fixes several more security vulnerabilities which are related to the fixes in <code>v0.5.14</code>. Please see the linked security advisories for more information.</p> <ul> <li><em>(moderate)</em> Command Injection via non-synchronizing literal in "raw" argument (CVE-2026-47240, GHSA-8p34-64r3-mwg8) This vulnerability depends how the server interprets non-synchronizing literals. The connection is <em>not</em> vulnerable if the server supports non-synchronizing literals. <ul> <li>🥅 Validate non-synchronizing literals support by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/703">ruby/net-imap#703</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/701">ruby/net-imap#701</a>)</li> </ul> </li> <li><em>(moderate)</em> Command Injection via unvalidated ID and ENABLE arguments (CVE-2026-47242, GHSA-46q3-7gv7-qmgg) <ul> <li>🥅 Validate <code>ID</code> values contain only valid bytes by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/703">ruby/net-imap#703</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/698">ruby/net-imap#698</a>)</li> <li>🥅 Validate <code>#enable</code> arguments are all atoms by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/703">ruby/net-imap#703</a> (backport <a href="https://redirect.github.com/ruby/net-imap/pull/699">ruby/net-imap#699</a>) <strong>NOTE:</strong> <code>#enable</code> should <strong><em>never</em></strong> be called with untrusted input.</li> </ul> </li> <li><em>(low)</em> Denial of Service via incomplete "raw" argument validation (CVE-2026-47241, GHSA-c4fp-cxrr-mj66) This results in the affected command hanging until the connection is closed. If another thread attempts to send a concurrent pipelined command, the first thread will return with a syntax error and the second thread will hang until the connection closes. <ul> <li><em>Reported by <a href="https://github.com/fg0x0"><code>@fg0x0</code></a></em></li> <li>🐛 Prevent trailing <code>{0}</code> in RawData validation by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/703">ruby/net-imap#703</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/700">ruby/net-imap#700</a>)</li> </ul> </li> </ul> <h3>Fixed</h3> <ul> <li>🥅 Validate that Atom and Flag are not empty by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/685">ruby/net-imap#685</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/684">ruby/net-imap#684</a>)</li> <li>🧵 Fix deadlock in <code>#disconnect</code> by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/697">ruby/net-imap#697</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/686">ruby/net-imap#686</a>)</li> </ul> <h3>Documentation</h3> <ul> <li>⚠️ Boost visibility of raw data argument documentation warnings by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/696">ruby/net-imap#696</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/677">ruby/net-imap#677</a>)</li> </ul> <h3>Other Changes</h3> <ul> <li>🏷️ Allow 64-bit Integer arguments in <a href="https://redirect.github.com/ruby/net-imap/pull/696">ruby/net-imap#696</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/675">ruby/net-imap#675</a>)</li> <li>🥅 Ensure send_number_data input is an Integer in <a href="https://redirect.github.com/ruby/net-imap/pull/696">ruby/net-imap#696</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/676">ruby/net-imap#676</a>)</li> <li>♻️ Improve <code>RawData.new</code>, Add <code>RawData.split</code> by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/696">ruby/net-imap#696</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/679">ruby/net-imap#679</a>)</li> <li>🥅 Validate response literal byte size format by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/696">ruby/net-imap#696</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/681">ruby/net-imap#681</a>)</li> </ul> <h3>Miscellaneous</h3> <ul> <li>✅ Improvements to tests' FakeServer in <a href="https://redirect.github.com/ruby/net-imap/pull/696">ruby/net-imap#696</a> (backports <a href="https://redirect.github.com/ruby/net-imap/pull/678">ruby/net-imap#678</a>)</li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/ruby/net-imap/compare/v0.5.14...v0.5.15">https://github.com/ruby/net-imap/compare/v0.5.14...v0.5.15</a></p> <h2>v0.5.14</h2> <h2>What's Changed</h2> <h3>🔒 Security</h3> <p>This release contains fixes for <strong>multiple vulnerabilities</strong> concerning <em><strong><code>STARTTLS</code> stripping</strong></em>, argument validation, and denial of service attacks.</p> <blockquote> <p>[!WARNING] <a href="https://redirect.github.com/ruby/net-imap/pull/665">ruby/net-imap#665</a> fixes a <code>STARTTLS</code> stripping vulnerability (GHSA-vcgp-9326-pqcp). Without this fix, a man-in-the-middle attacker can cause <code>Net::IMAP#starttls</code> to return "successfully", <strong><em>without starting TLS</em></strong>.</p> </blockquote> <blockquote> <p>[!IMPORTANT] Argument validation is significantly improved. Several command injection vulnerabilities have been fixed: <a href="https://redirect.github.com/ruby/net-imap/pull/662">ruby/net-imap#662</a> fixes CRLF/command/argument injection via Symbol arguments (GHSA-75xq-5h9v-w6px). <a href="https://redirect.github.com/ruby/net-imap/pull/662">ruby/net-imap#662</a> fixes CRLF/command/argument injection via the <code>attr</code> argument to <code>#store</code>/<code>#uid_store</code> (GHSA-hm49-wcqc-g2xg)</p> </blockquote> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/ruby/net-imap/commit/ce20fc8e9974ed87d0848dc411eef490623cdeb9"><code>ce20fc8</code></a> 🔖 Bump version to 0.5.15</li> <li><a href="https://github.com/ruby/net-imap/commit/0b7b83c19312dd3f44cb72be2e7681289324d9db"><code>0b7b83c</code></a> 🔀 Merge pull request <a href="https://redirect.github.com/ruby/net-imap/issues/703">#703</a> from ruby/backport/v0.5/security-patches</li> <li><a href="https://github.com/ruby/net-imap/commit/f22fd6cee01140b53cdb7fc8d42a352a734f4509"><code>f22fd6c</code></a> 🍒 pick 0ea9eba3 (<a href="https://redirect.github.com/ruby/net-imap/issues/701">#701</a>): ✅ Fix flaky tests for MacOS, TruffleRuby</li> <li><a href="https://github.com/ruby/net-imap/commit/12460740451d064cef84f59dd8c91baba0388ae1"><code>1246074</code></a> 🍒 pick ae9f83b5 (<a href="https://redirect.github.com/ruby/net-imap/issues/701">#701</a>): ♻️ Extract str.bytesize lvar in send_literal</li> <li><a href="https://github.com/ruby/net-imap/commit/a2f61af6b7a7e6f0e4f27691531de6e4861318cd"><code>a2f61af</code></a> 🍒 pick 62a0da6d (<a href="https://redirect.github.com/ruby/net-imap/issues/701">#701</a>): 🥅 Validate non-synchronizing literals support</li> <li><a href="https://github.com/ruby/net-imap/commit/e33348ccdc639d0d4414f72e4ba7024bdb24bf29"><code>e33348c</code></a> 🍒 pick d6ddd294 (<a href="https://redirect.github.com/ruby/net-imap/issues/700">#700</a>): 🐛 Prevent trailing <code>{0}</code> in RawData validation</li> <li><a href="https://github.com/ruby/net-imap/commit/4f81b69044297de02ada859fffba6ad9923a43a5"><code>4f81b69</code></a> 🍒 pick 1f97168b (<a href="https://redirect.github.com/ruby/net-imap/issues/699">#699</a>): 🥅 Validate <code>#enable</code> arguments are all atoms</li> <li><a href="https://github.com/ruby/net-imap/commit/69da4a490dd148526fb287a5c82056bfd20c6f95"><code>69da4a4</code></a> 🍒 pick 8d9397ab (<a href="https://redirect.github.com/ruby/net-imap/issues/698">#698</a>): 🥅 Validate QuotedString contains only valid bytes</li> <li><a href="https://github.com/ruby/net-imap/commit/7aab580ad35f2cad1404a58bf0ff015567f2593c"><code>7aab580</code></a> 🍒 pick e3c50fad (<a href="https://redirect.github.com/ruby/net-imap/issues/698">#698</a>): ♻️ Refactor RawText, add improve test coverage</li> <li><a href="https://github.com/ruby/net-imap/commit/fac1733d45ec57da3675c4d266c771c73c7265bb"><code>fac1733</code></a> 🍒 pick aab64f92 (<a href="https://redirect.github.com/ruby/net-imap/issues/686">#686</a>): 🧵 Fix deadlock in <code>#disconnect</code></li> <li>Additional commits viewable in <a href="https://github.com/ruby/net-imap/compare/v0.4.24...v0.5.15">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: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
Sony MathewandGitHub
|
b1c2db5435 |
fix: Stabilize help center builder error spec (#14725)
## Description Stabilizes the enterprise help center article builder source URL validation spec by asserting the custom exception via its class name and message text. This keeps the spec focused on the intended behavior while avoiding brittle custom exception constant identity checks in CI/reloading environments. A bunch of builds on different PRs have been failing because of this error, sample traces are below: * https://app.circleci.com/pipelines/github/chatwoot/chatwoot/114064/workflows/bdb6eca9-3b65-4c38-b8cf-f2f8564476f8/jobs/158777 * https://app.circleci.com/pipelines/github/chatwoot/chatwoot/114064/workflows/bdb6eca9-3b65-4c38-b8cf-f2f8564476f8/jobs/158777 Fixes # N/A ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? - `/Users/sonymathew/.rbenv/shims/bundle exec rspec spec/enterprise/services/onboarding/help_center_article_builder_spec.rb` - `/Users/sonymathew/.rbenv/shims/bundle exec rubocop spec/enterprise/services/onboarding/help_center_article_builder_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] My changes generate no new warnings - [x] New and existing unit tests pass locally with my changes - [ ] I have commented on my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [ ] I have added tests that prove my fix is effective or that my feature works - [ ] Any dependent changes have been merged and published in downstream modules |
||
|
Vishnu NarayananandGitHub
|
92a1fb8ab7 |
feat: manage active user sessions from profile (CW-7169) (#14556)
## Description First PR of user_sessions feature - enforcement, impersonation and mfa will be handled separately. Adds an Active Sessions section under Profile where users can see every device currently logged in and revoke any session they don't recognize. Helps users lock down stale or unrecognized logins on their own without needing support. **Behavior at the limit, by client:** - **Browser:** returns 409 with a picker overlay; user picks a session to revoke or chooses "End all sessions" to clear them. - **Mobile / API client:** silently evicts the oldest session and proceeds with login (no picker UI to render). - **Pre-tracking users** (token rows without `user_sessions`, i.e. anyone already logged in before this ships): silent-evict any untracked token first, so freshly tracked sessions are never killed in favor of legacy ones. Sessions are stored in a new `user_sessions` table keyed on `(user_id, client_id)` with browser, platform, IP, last activity and (when configured) geo. Kept in sync with `user.tokens` via an after_save callback so revoking a token from any path cleans up the row. Fixes https://linear.app/chatwoot/issue/CW-7169 ## Type of change - [x] New feature (non-breaking change which adds functionality) ## How Has This Been Tested? - Added specs. - Manual local testing: browser picker fires at limit; pre-tracking user silent-evicts; mixed tracked/untracked correctly drops the untracked one first; profile page revoke succeeds; current session cannot be revoked from profile. ## 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 |
||
|
|
e055cead35 |
fix: only subscribe calls webhook field when voice calling enabled (#14718)
## Description Solves issue https://github.com/chatwoot/chatwoot/issues/14690 ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) ## How has this been tested? - UI flows ## 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> |
||
|
|
c041fde3a2 |
fix: Preserve original filenames for WhatsApp cloud attachments (#14168)
## Summary Preserves the original filename provided in the WhatsApp Cloud attachment payload when downloading media files. ## Problem Files containing accented or special characters could be saved with malformed names or incorrect extensions due to relying on remote download metadata. ## Changes Made - Uses attachment_payload[:filename] when present - Creates a tempfile using the original filename and extension - Preserves content type metadata - Falls back to existing behavior when no filename is provided ## Notes This should improve attachment downloads for filenames containing accented characters. Related to #10973 --------- Co-authored-by: Rorrick Smith <rorrick@bulksms.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> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> |
||
|
|
c6a38e2fc6 |
fix: Keep Instagram scopes out of new Messenger OAuth flows (#14695)
Removes Instagram permissions from the Facebook Messenger inbox setup flow to avoid blocking Meta App Review for Messenger-only apps. Meta rejects or stalls Messenger-only app reviews when the OAuth flow requests unrelated Instagram permissions such as `instagram_basic` and `instagram_manage_messages`. This blocks approval for Messenger permissions like `human_agent`, even when the user only wants to configure a Facebook Messenger inbox. New Facebook Messenger inbox setup now requests only the Page and Messenger permissions required for Messenger. Existing Facebook Messenger inboxes that already have Instagram details continue to request Instagram permissions during reauthorization, preserving support for the legacy combined Facebook/Instagram inbox flow. Going forward, new Instagram setups should use the dedicated Instagram channel inbox instead of being bundled into the Messenger setup flow. Closes #13860 ## How to test 1. Go to Settings → Inboxes → Add Inbox → Facebook Messenger. 2. Click Login with Facebook. 3. Verify the OAuth scope does not include `instagram_basic` or `instagram_manage_messages`. 4. Reauthorize an existing Facebook Messenger inbox with `instagram_id` present. 5. Verify the reauth scope still includes `instagram_basic` and `instagram_manage_messages`. --------- Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> |
||
|
Sugar Ray LedesmaandGitHub
|
2663a8495d |
refactor(security): rename path_without_extensions in Rack::Attack (#14216)
Fix misspelling 'extentions' and clarify comments. Behavior unchanged: same path-stripping logic for throttle matching (e.g. /auth and /auth.json). Also correct 'You may' in remote_ip comment. |
||
|
Sivin VargheseandGitHub
|
d0d275d962 | fix: cannot resize pasted images (#14709) | ||
|
|
95d6aecb51 |
chore: Add security flags to session cookie configuration (#14248)
## Summary - Adds `httponly` and `secure` flags to session cookie configuration - Adds RSpec tests for session configuration ## Changes - `config/initializers/session_store.rb`: add `httponly: true`, `secure: FORCE_SSL` - `spec/config/session_store_spec.rb`: tests for all session store options Ref #2683 (hardens the session cookie but does not remove it, sessions are still needed for super_admin dashboard) --------- Co-authored-by: Adam-Relay <adam@userelay.ai> Co-authored-by: Adam Berger <adam@adam-berger.com> Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com> |
||
|
|
a901c87ab4 |
perf: merge 3 conversation COUNT queries in /meta into single query (#13536)
# Pull Request Template ## Description - Merges 3 separate COUNT queries in `ConversationFinder#set_count_for_all_conversations` into a single query using PostgreSQL `COUNT(*) FILTER (WHERE ...)` - Every call to `/meta` and conversation index fires 3 COUNT queries against the conversations table — one for "mine", one for "unassigned", one for "all". These share the same base query and scan the same rows, but execute as 3 independent round-trips. from pg_stats | Query | Calls | Total DB Time | Avg Latency | |-------|-------|--------------|-------------| | COUNT unassigned | 4.1M | 141,081 sec | 34ms | | COUNT all | 4.1M | 132,302 sec | 32ms | | COUNT mine | 3.7M | 37,637 sec | 10ms | | **Total** | **~12M** | **311,020 sec** | | `/meta` alone runs at 2.3K RPM (NewRelic), triggered on every WebSocket event (conversation created/updated/status changed/assignee changed). Fixes https://linear.app/chatwoot/issue/INF-43/make-single-query-to-count-the-assigned-unassigned-and-all-instead-of ## Type of change - [x] Performance fix ## How Has This Been Tested? - [x] Verify conversation list shows correct mine/unassigned/assigned/all counts - [x] Verify /meta endpoint returns correct counts - [x] Verify counts update correctly when assigning/unassigning conversations - [x] Verify counts with team filter applied - [x] Monitor DB query count reduction in NewRelic after deploy ## 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: Sony Mathew <ynos1234@gmail.com> |
||
|
Sony MathewandGitHub
|
6d26e7930a |
fix(contacts): truncate inbound contact names (IMAP sender display names) (#14631)
## Description Truncates long contact names in `ContactInboxWithContactBuilder` before persisting them, so inbound IMAP sender display names over the `contacts.name` 255-character limit no longer raise `ActiveRecord::RecordInvalid` from `Inboxes::FetchImapEmailsJob`. This keeps email ingestion moving while preserving the existing contact name length constraint. Linear ticket: [https://linear.app/chatwoot/issue/CW-7263/sentry-active-record-invalid-contact-create-from-imap-fetch-job](https://linear.app/chatwoot/issue/CW-7263/sentry-active-record-invalid-contact-create-from-imap-fetch-job) ## Type of change - [x] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? - [x] `bundle exec rspec spec/builders/contact_inbox_with_contact_builder_spec.rb` - [x] `bundle exec rspec spec/mailboxes/imap/imap_mailbox_spec.rb` - [x] `bundle exec rubocop app/builders/contact_inbox_with_contact_builder.rb spec/builders/contact_inbox_with_contact_builder_spec.rb` ## 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 |
||
|
Tanmay Deep SharmaandGitHub
|
8d5d02ea97 |
feat: add per-inbox toggle to disable incoming calls (#14645)
## Description Adds a per-inbox "Allow incoming calls" toggle for voice-enabled WhatsApp and Twilio inboxes. When turned off, the setting is persisted on the channel; actually rejecting inbound calls is handled in a follow-up PR. ## Type of change - [ ] New feature (non-breaking change which adds functionality) ## Screenshot <img width="804" height="384" alt="Screenshot 2026-06-04 at 11 44 07 AM" src="https://github.com/user-attachments/assets/df8bb026-0387-4031-bcba-6d9a56872eb7" /> ## 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 |
||
|
|
ce93ddec78 |
fix: re-fetch widget conversation status on reconnect (#14683)
When an inbox has **"Allow messages after conversation is resolved"** disabled, the live-chat widget should hide the reply box once a conversation is resolved — but users could still send a reply, silently reopening it. This syncs the widget's conversation status on reconnect so the reply box hides correctly. ## Closes - CW-7272 ## How to reproduce 1. Disable **Allow messages after conversation is resolved** on an inbox. 2. Open the widget, then let its websocket drop (background tab / lose network). 3. While disconnected, get the conversation resolved (e.g. auto-resolve on inactivity). 4. Reconnect → reply box is still visible and a sent message reopens the resolved conversation. ## Why Reply-box hiding is gated on the widget's local status, updated via the `conversation.status_changed` socket event. If the resolve happens while disconnected, the event is missed — and on reconnect the widget only re-synced messages, never the status, so it stayed stale at `open`. ## What changed - `onReconnect` now also dispatches `conversationAttributes/getAttributes` to refresh status after a missed event. - Added a spec covering the reconnect behavior. Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> |
||
|
Sivin VargheseandGitHub
|
940428c10e | fix: preserve markdown links with unsafe href characters in help center content (#14686) | ||
|
|
4d3196b02f |
feat: Show unread count for all conversations (#14627)
## Description Adds the unread count for All Conversations to the left sidebar. The unread counts API now returns an `all_count` aggregate based on the same permission-scoped inbox counts already used for sidebar badges, and the sidebar renders that backend-provided value on the All Conversations item. Fixes [CW-7240](https://linear.app/chatwoot/issue/CW-7240/unread-count-for-all-conversations) ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality not to work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? - `bundle exec rspec spec/services/conversations/unread_counts/counter_spec.rb spec/enterprise/services/conversations/unread_counts/counter_spec.rb spec/controllers/api/v1/accounts/conversations_controller_spec.rb` - `pnpm test app/javascript/dashboard/store/modules/specs/conversationUnreadCounts/actions.spec.js app/javascript/dashboard/store/modules/specs/conversationUnreadCounts/getters.spec.js app/javascript/dashboard/store/modules/specs/conversationUnreadCounts/mutations.spec.js` - `pnpm exec eslint app/javascript/dashboard/components-next/sidebar/Sidebar.vue app/javascript/dashboard/store/modules/conversationUnreadCounts.js app/javascript/dashboard/store/modules/specs/conversationUnreadCounts/actions.spec.js app/javascript/dashboard/store/modules/specs/conversationUnreadCounts/getters.spec.js app/javascript/dashboard/store/modules/specs/conversationUnreadCounts/mutations.spec.js` - `bundle exec rubocop app/services/conversations/unread_counts/counter.rb spec/services/conversations/unread_counts/counter_spec.rb spec/enterprise/services/conversations/unread_counts/counter_spec.rb spec/controllers/api/v1/accounts/conversations_controller_spec.rb` ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have commented on my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] Any dependent changes have been merged and published in downstream modules Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> |
||
|
Tanmay Deep SharmaandGitHub
|
c6e5657ee5 |
fix(call): emit assignee activity message when agent answers a call (#14700)
## Linear Ticket - https://linear.app/chatwoot/issue/CW-7249/debug-assignment-log ## Description When an agent answers an inbound WhatsApp call on an unassigned conversation, the conversation is claimed for that agent — but no "assigned" activity message or assignee-changed event was emitted, so the assignment was invisible in the timeline (and notifications/live assignee panel didn't update). The claim ran before `update_conversation_call_status`, so that later `update!` on the same conversation clobbered `saved_change_to_assignee_id?` before `after_commit` fired. Moving the claim to be the conversation's final write in the transaction restores the activity message, the `ASSIGNEE_CHANGED` event, and the live assignee update. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? 1. Open an unassigned WhatsApp-call conversation. 2. As an agent, answer an inbound call. 3. Before: the conversation is assigned to you, but no "self-assigned" activity message appears. After: the activity message is created and the assignee updates live. ## 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 |
||
|
Sony Mathew
|
e9a92a6366 | Merge branch 'release/4.14.2' into develop | ||
|
Sony Mathew
|
bec795f764 | Bump version to 4.14.2 | ||
|
Shivam MishraandGitHub
|
e6dfb91fcc | refactor: use SafeFetch for website branding page fetch (#14693) | ||
|
Shivam MishraandGitHub
|
d9c07fe2e9 |
feat: expose onboarding help center generation status (#14671)
This PR adds a reload-safe onboarding Help Center generation status path. Previously, generation progress was pushed through ActionCable, which meant the onboarding UI could lose context after a page reload or missed websocket event. The new endpoint exposes the current generation id, raw Redis generation state, and Help Center article/category counts so clients can recover state by fetching from the backend. **What changed** - Added an onboarding Help Center generation status endpoint. - Persisted `help_center_generation_id` when generation is enqueued. - Removed Help Center generation ActionCable broadcasts completely. - Kept generation progress in Redis as the backend source of truth. - Kept Help Center generation out of the onboarding hot path; the existing onboarding controller does not start generation yet. **How to test** 1. Start Help Center generation for an account. 2. Fetch the onboarding generation status endpoint and verify it returns the generation id, Redis state, and article/category counts. 3. Reload the onboarding UI or client state and fetch again to confirm progress can be recovered without relying on websocket events. 4. Verify skipped/completed generation states are reflected from Redis. ## Related PRs - https://github.com/chatwoot/chatwoot/pull/14569 - https://github.com/chatwoot/chatwoot/pull/14568 - https://github.com/chatwoot/chatwoot/pull/14567 - https://github.com/chatwoot/chatwoot/pull/14619 - https://github.com/chatwoot/chatwoot/pull/14565 (Primary onboarding PR) |
||
|
|
f93f2067b6 |
fix(whatsapp): Drop obsolete WABA scope check broken by Meta embedded signup (#14697)
## Description Fixes WhatsApp embedded signup failing with "No WABA scope found in token." Meta recently changed which scopes embedded-signup tokens carry (whatsapp_business_manage_events instead of whatsapp_business_management), which tripped a brittle scope-string check. That check was redundant anyway — PhoneInfoService already verifies the token's access to the specific WABA by calling its /phone_numbers endpoint right before it. This removes the obsolete TokenValidationService and relies on the functional check. ## 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: Muhsin Keloth <muhsinkeramam@gmail.com> |
||
|
Shivam MishraandGitHub
|
3dfb5061e1 |
refactor: route captain custom tool requests through SafeFetch (#14620)
Captain custom tools previously used their own hand-rolled `Net::HTTP` request code. This moves them onto `SafeFetch`, the same shared HTTP-fetching helper already used by webhooks, uploads, avatar imports, and the Captain page crawler. Behavior for normal tools is unchanged — they just now share one consistent path for host resolution, timeouts, response size limits, and redirect handling. **What changed** - `HttpTool#execute_http_request` now delegates to `SafeFetch.fetch` instead of building `Net::HTTP` requests by hand. Auth headers, basic auth, metadata headers, JSON content-type, and the 1 MB response cap all map onto `SafeFetch` options. - Removed ~80 lines of bespoke request/validation plumbing from `HttpTool`. - The custom tools `test` endpoint now reads the response body string directly (the executor returns the body rather than a response object). **How to test** 1. Enable `custom_tools` (or `captain_integration_v2`) for an account. 2. Create a Captain custom tool pointing at a public HTTPS endpoint (e.g. a test API). 3. Use the **Test** button in the tool form — you should get a success result. 4. Run the tool from a Captain conversation and confirm the response is returned/templated as before. **Gotchas** - **Local dev:** `SafeFetch` blocks requests to private/loopback addresses by default. If you're testing a custom tool against a service on `localhost` or a private IP during development, set `SAFE_FETCH_ALLOW_PRIVATE_NETWORK=true` or the request will be rejected. (This matches how the rest of `SafeFetch` already behaves locally.) - **Test endpoint status field:** on success the `test` response now reports `status: 200` rather than the exact 2xx code (201/204/etc.), because `SafeFetch` signals success-vs-failure rather than exposing the raw response. The UI only checks the 2xx range, so this is invisible there — but worth knowing if anything consumes the API directly. - **Non-2xx responses** still surface as an error (same as before), now via `SafeFetch::HttpError`. |
||
|
|
72a59e4795 |
fix: update oauth dependencies (#14691)
Updates the locked OAuth dependencies to patched versions so bundle audit no longer reports the current OAuth advisories. What changed - Updated `oauth` from `1.1.0` to `1.1.6` for `GHSA-prq8-7wvh-44qh`. - Updated `oauth2` from `2.0.9` to `2.0.22` for `GHSA-pp92-crg2-gfv9`. - Accepted Bundler's required transitive lockfile updates for the patched OAuth gems. How to test 1. Run `bundle exec bundle audit update && bundle exec bundle audit check -v` and confirm no vulnerabilities are reported. 2. Smoke test OAuth-based authentication and email integration flows. Co-authored-by: Shivam Mishra <scm.mymail@gmail.com> |
||
|
Sivin VargheseandGitHub
|
cabe9bc733 | fix: populate general settings form on hard reload (#14685) | ||
|
|
33f7550525 |
fix(whatsapp): restrict OGG voice recording to WhatsApp Cloud inboxes (#14692)
Recording and sending an audio message from a **Twilio WhatsApp** inbox
failed silently — Twilio rejected the media with delivery error `63019`
("Media failed to download") and the voice note never reached the
customer. This restores audio sending for Twilio WhatsApp (and
360dialog) inboxes.
Closes Regression from #14606
## How to reproduce
1. Open a conversation in a **Twilio WhatsApp** inbox.
2. Record a voice message in the reply box and send it.
3. Before this fix: the message fails to deliver and a
`Webhooks::TwilioDeliveryStatusJob` is enqueued with `ErrorCode: 63019`,
`ErrorMessage: "Media failed to download"`.
4. After this fix: the audio is recorded as MP3 and delivers normally.
## What changed
PR #14606 added WhatsApp **Cloud** voice notes, which require OGG/Opus.
It changed `audioRecordFormat` in `ReplyBox.vue` to return OGG for
`isAWhatsAppChannel` — but that getter is also `true` for Twilio
WhatsApp inboxes. The OGG handling (content-type normalization + the
`voice: true` flag) lives only in `WhatsappCloudService`, so Twilio
could not download/process the remuxed OGG file.
This change scopes OGG to `isAWhatsAppCloudChannel`. Twilio WhatsApp,
360dialog, and Telegram fall back to MP3 exactly as they did before the
PR.
🤖 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>
|
||
|
Sivin VargheseandGitHub
|
59d869d1ed | feat: Ability to resize table column width (#14611) | ||
|
|
8a3b129292 |
fix: Disable re-oauth flow for manual whatsapp (#13599)
Restrict the WhatsApp reauthorization flag to channels whose
provider_config source is 'embedded_signup'. Previously the view exposed
resource.channel.reauthorization_required? for all WhatsApp channels;
now it only returns true when (provider_config || {}).to_h['source'] ==
'embedded_signup' && resource.channel.reauthorization_required?. This
prevents showing reauthorization prompts for manual/API-key flows
(non-OAuth) and safely handles nil provider_config.
# 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 #13553
## 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
- [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
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
|
||
|
|
af1dfc21f6 |
fix: include account data in webhook payloads (#12445)
Conversation and inbox webhook payloads now include the account object
(`{ id, name }`) so integrations can reliably identify the account
without depending on nested message data.
## Closes
Closes #11753
Closes #12442
## Why
Message, contact, and contact inbox webhook payloads already expose
`account`. Conversation and inbox webhook payloads were outliers, which
forced webhook consumers to infer account context from nested messages
or other fields that may not always be present.
## What changed
- Adds `account: { id, name }` to conversation webhook payloads.
- Adds webhook-specific inbox payload data with `account: { id, name }`
for inbox created/updated events.
- Keeps non-webhook conversation and inbox push payload behavior
unchanged.
## How to test
- Configure an account webhook for `conversation_created`, trigger a new
conversation, and confirm the webhook payload includes `account.id` and
`account.name`.
- Configure an account webhook for `inbox_created`, create a new inbox,
and confirm the webhook payload includes `account.id` and
`account.name`.
- Configure a webhook agent bot and update a conversation status, then
confirm the bot webhook payload includes the same account object.
---------
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
|
||
|
|
d1c482cb64 |
fix(email): strip null bytes from inbound mailbox messages (#14546)
Inbound emails containing null bytes could fail while Chatwoot persisted the incoming message, causing IMAP sync to drop and repeatedly retry the same malformed email. This strips null bytes at the inbound mailbox message persistence boundary so the rest of the email can be saved normally. Fixes https://linear.app/chatwoot/issue/CW-7165/argumenterror-string-contains-null-byte-argumenterror Sentry: https://chatwoot-p3.sentry.io/issues/7405946944/ ## Test - [x] added specs - [x] manually tested the logic on prod for the inbox(email) which was throwing the error ## What changed - Sanitizes null bytes only while building attributes for inbound mailbox message persistence. - Uses the sanitized source ID for both duplicate lookup and message creation. - Adds regression coverage for the mailbox message creation path. --------- Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> Co-authored-by: Sony Mathew <sony@chatwoot.com> |
||
|
|
d8656edc61 |
fix(facebook): Stop force tagging Messenger replies with MESSAGE_TAG/ACCOUNT_UPDATE (#14329)
Outbound Facebook Messenger replies were always sent with `messaging_type: MESSAGE_TAG` and a `tag` of either `HUMAN_AGENT` or `ACCOUNT_UPDATE` (fallback). `ACCOUNT_UPDATE` is reserved by Meta policy for non-recurring account notifications (password resets, suspicious activity, account-status changes), so general agent replies were getting rejected by Facebook with "Invalid parameter" and risked page-level penalties. After this fix, Facebook treats default replies as standard `RESPONSE` messages within the 24-hour window, and only attaches `HUMAN_AGENT` tagging when the operator opts in via `ENABLE_MESSENGER_CHANNEL_HUMAN_AGENT`. ## Closes <!-- Add the relevant issue link, e.g. Closes #1234 --> ## How to reproduce 1. Connect a Facebook page inbox. 2. Leave `ENABLE_MESSENGER_CHANNEL_HUMAN_AGENT` disabled (default). 3. From the dashboard, reply to an active Messenger conversation with a regular/promotional message. 4. Before this PR: the request to Graph API includes `messaging_type=MESSAGE_TAG&tag=ACCOUNT_UPDATE`. Facebook returns "Invalid parameter" for content that does not match the `ACCOUNT_UPDATE` use case, and the message is marked failed in Chatwoot. 5. After this PR: the request omits `messaging_type` and `tag`, so Facebook treats it as a standard `RESPONSE` and accepts it within the 24-hour customer service window. ## What changed - `app/services/facebook/send_on_facebook_service.rb` now mirrors the Instagram service pattern: text and attachment params are built without `messaging_type`/`tag` by default, and a shared `merge_human_agent_tag` helper attaches `MESSAGE_TAG`/`HUMAN_AGENT` only when `ENABLE_MESSENGER_CHANNEL_HUMAN_AGENT` is enabled. - Removed the unused `sent_first_outgoing_message_after_24_hours?` helper (dead code with no callers). - Updated `spec/services/facebook/send_on_facebook_service_spec.rb`: dropped `ACCOUNT_UPDATE` expectations, added a spec asserting no `messaging_type`/`tag` is sent by default, and tightened the HUMAN_AGENT spec to verify both `messaging_type` and `tag`. ## Operator note Operators who were relying on the prior `ACCOUNT_UPDATE` fallback to bypass the 24-hour window were already in violation of Meta policy and likely seeing send failures. They should enable `ENABLE_MESSENGER_CHANNEL_HUMAN_AGENT` (and request the Human Agent permission from Meta) for the 7-day extended window --------- Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> |
||
|
|
e919a2cef5 |
feat: add contact filter for conversations (#14629)
# Pull Request Template ## Description Adds a Contact condition to the conversation advanced filter so agents can search for an existing contact and filter conversations by `conversations.contact_id`. Fixes [CW-7239](https://linear.app/chatwoot/issue/CW-7239/contact-filter-for-conversations) ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality not to work as expected) - [ ] This change requires a documentation update ## How Has This Been Tested? - `eval "$(rbenv init -)" && bundle exec rspec spec/services/conversations/filter_service_spec.rb` - `pnpm exec vitest --no-watch --no-cache --no-coverage --logHeapUsage app/javascript/dashboard/components-next/filter/helper/filterHelper.spec.js app/javascript/dashboard/store/modules/conversations/helpers/specs/filterHelpers.spec.js app/javascript/dashboard/helper/specs/customViewsHelper.spec.js app/javascript/dashboard/helper/specs/filterQueryGenerator.spec.js` - `pnpm eslint` - `eval "$(rbenv init -)" && bundle exec rubocop spec/services/conversations/filter_service_spec.rb` ## Checklist: - [x] My code follows the style guidelines of this project - [x] I have performed a self-review of my code - [x] I have commented on my code, particularly in hard-to-understand areas - [ ] I have made corresponding changes to the documentation - [x] My changes generate no new warnings - [x] I have added tests that prove my fix is effective or that my feature works - [x] New and existing unit tests pass locally with my changes - [ ] Any dependent changes have been merged and published in downstream modules --------- Co-authored-by: iamsivin <iamsivin@gmail.com> Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> |