Tuesday, March 31, 2026
15 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML documents. The fix skips PDF extraction when raw data is missing, ensuring that documents are processed correctly and preventing errors.
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 fixes an issue where delivery slips incorrectly displayed the quantity of packaged items. The change ensures that the correct quantity (5) is shown when items are delivered in packs, resolving a discrepancy between ordered and delivered amounts. This improves accuracy in inventory management.
Original PR description
Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity. ## Steps to replicate: - Install Purchase and Inventory with demo data -…
Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity.
## Steps to replicate:
- Install Purchase and Inventory with demo data
- Settings > Enable 'Units of Measure & Packagings' and 'Packages'
- Products > Desk Pad > Purchase > Add a line > Set unit to pack of 6 and set a vendor.
- Create new RFQ with the same vendor for 'Desk pad' having quantity 10
- Confirm RFQ > Go to receipt > Details
- Create and Set Destination Package to
- LOT A 5 pack of 6
- LOT B 5 pack of 6
- Validate Delivery Order and Print the Delivery Slip
## Observed Behavior:
Both the ordered and delivered quantities are showing 30.0 (Pack of 6), but this is incorrect.
The correct quantity ordered and delivered should be 5 (Pack of 6).
## Root cause:
This unintentional behavior occurs after commit [1].
When printing the delivery slip, function [2] is triggered. The packaging quantity is calculated using `move_line.product_uom_id`. In this case, the unit of measure is `pack of 6`, because the user selected a different UoM when setting the Destination Packaging.
As a result, when `_compute_quantity` is called, it reaches condition [3], where it checks whether the unit of measure provided as `self` matches `to_unit` Since both are `pack of 6`, no conversion is performed.
Because of this, the packaging quantity is not converted as expected, and the quantity is set to 30 instead of 5.
[2]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/stock/models/stock_move_line.py#L860-L945
[3]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/uom/models/uom_uom.py#L87-L88
## Solution:
Use the uom variable instead, as it reflects the unit of measure for the product applied directly on the receipt. This ensures that the unit-of-measure conversion for packaging quantities is handled correctly.
**Before:**
<img width="824" height="244" alt="image" src="https://github.com/user-attachments/assets/ce0ae06b-7cba-46e0-929b-a51aadc0c199" />
**After:**
<img width="833" height="244" alt="image" src="https://github.com/user-attachments/assets/dff563ef-e05c-4b86-bd89-99e89378d152" />
[1]:
https://github.com/odoo/odoo/commit/fa606530235ac413d17dd3d58bdb0921bd811d28
opw-5930343
Forward-Port-Of: odoo/odoo#249779This update resolves an issue where Odoo displayed a misleading warning message to users when uploading files without a password. The change now correctly checks for a password during saving, eliminating the unnecessary warning and improving the user experience. This ensures consistent and accurate behavior.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253834
This update allows users to search for inactive accounts using their code, which was previously unavailable. The change corrects a technical issue where the search criteria for inactive accounts was not properly applied. This ensures accurate account retrieval for all account statuses.
Original PR description
# How to reproduce - Go to the chart of account - Archive any record (e.g. Code 101401) - Search with the filters : - Inactive Accounts - Account: 101401 (the code of the record) # The problem The…
# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
- Inactive Accounts
- Account: 101401 (the code of the record)
# The problem
The record that we searched for is not shown
# Cause
The domain for the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147
And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159
This is correct and the search should return what we wanted, but the code's search is overriden by:
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384
And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored
This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`
# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search
opw-6059404
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update enhances the process for managing demo transactions in the Point of Sale system. Previously, users were stuck with demo transactions indefinitely. Now, users can easily delete the demo transaction or sync it to the 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 resolves an issue where project users couldn't add customers to tasks, resulting in an access error. The fix ensures project users can now correctly update customer information on tasks, improving task management functionality. Security enhancements were also implemented to control who can modify partner phone numbers.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only Project > User access. 2. Create a new task in project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Project users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/odoo#252406
This update resolves an issue where Field Service users couldn't add customers to tasks, resulting in an access error. The fix securely updates partner records using sudo() to allow task creation, and adds view-level restrictions to control who can modify customer phone numbers. This ensures Field Service functionality is consistently available.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Field Service > User" access. 2. Create a new task in an field service project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Field service users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Used sudo() in the inverse method to update the partner phone securely, bypassing restricted access. task-5039657 Forward-Port-Of: odoo/enterprise#109668 Forward-Port-Of: odoo/enterprise#93969
This update fixes an issue where refund creation from invoices with similar items would fail due to incorrect line matching. The new algorithm now accurately identifies the best matching invoice lines based on product, price, and quantity, ensuring refunds are processed correctly. This improves the reliability of refund processing for users.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update corrects a visual inconsistency in the sale management module, ensuring that optional product tables display with the standard report table styling. The change was made in the 'web' module to avoid requiring updates for customers, and a layout configuration save is needed to apply the color change.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update fixes an issue where refund creation from invoices with similar product details would fail due to incorrect line matching. The new algorithm now accurately identifies the best matching invoice lines based on product, price, and quantity, ensuring refunds are processed correctly. This improves the reliability of refund processing for users.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update corrects a visual inconsistency in the optional product table within the sale management module. The fix ensures that this table consistently uses the standard report table styling, improving the overall user experience. A minor user action (configuring the layout) is required to fully apply the color change.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update fixes an issue where refund processing for invoices with multiple identical lines would fail. The new algorithm now accurately matches refund lines to invoices based on product, price, and quantity, preventing incorrect matching and ensuring accurate credit note processing. This improves the reliability of refund operations.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update corrects a visual inconsistency in the optional product table within the sale management module. The fix ensures that this table consistently uses the standard report table styling, improving the overall user experience. A minor step is required in the document layout configurator to apply the color change.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update corrects a visual inconsistency in the sale management module, specifically for optional product tables within reports. The fix ensures these tables now match the standard report table styling, improving the overall user experience. A user configuration step is required to apply color changes.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update corrects a visual inconsistency in the sale management module, specifically for optional product tables within reports. The fix ensures these tables now match the standard report table styling, improving the overall presentation and user experience. A slight user action is required to apply the color change from the report templates.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430