Daily updates from Odoo
Friday, November 7, 2025
28 changes · saas-18.3
Resolved issues and error corrections
This update fixes a problem in the editor where selecting table cells from right to left or bottom to top could lose the first selected cell in Firefox. It makes table selection behave consistently, improving the editing experience for users working with tables.
Original PR description
Steps to Reproduce: 1. Create a table in the editor (Firefox). 2. Select table cells backward (right → left or bottom → top). Description of the issue this PR addresses: - The first selected cell does not remain selected in Firefox when extending the selection backward. task-5094832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234579 Forward-Port-Of: odoo/odoo#227694
When a guest changes their name on the meeting welcome page, the updated name now appears right away in the attendee list. This makes meeting participation clearer and avoids confusion for hosts and other participants.
Original PR description
**Steps to Reproduce:** - Login with Admin, start a meeting, open the member list. - Join the meeting with a guest, using the invite link. - Change the guest name from the welcome page. - Admin member list doesn't show updated guest name. **Current behavior before PR:** Before this PR, the guest appeared as `Guest` in the member list even after updating their name on the welcome page. **Desired behavior after PR is merged:** This PR ensures the guest name is updated and displayed instantly upon joining, providing a smoother and more consistent experience. task-[5062702](https://www.odoo.com/odoo/project/1519/tasks/5062702) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234299
This change fixes a migration issue where certain tax distributions could incorrectly fail validation and stop the database upgrade. It ensures records with no positive distribution are handled correctly, reducing unexpected errors during upgrades.
Original PR description
``` File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 611, in _validate_repartition_lines raise ValidationError(_("Invoice and credit note distribution should have a total…
```
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 611, in _validate_repartition_lines
raise ValidationError(_("Invoice and credit note distribution should have a total factor (+) equals to 100."))
odoo.exceptions.ValidationError: Invoice and credit note distribution should have a total factor (+) equals to 100.
```
- During the database migration, a traceback occurs because the [total_pos_factor](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L558) is being calculated as 0. When this happens, the float_compare [function](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L559) returns -1, which incorrectly satisfies the validation condition and triggers a ValidationError.
- To resolve this, we need to add an additional condition to check whether total_pos_factor is 0, similar to the condition already implemented [here](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L562) in the code.
tbg-1970
opw-5228357
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234334This fix makes lot and serial numbers appear in the barcode app only when the Manufacturing setting to show reserved lots/SNs is enabled, or when they have already been picked or scanned. It reduces visual clutter and helps users avoid picking or scanning the wrong items during manufacturing operations.
Original PR description
Issue: ------------------------------------- Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs…
Issue: ------------------------------------- Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs option was enabled in the Manufacturing settings. Steps to Produce: ------------------------------------- - In Manufacturing settings, disable the Show Reserved Lots/SNs option. - Create a Manufacturing Order and reserve component lots. - Go to the barcode app - Lots/SNs appear even though the Show Reserved Lots/SNs option is disabled. After this Commit: ------------------------------------- A correct value is now passed to the condition controlling the lot and serial number visibility. Lots/SNs are shown only when Show Reserved Lots/SNs is enabled in Manufacturing settings, or when they have been picked or scanned, helping users focus only on relevant information and reducing the chance of picking or scanning mistakes. Task Id: [3908929](https://www.odoo.com/odoo/project/966/tasks/3908929) Forward-Port-Of: odoo/enterprise#62853
This fix ensures that when users switch between IoT device screens, any previous background request is properly stopped before starting a new one. It prevents requests from piling up and avoids timeouts that could stop IoT actions from working reliably.
Original PR description
Steps to reproduce: 1. Pair an IoT box 2. In the IoT form view, click on any device, then click back to return to the IoT form view. 3. Repeat this step multiple times. If you have devtools open, you…
Steps to reproduce: 1. Pair an IoT box 2. In the IoT form view, click on any device, then click back to return to the IoT form view. 3. Repeat this step multiple times. If you have devtools open, you can see a `/event` fetch request every time you open the device form. Expected behaviour: - When a new request is made, the previous request is cancelled. Actual behaviour: - The previous requests remain active, and eventually no further requests are possible due to browser limits, causing action calls to timeout. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of jquery. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Before the fix (action times out due to many stuck event calls): <img width="545" height="249" alt="image" src="https://github.com/user-attachments/assets/f18b8a5d-c27c-47a3-ab58-428a78ef5383" /> After the fix (action succeeds): <img width="538" height="228" alt="image" src="https://github.com/user-attachments/assets/30f2863e-9df9-4a6e-b715-135ece4224ed" /> Forward-Port-Of: odoo/enterprise#98985
This update corrects an automated test for restaurant preparation tickets so it matches the current system behavior. It helps ensure the test keeps validating the right result after changes to how empty tickets are handled.
Original PR description
pos_* = post_restaurant_preparation_display Before this PR (https://github.com/odoo/odoo/pull/231733), the checkPreparationTicketData method returned True if the preparation ticket was empty. This is no longer the case, so the test has been updated to work correctly now. Related Community PR: https://github.com/odoo/odoo/pull/231733 Forward-Port-Of: odoo/enterprise#97333
This update fixes the live chat dashboard so its rating percentage only includes sessions that were actually rated. This makes the displayed score more accurate and consistent with the reporting view, helping teams rely on the dashboard for a true picture of customer feedback.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Before this change, the live chat rating percentage in the dashboard included sessions that were not rated, which made the overall rating misleading. While the sessions reporting view allowed filtering on "rating is set", the dashboard did not provide this option. **Current behavior before PR:** --------------------------------- - Unrated sessions are included in the dashboard rating percentage - The percentage is misleading compared to the sessions reporting view **Desired behavior after PR is merged:** ----------------------------------------- - The dashboard rating percentage only considers sessions with a rating - Unrated sessions are excluded, resulting in a more accurate rating display **Task:** 5048700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a website form is edited and saved, temporary elements added by Cloudflare Turnstile no longer get stored in the page content. This avoids forms being left with a disabled button or spinner after Turnstile is removed or turned off, keeping the site’s forms working as expected.
Original PR description
Steps to reproduce: 1. Install the `website_cf_turnstile` module. 2. Enter valid Cloudflare Turnstile credentials in the configuration. 3. Go to the Website Editor. 4. Add or edit a form (e.g.…
Steps to reproduce: 1. Install the `website_cf_turnstile` module. 2. Enter valid Cloudflare Turnstile credentials in the configuration. 3. Go to the Website Editor. 4. Add or edit a form (e.g. contact form) and save the page. 5. Notice that the form’s submit button temporarily shows a spinner and gets a 'disabled' class while Turnstile is initializing. 6. After saving the page, these temporary elements and classes (e.g. .turnstile-spinner and 'disabled') are incorrectly saved into the form’s HTML. 7. If you later remove or uninstall the website_cf_turnstile module, the submit button remains disabled and the spinner icon still appears, even though Turnstile is no longer active. After this commit: Now, when you save a website form in the editor, any temporary classes or elements added by Cloudflare Turnstile are removed. This prevents unwanted changes from being saved to forms. task-4951470 Forward-Port-Of: odoo/odoo#234730 Forward-Port-Of: odoo/odoo#221841
Quality checks created during receipt validation now keep the same company as the related stock movement. This prevents cross-company errors when users switch companies before confirming a draft receipt.
Original PR description
When creating quality checks per quantity, a multi-company error occurs if the active company differs from the one defined on the control point. Steps to reproduce: - Create a Quality Control Point for Company B and Product Table for the receipt operation with a per-quantity control. - Create a receipt in Company B for this product but leave it in draft. - Switch to Company A and try to confirm → error. Root cause: The company_id was not set when creating the quality check, causing it to default to `env.company` (A) instead of the stock move line’s company (B). opw-86993 Forward-Port-Of: odoo/enterprise#98827 Forward-Port-Of: odoo/enterprise#98655
This change prevents an error that could appear when users open a payment from certain invoice-related views. The system now only applies invoice-specific behavior to invoices, avoiding a mismatch that could break the payment screen.
Original PR description
Repro: - Create DDM for a client - Create 4+ invoices for him - Pay with SEPA - Go to batch payment set it with SEPA - Add all the invoices and set the date to any date <5 days from today. - A yellow line will appear along with (View All).. / click it - From the view click on any payment. - Exception arises saying made_sequence_gap not found in account.payment Issue: made_sequence_gap belongs to 'account.move' incompatible with 'account.payment' causing the exception. Solution: Here the view_duplicated_moves_tree_js view is intended for account.move elements not for account.payment ones, So I included it only when the resModel is account.move. opw-5149260 Forward-Port-Of: odoo/odoo#233450
The color picker interface now updates properly when users select grayscale, transparent grayscale, or theme colors. This makes it easier to fine-tune these colors and keeps the on-screen controls aligned with the selected color.
Original PR description
Before this commit, the colorpicker UI would not update when switching to some colors (grayscale, transparent grayscale, theme colors). It would therefore be difficult to make small changes to those colors. This commit make the colorpicker update correctly. Step to reproduce the bug (example with grayscale colors): - Add a snippet - Change the background color to a custom color (the colorpicker interface was updated to match the color) - Change the background color to a grayscale color (the colorpicker interface was not updated to match the color) task-3806989 Forward-Port-Of: odoo/odoo#179883
Uploading an unsupported file type in the Sign app no longer triggers a traceback when debug mode is enabled. Users now see a clear error message instead, which makes the app more reliable and easier to use during troubleshooting.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Enable debug mode. - Try uploading a non-PDF file in the Sign app. Before: - Uploading a non-PDF file in debug mode caused a traceback error. - The TemplateAlertDialog component tried to use a message prop that wasn’t defined. After: - Replaced the use of the undefined message prop with the correct body prop to display the error message. Impact: - Fixes the traceback error in debug mode. - Shows a clear and user-friendly error message when uploading unsupported file types. task-4828439
This update brings back the Save button and the related logic for trusted point of sale orders. It ensures the POS behaves as expected again for businesses relying on trusted order workflows, avoiding disruptions in daily operations.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220309 Forward-Port-Of: odoo/odoo#200567
This update corrects how fuzzy search measures text length after letters with accents or tone marks are simplified. As a result, searches are more reliable for languages that use these marks, reducing the risk of missing results or search errors.
Original PR description
The fuzzy search mechanism (specifically the _match utility) calculates the length of the string before normalizing it (e.g., with `unaccent`). However, `unaccent` can remove non-spacing marks (like Thai tone marks or vowels), which changes the length of the string. This mismatch caused the search loop to iterate past the end of the normalized string, leading to incorrect behavior or potential errors. This commit moves the length calculation to after the string has been unaccented, ensuring the loop has the correct bounds. opw-5189276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234616 Forward-Port-Of: odoo/odoo#233249
The search panel background on mobile now adjusts correctly in both light and dark modes. This makes the popover view easier to read and more consistent with the rest of the app.
Original PR description
This commit adjusts the search_panel background color so it adapts correctly to both light and dark modes on mobile. It only affects the "popover" use case. task-5121027 Requires: - https://github.com/odoo/enterprise/pull/98248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234361
This update adjusts the search panel colors on mobile when dark mode is enabled. It makes the interface easier to read and more consistent with the rest of the dark theme.
Original PR description
This commit adapts colors of search_panel for mobile in dark mode. | Before | After | |--------|--------| | <img width="904" height="1022" alt="image" src="https://github.com/user-attachments/assets/9136de22-3ce1-40e3-bb79-8f87c8ee2bf8" /> | <img width="372" height="653" alt="Capture d’écran 2025-10-29 à 08 37 39" src="https://github.com/user-attachments/assets/6aff402b-6dc8-46ce-8e2a-d55887374f51" /> | Requires: - https://github.com/odoo/odoo/pull/234361 task-5121027 Forward-Port-Of: odoo/enterprise#98248
Checks in the Philippines will now show the amount in words correctly when the payment includes cents. This removes the trailing “ONLY” in those cases and uses the proper lowercase “and” for the decimal part, making printed checks more accurate and compliant.
Original PR description
In phillipines, if any amount has centovas (decimal amount), the amount in words cannot contain 'ONLY' in the end. Additionally, changed 'And' -> 'and' for decimal amount. **task**-5155953 Forward-Port-Of: odoo/enterprise#98535
This change fixes an issue that could block confirming or updating a manufacturing order created from the BoM overview. It ensures the right quantity information is passed along, so users can continue working without the process failing.
Original PR description
This PR fixes the error that occurs when confirming an MO from the BoM overview for a product with a 2 level BoM.
Bug Reproduction:
1- Create BoM for a Main Product.
2- Create a child BoM for any component in the main Product's BoM and make that component have an MTO route.
3- Navigate to the BoM Overview of the Main Product.
4- Click "Manufacture" to create an MO for the Main Product.
5- Click the save icon in the MO.
6- There are two scenarios to reproduce the error now:
a- Confirm the MO form.
b- Or update the quantity to produce in the MO.
= The confirmation or update of the MO is blocked, it should be allowed.
The Issue:
A dirty context is being passed from the BoM overview. it sets the `default_product_qty` to be set in the MO. However, when creating the moves necessary for the MO, this makes an issue as `product_qty` should never be set in stock moves, we set `product_uom_qty` instead.
Task-4795105Sales orders that have been delivered are now marked as invoiced even when the full ordered quantity was not shipped, as long as no further stock operations are expected. This reduces confusion and prevents orders from incorrectly appearing as still waiting for invoicing.
Original PR description
If no other operations are expected on the picking, even if the full quantity wasn't delivered, the order should be marked as invoiced. task-4607401 Fixes #144485 Partial revert of #115871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234412 Forward-Port-Of: odoo/odoo#218322
This update prevents Shiprocket from failing when GST-specific tax tags are not available in the system. It also makes the related test more reliable by forcing a known tax rate, reducing the chance of unexpected test failures.
Original PR description
Some other test adds a fiscal position with tax mapping. This creates 2 problems 1. The new taxes have a tag, which means we evaluate the right hand of…
Some other test adds a fiscal position with tax mapping. This creates 2 problems
1. The new taxes have a tag, which means we evaluate the right hand of
https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239
However, since l10n_in is not installed,
`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`
does not return anything (False is not a fallback)
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588
So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558
2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true
Solution
-----
1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test
-----
runbot-232692
Forward-Port-Of: odoo/enterprise#98860
Forward-Port-Of: odoo/enterprise#97998This change avoids refreshing cached product data when nothing has actually changed during variant creation. It improves performance by reducing extra system work, which can help product-related operations run more smoothly.
Original PR description
Description of the issue/feature this PR addresses: Method `product.template._create_variant_ids()` triggers a `write()` on `product.product.product_template_attribute_value_ids` which will, in turn, invalidate the cache. This cache invalidation is unnecessary if the new value is the same as the old value. Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233677
This fix prevents repeated background requests from piling up when users open and close IoT device screens. It helps keep the IoT interface responsive and avoids hitting browser connection limits, which could otherwise stop new requests from working.
Original PR description
Steps to reproduce: 1. Pair an IoT box 2. In the IoT form view, click on any device, then click back to return to the IoT form view. 3. Repeat this step multiple times. If you have devtools open, you can see a `/event` fetch request every time you open the device form. Expected behaviour: - When a new request is made, the previous request is cancelled. Actual behaviour: - The previous requests remain active, and eventually no further requests are possible due to browser limits. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of Odoo's `rpc` method. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Manual Forward Port of Enterprise PR: https://github.com/odoo/enterprise/pull/98985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users selected several lines in the bank reconciliation list and created a statement, the starting balance could be incorrect. This update restores the correct line selection data so the statement balance is computed properly, avoiding misleading totals.
Original PR description
When selecting multiple lines and doing a statement in the list view. The balance start was wrong because the computation relies on the active_ids that wasn't correctly filled. The reason is that during the refactoring: https://github.com/odoo/enterprise/commit/2335c953723dce66af8811fdfbfd5b811d42b109 We actually remove a custom widget allowing to pass the active_ids. Task [link](https://www.odoo.com/odoo/project.task/5245426) task-5245426
When tracking changes on related records, Odoo will now gracefully fall back instead of showing an error if some records do not have a display name. This improves reliability and prevents a crash in common business workflows that use one-to-many or many-to-many relations.
Original PR description
Description of the issue/feature this PR addresses: Addresses: https://github.com/odoo/odoo/issues/178883 Same issue is also in 18.0. Is there a separate PR necessary or will this be ported forward? Current behavior before PR: An error is displayed when tracking is activated on one2many and many2many with records without display_name. Desired behavior after PR is merged: Should not crash and use fallback like in other cases. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214121
When sending a message from a contact record, Odoo now correctly handles contacts that have more than one email address in the email field. This prevents the system from treating the extra email as a new person and creating duplicate contacts.
Original PR description
**Steps to reproduce:** - Go to the `Contacts` app - Create a new contact - Add multiple emails in the email field (e.g. `"test1@example.com,test2@example.com"`) - Click on `Send Message` button in…
**Steps to reproduce:** - Go to the `Contacts` app - Create a new contact - Add multiple emails in the email field (e.g. `"test1@example.com,test2@example.com"`) - Click on `Send Message` button in the chatter - Default recipients are computed for each email - One of them match the contact, the other doesn't but still pass to the badges list - When sending a message, the second mail is considered as a new contact to create **Issue:** Emails coming from an email field with multiple emails are considered separately when added in the chatter recipients. The partner only match the first one which means that the second one creates a duplicate. This seems to be the default behavior when receiving an email from the additional email address of a partner (`If an email is not unique (e.g. multi-email input), only the first found valid email in input is considered.`), but automatically filling the recipients badges in this way seemed unintended. **Fix:** Properly parsed the email field of recipients to match the partner and avoid creating a duplicate when sending a message on a contact page. opw-4929564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220593
This change prevents an access error that could appear when opening the Documents app after a company has been archived. It ensures folders are only loaded for companies the user can still access, so the app opens normally and company-related documents remain available as expected.
Original PR description
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it…
**Steps to reproduce:** - Add some folders - Create a new company - Assign some folders to the new company - Archive the company - Click on Documents app - AccessError is raised when opening it **Issue:** The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`: `folders = accessible_records.filtered(lambda d: d.type == 'folder')` This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched. **Fix:** Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere. For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows. opw-4931278 Forward-Port-Of: odoo/enterprise#99004 Forward-Port-Of: odoo/enterprise#96817
This fix prevents a crash when converting very large uploaded XLSX files into O-spreadsheet format. It improves reliability for users working with big spreadsheets, so those files can be opened and processed without errors.
Original PR description
Steps to reproduce: - upload a large xlsx file (e.g. with >1000 sheets) - open it and convert it to o-spreadsheet => traceback Task: 5222481 Forward-Port-Of: odoo/enterprise#98482 Forward-Port-Of: odoo/enterprise#98443
We fixed an issue in Live Chat where the page breadcrumb could briefly show the wrong name or flicker when moving between sessions. This makes navigation look smoother and helps users stay oriented while switching conversations.
Original PR description
Before this PR, The breadcrumbs flickered when navigating between livechat sessions. This occurred because the `FormController`…
Before this PR,
The breadcrumbs flickered when navigating between livechat sessions.
This occurred because the `FormController` ([@web/views/form/form_controller](https://github.com/odoo/odoo/blob/saas-18.3/addons/mail/static/src/core/web/discuss_patch.js#L16-L23))
updated the breadcrumb title inside the `onRendered` hook and set it to
`this.model.root.data.display_name` which is `undefined`, the `Discuss` component
also updated the breadcrumb title in a `useEffect` hook. ([@mail/code/web/discuss_patch.js](https://github.com/odoo/odoo/blob/saas-18.3/addons/mail/static/src/core/web/discuss_patch.js#L16-L23))
The two updates conflicted: the onRendered hook first set the title to
“Unnamed,” and then the useEffect hook replaced it with the correct title,
causing a brief flicker. Additionally, when navigating to another session with
the same thread.displayName, the useEffect hook did not trigger (since its
dependency did not change), but onRendered still ran, causing the breadcrumb
to remain “Unnamed”.
This PR fixes the issue by introducing a `LivechatFormController` which
updates the breadcrumbs when channel is fetched in store.
task-4671251
Before:
After:
task-4671251