Tuesday, March 31, 2026
33 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document handling system, ensuring documents can now be reliably opened even after being renamed. This improves the overall usability of the documents feature.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#110315 Forward-Port-Of: odoo/enterprise#105602
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML files. The fix skips PDF extraction when raw data is missing, ensuring consistent file generation and preventing disruptions to the document processing workflow.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update resolves an issue where a validation check for the suspense line was failing due to a change in how the suspense line is calculated. The update ensures the suspense line is correctly formatted, preventing potential errors in the system's financial reporting. This ensures accurate data processing.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id Forward-Port-Of: odoo/enterprise#112481
This update corrects an issue preventing the SBR tax reports from being submitted correctly. Specifically, it restores the correct date format and ensures the consultant information is displayed concisely, resolving validation errors. This ensures compliance with tax reporting standards.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#112216 Forward-Port-Of: odoo/enterprise#111817
This update fixes an issue where barcode scanning with a different serial number than the reserved one didn't create a new lot in stock. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves data accuracy and reliability within the stock management system.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#112210
Forward-Port-Of: odoo/enterprise#109671This update resolves a technical issue within the Bank Reconciliation widget that could cause errors when deleting counterpart lines in bank transactions. The fix ensures the system correctly handles data props, preventing unexpected errors and improving the stability of the reconciliation process. This change impacts the Bank Reconciliation feature.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781 Forward-Port-Of: odoo/enterprise#112175
This update fixes a warning related to how work orders consume components in manufacturing. Previously, the system would incorrectly flag a lack of lots when component quantities were specified. The change now correctly generates the necessary serials, ensuring accurate tracking of component usage within work orders. This resolves a potential disruption in production workflows.
Original PR description
This commit update the test since the fix commit introduced a new behavior. Before if the manufacturing had qty_producing, it would not set the move to picked and raise an error because there is no lot. With the fix, when the production has qty_producing. It will generate the missing serial. We prefer this behavior to the old ones so we keep it. Forward-Port-Of: odoo/enterprise#106365
This update resolves an issue where AI conversations within the Odoo AI app were sometimes stuck in a self-chat loop, displaying an OOO banner. The fix ensures that AI conversations correctly identify and interact with agents, preserving the intended agent workflows. This improves the overall user experience and reliability of the AI assistant.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#112164 Forward-Port-Of: odoo/enterprise#111736
This update fixes a technical error that prevented users from correctly updating lot numbers on stock move lines. The change ensures that lot IDs are properly linked within the Odoo system, resolving a potential data inconsistency and preventing errors during inventory adjustments. This improves the reliability of stock tracking.
Original PR description
Since ce2a8f9c929, quality.check.lot_id (Many2one) was changed to lot_ids (Many2many), but the write() override in stock.move.line still assigns a raw integer to the field. This causes a ValueError when changing the lot on an MO move line. With this commit, use Command.link() to properly link the record to the Many2many field. Forward-Port-Of: odoo/enterprise#110180
This update resolves an issue where a test tour within the product catalog feature was failing due to a problem with how product selections were being tracked. The fix ensures the correct section ID is always used, preventing the tour from encountering an error and improving the overall user experience.
Original PR description
Cause: The `selectedSectionId` was not yet updated in the environment when the product was added, resulting in a `None` value being passed to `_update_order_line_info`. Fix: Use `this.env.selectedSectionId` when available, and fall back to `this.env.searchModel.selectedSection.sectionId` only if it is undefined or null. runbot-241960 Forward-Port-Of: odoo/odoo#254374
This update fixes an issue where combo prices were incorrect when multiple quantities were selected. The fix ensures that the combo price accurately reflects the total quantity of items, regardless of the customer or preset selected. This improves the accuracy of point-of-sale transactions.
Original PR description
**Steps to reproduce:** - Open the PoS - Select a combo and choose whatever - Use the numpad or keyboard to set the combo's qty to 10 - Choose another customer or preset - The price is all wrong…
**Steps to reproduce:** - Open the PoS - Select a combo and choose whatever - Use the numpad or keyboard to set the combo's qty to 10 - Choose another customer or preset - The price is all wrong **Why the fix:** Whenever we change the customer or the preset, the **setPriceList** function is triggered. In this function we recompute the combo's children lines' price. Before this commit, we assumed that the combo's parent line's qty would always be one, and the logic was written on this assumption. Meaning that when it's manually changed, the data is wrong. What really happens is that most of the children line's qty end up being treated as an extra price. This happens because in our exemple, the parent and children lines have a qty of 10, but we only set the free qty based on the assumption that the parent line has a qty of 1 on those lines https://github.com/odoo/odoo/blob/f5d5783b6a0c908127aa620ad0ec5b0008d7adf4/addons/point_of_sale/static/src/app/models/pos_order.js#L482-L485 This means that, as the free qty is rapidly depleted, we fall back on the extra products, and their unit price end up becoming the combo's base_price. We now set the right amount in the free qty based on the parent line's qty. When doing this, another problem arises, we have to multiply the children's unit price by the parent's qty, as theunit price's computation was based on the fact that weonly have a qty of one on the parent line. This is because we were still basing the unit_price the the parent's lstPrice, but this price was not using the parent's qty at all, so we need to multiply it by the parent line's qty to make it work. The unit price handling has to be done in the **computeComboItems** function, as we also need to adjust the remaining price accordingly. An access to the parent's qty was added onto the child line, to avoid adding a default parameter to the function, which should be avoided in stable if possible. opw-5266483 Forward-Port-Of: odoo/odoo#255898 Forward-Port-Of: odoo/odoo#244940
This update fixes an issue where Italy's chart of accounts was defaulting to incorrect expense and revenue accounts. The change explicitly defines the correct deferred accounts (`190200` and `270200`) within the chart template, ensuring accurate financial reporting for Italian businesses using Odoo.
Original PR description
Italy's chart template did not explicitly define deferred expense and revenue accounts, so deferred accounts fell back to the first `asset_current` and `liability_current` accounts in the chart. That could assign incorrect defaults such as `140100` and `220100`. This patch sets the intended Italian deferred accounts to `190200` and `270200` directly in the template to ensure correct configuration during chart loading. task-6076711 Forward-Port-Of: odoo/odoo#256623
This update automatically sets the correct analytic account when creating new items from the gross margin smart button within analytic accounts. Previously, new records didn't link to an account, leading to data inconsistencies. This change ensures accurate tracking of financial data within the Odoo system.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256426 Forward-Port-Of: odoo/odoo#255726
This update resolves an issue where credit notes created through 'Reverse and create invoice' didn't correctly show the original invoice's source information. The fix ensures that the source document is accurately reflected in the generated invoice PDF, improving reporting and traceability. This maintains consistent data across invoices and sales orders.
Original PR description
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source,…
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report. ### Steps to reproduce the issue: 1. Create a sales order for product A 2. Deliver product A 3. Create invoice 4. Create credit note by clicking on "Reverse and create invoice" 5. The new invoice correctly remains linked to the Sales order 6. However, the source document disapear on the PDF ### Cause of the issue: In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked. ### Reason to introduce the fix: To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF. opw-6034574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256284 Forward-Port-Of: odoo/odoo#254290
This update resolves an issue where certain XML tags were not properly removed from the Odoo import file. The change ensures that the import process accurately reflects recent updates by deleting the <report> and <act_window> tags from the import_xml.rng file. This improves the consistency and reliability of Odoo's import functionality.
Original PR description
`<report>` and `<act_window>` tags has been removed in https://github.com/odoo/odoo/pull/98138, but not in the import_xml.rng file. This commit removes the two tags from the file. Forward-Port-Of: odoo/odoo#220116
This update fixes a configuration issue with default accounting accounts for the Swiss (l10n_ch) version of Odoo. The previous misconfiguration has been corrected, ensuring accurate financial reporting for Swiss businesses using this module. This ensures compliance and reliable financial data.
Original PR description
[IMP] l10n_ch: Set default accounts in Switzerland Some defaults accounts in Switzerland were misconfigured, this commit set clean values by default task-6043978 Forward-Port-Of: odoo/odoo#255350
We've been experiencing an increase in payment failures related to an 'invalid billToPhone' error. This update corrects the way phone numbers are sent to Flutterwave, aligning with a recent change in the Flutterwave API that requires unformatted phone numbers. This resolves the payment errors and ensures smoother transactions.
Original PR description
With are recently seeing an increasing number of payments that fail with an `invalid billToPhone` error. It's unclear if it's a recent change of flutterwave API or of any intermediary payment processor, but the flutterwave v4.0.0-beta API now state to send the phone number "unformatted" - even if there is no such statement for the v3.0.0 API (that we are using), based on testing, sending the phone number "unformatted" do so seems do solve the issue. So this commit, sanitize the phone number to send it unformatted. opw-6074825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256478 Forward-Port-Of: odoo/odoo#256315
This update automatically checks out employees from attendance records when they are archived. Previously, archived employees remained checked in, leading to data inconsistencies. This change ensures accurate attendance tracking and simplifies the process of managing archived staff.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256083 Forward-Port-Of: odoo/odoo#255524
This update optimizes how the system loads partner data for self-ordering, addressing previous performance issues. By only loading essential information, the system now operates more efficiently, particularly when dealing with partners with extensive data. This results in a smoother and faster self-ordering experience.
Original PR description
Partner data loading for self-ordering was not optimized, leading to performance issues when the partner had a lot of data. This commit optimizes the partner data loading by only loading the necessary fields for self-ordering. Forward-Port-Of: odoo/odoo#256158 Forward-Port-Of: odoo/odoo#253563
This update resolves a potential instability in the testing of one2many fields within the Odoo web application. Specifically, a test was occasionally failing due to an unintended record creation. This fix prevents a second record creation, ensuring the test is more reliable and consistent.
Original PR description
This commit fixes a non deterministic one2many field test by ensuring that we don't quick create the record twice.
Before this commit, it might sometimes happen that the validation of the input ("Enter", by default) produced a second name_create. Note that in practice this is highly unlikely to happen as if the user presses Enter, the "Quick create" item in the dropdown only appears during a single frame, thus making impossible for the user to click on it.
runbot error~242204
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#256582This update significantly speeds up the Inventory Valuation report by correctly handling date comparisons across timezones. Previously, the report would slow down when the user's local time wasn't aligned with the report's UTC date. The change ensures faster report generation, especially for large inventories.
Original PR description
When accessing the Inventory Valuation report, we check if the selected date correspond to the current day:…
When accessing the Inventory Valuation report, we check if the selected date correspond to the current day: https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/report/stock_valuation_report.py#L33-L34 If the date is today, the method _run_average_batch() simply computes the value as qty_available * standard_price. But if it is not, it will replay the whole AVCO history which can be heavy. https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/models/product.py#L394-L397 The "date" variable used in the comparison is the local date obtained from the browser while fields.Date.today() returns the UTC date. In certain case, when the local timezone is not on the same day as UTC anymore, this causes the report to be very slow to load because it replays the full history when it should not. We propose to use the context_today() method instead to get the date from the user's timezone. Benchmark: | No AVCO Products | Before PR | After PR | |------------------|-----------|----------| | 12000 | > 40 s | 3 s | opw-6050007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255841
This update enhances the process for managing demo transactions in the Point of Sale system. Previously, users were permanently blocked with demo orders. Now, users can easily delete the demo transaction or sync it to the live production environment, providing greater control and flexibility.
Original PR description
Before this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` were readonly when
`l10n_jo_edi_pos_qr` was set. However, we did not take into account the fact
that `pos.order` cannot be reset once `done/paid/invoiced`; thereby blocking
the user with a demo transaction forever without any alternative.
After this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` are readonly when
`l10n_jo_edi_pos_qr and l10n_jo_edi_state == 'sent'`. Additionally, an
onchange is introduced on `l10n_jo_edi_pos_state` to clear
`l10n_jo_edi_pos_qr`. This gives back flexibility to the user to either delete
the demo mode transaction or sync them to the production endpoint.
task-5958427
Forward-Port-Of: odoo/odoo#250808This update fixes a bug in the production process that was causing consumption warnings to appear unexpectedly. The issue stemmed from an incorrect order of operations when setting production quantities, leading to inaccurate tracking of materials. The fix ensures that production quantities are correctly validated, eliminating these warnings.
Original PR description
Usecase to reproduce: - Create a BoM with a finished product and a component - Create a MO for 10 units - Produce all Expected behavior: 10 units produced Current behavior: Consumption warning It happens because the code use this order: - Set the moves raw to picked base on their quantity producing - Set the quantity producing for production without quantity. So it just don't work and the consumption warning is trigger. The fix just invert the order task: 5068382 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#245176
This update corrects an issue where QR codes generated for self-ordering pickup orders included incorrect URLs with table information. The fix ensures QR codes are generated correctly for 'pickup zone' ordering modes, preventing errors in downloaded PDFs and improving the customer experience. This resolves a previous problem with incorrect URL formatting.
Original PR description
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right…
Step to reproduce: - setup Restaurant and do the following config - set "self-ordering" -> "Qr Menu + Ordering" - set "service At" -> "pickup zone" - save and print the qr-code ( option is right there below these configs) Observation: - in downloaded pdf, we see a wrong url, which includes table_id, which shouldn't be. - QRs do not have table_id Cause: - there is issue in `generate_qr_codes_page` method, which uses table_id even if ordering mode is "pickup zone" Fix: - we only use table_id when ordering_mode = 'table'. **Before:** <img width="1002" height="397" alt="image" src="https://github.com/user-attachments/assets/e6dc50e5-6384-45b8-8ee5-817526769dc2" /> **After** <img width="1021" height="405" alt="image" src="https://github.com/user-attachments/assets/0be9b902-3870-4fc7-a409-e01265b7a1b3" /> opw-5095607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254897 Forward-Port-Of: odoo/odoo#247184
This update fixes a problem where PoS orders with additional products would prevent successful settlement from the PoS. The system now correctly calculates the unpaid amount based on the total PoS order amount, ensuring orders with multiple items can be properly settled. This resolves a previous issue preventing users from completing transactions.
Original PR description
The following commit introduced a change in compute_unpaid_amount. https://github.com/odoo/odoo/commit/b8b50a797cdc0053643f959eb2d04800163fe005 The unpaid_amount is now computed from the PoS order total instead of the settle payment order line. This causes an issue when the PoS order contains additional product lines besides the settle payment line. In such cases, the total amount may exceed the sale order amount, preventing the sale order from being settled again from the PoS. How to reproduce: - Create a sale order. - Apply a down payment in the PoS. - Add other products before validating the payment. - Ensure the total exceeds the sale order amount. - Pay the order. - Try to settle the same sale order from PoS, cannot find it. opw-5821232 Forward-Port-Of: odoo/odoo#256590 Forward-Port-Of: odoo/odoo#251387