# Pull Request Template
## Description
This PR fixes an issue where typing variables, like `{{contact.name}}`,
caused the variable list to miss showing `contact.name`. The search key
in this case became `contact.name}},` which didn't match any available
options. The logic in `VariableList.vue` only checked the part after the
last comma and didn’t fully sanitize the input.
**Solution**
Updated `searchKey` to remove all {} and commas for accurate matching.
Fixes
[CW-4574](https://linear.app/chatwoot/issue/CW-4574/i-dont-see-an-option-for-contactname-it-shows-initially-but-it-doesnt)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Loom video
https://www.loom.com/share/fc86e53853ad49e6acf6de57ebbd8fcb?sid=6702f896-d1a3-4c5a-9eb7-b96b5ed91531
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [x] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
This PR introduces a new channel type for voice conversations.
ref: #11481
## Changes
- Add database migration for channel_voice table with phone_number and
provider_config
- Create Channel::Voice model with E.164 phone number validation and
Twilio config validation
- Add voice channel association to Account model
- Extend inbox helpers and types to support voice channels
- Add voice channel setup UI with Twilio configuration form
- Include voice channel in channel factory and list components
- Add API routes and store actions for voice channel creation
- Add comprehensive translations for voice channel management
---------
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: iamsivin <iamsivin@gmail.com>
# Pull Request Template
## Description
This PR fixes the translation inconsistency in the reports pages, where
table-column headers reverted to English after a page reload.
**Cause**
The components defined the columns array statically, so header labels
were translated only once during component creation. On reload, the
table showed the default system language (English) until the user’s
locale finished loading.
**Solution**
Replaced the static columns array with a computed property and passed it
to `Tanstack useVueTable` via a getter. This makes the headers reactive,
ensuring they automatically update whenever the locale changes and
remain translated after every reload.
Fixes
https://linear.app/chatwoot/issue/CW-4539/translation-issue-in-reports-page-table-header-on-reload
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [ ] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
This PR will prevent saving user preferences and online status when impersonating. Previously, these settings could be updated during impersonation, causing the user to see a different view or UI settings.
Fixes https://linear.app/chatwoot/issue/CW-4163/impersonation-improvements
# Pull Request Template
## Description
This PR fixes the translation inconsistency in the
`<ConversationBasicFilter />` component, where dropdown options would
revert to English after page reload.
**Cause:**
The component used static arrays for chat status and sort options, with
translations initialized only once. After a reload, it showed system
language (English) until the user's locale was fully loaded.
**Solution:**
Replaced static arrays with computed properties to make translations
reactive. This ensures the options automatically update when the locale
changes.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Loom video
**Before**
https://www.loom.com/share/eeac97c59b21480b95ef74813d3d7fa9?sid=0481994a-8d35-4c44-87d0-c6c5a77a54fd
**After**
https://www.loom.com/share/c1bdfbdb19ca4e37bda373f0fe12527a?sid=cb5b1d19-272b-48cb-967c-9a82c2a2b028
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [ ] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
# Pull Request Template
## Description
This PR fixes,
1. Fix display issue where the attribute value `0` was not shown for
attributes of type "number" and instead displayed as `"---"`
2. Fix issue where the copy and delete buttons were not visible when the
attribute value was `0`
3. Fix an issue with updating contact custom attributes in the
conversation sidebar (caused by the camelCase param key mismatch in
`contacts/update`; only reproducible for attributes type "date")
4. Ensure the delete button is shown for checkbox-type attributes, even
when the value is `true` or `false` (previously hidden when the value
was `false`, despite the key being present)
Fixes
[CW-4326](https://linear.app/chatwoot/issue/CW-4326/custom-attribute-with-value-0-not-displayed-correctly-in-chatwoot)
https://github.com/chatwoot/chatwoot/issues/11459
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Loom video
https://www.loom.com/share/77257dc09a37452bab7876d1554b8a03?sid=dc5635eb-4fe0-4f39-8da2-036d71649ffc
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [x] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
# Pull Request Template
## Description
This PR introduces a `CustomTeleport` component that wraps Vue's
Teleport to preserve directionality context (ltr / rtl) when teleporting
content outside the app’s root container.
### Problem
Currently, the app sets the text direction (`[dir="ltr"]` or
`[dir="rtl"]`) on a container `div` inside `<body>`, not on `<body>`
itself. When content is teleported directly into `body`, it no longer
inherits the correct direction context. As a result, direction-aware
utility classes like `ltr:pl-2`, `rtl:ml-1`, etc., break because CSS
selectors like `[dir="ltr"] .ltr\:pl-2` no longer match. Identified this
issue when working on this
[PR](https://github.com/chatwoot/chatwoot/pull/11382)
### Solution
The `CustomTeleport` component automatically applies the correct `[dir]`
attribute (`ltr` or `rtl`) on the teleported content's wrapper based on
the current `isRTL` setting from the store. This ensures that
direction-specific Tailwind utility classes continue to work as
expected, even when the content is rendered outside the app root.
## 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
- [ ] 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: Pranav <pranavrajs@gmail.com>
# Pull Request Template
## Description
This PR uses `useScrollLock` from `VueUse` to lock scrolling on the chat
list panel when the context menu is open.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Loom video
https://www.loom.com/share/68a25af2c1b149f8bd06bdbaafb4d82d?sid=0984fde6-ade2-405a-afc9-6d8f99480874
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [ ] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
# Pull Request Template
## Description
This PR updates the basic filter UI for conversations.
## Type of change
- [x] New feature (non-breaking change which adds functionality)
## How Has This Been Tested?
### Loom video
https://www.loom.com/share/df69a023a39c4dfca2c12b1ee42a0b2e?sid=977e802e-2865-46f1-ae8e-f89ab5eabc2a
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [ ] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
---------
Co-authored-by: Pranav <pranav@chatwoot.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
# Pull Request Template
## Description
This PR fixes the CC/BCC field reset issue on activity action.
Fixes
[CW-4256](https://linear.app/chatwoot/issue/CW-4256/emails-added-in-cc-and-bcc-disappears-when-you-click-on-assign-to-me),
#5234
### Cause of the Issue
Previously, the CC and BCC fields in the reply box were being reset
whenever a conversation activity occurred (such as assignment, status
change, etc.). This happened because watchers on the current chat
messages array and current chat object would trigger
`setCCAndToEmailsFromLastChat` even when the last message was an
activity or system message, not a real email.
### Solution
- The updated logic ensures that the CC and BCC fields are only set
under the following conditions:
**1**. Switching to a new conversation.
**2**. In the same conversation, only if the last message is not an
activity (i.e., only for actual emails).
- It uses the `lastEmail` computed property, which filters out private
and activity messages, ensuring only real email context changes update
the fields.
- This prevents user-entered `CC/BCC` values from being cleared after
system events (e.g., assignments or status changes), while still
updating the fields correctly when relevant messages are received.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Loom video
**Before**
https://www.loom.com/share/2ec50dd1c0ed4eaf9170465274bea41e?sid=cc8b88cb-fd39-473a-8df3-78a242c8407b
**After**
https://www.loom.com/share/17fd2d96d5d84a049dcbf20d401d2ada?sid=8949ad48-7769-49d2-92c5-267da8c60d6e
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [x] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
We have added warnings for existing Instagram messenger inboxes via
https://github.com/chatwoot/chatwoot/pull/11303. However, an issue arose
where warnings were incorrectly displaying for messenger conversations.
This PR resolves that issue.
When we send text with attachments on Instagram, Instagram treats text
and attachments as separate messages. However, Chatwoot keeps them as a
single message. Since Instagram sends echo events for each message, this
can create duplicate messages in Chatwoot. To prevent this, we will send
text and attachments as separate messages.
---------
Co-authored-by: Pranav <pranav@chatwoot.com>
- Add agent bots management UI in settings with avatar upload
- Enable agent bot configuration for all inbox types
- Implement proper CRUD operations with webhook URL support
- Fix agent bots menu item visibility in settings sidebar
- Remove all CSML-related code and features
- Add migration to convert existing CSML bots to webhook bots
- Simplify agent bot model and services to focus on webhook bots
- Improve UI to differentiate between system bots and account bots
## Video
https://github.com/user-attachments/assets/3f4edbb7-b758-468c-8dd6-a9537b983f7d
---------
Co-authored-by: iamsivin <iamsivin@gmail.com>
Co-authored-by: Sivin Varghese <64252451+iamsivin@users.noreply.github.com>
Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>
Co-authored-by: Pranav <pranav@chatwoot.com>
We have added warnings for existing Instagram messenger inboxes via
https://github.com/chatwoot/chatwoot/pull/11303. There is an issue with
finding the correct Instagram/messenger inbox. This PR will fixes that
issue.
# Pull Request Template
## Description
This PR resolves a Chrome-specific rendering bug where emojis in the
`<textarea>` of the reply box display a shadow or different color tone
when placed at the start of the input without a leading space.
**Solution:** Removed the border-radius from the textarea in the Reply
box component, which resolves the rendering issue in Chrome
**Cause:** This appears to be a Chrome rendering bug related to how
border-radius is handled on form elements, especially with emojis. The
exact cause is unclear, but there is some known issue
[Chromium Issue 40333458](https://issues.chromium.org/issues/40333458)
[Related Chromium
Duplicates](https://issues.chromium.org/issues/40333458/dupes)
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How Has This Been Tested?
### Screen recording
**Before**
https://github.com/user-attachments/assets/618de129-5631-4c7c-ab0b-7188b83c6bf1
**After**
https://github.com/user-attachments/assets/bb3adcbe-e603-4792-a8fd-51501d284c78
## Checklist:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [ ] I have commented on my code, particularly in hard-to-understand
areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream
modules
