Daily updates from Odoo
Monday, June 16, 2025
21 changes · master
Enhancements to existing features
This update standardizes date values to use full ISO formatting, ensuring months and days are always written with two digits. It reduces the risk of date parsing errors in payroll, accounting, appointments, manufacturing, and localization processes.
Original PR description
ISO format does not accept single digit months or days. odoo/odoo#214350
This update adds testing to confirm that AI-generated HTML field content is properly cleaned before use, helping prevent unsafe or unwanted content from being stored or displayed. It also increases the API call timeout, making AI field processing more reliable when responses take longer.
Original PR description
Purpose ======= Add test about sanitization for HTML properties. Increase the timeout limit when calling the API. Task-4712395
Code cleanup and technical improvements
This update reorganizes how WhatsApp and VoIP identify internal users by moving that logic to the user model. It should make the behavior more consistent across related communication features, with no expected change for day-to-day users.
Original PR description
Enterprise counter-part. Part of task-3208257 https://github.com/odoo/odoo/pull/214021
This update clarifies which automated test steps intentionally move users to a new page. It helps make testing more predictable across appointment, documents, helpdesk, point of sale, ecommerce, planning, and signing workflows, reducing false test issues without changing day-to-day user behavior.
Original PR description
In this commit, we add willUnload to steps that require it to explicitly declare that the step will cause the page to be unloaded.
Miscellaneous changes
Rounding errors may occur when using `int()` on float values. Steps to reproduce: - Create an invoice with a total amount of 256.46 - Create a RIBA payment for this invoice - Add this payment to a batch payment - Export the batch payment file In the exported file, the amount should be 25646, but it is incorrectly 25645 in two places. This happens because in Python: `int(256.46 * 100) → int(25645.999999...) → 25645` To fix this, we use `float_round()` to round correctly the float
Original PR description
Rounding errors may occur when using `int()` on float values. Steps to reproduce: - Create an invoice with a total amount of 256.46 - Create a RIBA payment for this invoice - Add this payment to a batch payment - Export the batch payment file In the exported file, the amount should be 25646, but it is incorrectly 25645 in two places. This happens because in Python: `int(256.46 * 100) → int(25645.999999...) → 25645` To fix this, we use `float_round()` to round correctly the float before applying `int()` to convert the value to an integer. This ensures accurate rounding for exported payment amounts. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4858205) opw-4858205 Forward-Port-Of: odoo/enterprise#87703 Forward-Port-Of: odoo/enterprise#87597
Some aggregation expressions used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses terms from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. This was done
Original PR description
Some aggregation expressions used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses terms from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. This was done in https://github.com/odoo/odoo/commit/bbba54a08c56e0a4d040fc8035996d9d7cafedad for the monthly Luxembourgish tax report ; but some other occurrences needed to be fixed. Forward-Port-Of: odoo/enterprise#87492
Following page 35 of the documentation here https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf In Switzerland, SEPA and ISO20022 are considered as subsets of the Swiss standard, and it is hence possible to include within the Swiss file nodes that are generated following these formats. We didn't support that before this commit. To allow that, we also remove the ability to force the value of the ChrgBr node when using SEPA ; ot
Original PR description
Following page 35 of the documentation here https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf In Switzerland, SEPA and ISO20022 are considered as subsets of the Swiss standard, and it is hence possible to include within the Swiss file nodes that are generated following these formats. We didn't support that before this commit. To allow that, we also remove the ability to force the value of the ChrgBr node when using SEPA ; other values as SLEV are not supported by that format anyway. opw-4535542 Forward-Port-Of: odoo/enterprise#87441 Forward-Port-Of: odoo/enterprise#86996
**Before this commit:** - If the user had a website with a theme, then exporting from `Studio Export` would fail if no changes were made to the view via `web_studio`. **After this commit:** - The export now completes successfully, even when there are no changes made in the view through `web_studio`. task-4815179 Forward-Port-Of: odoo/enterprise#87655 Forward-Port-Of: odoo/enterprise#86972
Original PR description
**Before this commit:** - If the user had a website with a theme, then exporting from `Studio Export` would fail if no changes were made to the view via `web_studio`. **After this commit:** - The export now completes successfully, even when there are no changes made in the view through `web_studio`. task-4815179 Forward-Port-Of: odoo/enterprise#87655 Forward-Port-Of: odoo/enterprise#86972
This commit fixes the alignment of the copy button in ai chats for user messages. --- Behaviour Before this Fix --- The copy button would be aligned on the left side of the chat window while the user message would be on the right side. --- Changes Done for the Fix --- Previously, the flex-reversed class was added in the contentContainer div, which includes the message and its actions. That was removed and now the flex-row-reversed class is added when the chat is not AI. When the chat is
Original PR description
This commit fixes the alignment of the copy button in ai chats for user messages. --- Behaviour Before this Fix --- The copy button would be aligned on the left side of the chat window while the user message would be on the right side. --- Changes Done for the Fix --- Previously, the flex-reversed class was added in the contentContainer div, which includes the message and its actions. That was removed and now the flex-row-reversed class is added when the chat is not AI. When the chat is AI, the flex-row-reversed class is added but this time only for the actions div. --- Behaviour After the Fix --- The copy button is now aligned on the right side, under the user's message. Task-4840542 Forward-Port-Of: odoo/enterprise#86764
Issue: --- - For providers like JustEat, Grubhub, DoorDash, and UberEats (US/UK regions), UrbanPiper expects the entire product catalog during sync. - However, Odoo was sending only updated products, causing issues on their end. Fix: --- - Updated the condition to ensure a full product sync is performed when any of the configured providers require it. task-4863894 Forward-Port-Of: odoo/enterprise#87470
Original PR description
Issue: --- - For providers like JustEat, Grubhub, DoorDash, and UberEats (US/UK regions), UrbanPiper expects the entire product catalog during sync. - However, Odoo was sending only updated products, causing issues on their end. Fix: --- - Updated the condition to ensure a full product sync is performed when any of the configured providers require it. task-4863894 Forward-Port-Of: odoo/enterprise#87470
- Fix error when trying to `Mark as Ready` an order coming from `pos_urban_piper` when using it with a Belgian blackbox. - Now we also correctly send a NS (Normal Sale) to the blackbox. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87648
Original PR description
- Fix error when trying to `Mark as Ready` an order coming from `pos_urban_piper` when using it with a Belgian blackbox. - Now we also correctly send a NS (Normal Sale) to the blackbox. task-id: 4781945 Forward-Port-Of: odoo/enterprise#87648
Contains Four improvements: - If the payment references are all identical, we allow the LCS to be less than 10 letters. - The regex matching is now case-insensitive. - The amounts are not taken into consideration anymore when auto-creating reconciliation rules. This is done as it can be very restrictive. I.e. for parking fees. - We had an issue where on choosing an account that leads to the creation of a new reconciliation model, the existing lines that should now use the new rule won't show
Original PR description
Contains Four improvements: - If the payment references are all identical, we allow the LCS to be less than 10 letters. - The regex matching is now case-insensitive. - The amounts are not taken into…
Contains Four improvements: - If the payment references are all identical, we allow the LCS to be less than 10 letters. - The regex matching is now case-insensitive. - The amounts are not taken into consideration anymore when auto-creating reconciliation rules. This is done as it can be very restrictive. I.e. for parking fees. - We had an issue where on choosing an account that leads to the creation of a new reconciliation model, the existing lines that should now use the new rule won't show it in the UI. This was partially fixed in https://github.com/odoo/enterprise/commit/6a6f4231b60d4c46267b1422bbe3308d1183fcff as it runs the matching algorithm on creation, but on the JS side, we should also reload those lines. This is taken care of here. Also, for general reconciliation rules: - Matching amounts for reco rules now have `or equal to` for the `greater than` and `lower than` selections. - The query that matched the amounts for the reconciliation used the absolute value of the line amount. This was done before as it was thought the users wouldn't care about the sign, but now we think it makes more sense to remove the absolute for some cases. For example, a rule with (Is lower than 0) should match the payable lines only. task-4863744 Forward-Port-Of: odoo/enterprise#87432
Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before. Task-4737096 Forward-Port-Of: odoo/enterprise#87628 Forward-Port-Of: odoo/enterprise#83681
Original PR description
Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before. Task-4737096 Forward-Port-Of: odoo/enterprise#87628 Forward-Port-Of: odoo/enterprise#83681
Currently, when the user language is arabic and we try to select the booking tab inside pos, a traceback appears. Steps to reproduce: ------------------- * Make sure shop has activate the booking feature * Set appointment type to "Table" * Set user language to arabic * Open pos session * Open the booking tab > Traceback: ... invalid isoformat string Why the fix: ------------ `.toFormat` was responsible for the "translation" of the date to arabic. opw-4817845 Forward-Port-Of: o
Original PR description
Currently, when the user language is arabic and we try to select the booking tab inside pos, a traceback appears. Steps to reproduce: ------------------- * Make sure shop has activate the booking feature * Set appointment type to "Table" * Set user language to arabic * Open pos session * Open the booking tab > Traceback: ... invalid isoformat string Why the fix: ------------ `.toFormat` was responsible for the "translation" of the date to arabic. opw-4817845 Forward-Port-Of: odoo/enterprise#87121
Steps to reproduce: 1. Install website_sale_renting. 2. Go to the Website -> shop, open the renting product 3. Try to set today's date as start date of the Rental Period Issue: - The default date was always set to the next day with the current time hours. That's making it impossible for users to select today's date without Adjusting the time manually. Solution: - Updated the logic for hourly rentals to set the default date next day with adding one hour from the current time, to allow
Original PR description
Steps to reproduce: 1. Install website_sale_renting. 2. Go to the Website -> shop, open the renting product 3. Try to set today's date as start date of the Rental Period Issue: - The default date was always set to the next day with the current time hours. That's making it impossible for users to select today's date without Adjusting the time manually. Solution: - Updated the logic for hourly rentals to set the default date next day with adding one hour from the current time, to allow customers to select the current date Reference-https://github.com/odoo/enterprise/commit/32b5db6242a0a9cf43002e3723442be7d0cd210a opw-4844754 Forward-Port-Of: odoo/enterprise#86908
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/enterprise#86597 Forward-Port-Of: odoo/enterprise#43574
This commit will put the accounting date in optional hide while the invoice date is put as optional show. Also adding a button to view the move. Removing the default filter on the set account wizard. task-4860306 Forward-Port-Of: odoo/enterprise#87347
Original PR description
This commit will put the accounting date in optional hide while the invoice date is put as optional show. Also adding a button to view the move. Removing the default filter on the set account wizard. task-4860306 Forward-Port-Of: odoo/enterprise#87347
In this commit: Improved recognition of multiple invoices in bank statement line when: - Bank statement line and invoices have the same `partner_id`, the amount matches their combined total, and `payment_ref` contains all invoice references - When any 2 of the 3 criteria are satisfied Also, we enhance the reconciliation logic by adding a check to match the payment memo against the bank statement line label. If a part of the memo is found exactly in the label and only one such mat
Original PR description
In this commit: Improved recognition of multiple invoices in bank statement line when: - Bank statement line and invoices have the same `partner_id`, the amount matches their combined total, and `payment_ref` contains all invoice references - When any 2 of the 3 criteria are satisfied Also, we enhance the reconciliation logic by adding a check to match the payment memo against the bank statement line label. If a part of the memo is found exactly in the label and only one such match exists, the system proceeds to reconcile it based on a second matching criterion such as amount and/or partner. Also enable full-text search for invoice references within `payment_ref` (e.g., "INV/2025/00027" found in "Payment for INV/2025/00027"). Task: 4797388, 4791517, 4852948 Co-authored-by: hatr-odoo <hatr@odoo.com> Co-authored-by: igbe-odoo <igbe@odoo.com> Forward-Port-Of: odoo/enterprise#86496
### Steps to reproduce: - Install both mrp and quality_control - Create 2 products: - FP (Final Product) - COMP (Component) tracked by SN > pu SN1 to SN4 in stock - Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product. - Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved - Click on the wheel icon > Split production > Split in 2 - On the MO-001, SN1 is reserved - Open
Original PR description
### Steps to reproduce: - Install both mrp and quality_control - Create 2 products: - FP (Final Product) - COMP (Component) tracked by SN > pu SN1 to SN4 in stock - Create a BOM for FP using COMP as…
### Steps to reproduce:
- Install both mrp and quality_control
- Create 2 products:
- FP (Final Product)
- COMP (Component) tracked by SN > pu SN1 to SN4 in stock
- Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product.
- Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved
- Click on the wheel icon > Split production > Split in 2
- On the MO-001, SN1 is reserved
- Open the operation in the shopfloor and proceed with the quality check
#### > It is currently refering to SN2 !!
- register SN3
#### > It did not alter the value of the lot referred to on MO-001. It did update the serial number present on MO-002 from SN2 to SN3.
### Cause of the issue:
Confirming the MO will in turn confirm the workorder and create a quality check for the consumed material registration of SN: https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L625-L628 https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L415-L421 At this point, the create quality check is linked to the MO but also to the first move line (sml1) of the raw move (m1) refering to SN in that MO:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L495-L503 However, the `move_id`, `move_line_id` and `production_id` are all three stored non computed fields of the `quality.check` model. The issue will then be that when the production is split, MO will be renamed MO-001 the QC will still refer to MO-001, sm1, sml1 but sml1 will be reassigned to the raw move of the new production MO-002. In particular, while the QC is still accessed from MO-001 and still refer to the raw move sm1 of MO-001, it actually updates the values MO-002 since performing these kind of quality checks actually updates the qty and lots on the move line it is related to:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/quality.py#L507-L508 Now, the reason why sml1 is reassigned to the mo to back order rather than staying on sm1 and hence on MO-001 is because the order of stock move line is altered to be reassigned by these lines during the `_split_production`:
https://github.com/odoo/odoo/blob/e4bd46930d1841fcd50bf426f5625e9495213ef7/addons/mrp/models/mrp_production.py#L1890-L1895 Currently, this order puts sml with an existing quality check after stock move lines without QC:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/quality_mrp/models/stock_move_line.py#L36-L41 As such, they will end up being assigned with the latest backorder to assign.
### Fix:
Since these kind of QC's are created at confirmation and since the first MO will not be reconfirmed, it is important that the QC created for MO-001 stays linked to that MO. In order to achieve this, move lines associated with a QC should definitely stay assigned to the first MO and the sml should therefore be ordered by these without QC last.
opw-4656240
Forward-Port-Of: odoo/enterprise#87555
Forward-Port-Of: odoo/enterprise#84606**Problem:** When internal transfer operation type has a manadatory destination in barcode, the transfer can still be validated without destination location scanned if it's a package **Steps to reproduce:** - In settings, enable the "packages" settings - Navigate to Inventory/Configuration/Warehouse Management/ Operations Types - Select "Internal Transfers", in the "Barcode App" page for Source Location, select Mandatory Scan - for "Destination Location" select "after each product"
Original PR description
**Problem:** When internal transfer operation type has a manadatory destination in barcode, the transfer can still be validated without destination location scanned if it's a package **Steps to…
**Problem:** When internal transfer operation type has a manadatory destination in barcode, the transfer can still be validated without destination location scanned if it's a package **Steps to reproduce:** - In settings, enable the "packages" settings - Navigate to Inventory/Configuration/Warehouse Management/ Operations Types - Select "Internal Transfers", in the "Barcode App" page for Source Location, select Mandatory Scan - for "Destination Location" select "after each product" - create a new storable product - Navigate to Inventory/Operations/Physical Inventory - Create a new line and select stock as the location - Select your product - In the package column, create a package and give it a name - Set a quantity > Apply - Open the barcode app, select operations and then internal transfers - Click on New and then Scan WH-Stock and the package name: PACK **Current behavior:** The validate button is higlighted in green and clickable **Expected behavior:** Because we didn't scan a destination location it shouldn't be green and clickabel **Cause of the issue:** When a package barcode is scanned, when _processBarcode calls _processPackage https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1007 Inside _processPackage barcodeData.stopped is set to true (1) and this.selectedLineVirtualId is set to false (2) https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L1532-L1533 Because of (1) _processBarcode returns here https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1008-L1011 and doesn't reach the part of the method where _selectLine is called https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1181-L1182 (Inside _selectLine the value of selectedLineVirtualId is defined https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1269-L1274 ) So as a consequence of (1) and (2) the value of this.selectedLineVirtualID is false when a package is scanned When the validate method is called when the user clicks on validate, the method uses the value of this.selectedLine https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L777-L779 Because this.selectedLineVirtualID is false, get selectedLine returns false https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L307-L309 So the if condition is false, the method is allowed to run and the error notification is not triggered **Fix:** After scanning a package there is no selectedLine so we need another condition opw-4590345 Forward-Port-Of: odoo/enterprise#87446 Forward-Port-Of: odoo/enterprise#83710
The Libro Giornale report was missing the bank (liquidity) line for payment entries, which caused the report to be unbalanced. This happened because the report is based on the standard journal report, which skips liquidity lines by default. To fix this, the `_get_export_lines_for_journal` method was updated to treat the bank line like a normal journal line, so it now appears in the report. This ensures that payment entries show both the credit and debit sides as required. Return to t
Original PR description
The Libro Giornale report was missing the bank (liquidity) line for payment entries, which caused the report to be unbalanced. This happened because the report is based on the standard journal report, which skips liquidity lines by default. To fix this, the `_get_export_lines_for_journal` method was updated to treat the bank line like a normal journal line, so it now appears in the report. This ensures that payment entries show both the credit and debit sides as required. Return to the default pdf and xml buttons name and remove _custom_options_initializer overwrite function task-4830113 Forward-Port-Of: odoo/enterprise#86984