7f0d5caca41b32d36d53dcf2260d1ce8d91efb10
6161
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
7f0d5caca4 |
chore: Update translations (#14276)
Co-authored-by: Sojan Jose <sojan@pepalo.com> |
||
|
|
1d2f3e86dd |
feat(companies): track company last activity (#14435)
Tracks company recency from linked contact activity so the Companies list and detail page can show/sort by real customer engagement instead of generic record updates. ## Closes None. ## Why Company recency should reflect activity from people associated with the company. This keeps the signal tied to persisted contact activity, without treating passive online presence or widget heartbeat pings as company activity. ## What Changed - Adds a company helper to record `last_activity_at` from linked contact activity. - Rolls up `Contact#last_activity_at` changes to the associated company. - Initializes company activity when an already-active contact is associated with a company, including the business-email auto-association path. - Throttles company activity rollups to once every 5 minutes per company to avoid unnecessary writes during active conversations. - Treats company activity as monotonic: unlinking, moving, or deleting contacts does not move a company's activity timestamp backwards. - Leaves historical backfill, online presence tracking, widget visit tracking, and richer activity attribution out of scope. ## How to Test 1. Open an account with Companies enabled and visit the Companies list. 2. Trigger activity for a contact that belongs to a company, for example by receiving or sending a message in that contact's conversation. 3. Confirm the linked company shows a recent activity timestamp in the Companies list/detail page after the contact activity updates. 4. Associate an already-active contact with a company and confirm the company receives that contact's existing activity timestamp. 5. Confirm repeated contact activity within a short window does not continuously rewrite the company timestamp. --------- Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
|
3253e863ed |
fix: validate OpenAI hook credentials (#14068)
# Pull Request Template ## Description - Validates openai key while configuring hooks - added backfill logic Fixes # (issue) ## 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 <img width="1710" height="1234" alt="CleanShot 2026-04-15 at 16 15 02@2x" src="https://github.com/user-attachments/assets/3d319fe0-19f9-4fd0-9308-74987daac2e1" /> <img width="2884" height="1136" alt="CleanShot 2026-05-11 at 19 22 53@2x" src="https://github.com/user-attachments/assets/5eae8650-985b-4c4a-af42-35f7175ff52d" /> ## 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: Vishnu Narayanan <iamwishnu@gmail.com> |
||
|
Aakash BakhleandGitHub
|
059d840272 |
feat: Refresh llm settings when superadmin configs change [AI-151] (#14388)
# Pull Request Template ## Description fixes: https://linear.app/chatwoot/issue/AI-151/captains-super-admin-config-dont-get-applied-into-rails-without ## 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. specs and locally To test locally: go to super admin -> settings -> captain -> Change endpoint to something incorrect go to local app -> captain -> playground -> try chatting (should fail due to incorrect endpoint) now in super admin captain settings, set the correct endpoint then chat in playground. Now it should work. Current develop code doesn't reflect the changes in installation config for captain instantly, needs a server restart. ## 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 |
||
|
|
b8deb89613 |
fix: make SAML callback session independent (#14467)
This PR makes SAML login independent of Rails session cookies ## Problem The normal SAML login flow should be straightforward: - User opens Chatwoot. - Chatwoot creates `_chatwoot_session`. - User starts SSO. - Chatwoot redirects the browser to the SAML provider. - The provider authenticates the user. - The provider sends the browser back to Chatwoot's ACS URL. - Chatwoot reads the SAML response, finds or creates the user, and logs them in. The fragile step is the ACS callback. Most SSO flows return to the app through browser redirects where cookies usually pass through as expected. **ADFS commonly returns the SAML response with a cross-site POST**. With Chatwoot's session cookie using `SameSite=Lax`, browsers may not send `_chatwoot_session` on that POST. SAML validation itself does not need the old Rails session cookie. The problem was our callback handoff after validation. DeviseTokenAuth stores the verified OmniAuth payload in Rails session, then redirects to a second callback route. If the browser does not preserve that session, Chatwoot has already received a valid SAML response but can no longer finish login. ## Solution This PR removes the session-backed handoff for SAML only: - The SAML callback completes login in the same request where OmniAuth validates the SAML response. - Chatwoot reads the verified auth payload directly from `request.env['omniauth.auth']`. - Account context and RelayState come from callback params or OmniAuth env data, not Rails session. - Other OmniAuth providers continue using the existing DeviseTokenAuth flow. - Mobile SAML still works when the IdP returns `RelayState=mobile`; the callback redirects to the mobile deep link with the generated SSO token. The previous SAML override used `303 See Other` to avoid replaying the SAML POST into the second callback route. This change keeps that intent, but removes the second callback route for SAML entirely. ## Screen recording ### SP Initiated https://github.com/user-attachments/assets/b0735e93-3864-4cc3-b6fc-419fff4b549e ### IDP Initiated https://github.com/user-attachments/assets/3ded0246-933c-4c85-9b7c-fa15fdc34883 ## Testing Manual validation: - Complete a SAML login. - In the browser network trace, find the IdP POST to `/omniauth/saml/callback?account_id=<account-id>`. - Confirm it redirects directly to `/app/login?...sso_auth_token=...` for web login. - For mobile, confirm `RelayState=mobile` redirects to the configured mobile deep link. - Confirm there is no intermediate `/auth/saml/callback` request. Testing with mocksaml.com: - Configure Chatwoot with a public `FRONTEND_URL`. - Set the mocksaml ACS URL to: ```text https://<chatwoot-host>/omniauth/saml/callback?account_id=<account-id> ``` - Set the mocksaml audience/SP entity ID to the value shown in Chatwoot SAML settings, usually: ```text https://<chatwoot-host>/saml/sp/<account-id> ``` - Use an email returned by mocksaml that exists in the SAML-enabled account. - Start login from Chatwoot's SSO login page. - Confirm the callback redirects directly to the app login URL with an SSO token. --------- Co-authored-by: Sojan Jose <sojan@pepalo.com> |
||
|
Shivam MishraandGitHub
|
ef27e571f7 |
feat: enable quoted reply for everyone (#14469)
Quoted email replies is now available to every account by default.
Previously this was gated behind the `quoted_email_reply` account-level
feature flag, so accounts needed it toggled on (via Super Admin) before
agents saw the toggle in the reply box.
## How to test
1. Open any conversation on an email inbox.
2. Confirm the **Quote previous email** toggle is visible in the reply
box (and is **not** visible on private notes or non-email channels).
3. Toggle it on, type a reply, and send — the outbound email should
include the quoted prior email below your message.
4. Toggle it off and send another reply — the quoted block should not
appear.
5. The toggle preference should persist per channel type (UI setting),
as before.
6. Verify the toggle works on a brand new account with no feature flags
flipped on (previously it would have been hidden).
## What changed
- Removed all `isFeatureEnabledonAccount(..., QUOTED_EMAIL_REPLY)` gates
from `ReplyBox.vue`, so the toggle and quoted-content behavior are
unconditional on email channels.
- Removed the `QUOTED_EMAIL_REPLY` constant from
`dashboard/featureFlags.js`.
- Marked the flag as `deprecated: true` in `config/features.yml` (kept
the entry in place to preserve FlagShihTzu bit positions on existing
accounts; `deprecated: true` hides it from the Super Admin UI).
- Dropped the now-unnecessary
`account.enable_features('quoted_email_reply')` setup from the message
builder spec.
|
||
|
|
1528fcde0c |
fix: missing widget es translations (#14375)
# Pull Request Template ## Description There were English strings in the Spanish i18n file for the widget. This PR translates them. ## 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? ## 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 - [ ] 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: Sojan Jose <sojan@pepalo.com> |
||
|
|
5f6bd951b9 |
fix: portals#create returns 500 when custom_domain is omitted (#14400)
## Description
`POST /api/v1/accounts/:account_id/portals` returns a generic 500
(`{"status":500,"error":"Internal Server Error"}`) whenever the request
body omits `custom_domain`. Root cause: `parsed_custom_domain` calls
`URI.parse(@portal.custom_domain)` and `URI.parse(nil)` raises
`URI::InvalidURIError`. Existing callers either had to know to pass
`"custom_domain": ""` as a workaround or hit a 500 with no useful
diagnostic.
This PR guards `parsed_custom_domain` against blank values so the
existing fall-through (`else @portal.custom_domain`) applies —
equivalent to passing an empty string.
It also moves the `process_attached_logo` guard from the helper into the
`create` call site so `create` mirrors `update` (`process_attached_logo
if params[:blob_id].present?`) and avoids an unnecessary signed-blob
lookup on every create that doesn't include a logo.
Fixes #14397
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
Two new request specs in
`spec/controllers/api/v1/accounts/portals_controller_spec.rb` covering
the regression:
- `creates portal when custom_domain is omitted from request body` — the
previously-broken case, now returns 200.
- `creates portal when custom_domain is blank` — verifies the existing
workaround (`"custom_domain": ""`) still works after the change.
Manually verified against `chatwoot/chatwoot:latest` Docker image before
the fix (500) and against this branch (200) using the curl repro from
the issue.
```bash
curl -X POST "https://<host>/api/v1/accounts/<account_id>/portals" \
-H "Content-Type: application/json" \
-H "api_access_token: <token>" \
-d '{"name":"Test Portal","slug":"test-portal","color":"#3b82f6"}'
```
Before: `{"status":500,"error":"Internal Server Error"}`
After: `200 OK` with the portal payload.
## 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 (no doc
change needed — controller behaviour, fully backward-compatible)
- [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: Sojan Jose <sojan@pepalo.com>
|
||
|
|
cfc7699b7e |
chore(deps): bump net-imap from 0.4.20 to 0.4.24 (#14361)
Bumps [net-imap](https://github.com/ruby/net-imap) from 0.4.20 to 0.4.24. <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.4.24</h2> <blockquote> <p>[!IMPORTANT] <em>The <code>0.4.x</code> release branch will only receive critical security fixes, and will be unsupported when ruby 3.3 is EOL. Please upgrade to a newer version.</em></p> </blockquote> <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/666">ruby/net-imap#666</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 injection vulnerabilities have been fixed: <a href="https://redirect.github.com/ruby/net-imap/pull/663">ruby/net-imap#663</a> fixes CRLF/command/argument injection via Symbol arguments (GHSA-75xq-5h9v-w6px). <a href="https://redirect.github.com/ruby/net-imap/pull/663">ruby/net-imap#663</a> fixes CRLF/command/argument injection via the <code>attr</code> argument to <code>#store</code>/<code>#uid_store</code> (GHSA-hm49-wcqc-g2xg) <a href="https://redirect.github.com/ruby/net-imap/pull/663">ruby/net-imap#663</a> fixes CRLF/command/argument injection via the <code>storage_limit</code> argument to <code>#setquota</code> (GHSA-hm49-wcqc-g2xg). <a href="https://redirect.github.com/ruby/net-imap/pull/663">ruby/net-imap#663</a> fixes CRLF/command injection via <code>RawData</code> (GHSA-hm49-wcqc-g2xg):</p> <ul> <li><code>#search</code> and <code>#uid_search</code> send <code>criteria</code> as raw data, when it is a String</li> <li><code>#fetch</code> and <code>#uid_fetch</code> send <code>attr</code> as raw data, when it is a String. When <code>attr</code> is an Array, its String members are sent as raw data.</li> </ul> </blockquote> <blockquote> <p>[!CAUTION] <code>RawData</code> does not defend against <em>other</em> forms of argument injection! It is an intentionally low-level API.</p> </blockquote> <blockquote> <p>[!NOTE] Two denial of service vulnerabilities have been addressed. These are generally only relevant when connecting to an <em>untrusted hostile server</em> (or without TLS).</p> <p><a href="https://redirect.github.com/ruby/net-imap/pull/651">ruby/net-imap#651</a> fixes quadratic time complexity when reading large responses containing many string literals (GHSA-q2mw-fvj9-vvcw). <a href="https://redirect.github.com/ruby/net-imap/pull/655">ruby/net-imap#655</a> adds a configurable <code>max_iterations</code> count for <code>SCRAM-*</code> authentication (GHSA-87pf-fpwv-p7m7).</p> <p>The default <code>ScramAuthenticator#max_iterations</code> is <code>2**31 - 1</code> (max 32-bit signed int), which was already OpenSSL's maximum value. <em>It provides no protection</em> against hostile servers unless it is explicitly set to a lower value by the user.</p> </blockquote> <h3>Added</h3> <ul> <li>🔒 Add <code>ScramAuthenticator#max_iterations</code> (backports <a href="https://redirect.github.com/ruby/net-imap/issues/654">#654</a>) in <a href="https://redirect.github.com/ruby/net-imap/pull/655">ruby/net-imap#655</a>, reported by <a href="https://github.com/Masamuneee"><code>@Masamuneee</code></a></li> </ul> <h3>Fixed</h3> <ul> <li>🔒 Fix STARTTLS stripping vulnerability (backports <a href="https://redirect.github.com/ruby/net-imap/issues/664">#664</a>) in <a href="https://redirect.github.com/ruby/net-imap/pull/666">ruby/net-imap#666</a>, reported by <a href="https://github.com/Masamuneee"><code>@Masamuneee</code></a></li> <li>🔒 Fix CRLF injection vulnerabilities (backports <a href="https://redirect.github.com/ruby/net-imap/issues/657">#657</a>, <a href="https://redirect.github.com/ruby/net-imap/issues/658">#658</a>, <a href="https://redirect.github.com/ruby/net-imap/issues/659">#659</a>, <a href="https://redirect.github.com/ruby/net-imap/issues/660">#660</a>, <a href="https://redirect.github.com/ruby/net-imap/issues/636">#636</a>, <a href="https://redirect.github.com/ruby/net-imap/issues/661">#661</a>) in <a href="https://redirect.github.com/ruby/net-imap/pull/663">ruby/net-imap#663</a>, reported by <a href="https://github.com/manunio"><code>@manunio</code></a></li> <li>⚡ Much faster ResponseReader performance (backports <a href="https://redirect.github.com/ruby/net-imap/issues/642">#642</a>) in <a href="https://redirect.github.com/ruby/net-imap/pull/651">ruby/net-imap#651</a>, reported by <a href="https://github.com/Masamuneee"><code>@Masamuneee</code></a></li> <li>🐛 Wait to continue RawData literals (backports <a href="https://redirect.github.com/ruby/net-imap/issues/660">#660</a>) by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/663">ruby/net-imap#663</a></li> </ul> <h3>Other Changes</h3> <ul> <li>♻️ Improve internal literal sending (partially backports <a href="https://redirect.github.com/ruby/net-imap/issues/358">#358</a>, <a href="https://redirect.github.com/ruby/net-imap/issues/616">#616</a>, <a href="https://redirect.github.com/ruby/net-imap/issues/649">#649</a>) by <a href="https://github.com/nevans"><code>@nevans</code></a> in <a href="https://redirect.github.com/ruby/net-imap/pull/653">ruby/net-imap#653</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/ruby/net-imap/compare/v0.4.23...v0.4.24">https://github.com/ruby/net-imap/compare/v0.4.23...v0.4.24</a></p> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/ruby/net-imap/commit/24a4e770b43230286a05aa2a9746cdbb3eb8485e"><code>24a4e77</code></a> 🔀 Merge pull request <a href="https://redirect.github.com/ruby/net-imap/issues/666">#666</a> from ruby/backport/v0.4/STARTTLS-stripping</li> <li><a href="https://github.com/ruby/net-imap/commit/63f53ffdefa3be6c779090bdbe6b7257b632b36c"><code>63f53ff</code></a> 🔖 Bump version to 0.4.24</li> <li><a href="https://github.com/ruby/net-imap/commit/038ae35d5ecbb2b85f77f4fa35e46604154dc8c4"><code>038ae35</code></a> 🍒 pick 24d5c773d: 🔒🥅 Handle tagged "OK" to incomplete command [backport <a href="https://redirect.github.com/ruby/net-imap/issues/664">#664</a>]</li> <li><a href="https://github.com/ruby/net-imap/commit/705aa59faa28083f496dce50c0ee1eccca287506"><code>705aa59</code></a> 🍒 pick 62eea6ffe: 🔒🥅 Ensure STARTTLS tagged response was handled [backport <a href="https://redirect.github.com/ruby/net-imap/issues/664">#664</a>]</li> <li><a href="https://github.com/ruby/net-imap/commit/c9a6f28f8794cb991613d378b3920e5719062e29"><code>c9a6f28</code></a> 🍒 pick 46636cae8: ❌🔒 Add failing test for STARTTLS stripping [backport <a href="https://redirect.github.com/ruby/net-imap/issues/664">#664</a>]</li> <li><a href="https://github.com/ruby/net-imap/commit/aec06996eb87a7e1bbcef1f9f8926e8add2b8c71"><code>aec0699</code></a> 🔀 Merge pull request <a href="https://redirect.github.com/ruby/net-imap/issues/663">#663</a> from ruby/backport/v0.4/raw_data-warnings</li> <li><a href="https://github.com/ruby/net-imap/commit/fd245ddd1e220143c9b7c7861700590fbe9d35ef"><code>fd245dd</code></a> 🍒 pick be32e712e: 📚 Improve documentation of RawData arguments [backports <a href="https://redirect.github.com/ruby/net-imap/issues/661">#661</a>]</li> <li><a href="https://github.com/ruby/net-imap/commit/6dd110bfda6b47da9c294791ef16911bd1f49033"><code>6dd110b</code></a> 🍒 pick 47c72186d: 🐛 Validate RawData and wait to continue literals [backports...</li> <li><a href="https://github.com/ruby/net-imap/commit/4e93149e65f6f1a6225ef770d0cd129acb5d63a9"><code>4e93149</code></a> 🔀 Merge branch 'backport/v0.4/QUOTA-argument-validation' into backport/v0.4/s...</li> <li><a href="https://github.com/ruby/net-imap/commit/d2b23602e8617311900a9b3acf0c8d708b70bad4"><code>d2b2360</code></a> 🍒 pick 0ec4fd351: 🥅 Validate <code>#setquota</code> storage limit argument [backports <a href="https://redirect.github.com/ruby/net-imap/issues/659">#659</a>]</li> <li>Additional commits viewable in <a href="https://github.com/ruby/net-imap/compare/v0.4.20...v0.4.24">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: Pranav <pranav@chatwoot.com> |
||
|
|
dc332dd93e |
feat: add attachments endpoint for contact media view (#14391)
# Pull Request Template ## Description This PR adds an endpoint to fetch all attachments shared with or by a contact across all of their conversations. Results are scoped based on the access: * Admins can access all attachments * Agents can access attachments only from inboxes they belong to * Custom role agents are further filtered based on their conversation permissions Each attachment payload includes `conversation_id`, allowing the UI to deep-link back to the source conversation. Added `GET /api/v1/accounts/:account_id/contacts/:contact_id/attachments` under the existing contacts scope. Fixes https://linear.app/chatwoot/issue/CW-7021/add-media-view-to-the-contact-details-page ## 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 - [ ] 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> |
||
|
|
13f66e3a88 |
fix: incorrect scope across controllers (#14459)
Co-authored-by: Sojan Jose <sojan@pepalo.com> |
||
|
|
fbcb89e955 |
fix(swagger): prevent path traversal in docs controller (#14458)
This hardens the development/test Swagger docs endpoint by ensuring requested files are resolved only within the `swagger/` directory. This did not affect production security because the Swagger controller only renders files in development or test environments; production already returns `404`. The change still closes the scanner finding and prevents future automated reports from flagging the development-only path. ## Closes Addresses: GHSA-xhp7-ggjq-p2rg ## How to reproduce 1. Start Chatwoot locally in development. 2. Visit `/swagger/%2Fetc%2Fpasswd`. 3. Before this change, the endpoint could render files outside the Swagger directory in development/test. ## What changed - Resolve Swagger file requests relative to `Rails.root/swagger`. - Return `404` when the resolved path is outside the Swagger directory or does not point to a file. - Strip leading slashes from derived request paths. - Add a request spec for the encoded absolute-path case. ## How to test 1. Start the app locally. 2. Visit `/swagger` and confirm the ReDoc page loads. 3. Visit `/swagger/swagger.json` and confirm the Swagger JSON loads. 4. Visit `/swagger/%2Fetc%2Fpasswd` and confirm it returns `404` with no file contents. Note: `bundle exec rspec spec/controllers/swagger_controller_spec.rb` was passing locally earlier during this fix. A final rerun before opening the PR was blocked because local Postgres on `localhost:5432` was not accepting connections. Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> |
||
|
Shivam MishraandGitHub
|
8712879681 |
test: Stabilize SafeFetch spec against constant-identity flake (#14454)
`spec/lib/safe_fetch_spec.rb` has been flaking intermittently under full-suite runs with errors like: ``` expected SafeFetch::FileTooLargeError, got #<SafeFetch::FileTooLargeError: exceeded 1048576 bytes> ``` The class name on both sides is identical — yet RSpec reports a mismatch. This PR replaces the constant-identity assertions in this spec with a name-based matcher so the comparison stops depending on the live Class object's identity. We have made a similar fix earlier, but that wasn't addressing the core of the issue in #14139. **How to reproduce:** The flake only surfaces under load. Running the spec in isolation almost always passes, here's a [run failing in CI](https://github.com/chatwoot/chatwoot/actions/runs/25852294516/job/75961520248?pr=14370) ## What's actually going on Three facts combine: 1. **Test env reloads classes.** `config/environments/test.rb` sets `cache_classes = false` so Zeitwerk reloads autoloadable code on demand. 2. **`lib/` is on the reloadable autoload tree.** `config/application.rb` adds `lib` to `eager_load_paths`, which (with `eager_load = false` in test) makes it lazily loaded by Zeitwerk's *main* (reloading) autoloader. `lib/safe_fetch/` lives under that umbrella. 3. **RSpec's `raise_error(Klass)` snapshots the Class object.** `raise_error` matcher captures `Klass` (a specific `Class` instance) when the matcher is built. At raise time it compares with `Module#===`, which is identity-based. When the executor between examples triggers `Rails.application.reloader.reload!`, Zeitwerk does `remove_const(:SafeFetch)` and re-installs an autoload trigger. The next access produces a **fresh** `Class` object for `SafeFetch::FileTooLargeError` — same name, different identity. The matcher's snapshot now points at the dead Class, and the live raise produces the new one. Identity fails, even though the error is semantically correct. This bites SafeFetch specifically because: - SafeFetch is a *namespace* with 7 nested error classes — one reload invalidates all of them. - The spec contains 14+ `raise_error(SafeFetch::Foo)` assertions — many chances to land in a reload window. - SafeFetch is exercised by request-driven code (webhook delivery, avatar fetch). Earlier specs in the suite warm up the reloader machinery, which then fires during this spec. Other custom-error specs don't visibly flake because their consumers `rescue ConstName => e` (dynamic class lookup at raise time, walks the ancestor chain via `Module#===` *at the moment of raise*, with no captured snapshot), rather than RSpec's snapshot-then-compare pattern. ## What this PR does Adds a small local helper to the spec that matches by class name string, not by Class identity: ```ruby def safe_fetch_error(name, message_pattern = nil) satisfy("raise SafeFetch::#{name}#{" matching #{message_pattern.inspect}" if message_pattern}") do |error| error.class.name == "SafeFetch::#{name}" && (message_pattern.nil? || message_pattern.match?(error.message)) end end ``` Every `raise_error(described_class::FooError)` becomes `raise_error(safe_fetch_error('FooError'))`. Class names are strings; string equality survives any number of reloads. The semantic assertion ("this raised the right kind of error") is preserved. This is the pattern CLAUDE.md already endorses for this codebase: > Specs in parallel/reloading environments: prefer comparing `error.class.name` over constant class equality when asserting raised errors. ## Why this approach (even though it's suboptimal) To be honest with reviewers: **this is a workaround, not a root-cause fix.** Future spec authors who use `raise_error(SafeFetch::Foo)` in other files will hit the same flake. The "real" fix removes the failure mode at the source rather than dodging it per-spec. Here's the menu of options we considered and the tradeoffs: ### Option A — Spec-side name matcher (this PR) - **What:** the helper above. - **Pro:** one-file change, zero blast radius beyond the spec. - **Pro:** matches CLAUDE.md's documented stance. - **Con:** every new spec touching reloadable error classes needs to remember this pattern. It's a discipline tax, not a structural fix. - **Verdict:** chosen for this PR. ### Option B — Pin SafeFetch outside Zeitwerk ```ruby # config/application.rb Rails.autoloaders.main.ignore( Rails.root.join('lib/safe_fetch.rb'), Rails.root.join('lib/safe_fetch'), ) require Rails.root.join('lib/safe_fetch') ``` - **Pro:** real root-cause fix. `SafeFetch::*` constants become process-lifetime stable. The spec helper becomes unnecessary, every assertion in any spec works correctly. - **Pro:** preserves the public API exactly. - **Con:** loses hot-reload for SafeFetch in dev (need server restart to see edits). - **Con:** modifies `application.rb`, which has cross-team review weight. - **Verdict:** rejected for scope reasons in this PR; a sensible follow-up. ### Option C — Move error classes to a non-reloadable location Define top-level error classes in `config/initializers/safe_fetch_errors.rb`. Initializers run once at boot, constants are never reloaded. - **Pro:** identity-stable errors, no spec helper needed. - **Con:** API change — `SafeFetch::FileTooLargeError` becomes `SafeFetchFileTooLargeError` (or similar). Every consumer's `rescue` clause has to update. - **Con:** namespace pollution at top-level. - **Verdict:** rejected. The constraint of touching initializers is what motivated the simpler PR. ### Option D — Vendor SafeFetch as a path gem Move `lib/safe_fetch/` → `vendor/gems/safe_fetch/` with a gemspec. Bundler `require`s gems once; Zeitwerk has zero involvement. - **Pro:** structurally the most correct fix. Same identity stability as Option B, no Zeitwerk plumbing required. - **Pro:** zero API change for consumers. - **Con:** larger refactor (6+ files moved, gemspec authored, Gemfile/Gemfile.lock updated). - **Con:** SafeFetch becomes harder to iterate on in dev (gem-style edit-then-restart loop). - **Verdict:** rejected for scope in this PR; the cleanest long-term home for a security primitive. ### Option E — Drop custom errors, return a `Result` Refactor SafeFetch to yield a result hash (`{ ok: true, ... }` / `{ ok: false, kind: :unsafe_url, ... }`) instead of raising for anticipated outcomes. Failure kinds become symbols, which are interned for the process lifetime. - **Pro:** eliminates the failure mode at its true root — there are no custom exception classes to reload, anywhere. - **Pro:** forces explicit, exhaustive handling at every call site — a feature for a security primitive. - **Pro:** spec assertions become data assertions (`expect(result).to match(ok: false, kind: :too_large)`), which are robust against any reload, any reordering. - **Con:** paradigm shift away from the exception-driven style used everywhere else in the codebase. - **Con:** every consumer rewrites their `rescue` block into pattern-matched handling. - **Verdict:** rejected for scope in this PR; the architecturally cleanest answer if we ever revisit SafeFetch's API. ## Why we're shipping A despite knowing B–E are better This flake has been chewing CI time intermittently and previously took a partial fix (#14139). We need it stable *now*. Options B–E are real refactors with broader review surface (`application.rb`, consumer code, or the lib's public contract). Option A: - Costs nothing — one helper, mechanical replacements. - Doesn't preclude any of B/C/D/E later. The helper goes away cleanly once a root-cause fix lands. - Aligns with the project's documented guidance for this scenario. When SafeFetch next gets a substantive change, that's the right moment to fold in B or D. Until then, the spec is stable and CI gets its time back. ## What changed - `spec/lib/safe_fetch_spec.rb`: added `safe_fetch_error(name, message_pattern = nil)` helper; converted all 14 `raise_error(described_class::FooError[, /regex/])` assertions to `raise_error(safe_fetch_error('FooError'[, /regex/]))`. |
||
|
|
ffbf40c720 |
fix: harden Active Storage direct uploads and proxy streaming (#14440)
Hardens Active Storage handling on Rails 7.1 by filtering internal direct-upload metadata keys and limiting proxy range requests, while keeping audio playback on redirect URLs so large recordings are not routed through the proxy limiter. Closes - CVE-2026-33173 - CVE-2026-33174 - CVE-2026-33658 Why Rails 7.1 does not currently have patched releases for these Active Storage advisories, and Chatwoot exposes Active Storage direct-upload endpoints and media URLs. This keeps the Rails dependency unchanged while adding small local mitigations until Rails can be upgraded to 7.2.3.1+. What changed - Filters `identified`, `analyzed`, and `composed` from direct-upload blob metadata. - Limits Active Storage proxy range requests to one range under 100 MB. - Uses redirect URLs for inline audio attachments so normal playback of large recordings avoids the proxy streaming path. - Adds scoped bundle-audit ignores for the locally mitigated Active Storage advisories and the remaining Rails advisories that are not reachable through current Chatwoot usage. How to test - Upload an attachment from the dashboard reply composer and confirm it sends successfully. - Upload an attachment from the website widget and confirm it appears in the conversation. - POST a direct-upload request with `blob.metadata.identified`, `blob.metadata.analyzed`, and `blob.metadata.composed`; confirm those keys are not persisted while custom metadata remains. - Play an audio/call-recording attachment and confirm the audio URL loads through Active Storage redirect rather than proxy. - Run `bundle exec bundle audit check -v`. --------- Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> |
||
|
|
dd7f5c27e5 |
perf: eliminate N+1 queries on inboxes#index (#14451)
The `inboxes#index` API endpoint was firing 3 queries per inbox while rendering the response — one each for the polymorphic channel, avatar attachment, and working hours. For accounts with many inboxes this turned a routine list call into a multi-second request — measured at 35 seconds on an account with 5,000 inboxes. Two root causes: 1. `policy_scope` was silently discarding the controller's `.includes(...)` chain because `InboxPolicy::Scope#resolve` returns a fresh `user.assigned_inboxes` relation, ignoring whatever scope is passed in. So the eager loading never actually applied. 2. `Inbox#weekly_schedule` called `working_hours.order(...).select(...)` which fires a new query per inbox even when the association is preloaded. The fix chains the eager loads and ordering after `policy_scope` so they apply to the relation the policy actually returns, adds `:portal` and `:working_hours` to the preload list, and refactors `weekly_schedule` to sort the preloaded collection in Ruby and build the hash directly. Result: queries drop from O(n) to a constant ~15 regardless of inbox count, and total request time drops 5–6× across every account size tested. Response payload is byte-identical. ## How to test 1. Open the agent dashboard for an account with a large number of inboxes (1000+). On a stock dev DB you can seed quickly with `Seeders::AccountSeeder` or by creating a few hundred `Channel::Api` inboxes via the rails console. 2. Hit any UI surface that lists inboxes (settings → inboxes, sidebar inbox list, agent assignment dropdowns). Should feel near-instant where it previously hung. 3. Confirm every inbox shows the same data as before — channel type, working hours, avatar, portal/help-center link. No fields should be missing or different. ## Benchmarks Real HTTP requests via curl against a dev Rails server (median of 5 timed trials after warmup; "Server total" is the time reported in Rails' `Completed 200 OK in <X>ms` log line). | Account | Channel mix | OLD | NEW | Speedup | |---|---|---|---|---| | 1000 inboxes | 3 types, no portals/avatars | 5.87 s | 0.96 s | **6.1×** | | 5000 inboxes | 3 types, no portals/avatars | 33.07 s | 6.93 s | **4.8×** | | 5000 inboxes | 10 types, 25% portals, 10% avatars | 35.04 s | 6.55 s | **5.4×** | Detailed breakdown for the realistic 5000-inbox case: | | OLD | NEW | Δ | |-----------------|-----------|----------|----------| | Server total | 35,042 ms | 6,550 ms | −81% | | Views | 32,034 ms | 6,452 ms | −80% | | ActiveRecord | 2,948 ms | 92 ms | −97% | | Allocations | 42.3 M | 11.3 M | −73% | | Queries | ~15,000 | 15 | −99.9% | ## What changed - `app/controllers/api/v1/accounts/inboxes_controller.rb` — chain `.includes(:channel, :portal, :working_hours, avatar_attachment: :blob).order_by_name` *after* `policy_scope(...)`. The previous code passed them into `policy_scope` but the policy resolver dropped the chain. - `app/models/concerns/out_of_offisable.rb` — `weekly_schedule` now sorts the preloaded `working_hours` collection in Ruby and constructs the result hashes inline, avoiding both the per-inbox query from `.order(...).select(...)` and the `as_json` reflection overhead. Co-authored-by: Shivam Mishra <scm.mymail@gmail.com> |
||
|
|
c2523c5d8b |
fix(editor): Refresh reply editor when reply window reopens in real-time (#14446)
On WhatsApp and any channel that disables the reply editor outside its messaging window (WhatsApp Cloud, Twilio WhatsApp, API channels with `agent_reply_time_window` set), when the window was already expired and a new inbound message arrived in real-time, the "messaging restricted" banner correctly hid but the editor itself stayed un-typeable until the agent refreshed the page. This made the dashboard look like it accepted replies even though typing did nothing. Fixes [CW-7087](https://linear.app/chatwoot/issue/CW-7087/reply-editor-stays-disabled-after-real-time-incoming-message-reopens) #### How to reproduce 1. Open a WhatsApp conversation whose last incoming message is older than 24h, so `can_reply` is `false` (banner shown, editor greyed out). 2. With the dashboard open on that conversation, have the customer send a fresh inbound message (or simulate one via the channel's webhook). 3. Before the fix: banner disappears, editor wrapper loses its disabled styling, but clicking into the editor and typing does nothing — refresh required. 4. After the fix: banner disappears and the editor accepts input immediately. Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> |
||
|
Shivam MishraandGitHub
|
05bda5f742 |
feat: don't let onboarding write domain (#14442)
Stop the onboarding flow from writing the user's company website into `accounts.domain`. That column is reserved for the inbound email domain used to construct reply-to addresses (`reply+<uuid>@<domain>`), and silently overloading it from onboarding was breaking email continuity for accounts whose domain MX didn't point at Chatwoot's inbound — customer replies were going to an unreachable address. The website value now lives in `custom_attributes.website`, which is what the rest of the app already treats as the "company website" field. |
||
|
|
379e28df1f |
fix: prevent bot metrics double-counting when handoff and resolution coexist [CW-6210] (#14032)
The bot metrics dashboard can show `handoff_rate + resolution_rate >
100%`. A single conversation can accumulate both
`conversation_bot_handoff` and `conversation_bot_resolved` events, and
the rate queries count them independently against a shared denominator.
## How it happens
```
Customer messages bot inbox
│
▼
┌──────────┐
│ pending │ (bot handling)
└────┬─────┘
│ bot can't help
▼
┌──────────┐
│ open │ (handed off → conversation_bot_handoff event created)
└────┬─────┘
│ agent clicks "Resolve" WITHOUT sending a message
▼
┌──────────┐
│ resolved │ conversation_resolved fires
└──────────┘
│
▼
create_bot_resolved_event guard checks:
✅ inbox.active_bot?
✅ no outgoing messages with sender_type: 'User' ← agent never messaged!
│
▼
conversation_bot_resolved event ALSO created ← BUG
│
▼
Same conversation counted in BOTH rates → sum exceeds 100%
```
## Why fix at the read path, not the write path
An earlier attempt added guards in the listener to make the two events
mutually exclusive per conversation — deleting `bot_resolved` when a
handoff fires, suppressing resolutions when a handoff exists. This was
rejected because conversations can be reopened across multiple cycles
(bot resolves on day 1, customer returns on day 5, bot hands off).
Deleting the day-1 resolution corrupts historical reports, and the async
event dispatcher makes listener-level guards vulnerable to race
conditions.
## What this PR does
Within a reporting window, if a conversation has both events, **handoff
wins** — the conversation is excluded from the resolution count. This is
applied via SQL subquery across all three read paths:
```
┌─────────────────────────┐
│ Reporting Events DB │
│ │
│ conv_bot_handoff: [A,B] │
│ conv_bot_resolved: [A,C]│
└────────┬────────────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
BotMetricsBuilder ReportHelper CountReportBuilder
(rate cards) (bot_summary) (timeseries charts)
│ │ │
▼ ▼ ▼
resolutions: resolutions: resolutions:
[A,C] minus [A,B] same logic same logic
= [C] only = [C] only = [C] only
Result: Conversation A → handoff only
Conversation B → handoff only
Conversation C → resolution only
```
For wide date ranges spanning multiple lifecycles, a conversation
bot-resolved in one cycle and handed off in a later cycle will only show
as a handoff. This is an acceptable tradeoff — the alternative (>100%
rates) is clearly worse, and narrow ranges handle this correctly since
the events fall into different windows. No reporting events are
modified, so historical data stays intact.
## Diagnostic tool
`rake bot_metrics:diagnose` — read-only task that prompts for account ID
and date range, shows a before/after rate comparison without modifying
data.
---------
Co-authored-by: aakashb95 <aakashbakhle@gmail.com>
Co-authored-by: Aakash Bakhle <48802744+aakashb95@users.noreply.github.com>
|
||
|
Aarav UniyalandGitHub
|
c6dceb0e07 | fix: contacts dropdown overlap (#14305) | ||
|
Sivin VargheseandGitHub
|
cd33cea69f |
chore: Update nl translation in widget (#14441)
|
||
|
|
71cc5168be |
feat(linear): Auto link Linear issues from private notes (#14405)
When an agent pastes a Linear issue URL into a private note on a
conversation, Chatwoot now links the issue to the conversation
automatically — no need to click "Link to Linear issue" first. The
standard activity message ("X linked Linear issue ABC-123") is posted
just like a manual link.
Fixes
[CW-7032](https://linear.app/chatwoot/issue/CW-7032/if-someone-post-a-linear-url-in-the-private-notes-automatically-link)
---------
Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com>
Co-authored-by: Sojan Jose <sojan@pepalo.com>
|
||
|
|
58fdd20625 |
test(voice): WhatsApp Cloud Calling specs [5] (#14357)
Backend test coverage for the WhatsApp Cloud Calling pipeline introduced in #14356. Stacked on top of that PR so the controller and service under test exist when CI runs. ## Closes - Replaces #14348 (which was based on the abandoned \`feature/pla-150\`) ## What's covered - \`spec/enterprise/controllers/api/v1/accounts/whatsapp_calls_controller_spec.rb\` (new, ~210 lines) - \`show / accept / reject / terminate / initiate / upload_recording\` happy paths - 422 paths: missing sdp_offer, missing recording, calling_disabled inbox, missing contact phone, ringing-state guards, AlreadyAccepted, NotRinging, CallFailed - 138006 (no permission) → throttled opt-in template send under conversation lock; idempotency on retry - \`upload_recording\` idempotency guard (\`already_uploaded\`) - \`spec/enterprise/services/whatsapp/call_service_spec.rb\` (new, ~135 lines) - State machine: ringing → in_progress → completed; ringing → failed (reject); ringing → no_answer (terminate) - Lock contention: concurrent terminate during accept doesn't corrupt the message/conversation broadcast - Provider failure paths surface as \`Voice::CallErrors::CallFailed\` (transport and business) - \`spec/models/channel/whatsapp_spec.rb\` — extends existing file with \`voice_enabled?\` matrix (provider × source × calling_enabled) ## Verification - 77/77 examples pass locally on this branch (controller + service + channel + incoming-call + permission-reply + open-ai message builder) - RuboCop clean ## Stack - Backend: #14356 (\`feat/whatsapp-call-meta-bridge\` — base of this PR) - FE: #14346 (\`feat/whatsapp-call-ui\`) --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
6c67eb9ba0 |
fix(notifications): Respect conversation access when notifying agents (#14412)
Agents with limited custom roles were receiving notifications (creation, assignment, mentions, new messages, SLA) for conversations they couldn't actually open. For example, an agent whose custom role only grants `conversation_unassigned_manage` was getting notified about conversations assigned to other agents. Notifications now go through the same `ConversationPolicy#show?` check that gates the conversation view itself, so an agent only gets notified for conversations they're permitted to see. Administrators and agents without custom roles are unaffected. --------- Co-authored-by: Sojan Jose <sojan@pepalo.com> Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> |
||
|
Sivin VargheseandGitHub
|
3df827c931 | chore: update Captain documents filter UI (#14429) | ||
|
|
de696a55cb |
feat(voice): add WhatsApp inbound call webhook pipeline [3] (#14315)
Adds the server-side flow that turns Meta WhatsApp Cloud Calling webhooks into Chatwoot Calls, conversations, voice_call message bubbles, and ActionCable broadcasts. Stacked on top of #14312 (PR-2 — provider methods); intentionally does not include the HTTP controller, routes, or frontend (those land in PR-4 and PR-9). ## Closes - Part of the WhatsApp Cloud Calling rollout. Linear: TBD ## What changed **Webhook routing** - `app/jobs/webhooks/whatsapp_events_job.rb` — append `prepend_mod_with('Webhooks::WhatsappEventsJob')` so EE can extend it without forking. - `enterprise/app/jobs/enterprise/webhooks/whatsapp_events_job.rb` (new) — overlay that prepends `handle_message_events` to intercept `field: 'calls'` payloads (route to `Whatsapp::IncomingCallService`) and `interactive.call_permission_reply` messages (route to `Whatsapp::CallPermissionReplyService`); falls through with `super` for regular messages. **Services** - `enterprise/app/services/whatsapp/incoming_call_service.rb` (new) — gated on `provider_config['calling_enabled']`; processes `connect` (creates inbound call via `Voice::InboundCallBuilder` or transitions an existing outbound call to `in_progress`) and `terminate` events; updates conversation `additional_attributes` and broadcasts `voice_call.incoming`/`voice_call.outbound_connected`/`voice_call.ended`. - `enterprise/app/services/whatsapp/call_permission_reply_service.rb` (new) — handles WhatsApp interactive `call_permission_reply` replies; clears the conversation's `call_permission_requested_at` flag and broadcasts `voice_call.permission_granted` so the agent UI can re-enable the call button. **Builder/model adjustments** - `enterprise/app/services/voice/inbound_call_builder.rb` — provider-agnostic; accepts `provider:` and `extra_meta:` kwargs, drops `account:` (now derived from `inbox.account` to keep the param count under rubocop's ceiling without disabling cops), uses digits-only `source_id` for WhatsApp ContactInbox (validation requires `^\d{1,15}\z`), skips Twilio-only `conference_sid` for non-Twilio providers. - `enterprise/app/services/voice/call_message_builder.rb` — adds `create!`/`update_status!` API and `CALL_TO_VOICE_STATUS` map; uses direct `Message.create!` (bypasses `Messages::MessageBuilder`'s incoming-on-non-Api-inbox guard, which would otherwise reject the system bubble); content is `'WhatsApp Call'` for WhatsApp and `'Voice Call'` for Twilio. Backwards-compatible `perform!` retained for the existing Twilio call sites. - `enterprise/app/models/call.rb` — adds `default_ice_servers` (driven by `VOICE_CALL_STUN_URLS` env), `direction_label` alias for the `inbound`/`outbound` strings the FE expects, and `ringing?`/`in_progress?`/`terminal?` predicates used throughout the pipeline. **Outgoing-channel guard** - `app/services/base/send_on_channel_service.rb` — extends `invalid_message?` to skip messages with `content_type == 'voice_call'`. Without this, agent-initiated outbound calls (PR-4) would deliver \"WhatsApp Call\" as a text message to the contact every time. **Twilio call-site update** - `enterprise/app/controllers/twilio/voice_controller.rb` — drops the now-redundant `account: current_account` kwarg from the `Voice::InboundCallBuilder.perform!` call. **Tests** - New: `spec/enterprise/services/whatsapp/incoming_call_service_spec.rb` (5 examples — calling-disabled, inbound connect, outbound connect, terminate completed, terminate no-answer, unknown event). - New: `spec/enterprise/services/whatsapp/call_permission_reply_service_spec.rb` (3 examples — accept, reject, calling-disabled). - Updated: `spec/enterprise/services/voice/inbound_call_builder_spec.rb` and `spec/enterprise/controllers/twilio/voice_controller_spec.rb` to drop the `account:` kwarg from call expectations. ## How to test In `rails console` against an account with a WhatsApp inbox where `provider_config['calling_enabled']` is true: ```ruby inbox = Inbox.find(<id>) params = { calls: [{ id: 'wacid_test', from: '15550001111', event: 'connect', session: { sdp: 'v=0...', sdp_type: 'offer' } }] } Whatsapp::IncomingCallService.new(inbox: inbox, params: params).perform # => Conversation + Call (status: 'ringing', provider: 'whatsapp') + voice_call message bubble # => ActionCable broadcasts `voice_call.incoming` to the assignee or account-wide # Then terminate it: Whatsapp::IncomingCallService.new(inbox: inbox, params: { calls: [{ id: 'wacid_test', event: 'terminate', duration: 0, terminate_reason: 'no_answer' }] } ).perform # => Call status flips to 'no_answer', message bubble updates, `voice_call.ended` broadcast fires ``` End-to-end browser flow (Meta → cable → UI) requires the controller from PR-4 and the frontend from PR-9. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
|
79a7423f9f |
chore(deps): bump nokogiri from 1.19.1 to 1.19.3 (#14410)
Bumps [nokogiri](https://github.com/sparklemotion/nokogiri) from 1.19.1 to 1.19.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/sparklemotion/nokogiri/releases">nokogiri's releases</a>.</em></p> <blockquote> <h2>v1.19.3 / 2026-04-27</h2> <h3>Fixed / Security</h3> <ul> <li>Address exponential regex backtracking in CSS selector tokenizer. See <a href="https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-c4rq-3m3g-8wgx">GHSA-c4rq-3m3g-8wgx</a> for more information.</li> <li>[CRuby] Address memory leak in <code>XSLT::Stylesheet#transform</code>. See <a href="https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-v2fc-qm4h-8hqv">GHSA-v2fc-qm4h-8hqv</a> for more information.</li> </ul> <!-- raw HTML omitted --> <pre><code>46b89e5d7b9e844c2ee360794240c6ea2a4e6fa0c5892a4ed487db621224b639 nokogiri-1.19.3-aarch64-linux-gnu.gem 8392dfdcd21be7a94dbbe9ccc138dea01b97b24cb2dc02a114ca98bfb1d9a0b7 nokogiri-1.19.3-aarch64-linux-musl.gem 3919d5ffc334ad778a4a9eb88fda7dcb8b1fb58c8a52ac640c6dcd2f038e774f nokogiri-1.19.3-arm-linux-gnu.gem 9ce1cb6346bb9c67b1550eb537aa183ead91e4b6eadb2f36ade02d8dd2a79fb6 nokogiri-1.19.3-arm-linux-musl.gem 71b9bd424b1b7abc18b05052a1a3cfd3627abdca62be280854cc411791357e42 nokogiri-1.19.3-arm64-darwin.gem 40ea6ebf5cf2005dae1dee26dd557d3afb41fb6de6c9764aca8cf06fdb841db1 nokogiri-1.19.3-java.gem 8bb7132cad356c879a1286eaabcb5e68326cb2490317984280fbc62f456d506a nokogiri-1.19.3-x64-mingw-ucrt.gem 77f3fba57d46c53ab31e62fc6c28f705109d1bf6264356c76f132b2be5728d4d nokogiri-1.19.3-x86_64-darwin.gem 2f5078620fe12e83669b5b17311b32532a8153d02eee7ad06948b926d6080976 nokogiri-1.19.3-x86_64-linux-gnu.gem 248c906d2166eca5efb56d52fdee5f9a1f51d69a72e2b64fdac647b4ce39ea3f nokogiri-1.19.3-x86_64-linux-musl.gem 78312cbac32a40c812780d9678221b79d51288eec00054c1a8d15f7ce05960e8 nokogiri-1.19.3.gem </code></pre> <h2>v1.19.2 / 2026-03-19</h2> <h3>Dependencies</h3> <ul> <li>[JRuby] Saxon-HE is updated to 12.7, from 9.6.0-4. Saxon-HE is a transitive dependency of nu.validator:jing, and this update addresses CVEs in Saxon-HE's own transitive dependencies JDOM and dom4j. We don't think this warrants a security release, however we're cutting a patch release to help users whose security scanners are flagging this. <a href="https://redirect.github.com/sparklemotion/nokogiri/issues/3611">#3611</a> <a href="https://github.com/flavorjones"><code>@flavorjones</code></a></li> </ul> <h3>SHA256 Checksums</h3> <pre><code>c34d5c8208025587554608e98fd88ab125b29c80f9352b821964e9a5d5cfbd19 nokogiri-1.19.2-aarch64-linux-gnu.gem 7f6b4b0202d507326841a4f790294bf75098aef50c7173443812e3ac5cb06515 nokogiri-1.19.2-aarch64-linux-musl.gem b7fa1139016f3dc850bda1260988f0d749934a939d04ef2da13bec060d7d5081 nokogiri-1.19.2-arm-linux-gnu.gem 61114d44f6742ff72194a1b3020967201e2eb982814778d130f6471c11f9828c nokogiri-1.19.2-arm-linux-musl.gem 58d8ea2e31a967b843b70487a44c14c8ba1866daa1b9da9be9dbdf1b43dee205 nokogiri-1.19.2-arm64-darwin.gem e9d67034bc80ca71043040beea8a91be5dc99b662daa38a2bfb361b7a2cc8717 nokogiri-1.19.2-java.gem 8ccf25eea3363a2c7b3f2e173a3400582c633cfead27f805df9a9c56d4852d1a nokogiri-1.19.2-x64-mingw-ucrt.gem 7d9af11fda72dfaa2961d8c4d5380ca0b51bc389dc5f8d4b859b9644f195e7a4 nokogiri-1.19.2-x86_64-darwin.gem fa8feca882b73e871a9845f3817a72e9734c8e974bdc4fbad6e4bc6e8076b94f nokogiri-1.19.2-x86_64-linux-gnu.gem 93128448e61a9383a30baef041bf1f5817e22f297a1d400521e90294445069a8 nokogiri-1.19.2-x86_64-linux-musl.gem 38fdd8b59db3d5ea9e7dfb14702e882b9bf819198d5bf976f17ebce12c481756 nokogiri-1.19.2.gem </code></pre> <p><strong>Full Changelog</strong>: <a href="https://github.com/sparklemotion/nokogiri/compare/v1.19.1...v1.19.2">https://github.com/sparklemotion/nokogiri/compare/v1.19.1...v1.19.2</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/sparklemotion/nokogiri/blob/main/CHANGELOG.md">nokogiri's changelog</a>.</em></p> <blockquote> <h2>v1.19.3 / 2026-04-27</h2> <h3>Fixed / Security</h3> <ul> <li>Address exponential regex backtracking in CSS selector tokenizer. See <a href="https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-c4rq-3m3g-8wgx">GHSA-c4rq-3m3g-8wgx</a> for more information.</li> <li>[CRuby] Address memory leak in <code>XSLT::Stylesheet#transform</code>. See <a href="https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-v2fc-qm4h-8hqv">GHSA-v2fc-qm4h-8hqv</a> for more information.</li> </ul> <h2>v1.19.2 / 2026-03-19</h2> <h3>Dependencies</h3> <ul> <li>[JRuby] Saxon-HE is updated to 12.7, from 9.6.0-4. Saxon-HE is a transitive dependency of nu.validator:jing, and this update addresses CVEs in Saxon-HE's own transitive dependencies JDOM and dom4j. We don't think this warrants a security release, however we're cutting a patch release to help users whose security scanners are flagging this. <a href="https://redirect.github.com/sparklemotion/nokogiri/issues/3611">#3611</a> <a href="https://github.com/flavorjones"><code>@flavorjones</code></a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/sparklemotion/nokogiri/commit/c139a3da0fe0cae7499a0bafa20f2875877c585b"><code>c139a3d</code></a> version bump to v1.19.3</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/7501a63b9f4246d12516e35b91fed8be34f854c0"><code>7501a63</code></a> fix: backtracking in CSS tokenizer rules (v1.19.x backport) (<a href="https://redirect.github.com/sparklemotion/nokogiri/issues/3627">#3627</a>)</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/03e7968a730a6544ab56a8d6c3e82dd630ad4339"><code>03e7968</code></a> test: skip CSS tokenizer benchmarks on JRuby</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/b984b7e47f622d1aa97d54c16d5cd596c3eb9538"><code>b984b7e</code></a> fix: ReDoS in CSS tokenizer ident rule</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/00926231e28d5a20e5b4873efba36099aea0d5c6"><code>0092623</code></a> fix: ReDoS in CSS tokenizer STRING rule</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/ee17d33aff3adb30c14e71d3d4c8163465acaccf"><code>ee17d33</code></a> fix: memory leak in XSLT transform (backport to v1.19.x) (<a href="https://redirect.github.com/sparklemotion/nokogiri/issues/3624">#3624</a>)</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/ce188a395192e3757d8701949afb643dc025084c"><code>ce188a3</code></a> doc: update CHANGELOG</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/caeaac41f874f0944f9397c78bf6c1bfac2cb472"><code>caeaac4</code></a> fix: memory leak in XSLT transform</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/25220bf268c9808e28415563ed7f8ea8d5c332bf"><code>25220bf</code></a> dep(test): test against libxml-ruby v6 (<a href="https://redirect.github.com/sparklemotion/nokogiri/issues/3618">#3618</a>)</li> <li><a href="https://github.com/sparklemotion/nokogiri/commit/0caeb21a5c5e9ff45bbede88fb53655f6753bb0e"><code>0caeb21</code></a> doc: add security warnings for untrusted XSLT stylesheets</li> <li>Additional commits viewable in <a href="https://github.com/sparklemotion/nokogiri/compare/v1.19.1...v1.19.3">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> |
||
|
Sivin VargheseandGitHub
|
85ddc68834 | fix: prevent bulk action checkbox reset in team view (#14432) | ||
|
Sojan JoseandGitHub
|
086aa36ffe | feat(companies): add notes and history to company details (#14401) | ||
|
|
f6be0d80ef |
feat: UI changes for document auto sync [AI-153] (#14258)
# Pull Request Template ## Description FE code for document sync Adds: - UI to show counts (stats) of available web pages, stale and synced documents and last synced at - Bulk action and manual ways to sync web documents - index to stats related columns ## Type of change Please delete options that are not relevant. - [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. https://linear.app/chatwoot/issue/AI-153/fe-document-auto-sync Documents dashboard: <img width="2160" height="986" alt="CleanShot 2026-05-11 at 17 57 09@2x" src="https://github.com/user-attachments/assets/6d934764-964c-4656-b005-1b4f0329e553" /> Filters: <img width="1138" height="564" alt="CleanShot 2026-05-11 at 17 58 13@2x" src="https://github.com/user-attachments/assets/cee780e6-eb8f-4aed-8cc5-b674244a821b" /> Needs update: <img width="2222" height="966" alt="CleanShot 2026-05-11 at 17 57 53@2x" src="https://github.com/user-attachments/assets/70c85ddd-7eb1-4328-ba14-7929e67e7b36" /> pdfs: <img width="2180" height="558" alt="CleanShot 2026-05-11 at 17 58 30@2x" src="https://github.com/user-attachments/assets/975b5c9f-bd1c-4979-9870-8f926d7f6e11" /> bulk actions: <img width="2244" height="992" alt="CleanShot 2026-05-11 at 17 58 57@2x" src="https://github.com/user-attachments/assets/bdb3c63f-d2de-41dc-a6d5-8821d3303be0" /> single url sync: <img width="2264" height="722" alt="CleanShot 2026-05-11 at 17 59 19@2x" src="https://github.com/user-attachments/assets/7d7323a5-0fcb-4be9-8635-55e56964999b" /> ## 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: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> Co-authored-by: iamsivin <iamsivin@gmail.com> Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com> Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Vishnu Narayanan <iamwishnu@gmail.com> |
||
|
Shivam MishraandGitHub
|
3489298726 |
feat: add WidgetCreationService for onboarding web widget setup (#14314)
When a new account finishes onboarding we want to land them on a
dashboard with a working web widget already configured, branded, named,
and assigned to them, instead of an empty inbox list. This PR adds the
services that produce that widget. **No user-visible change yet:** the
services are dormant until the trigger and background job are wired up
in the follow-up PR.
## Context
Milestone 1 added `Account::BrandingEnrichmentJob`, which calls
context.dev during signup and stores brand data on
`account.custom_attributes['brand_info']`, plus the new onboarding form
that captures `domain`, `name`, `industry`, etc. Milestone 2 starts
using that data, and the first thing we want is a web widget
materialized automatically. Splitting the service layer from the
orchestration plumbing (Redis key, `onboarding_step` extension,
controller wiring, ActionCable) keeps this diff focused and lets the
LLM/widget logic merge independently.
## How to test
Run against an existing account that already has `brand_info` populated.
```ruby
account = Account.find(<account_id>)
user = account.administrators.first
inbox = WidgetCreationService.new(account, user).perform
inbox.channel.widget_color # color from brand_info, or '#1f93ff'
inbox.channel.welcome_title # brand_info[:title], or account.name
inbox.channel.welcome_tagline # LLM tagline (Enterprise + system key set),
# else brand_info[:slogan]/[:description]/nil
inbox.inbox_members.pluck(:user_id)
```
Toggle `InstallationConfig['CAPTAIN_OPEN_AI_API_KEY']` to flip between
LLM and brand-text tagline paths. To verify failure isolation, raise
inside `Captain::Llm::WidgetTaglineService#perform` and confirm widget
creation still succeeds with the fallback tagline.
|
||
|
Shivam MishraandGitHub
|
2e13f69fdf |
chore: log errors from context.dev (#14310)
This PR updates the way we log errors and results from context.dev to have better visibility on the enrichment process for onboarding |
||
|
Shivam MishraandGitHub
|
bc768bf04f | chore: verbosely log errors for leadsquare activity failure (#14407) | ||
|
Shivam MishraandGitHub
|
cc612e755b |
fix: SafeFetch dependency loading (#14408)
The SafeFetch spec suite was failing in CI with `NameError: uninitialized constant SafeFetch::Fetcher` across every example that exercised `SafeFetch.fetch`. From a product perspective, this made the external-file fetch path look unreliable even though the failure happened before any network validation, SSRF protection, content-type checks, or tempfile handling could run. The symptom pointed to a load-order issue rather than an actual fetch behavior regression. `SafeFetch.fetch` referenced `Fetcher` from the top-level module, but that nested class was not guaranteed to be loaded in every test execution path before the method was invoked. This change keeps the existing SafeFetch split between the public API and the implementation classes, but makes the public entry point responsible for loading the implementation it needs before use. That is intentionally smaller than folding all of the fetcher logic into `lib/safe_fetch.rb`; the separate files still keep the request option parsing and streaming implementation readable, while the public API no longer depends on Rails or the test runner having loaded nested constants in a particular order. The file also now uses a single `SafeFetch` module declaration. That removes the awkward reopen pattern and makes the dependency boundary easier to see: constants and errors are defined first, then the public `fetch` method loads and delegates to the implementation classes. |
||
|
Aakash BakhleandGitHub
|
aa10d42237 |
chore: bump RubyLLM version [AI-152] (#14387)
# Pull Request Template ## Description Bump RubyLLM version and update model registry ## Type of change Version bump on package ## 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 |
||
|
|
202403873d |
feat: Ability to specify the authentication type for imap server (#12306)
# Pull Request Template ## Description This PR adds IMAP authentication mechanism selection to Chatwoot's email inbox configuration. Users can now choose between 'plain', 'login', and 'cram-md5' authentication methods when configuring IMAP settings, providing flexibility for different email providers that require specific authentication types. https://github.com/chatwoot/chatwoot/issues/8867 The implementation includes: - Frontend dropdown with numeric keys (1, 2, 3) matching SMTP auth style - Backend API validation for allowed authentication mechanisms - Consistent 'cram-md5' format throughout the codebase - Updated IMAP service to handle different auth types properly This feature maintains consistency with existing SMTP authentication options and follows the established UI/UX patterns in the application. ## Type of change Please delete options that are not relevant. - [x] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] 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? ### Manual Testing: - Tested in Docker environment - Verified IMAP auth dropdown appears in inbox settings - Confirmed all three auth mechanisms (plain, login, cram-md5) can be selected and saved - Tested API validation by attempting to save invalid auth mechanisms ### Automated Testing: - Updated existing IMAP service tests to use consistent lowercase values - Updated API controller tests for authentication parameter handling - All tests pass locally with the new changes ### Test Configuration: - Tested with both new and existing inbox configurations ## 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 ## Additional Notes - This feature is backward compatible and doesn't break existing IMAP configurations - The 'cram-md5' format is used consistently throughout (UI, API, storage, services) - Net::IMAP compatibility is maintained by converting to 'CRAM-MD5' internally - Follows the same pattern established by SMTP authentication configuration --------- Co-authored-by: João Santos <joao.santos@madigital.eu> Co-authored-by: Sony Mathew <sony@chatwoot.com> |
||
|
|
9c1d1c4070 |
feat(labels): remove label associations asynchronously on delete (#13531)
## Summary - Remove label deletion dependency on association cleanup by deleting immediately and enqueueing a background job. - Add `Labels::RemoveAssociationsJob` to strip deleted label references from tagged conversations and contacts. - Keep this version simple by removing the label count/prompt requirement requested. ## Implementation notes - Enqueue job from `Api::V1::Accounts::LabelsController#destroy` with label title + account id. - Background work performed in `Labels::DestroyService`. ## References - Linear issue: https://linear.app/chatwoot/issue/CW-4765/cw-2857-enhancement-removing-labels-is-inconsistent - GitHub issue: https://github.com/chatwoot/chatwoot/issues/1249 ## Testing - `bundle exec rspec spec/controllers/api/v1/accounts/labels_controller_spec.rb spec/services/labels/destroy_service_spec.rb spec/jobs/labels/remove_associations_job_spec.rb spec/services/labels/update_service_spec.rb` - `bundle exec rubocop app/controllers/api/v1/accounts/labels_controller.rb app/jobs/labels/remove_associations_job.rb spec/controllers/api/v1/accounts/labels_controller_spec.rb spec/jobs/labels/remove_associations_job_spec.rb spec/services/labels/destroy_service_spec.rb` --------- Co-authored-by: Sony Mathew <sony@chatwoot.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
|
5c6ea78ce6 |
fix(security): Enforce admin authorization on custom attribute definitions API (#14392)
Custom attribute definitions can now only be created, edited, or deleted by administrators, matching the existing settings UI restriction. Previously, an agent could call the `custom_attribute_definitions` API directly and modify account configuration that they couldn't reach through the dashboard — a Broken Access Control vulnerability reported externally. Fixes https://linear.app/chatwoot/issue/CW-7038/broken-access-control-on-custom-attribute-definitions-api ## How to test 1. Sign in as an agent. 2. Try to create a custom attribute by calling `POST /api/v1/accounts/<id>/custom_attribute_definitions` directly (the settings page is hidden for agents — use curl with the agent's `api_access_token`). 3. Expect `401 Unauthorized` with body `{"error":"You are not authorized to do this action"}`. Repeat for `PATCH` and `DELETE`. 4. Sign in as an administrator and confirm create/edit/delete still work from Settings → Custom Attributes. 5. As either role, the listing endpoint (`GET .../custom_attribute_definitions`) should still succeed — agents need this to render attributes in conversation and contact panels. Co-authored-by: Muhsin <12408980+muhsin-k@users.noreply.github.com> |
||
|
Tanmay Deep SharmaandGitHub
|
e6b8f48b3b |
fix: settle captain credits on subscription cancellation (#14089)
## Linear Ticket - https://linear.app/chatwoot/issue/CW-6875/captain-credits-3-bugs-in-stripe-subscription-lifecycle-cancel-ratchet ## Description Fixes Captain credit settlement on subscription cancellation. Previously `limits['captain_responses']` and `captain_responses_usage` were left in their pre-cancellation state, which caused incorrect credit totals when a customer re-subscribed. Cancellation now settles the monthly allotment (preserving any remaining topup) and resets the usage counter. ## Type of change - [ ] Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? 1. Set up an account subscribed to a paid plan (e.g. Startups) so `limits['captain_responses']` reflects the plan allotment. 2. Fire `customer.subscription.deleted` for that account's Stripe customer. Confirm the limits. 3. Fire `customer.subscription.updated` re-subscribing to the paid plan. Confirm the limits. 4. Repeat cancel → re-subscribe several times; ## 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 |
||
|
Sojan JoseandGitHub
|
10597863d7 | feat(companies): add company creation flow (#14402) | ||
|
|
53b2a517d7 |
fix: resolve SendReplyJob flaky specs (#14394)
`SendReplyJob` was caching reloadable service class objects in `CHANNEL_SERVICES`. In test, a request spec can trigger Rails constant reloading after `SendReplyJob` has already been loaded, leaving the job with stale class objects while later specs stub the reloaded constants. This resolves the channel service at perform time so the job follows the current Rails constant table. How to reproduce Run the CircleCI shard that contains send_reply_job_spec, or the minimized order-dependent reproduction: ```sh bundle exec rspec --format progress spec/builders/v2/reports/label_summary_builder_spec.rb spec/controllers/api/v1/accounts/bulk_actions_controller_spec.rb spec/jobs/send_reply_job_spec.rb:32 ``` What changed - Store service class names in `SendReplyJob::CHANNEL_SERVICES` instead of class objects. - Resolve the service with constantize inside perform so reloads do not leave stale cached classes. Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
|
7a7db22a43 |
fix: Implement resend confirmation feature for login page (#11970)
# Pull Request Template ## Description This PR fixes the non-functional resend confirmation feature on the V3 login page where clicking "Resend confirmation" did nothing. The issue was caused by the V3 store not having the `resendConfirmation` action that the login page was trying to dispatch. **Key improvements:** - Fixed V3 store integration by importing `resendConfirmation` directly from auth API - Added comprehensive UX improvements with loading states and 60-second cooldown timer - Implemented environment-aware debug logging for development - Added proper error handling and user feedback - Enhanced backend test coverage **Context:** Users with unconfirmed accounts were unable to resend confirmation emails from the login page, creating a poor user experience and potential support burden. Fixes #3157 ## 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? **Backend Testing:** - All existing resend_confirmation tests passing (7/7) - Added comprehensive new test suite in `spec/requests/api/v1/resend_confirmation_spec.rb` - API endpoint returns 200 OK responses in ~0.39 seconds - Email delivery confirmed via SMTP with test user `info@airbonar.com` **Frontend Testing:** - All frontend tests passing - ESLint compliant code with automatic corrections applied - Manual testing of login page functionality: - 60-second cooldown timer with countdown display - Error handling with user-friendly messages - Development logging works (console output in dev mode only) **Test Configuration:** - Ruby/Rails backend with RSpec test suite - Vue.js frontend with Jest/testing-library - Development environment with Gmail SMTP configured - Test user: unconfirmed account `info@airbonar.com` **Reproduction Steps:** 1. Navigate to login page with unconfirmed account 2. Click "Resend confirmation link" 3. Observe loading state, API call, and success feedback 4. Verify 60-second cooldown prevents spam 5. Check email delivery. ## Checklist: - [ ] 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: Sivin Varghese <64252451+iamsivin@users.noreply.github.com> Co-authored-by: Sojan Jose <sojan@pepalo.com> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> Co-authored-by: Sony Mathew <sony@chatwoot.com> |
||
|
Sivin VargheseandGitHub
|
2435d7503c | feat: Update conversation bulk action UI (#14118) | ||
|
salmonumbrellaandGitHub
|
fe44b07147 | feat(companies): add company detail page (#14054) | ||
|
|
42bba748cf |
fix(mailbox): render inline images without Content-Disposition (#11949)
## Description This pull request addresses issue #11948, where inline images embedded in emails (such as those sent from Outlook) are not rendered correctly if the Content-Disposition header is missing. The solution ensures that images referenced via cid: in the HTML body are correctly identified and rewritten using url_for. Fixes #11948 ## Type of change Bug fix (non-breaking change which fixes an issue) ## How Has This Been Tested? Added test: detects image inline attachment by cid reference when Content-Disposition is missing ## 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 - [ ] New and existing unit tests pass locally with my changes - [ ] Any dependent changes have been merged and published in downstream modules --------- Co-authored-by: Pranav <pranav@chatwoot.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> |
||
|
|
d43a87c9dc |
feat: Add labels to contact import/export (#13313)
Adds label support to contact import and export so teams can carry approved contact labels through CSV workflows. Imports accept a `labels` column with labels that already exist in the account; multiple labels should be entered as a quoted comma-separated CSV value, for example `"customer,vip"`. Imports are additive: they add labels to contacts and do not remove labels already on a contact. Removing a label from the CSV row or leaving the `labels` cell blank will not clear existing contact labels. To remove a label, edit the contact directly. ## Closes - Closes #8535 ## How to test 1. Create a few contact labels in the account, such as `customer`, `vip`, and `lead`. 2. Go to Contacts -> Import contacts and download the sample CSV. 3. Import contacts with a `labels` column. Use a single label like `lead`, or quote multiple labels like `"customer,vip"`. 4. Confirm imported contacts are created with the expected labels. 5. Re-import an existing contact with a new label and confirm the new label is added without removing existing labels. 6. Try a row with an unknown label, such as `"vip,unknown_label"`, and confirm only that row is rejected in the failed records CSV while the other valid rows are imported. 7. Export contacts and confirm the CSV includes a `labels` column with comma-separated approved labels. ## What changed - Contact exports include approved `labels` in the default CSV columns. This adds a new default export column for CSV consumers. - Contact imports parse `labels` as comma-separated values inside the CSV cell. - Imported labels are validated against labels that already exist in the account. - Rows with unknown labels are rejected with an `Unknown labels: ...` error; valid rows in the same import continue to process. - Imported labels are additive and do not remove existing contact labels. - Label application during import does not dispatch an additional per-contact update event. - The sample CSV includes an import-safe `labels` column. The modal keeps the existing generic CSV import copy. --------- Co-authored-by: Sojan Jose <sojan@pepalo.com> |
||
|
Aakash BakhleandGitHub
|
d7d1e4113c |
fix: captain auto sync scheduler resilience (#14379)
# Pull Request Template ## Description skip documents that fail with ActiveRecord errors possibly due to stale/corrupt data and not crash scheduler How did we find out about this error? before October 28th, 2025, we did not have url normalisation. so we had document rows as: id: 123 `https://example.com` status: `in_progress` --> likely stuck crawl id 234: `https://example.com/` status: `available` When the schedule sync job ran, it ran an `document.update!(sync_status: :syncing, last_sync_attempted_at: Time.current)` on the 234 one since it was `available` now `update!` runs `before_validation :normalize_external_link` so `https://example.com/` became `https://example.com` which invalidated: `validates :external_link, uniqueness: { scope: :assistant_id }` so the scheduler crashed. This PR logs the skipped ones with their errors and continues to pick other documents to scheduler doesn't crash ## 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. 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 |
||
|
Sivin VargheseandGitHub
|
815593eec9 | feat: display conversation ID conversation view (#14381) | ||
|
|
8d7e926e06 |
fix: [Snyk] Security upgrade video.js from 7.18.1 to 7.21.1 (#13973)
 ### Snyk has created this PR to fix 1 vulnerabilities in the yarn dependencies of this project. #### Snyk changed the following file(s): - `package.json` #### Note for [zero-installs](https://yarnpkg.com/features/zero-installs) users If you are using the Yarn feature [zero-installs](https://yarnpkg.com/features/zero-installs) that was introduced in Yarn V2, note that this PR does not update the `.yarn/cache/` directory meaning this code cannot be pulled and immediately developed on as one would expect for a zero-install project - you will need to run `yarn` to update the contents of the `./yarn/cache` directory. If you are not using zero-install you can ignore this as your flow should likely be unchanged. <details> <summary>⚠️ <b>Warning</b></summary> ``` Failed to update the yarn.lock, please update manually before merging. ``` </details> #### Vulnerabilities that will be fixed with an upgrade: | | Issue | :-------------------------:|:-------------------------  | XML Injection <br/>[SNYK-JS-XMLDOMXMLDOM-15869636](https://snyk.io/vuln/SNYK-JS-XMLDOMXMLDOM-15869636) --- > [!IMPORTANT] > > - Check the changes in this PR to ensure they won't cause issues with your project. > - Max score is 1000. Note that the real score may have changed since the PR was raised. > - This PR was automatically created by Snyk using the credentials of a real user. --- **Note:** _You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs._ For more information: <img src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiJhMzFhMWZiNS1hOWYwLTQ1MTMtOTMxNi1iZTg3OThhYmZkOWMiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6ImEzMWExZmI1LWE5ZjAtNDUxMy05MzE2LWJlODc5OGFiZmQ5YyJ9fQ==" width="0" height="0"/> 🧐 [View latest project report](https://app.snyk.io/org/chatwoot/project/3ca3819e-26b5-4e23-ac65-184abd9a6f10?utm_source=github&utm_medium=referral&page=fix-pr) 📜 [Customise PR templates](https://docs.snyk.io/scan-using-snyk/pull-requests/snyk-fix-pull-or-merge-requests/customize-pr-templates?utm_source=github&utm_content=fix-pr-template) 🛠 [Adjust project settings](https://app.snyk.io/org/chatwoot/project/3ca3819e-26b5-4e23-ac65-184abd9a6f10?utm_source=github&utm_medium=referral&page=fix-pr/settings) 📚 [Read about Snyk's upgrade logic](https://docs.snyk.io/scan-with-snyk/snyk-open-source/manage-vulnerabilities/upgrade-package-versions-to-fix-vulnerabilities?utm_source=github&utm_content=fix-pr-template) --- **Learn how to fix vulnerabilities with free interactive lessons:** 🦉 [XML Injection](https://learn.snyk.io/lesson/xxe/?loc=fix-pr) [//]: # 'snyk:metadata:{"breakingChangeRiskLevel":null,"FF_showPullRequestBreakingChanges":false,"FF_showPullRequestBreakingChangesWebSearch":false,"customTemplate":{"variablesUsed":[],"fieldsUsed":[]},"dependencies":[{"name":"video.js","from":"7.18.1","to":"7.21.1"}],"env":"prod","issuesToFix":["SNYK-JS-XMLDOMXMLDOM-15869636","SNYK-JS-XMLDOMXMLDOM-15869636"],"prId":"a31a1fb5-a9f0-4513-9316-be8798abfd9c","prPublicId":"a31a1fb5-a9f0-4513-9316-be8798abfd9c","packageManager":"yarn","priorityScoreList":[null],"projectPublicId":"3ca3819e-26b5-4e23-ac65-184abd9a6f10","projectUrl":"https://app.snyk.io/org/chatwoot/project/3ca3819e-26b5-4e23-ac65-184abd9a6f10?utm_source=github&utm_medium=referral&page=fix-pr","prType":"fix","templateFieldSources":{"branchName":"default","commitMessage":"default","description":"default","title":"default"},"templateVariants":["updated-fix-title","pr-warning-shown"],"type":"auto","upgrade":["SNYK-JS-XMLDOMXMLDOM-15869636"],"vulns":["SNYK-JS-XMLDOMXMLDOM-15869636"],"patch":[],"isBreakingChange":false,"remediationStrategy":"vuln"}' --------- Co-authored-by: snyk-bot <snyk-bot@snyk.io> Co-authored-by: Sony Mathew <2040199+sony-mathew@users.noreply.github.com> |
||
|
|
dd52f1d32b |
chore(deps): bump rack-session from 2.1.1 to 2.1.2 (#14017)
Bumps [rack-session](https://github.com/rack/rack-session) from 2.1.1 to 2.1.2. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rack/rack-session/blob/main/releases.md">rack-session's changelog</a>.</em></p> <blockquote> <h2>v2.1.2</h2> <ul> <li><a href="https://github.com/advisories/GHSA-33qg-7wpp-89cq">CVE-2026-39324</a> Don't fall back to unencrypted coder if encryptors are present.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rack/rack-session/commit/504367b59caf7ec78127785cc6351f46be14f8ca"><code>504367b</code></a> Bump patch version.</li> <li><a href="https://github.com/rack/rack-session/commit/f43638cb3a4d15c3ecaf59e67a04b47fda08eeac"><code>f43638c</code></a> Don't fall back to unencrypted coder if encryptors are present.</li> <li><a href="https://github.com/rack/rack-session/commit/dadcfe60f193e8d8540bec6b95ca75bed8e5fd7e"><code>dadcfe6</code></a> Bump actions/checkout from 4 to 5 (<a href="https://redirect.github.com/rack/rack-session/issues/54">#54</a>)</li> <li><a href="https://github.com/rack/rack-session/commit/4eb9ea83b372e319c65a8c2bcfe87e8be942cf9b"><code>4eb9ea8</code></a> Add top level session spec to validate existing formats.</li> <li><a href="https://github.com/rack/rack-session/commit/8f94577c1d11b746692974f1417acff2856060cb"><code>8f94577</code></a> Add rails to external tests.</li> <li><a href="https://github.com/rack/rack-session/commit/38ea47da9937afb4f2140b3c23866e3791a46eaf"><code>38ea47d</code></a> Allow the v2 encryptor to serialize messages with <code>Marshal</code> (<a href="https://redirect.github.com/rack/rack-session/issues/44">#44</a>)</li> <li><a href="https://github.com/rack/rack-session/commit/43f2e3a46393b51473bb90f54e61189465ae759d"><code>43f2e3a</code></a> Fix compatibility with older Rubies.</li> <li><a href="https://github.com/rack/rack-session/commit/6a060b806399bff4961eaf6bf89535395c95549c"><code>6a060b8</code></a> Support UTF-8 data when using the JSON serializer (<a href="https://redirect.github.com/rack/rack-session/issues/39">#39</a>)</li> <li><a href="https://github.com/rack/rack-session/commit/8ce0146a7079332d9c58a43e418acb1ecf904ef6"><code>8ce0146</code></a> Fix <code>auth_tag</code> retrieval on JRuby (<a href="https://redirect.github.com/rack/rack-session/issues/32">#32</a>)</li> <li><a href="https://github.com/rack/rack-session/commit/77271850efd977897d02903bfde8ed51e4137a68"><code>7727185</code></a> Add AEAD encryption (<a href="https://redirect.github.com/rack/rack-session/issues/23">#23</a>)</li> <li>See full diff in <a href="https://github.com/rack/rack-session/compare/v2.1.1...v2.1.2">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> |
||
|
|
deb259c8d2 |
chore(deps): bump rack from 3.2.5 to 3.2.6 (#13987)
Bumps [rack](https://github.com/rack/rack) from 3.2.5 to 3.2.6. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/rack/rack/releases">rack's releases</a>.</em></p> <blockquote> <h2>v3.2.6</h2> <p><strong>Full Changelog</strong>: <a href="https://github.com/rack/rack/compare/v3.2.5...v3.2.6">https://github.com/rack/rack/compare/v3.2.5...v3.2.6</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/rack/rack/blob/main/CHANGELOG.md">rack's changelog</a>.</em></p> <blockquote> <h2>[3.2.6] - 2026-04-01</h2> <h3>Security</h3> <ul> <li><a href="https://github.com/advisories/GHSA-7mqq-6cf9-v2qp">CVE-2026-34763</a> Root directory disclosure via unescaped regex interpolation in <code>Rack::Directory</code>.</li> <li><a href="https://github.com/advisories/GHSA-v569-hp3g-36wr">CVE-2026-34230</a> Avoid O(n^2) algorithm in <code>Rack::Utils.select_best_encoding</code> which could lead to denial of service.</li> <li><a href="https://github.com/advisories/GHSA-qfgr-crr9-7r49">CVE-2026-32762</a> Forwarded header semicolon injection enables Host and Scheme spoofing.</li> <li><a href="https://github.com/advisories/GHSA-vgpv-f759-9wx3">CVE-2026-26961</a> Raise error for multipart requests with multiple boundary parameters.</li> <li><a href="https://github.com/advisories/GHSA-q4qf-9j86-f5mh">CVE-2026-34786</a> <code>Rack::Static</code> <code>header_rules</code> bypass via URL-encoded path mismatch.</li> <li><a href="https://github.com/advisories/GHSA-q2ww-5357-x388">CVE-2026-34831</a> <code>Content-Length</code> mismatch in <code>Rack::Files</code> error responses.</li> <li><a href="https://github.com/advisories/GHSA-x8cg-fq8g-mxfx">CVE-2026-34826</a> Multipart byte range processing allows denial of service via excessive overlapping ranges.</li> <li><a href="https://github.com/advisories/GHSA-g2pf-xv49-m2h5">CVE-2026-34835</a> <code>Rack::Request</code> accepts invalid Host characters, enabling host allowlist bypass.</li> <li><a href="https://github.com/advisories/GHSA-qv7j-4883-hwh7">CVE-2026-34830</a> <code>Rack::Sendfile</code> header-based <code>X-Accel-Mapping</code> regex injection enables unauthorized <code>X-Accel-Redirect</code>.</li> <li><a href="https://github.com/advisories/GHSA-h2jq-g4cq-5ppq">CVE-2026-34785</a> <code>Rack::Static</code> prefix matching can expose unintended files under the static root.</li> <li><a href="https://github.com/advisories/GHSA-8vqr-qjwx-82mw">CVE-2026-34829</a> Multipart parsing without <code>Content-Length</code> header allows unbounded chunked file uploads.</li> <li><a href="https://github.com/advisories/GHSA-v6x5-cg8r-vv6x">CVE-2026-34827</a> Multipart header parsing allows denial of service via escape-heavy quoted parameters.</li> <li><a href="https://github.com/advisories/GHSA-rx22-g9mx-qrhv">CVE-2026-26962</a> Improper unfolding of folded multipart headers preserves CRLF in parsed parameter values.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/rack/rack/commit/e1f22fdbe99afd2126b6fbf05bb12399359574b7"><code>e1f22fd</code></a> Bump patch version.</li> <li><a href="https://github.com/rack/rack/commit/31989fd7bb6f806fdb3cfa4e9aec1fe8434f47d1"><code>31989fd</code></a> Fix typo in test.</li> <li><a href="https://github.com/rack/rack/commit/d268165e390e17b83573fec916dcdef6304a8b4b"><code>d268165</code></a> Fix test expectation.</li> <li><a href="https://github.com/rack/rack/commit/8f425de0ee75a2f3cdfbfdd57858c1910b7645ff"><code>8f425de</code></a> Add Ruby v4.0 to the test matrix.</li> <li><a href="https://github.com/rack/rack/commit/bf830426ce5b3daccb5a226b733703c86504ceba"><code>bf83042</code></a> Drop EOL Rubies from external tests.</li> <li><a href="https://github.com/rack/rack/commit/d50c4d3dab62fa80b2a276271d0d4fb338cfa7df"><code>d50c4d3</code></a> Implement OBS unfolding for multipart requests per RFC 5322 2.2.3</li> <li><a href="https://github.com/rack/rack/commit/bfb69142dbe2a1e3298ad52d12935938d1b58205"><code>bfb6914</code></a> Limit the number of quoted escapes during multipart parsing</li> <li><a href="https://github.com/rack/rack/commit/b3e5945c648c5a5b6982e5072b26e51990991229"><code>b3e5945</code></a> Add Content-Length size check in Rack::Multipart::Parser</li> <li><a href="https://github.com/rack/rack/commit/7a8f32696609b88e2c4c1f09d473a1d2d837ed4b"><code>7a8f326</code></a> Fix root prefix bug in Rack::Static</li> <li><a href="https://github.com/rack/rack/commit/a57bc140247f904dc1e3302badedcb73645072c7"><code>a57bc14</code></a> Only do a simple substitution on the x-accel-mapping paths</li> <li>Additional commits viewable in <a href="https://github.com/rack/rack/compare/v3.2.5...v3.2.6">compare view</a></li> </ul> </details> <br /> 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> |
