Daily updates from Odoo
Tuesday, October 7, 2025
229 changes
8 changes
Enhancements to existing features
This update adds automated checks for appointment booking flows, including capacity handling, availability, cart bookings, invoice confirmation, and final event creation. These tests help reduce the risk of booking errors and improve reliability across appointment sales and payment scenarios.
Original PR description
\* = website_appoinment_sale, appointment_account_payment Add tests to ensure correct behaviour for the various scenarios. The following tests are added: - Users/resource's capacity computation when manage capacity is on and off. - Unavailability computation of users/resources in the `calendar.event`. - Check the bookings of user/resource in the cart for the availability after the invoice is confirmed. - Creation of the actual event when the booking from the cart is confirmed. Task-4919317
Resolved issues and error corrections
Incoming Chilean electronic invoice emails with accented characters could fail to process and show an error. This fix allows those XML invoices to be read correctly, reducing manual follow-up for affected documents.
Original PR description
### Issue:
The invoice XMLs having special characters like "Ó" received in DTE emails will trigger a traceback.
### Cause:
`.decode('utf-8')` will try decoding the bytes in utf-8 but Ó is not UTF-8, so there is a traceback:
```
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xcd in position 1734: invalid continuation byte
```
In any case, it crashes at the next line: `xml_content = etree.fromstring(xml_dte)` because the XML specifies the encoding (i.e. unicode) but the true encoding is `utf-8` so an error is raised:
```
ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.
```
### Solution:
Remove `.decode('utf-8')` when decoding. The method `fromstring` accepts bytes and will use the encoding specified in the XML.
opw-5124661This fix ensures manufacturing shop floor screens handle removed BoM components without showing duplicate material lines or crashing. It adds test coverage so the issue does not return, helping operators continue work smoothly after production setup changes.
Original PR description
### Steps to reproduce: 1. Create a BoM with two components to be consumed in an operation 2. Create a Manufacturing Order with this BoM and confirm it 3. On the BoM, remove one of the products and save 4. Go to the Shop Floor 5. Select the workcenter used in step 1 6. Got duplicate key in t-foreach ### Before this commit: Stock moves without quality checks, that are linked to a workorder but not linked to a BoM line, are included twice in the view, resulting into a traceback. ### After this commit: Include only once the stock moves, removing duplicates from the view. opw-5029970 Forward-Port-Of: odoo/enterprise#93482
This change fixes an unreliable automated test for bus notifications that could fail randomly depending on how notification batches were read. It helps keep the release process stable by ensuring the test checks all received notifications instead of accidentally ignoring some.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. However, the listener only consider the first notification of the batch (`conn.notifies.pop()`) and ignore the rest. When the expected notifications come as part of a bigger batch, they can be ignored thus making the test fail. This commit ensures we read every notification received. fixes runbot-233185 Description of the issue/feature this PR addresses: 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#230117 Forward-Port-Of: odoo/odoo#230054
This update prevents UK tax report submissions from reusing invalid saved device identifiers when contacting HMRC. If an incorrect value is found in the browser, Odoo clears it so a valid identifier can be used and requests are less likely to be rejected.
Original PR description
There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086 Forward-Port-Of: odoo/enterprise#96409 Forward-Port-Of: odoo/enterprise#87335
This fixes an issue where certain remote procedure calls could fail when request parameters used names that conflicted with internal fields such as model or method. The change improves reliability for integrations and web requests without changing user workflows.
Original PR description
Backport of odoo/odoo#227801 in saas-18.4 X-Original-Commit: 1bb69de64165b18fca7d00164c5299e58c48d40f
This update ensures IoT drivers correctly prepare information before sending it to the Odoo database. It prevents failures when using connected payment terminal libraries, helping devices continue to communicate reliably after recent platform changes.
Original PR description
This PR fixes the bytestrings being sent as such when using ctypes C/C++ libraries in iot drivers. After the PR https://github.com/odoo/odoo/pull/206903 the bytestrings are not supported anymore in the requests sent to the database from the iot and need to be decoded first. Related PR for v19 -> master: https://github.com/odoo/enterprise/pull/96537 opw-5129596
The German Datev export now handles sales and purchase receipts even when no customer or vendor is entered. This prevents export failures and helps businesses keep accounting data flowing correctly for receipt-based transactions.
Original PR description
Since 18.4, there are purchase receipts as a function for vendor bills, where you can choose to put no vendor in the vendor field, the same is true for invoices with sale receipts. Making sure that partners are not Null task-5114562
7 changes
Enhancements to existing features
The state selection field now aligns visually with other similar lookup fields by removing an extra margin. This creates a more consistent form layout and reduces small visual inconsistencies for users entering addresses or location details.
Original PR description
Related PR: https://github.com/odoo/odoo/pull/229290 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Updates the spreadsheet component to a newer version with several fixes that make spreadsheets more reliable. Users should see fewer issues with formatting, pivot calculations, sheet renaming, and spreadsheet headers.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4764cba65 [REL] 18.3.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4764cba65 [REL] 18.3.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/01de174f41 [FIX] format: wrong internal format conversion [Task: 5126306](https://www.odoo.com/odoo/2328/tasks/5126306) https://github.com/odoo/o-spreadsheet/commit/e53c7f5125 [FIX] Evaluation: remove spread relations [Task: 5105030](https://www.odoo.com/odoo/2328/tasks/5105030) https://github.com/odoo/o-spreadsheet/commit/7a80bf28f1 [FIX] spreadsheet: prevent sheet name edit from losing focus [Task: 5109129](https://www.odoo.com/odoo/2328/tasks/5109129) https://github.com/odoo/o-spreadsheet/commit/0b6565e4de [FIX] headers: can add lots of headers [Task: 5092626](https://www.odoo.com/odoo/2328/tasks/5092626) https://github.com/odoo/o-spreadsheet/commit/af28911cdb [FIX] pivot: add deferred calculated measure [Task: 5096156](https://www.odoo.com/odoo/2328/tasks/5096156) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Manufacturing order overviews can now be opened even when the order has no linked bill of materials. This prevents an error after completing such orders and helps users review production information without interruption.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Create a manufacturing order to produce one unit of P1: - add any component - Mark the MO as done - Try to open the MO overview Issue: An error is raised because the MO has no BoM. But in the function we try to compute the missing quantity in the BoM's UoM, but since no BoM is linked, there is no UoM available. Error message: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure %(product_unit)s defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category." Fix: Skip the computation of missing BoM quantities when no BoM is linked, allowing the MO overview to be opened without error. opw-5112132 Opw-5105544 Opw-5119897 Forward-Port-Of: odoo/odoo#229707
This change removes a non-essential test check that could fail unpredictably when product lists changed. It helps keep point-of-sale loyalty testing stable without affecting customer-facing behavior.
Original PR description
Before this commit, some tests could fail randomly if a new product was included in the list of limited loading products. The part of the test that checked whether the product was not loaded was not essential, so it has been removed to prevent unnecessary failures. opw-5109838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an unreliable automated test for bus notifications by making sure every notification in a received batch is checked. The change helps reduce false test failures and improves confidence in release validation without changing user-facing behavior.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. However, the listener only consider the first notification of the batch (`conn.notifies.pop()`) and ignore the rest. When the expected notifications come as part of a bigger batch, they can be ignored thus making the test fail. This commit ensures we read every notification received. fixes runbot-233185 Description of the issue/feature this PR addresses: 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#230117 Forward-Port-Of: odoo/odoo#230054
Unmarking a completed package in Inventory now correctly clears the related picked status, so delivery orders no longer get stuck waiting and can check availability again. The fix also preserves picked status when users manually enter done quantities after starting from zero stock, avoiding a new workflow regression.
Original PR description
### Issue: To reproduce the bug: 1. Activate `Packages` settings in Inventory: 2. Activate `Move entire packages` on picking type `delivery orders` 3. Create new product `Test move package` 4. Update…
### Issue:
To reproduce the bug:
1. Activate `Packages` settings in Inventory:
2. Activate `Move entire packages` on picking type `delivery orders`
3. Create new product `Test move package`
4. Update quantity in `WH/Stock` with a newly created package and a qty (eg 5)
5. Go to the delivery orders and create a new picking with the created product and a quantity of 5
6. Click on `Mark as Todo`, the picking is set as ready and a package level is created automatically to move the quantity we did put in stock in the package.
7. Mark the checkbox `Done` on the package level (this will mark the move line and the move as picked)
8. Unmark the checkbox `Done` on the package level.
The package level is deleted, as well as the stock move line,
but the stock move still has the checkbox picked that is
marked.
The picking is then in waiting state and we cannot check
availability again.
Currently to be able to check the availability, the picked
check should be undone manually.
### Cause of issue
Currently, in `_compute_picked` in `stock_move`, we don't
update value of move.picked if there is `no move_line_ids`
present which is wrong.
### Fix:
In the fix, picked is set to False when there no
`move_line_ids`
### Issue 2
This fix cause another issue, in which the move loses its `picked` status after manually setting the done quantity when no stock was initially available,
### Cause of issue 2
To be more specific this fix on `_compute_picked`
```diff
- elif move.move_line_ids:
move.picked = False
+ else:
move.picked = False
```
has the following side effect:
- On a confirmed picking, pick a move with a quantity of 0 then change the quantity to 10 the move is unpicked -> undesirable.
After you picked the move, when you set the quantity, you will set `move_line_ids` on your move to match the quantity increase here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L2157-L2165
However,`self._set_quantity_done_prepare_vals(qty)` does not return a `stock.move.line` record set but a `Command.create` whose values do not contain any info on the picked value of the move *line*:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
The fact that the `move_line_ids` is set on the move to this command.create, flags the `picked` field of the stock move to dirty and adds it to the field to recompute because of the dependency `move_line_ids.state`:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L208-L209
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/odoo/api.py#L795-L800
THEN, the creation of the move.line happends and since the value of the picked was not set in the command.create, we populate it based on the picked value of the move:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move_line.py#L347-L348
However, at this point since the picked value of the move has been flagged as dirty it is recomputed using the `compute_method` modified in our fix.
And since the move does not have any move line at this stage, it is computed to be picked = False resetting the picked value.
### Fix of Issue 2:
We should set the picked values in the vals here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
opw-4964561
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222034This fix clears invalid saved device identifiers before sending UK HMRC requests. It helps prevent rejected submissions caused by outdated or corrupted browser data, improving reliability for UK tax reporting users.
Original PR description
There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086 Forward-Port-Of: odoo/enterprise#96409 Forward-Port-Of: odoo/enterprise#87335
2 changes
Resolved issues and error corrections
The appraisal skills list now allows horizontal scrolling on mobile again, so users can see the justification field and the add or remove buttons. This fixes a mobile usability issue that prevented employees or managers from completing skill appraisals properly.
Original PR description
Horizontal scrolling has been disabled on the appraisal skills list. An unwanted side effect of that is that the justification field along with the add and remove buttons are not visible on mobile. This PR re-enables the scrolling and removes some dead css. task-5001344 Forward-Port-Of: odoo/enterprise#96068 Forward-Port-Of: odoo/enterprise#91882
UK tax report submissions to HMRC now discard invalid saved device identifiers before sending requests. This prevents repeated rejection of submissions caused by corrupted browser-stored data, improving reliability for affected users.
Original PR description
There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086 Forward-Port-Of: odoo/enterprise#96409 Forward-Port-Of: odoo/enterprise#87335
5 changes
Resolved issues and error corrections
This fixes a problem where using the browser back button from an invalid form could make Odoo stop responding. Users can now continue interacting with the web client instead of being stuck on a locked screen.
Original PR description
Be in an invalid form view and do browser back. The form view can't be saved as it is invalid, so it can't be left. Before this commit, the body was `pointer-events: none`, i.e. the user couldn't…
Be in an invalid form view and do browser back. The form view can't be saved as it is invalid, so it can't be left. Before this commit, the body was `pointer-events: none`, i.e. the user couldn't interact with the webclient anymore. This is due to a code in webclient.js, which listens to the `ROUTE_CHANGE` event and calls `loadState`. PR [1] prevented the user to interact with the UI during the state loading, as it could lead to weird side-effects. To achieve this, it set the `point-events: none` rule on the body, and reset it once the promise returned by loadState was fullfilled. Unfortunately, in the above mentionned case, loadState returned a promise that was left pending forever, leading to a fully locked webclient. This commit fixes the issue by returning nothing, like we already do in other similar cases in the action service, when the requested action can't be executed. [1] https://github.com/odoo/odoo/pull/205290 Description of the issue/feature this PR addresses: 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
This fixes how inventory value is calculated when there is not enough FIFO stock history and stock temporarily goes negative. The system now uses the last known unit cost instead of the full previous move value, helping keep inventory and accounting valuations accurate.
Original PR description
Before this commit: If there are not enough FIFO in valuations, (i.e. going -ve) the extra value comes from the last known move. But we should not use the whole move value - just the unit value from it. After this commit: The move value is made a unit before multiplying. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes an internal messaging test read all notifications it receives instead of only the first one. It reduces random test failures and helps keep the messaging infrastructure validation stable without changing user-facing behavior.
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. However, the listener only consider the first notification of the batch (`conn.notifies.pop()`) and ignore the rest. When the expected notifications come as part of a bigger batch, they can be ignored thus making the test fail. This commit ensures we read every notification received. fixes runbot-233185 Description of the issue/feature this PR addresses: 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#230117 Forward-Port-Of: odoo/odoo#230054
The mail app now keeps blur settings adjustable in real time during call previews and active calls. This fixes an issue where users could not change background or edge blur once the blur effect was applied, improving the video call experience.
Original PR description
**Current behavior before PR:** - Before this commit, `applyBlurEffect` returned a partial object with only `stream` and `close` properties, preventing access to properties like `edgeBlur` and `backgroundBlur` needed for real-time adjustments during calls. **Desired behavior after PR is merged:** - This commit returns the `BlurManager` instance from `applyBlurEffect` and adds an `onChange` listener in `CallPreview`, enabling users to adjust blur characteristics in real-time during both preview and active calls. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where users could be blocked from validating a backordered delivery in warehouses using a two-step delivery process with packaged and lot-tracked products. The correction ensures stock reservations are adjusted only where appropriate, reducing interruptions during order fulfillment.
Original PR description
# Problem Unreserve issue preventing users from validating a delivery order with 2-step delivery warehouse configuration. Introduced in the following commit:…
# Problem Unreserve issue preventing users from validating a delivery order with 2-step delivery warehouse configuration. Introduced in the following commit: https://github.com/odoo/odoo/commit/13567aa27250f5798bbe42648eeac82241dbb780 # Steps to reproduce on the runbot: - Activate packages - Edit the warehouse to deliver in 2-steps - Create a product tracked by lot - Create two lots with 5 qty each - Create a sale order with 10 qty and confirm - Check the delivery order and assign: => 2 units to lot1 and create a pkg for it => 1 units to lot1 without pkg => 3 to lot2 without package - Validate the delivery and create a backorder - go to pick backorder and try to validate - Unreserve issue pops up - For further details, check: [#225948](https://github.com/odoo/odoo/issues/225948) # Solution: Conditional subtracting limited to new lines only. Task ID: opw-5086289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229994 Forward-Port-Of: odoo/odoo#229420
7 changes
Enhancements to existing features
Portal discussions now treat messages that include only a rating as meaningful content, so reviews are not considered empty or ignored. This improves how customer feedback and course reviews are displayed and managed across portal and website learning pages.
Original PR description
*: portal, portal_rating, rating, website_slides task-5016995
UBL electronic invoices now include the delivery party in the delivery information. This gives recipients clearer shipping details by using the shipping contact when available, or the customer name as a fallback, while keeping existing delivery date and location behavior unchanged.
Original PR description
Previously, the Peppol UBL export only covered the mandatory delivery fields and did not include the `delivery party`. This commit adds the `<cac:DeliveryParty>` element under `<cac:Delivery>` to improve the exported information. - Include `<cac:DeliveryParty>` in the `<cac:Delivery>` section of UBL invoices. - Use the shipping partner name if set; otherwise, fallback to the customer name - Keep existing `<cac:DeliveryLocation>` and delivery date logic unchanged. <img width="766" height="306" alt="image" src="https://github.com/user-attachments/assets/d07c1b37-4c6d-42d1-99b4-66c5abc8e298" /> ----- task-5022404
Resolved issues and error corrections
This fixes an inventory issue where a transfer could show the same source document reference multiple times when several items came from the same receipt. The source document field now lists each reference only once, making transfer records clearer and reducing confusion for warehouse users.
Original PR description
### Behavior: #### Current: During the assignment of a picking, if several of its moves have the same origin, it will repeat that origin in its own origin. #### Expected: Only have one time each origin. ### Steps to reproduce: From Inventory * Enable two step transfer for the warehouse From Barcode * create and validate new receipts with "Product A" * create and validate a second new receipts with "Product A" and other products From Inventory/Operations/Transfers/Receipts * Open the corresponding receipts * In "source Document" (Field: origin, Model : stock.picking) we can see that the reference from second receipts is repeated. ### Observation: In the case of already existing origins it will not duplicate them but it's missing if several item comes from the same origin. https://github.com/odoo/odoo/commit/0caa44ca97d9d197811a03ad2ff227df68d4437a#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR1410 opw-4970159
Pasted tables from tools like Google Docs now keep the expected formatting and structure in Odoo's HTML editor. This prevents tables from appearing incorrectly or with empty cells, making copied content more reliable for users.
Original PR description
### Purpose of this PR: - Ensure that pasted table elements get the standard classes: `table, table-bordered, and o_table.` - When content is pasted from other source (e.g., Google Docs inside iframe), attribute nodes coming from another JavaScript context do not match the `Attr` prototype of the current context. Use `item.nodeType === Node.ATTRIBUTE_NODE` instead of `instanceof Attr` to detect attribute nodes. - Insert a base container into empty `<td>` elements when pasting tables from external sources. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Public-facing mail page text now uses the proper translation system instead of always showing the original source language. This helps visitors see page components in their selected language, improving localization consistency.
Original PR description
Human-readable content defined in public page components isn't translated. This is because we forgot to give Owl a translation function, so it falls back to returning the source terms as they are (identity function). This commit resolves the issue by providing the missing translation function. Task-4493082 Task-5140665 Forward-Port-Of: odoo/odoo#230129
The fix keeps valid accented characters, including ü, in Mexican legal names used for electronic invoicing. This helps prevent unnecessary name changes that could cause validation issues with Mexico's tax authority (SAT).
Original PR description
Previous commit (#95207) removed accents for names including character ü which indeed is a recognized character for SAT opw-5125107
Miscellaneous changes
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324