Daily updates from Odoo
Navigate
Branch
Sunday, July 6, 2025
13 changes
10 changes
Enhancements to existing features
The live chat information panel now shows more customer context, including open leads, open support tickets, chatbot answers, and conversation outcomes. This helps teams understand each chat faster and follow up more effectively without switching screens.
Original PR description
Adding following features to info panel: - Display open leads in info panel - Display open tickets in info panel - Display chatbot answers in info panel - Display outcome in info panel follow up of task-4771890 https://github.com/odoo/enterprise/pull/89573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Live chat conversations that have ended now show a checkered flag indicator in the Discuss sidebar and on chat bubbles. This helps support teams quickly identify closed or inactive chats without opening each conversation.
Original PR description
Before this commit, seeing whether a livechat has ended, e.g. due to visitor leaving, required opening the conversation and seeing the "livechat has ended" where composer is shown. This commit improves visibility of livechat that have ended by showing a checkered flag icon on avatar of livechat conversation that have ended. This icon is also shown on chat bubbles. <img width="293" alt="Screenshot 2025-07-05 at 21 55 16" src="https://github.com/user-attachments/assets/5918fc19-9397-40c7-84ff-be34f6f8552d" />
Website and HTML builder options can now wait for background state updates before refreshing related controls. This helps keep image, form, card, carousel, and animation settings consistent when edits depend on asynchronous updates.
Original PR description
Whenever there is a need to update the state of a builder option asynchronously, we need all the options to await for the state of all other options to be updated. This commit makes allow any options that need to update the state of the builder options asynchronously to do so by using the `useDomState` hook. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mobile users can now open message actions with a long press, copy message text, and use reaction menus that appear more consistently at the bottom of the screen. The update makes Discuss easier to use on phones and avoids confusing background overlay changes when navigating message options.
Original PR description
This PR improves several aspects of discuss on mobile devices: - Long press to open message actions - Fix background color issue when opening sub-menu from message actions - Improve reaction menu position - Add a copy action for messages | - | Before | After | | -------------| ------------- | ------------- | | Background ||  | | Reaction menu |  |  | enterprise: https://github.com/odoo/enterprise/pull/89402
The live chat information panel now shows more customer context, including open leads, open helpdesk tickets, chatbot answers, and conversation outcomes. This helps support and sales teams understand each visitor faster and respond with more relevant next steps.
Original PR description
Adding following features to info panel: - Display open leads in info panel - Display open tickets in info panel - Display chatbot answers in info panel - Display outcome in info panel follow up of task-4771890
Website builder options can now wait for related option settings to finish updating before applying their own changes. This helps make asynchronous builder behavior more reliable, especially for website appointments and studio form options.
Original PR description
Whenever there is a need to update the state of a builder option asynchronously, we need all the options to await for the state of all other options to be updated. This commit makes allow any options that need to update the state of the builder options asynchronously to do so by using the useDomState hook.
The AI discussion feature now uses the shared mail copy-message action instead of its own version. This keeps behavior consistent with the core messaging system and reduces future maintenance effort, with minimal user-facing impact.
Original PR description
The "copy-message" action is moved to mail in the community counterpart of this commit. This commit updates the ai code to use the mail action. community: https://github.com/odoo/odoo/pull/217310
Resolved issues and error corrections
Confirmed purchase orders now allow users to edit product descriptions when needed by hiding the product column. This restores flexibility for buyers to correct or clarify order line descriptions after confirmation without changing the product itself.
Original PR description
<b>Steps to Reproduce:</b> - Navigate to Purchase → Create a new Purchase Order. - Add a Vendor → Add a Product with description or enter one using the ☰ widget. - Save and Confirm the order, Try to…
<b>Steps to Reproduce:</b>
- Navigate to Purchase → Create a new Purchase Order.
- Add a Vendor → Add a Product with description or enter one using the ☰ widget.
- Save and Confirm the order, Try to edit the description.
<b>Issue:</b>
- The product description becomes non-editable after confirming the PO.
- Previously, the description was separated in view.
<b>Cause:</b>
- Since `product_id` is readonly, the `name` (description) field also does not allow to edit.
- e.g. In SO, the description is editable if the product_id is hidden and only name (description) field is visible.
<b>Since the product_id field is read-only in the states ('purchase', 'to approve', 'done', 'cancel'), the description field
also becomes read-only, as they are combined. By hiding the product_id, we can edit the description, as it is not.</b>
<b>Solution:</b>
- Added `optional="show"` to `product_id` in the XML view to allow toggling discription editability.
- When `product_id` is hidden, the `name` field becomes editable.
<b>Steps to Verify:</b>
- Open same confirmed PO and hide the `product_id` column.
- Make sure `name` (description) field is visible and now it is editable.
<b>opw-4892063</b>
Forward-Port-Of: odoo/odoo#215997The User Preferences screen now correctly shows the "Email Signature" field title when the Calendar app is installed. This removes a small interface inconsistency that could confuse administrators editing user settings.
Original PR description
**Issue:** The "Email Signature" field title is missing in the User Preferences tab when calendar is installed. **Steps to reproduce:** 1. Ensure the Calendar app is installed. 2. Go to Settings > Users. 3. Open any user form and navigate to the Preferences tab. This patch mirror this commit: https://github.com/odoo/odoo/commit/af701b3e5bd9106c6ccea5b4a59b9e79424b3a26 by targetting the wrapping group instead of the field opw-4796115 Forward-Port-Of: odoo/odoo#211491
Miscellaneous changes
Before this commit, there could be a traceback when downloading call logs that contains `serverInfo`, that was because it is a proxy and cannot be cloned (to be passed to the service worker). This commit fixes it by using the raw value instead of the proxy when logging. Forward-Port-Of: odoo/odoo#216215
Original PR description
Before this commit, there could be a traceback when downloading call logs that contains `serverInfo`, that was because it is a proxy and cannot be cloned (to be passed to the service worker). This commit fixes it by using the raw value instead of the proxy when logging. Forward-Port-Of: odoo/odoo#216215
1 change
Resolved issues and error corrections
Barcode scanning now correctly updates an existing stock receipt line when a product is scanned through its packaging barcode, instead of creating a duplicate line. This helps warehouse teams keep receipt quantities accurate and reduces manual cleanup during barcode operations.
Original PR description
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable…
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable "Units of Measure & Packagings" - Create a product using the base Unit as uom and allowing pack of 6 aspackaging (optional) - Inventory > Configuration > Product > Units & Pacakagings - Click on pack of 6 > Packaging Barcodes > New - Create a new one for your product - Create and confirma receipt for 6 units of your product - Go to the barcode app and scan a pack of 6 #### > A new line 1 pack of 6 was created rather than updating the already existing one. ### Cause of the issue: When the packaging is scanned, we will call the `findLine` of the `BarcodeModel` in order to determine if there is already an existing line that could absorb the scanned qty. However, this call currently requires the uom of the barcodeData to coincide either with the line uom or its referred packaging to be a valid candidate: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1748-L1753 ### Note: This additional check was added in a9a20f8ec5a7883a08eb4bea15dbf3c4cc97caac when the uom and packagings were refactored and merged together. However, it is really unecessary since the system can handle different uoms via these lines: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1450-L1466 ### opw-4866981 Forward-Port-Of: odoo/enterprise#89453 Forward-Port-Of: odoo/enterprise#88494
1 change
Enhancements to existing features
The AI discussion tools now rely on the standard mail message copy action instead of maintaining their own version. This keeps the experience consistent across apps and reduces duplicated maintenance work.
Original PR description
The "copy-message" action is moved to mail in the community counterpart of this commit. This commit updates the ai code to use the mail action. community: https://github.com/odoo/odoo/pull/217310 Forward-Port-Of: odoo/enterprise#89402
1 change
Enhancements to existing features
This update helps Turkish e-invoices meet GIB requirements by using the customer reference field as the registered tax office name in Nilvera documents. Users will now see warnings or validation errors if an e-invoice customer is missing this required information, reducing the risk of non-compliant invoices.
Original PR description
### Description of the issue/feature this PR addresses This PR adds a validation to ensure that E-Invoice partners in Turkey have the `reference` field filled with their registered tax office name,…
### Description of the issue/feature this PR addresses This PR adds a validation to ensure that E-Invoice partners in Turkey have the `reference` field filled with their registered tax office name, as required by GİB regulations. ### Current behavior before PR Partners marked as E-Invoice customers can be used in invoicing without a value in the `reference` field, which may lead to non-compliant UBL documents. ### Desired behavior after PR is merged Once the reference field is filled, it is sent via the UBL, as it is passed to tax_scheme_vals. The account move send wizard issues a critical warning for partners that should have the tax office name in the reference field. If this warning is ignored and the customer on the invoice has a TR e-invoicing status of Nilvera, a validation error is raised, prompting the user to complete the required reference field on the customer. Task-4886128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215772