Daily updates from Odoo
Sunday, July 19, 2026
6 changes · saas-19.3
Enhancements to existing features
Online payment initiation now includes the payer’s bank account details, such as account number and account holder name, when required by certain banks through Powens. This helps payment providers complete bank payment requests with fewer manual follow-ups or failed initiations.
Original PR description
With Powens, some banks requires the payer's bank information such as bank account number and bank holder name. This commit adds those informations to the odoofin route to be sent to the payment providers. task-6373634 Forward-Port-Of: odoo/enterprise#124930 Forward-Port-Of: odoo/enterprise#124088
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachment
Original PR description
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachments, 35fd6ce handles the decoding. task-6377121 Forward-Port-Of: odoo/odoo#275376
Resolved issues and error corrections
Fixed an issue where users without certain app permissions could be blocked by an error when confirming records covered by a Studio approval rule. Approval checks now run reliably even when the rule references fields the user cannot normally access, preventing unnecessary workflow interruptions.
Original PR description
Issue: A studio.approval.rule.domain includes a related field that calls an access rights group that the user who used the action isn't apart of, Is blocked by the filtered_domain. To Replicate: 1) Install studio, sale, Accounting and make sure "account_followup" is installed 2) create a related field on the sales.order form related to "customer -> follow up status" 3) Save 4) Create a "Studio Approval Rule" (studio.approval.rule) with a domain using the new related studio field -> method : "action_confirm" -> approver:admin 5) create a test user with no accounting access rights 6) in an incognito browser try and create a sales order, and then confirm it. it will throw the access rights error Fix: add a sudo to the filtered_domain opw-6316069 Forward-Port-Of: odoo/enterprise#124722 Forward-Port-Of: odoo/enterprise#121856
Mexican payroll CFDI generation now includes the employer's CURP when the company's tax ID identifies it as an individual. This prevents payroll document generation errors for businesses operating under the individual fiscal regime.
Original PR description
Issue: ---------------------------------------- There is a fiscal regime where the company is actually an individual but is authorized to generate documents. Steps to reproduce:…
Issue: ---------------------------------------- There is a fiscal regime where the company is actually an individual but is authorized to generate documents. Steps to reproduce: ---------------------------------------- - Install "l10n_mx_hr_payroll_account_edi" - Change the current company fiscal regime to '621' - Add an VAT of length 13 to the current company - Add a CURP number on the current company - In Payroll generate a payslip, validate it - Post the Journal entry - On the payslip, click "Generate CFDI" - An error is returned, saying the Emisor:Curp applies to individuals Cause: ---------------------------------------- An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'. We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML. Solution: ---------------------------------------- We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present. opw-6351558 Forward-Port-Of: odoo/enterprise#124728 Forward-Port-Of: odoo/enterprise#124027
`_send_void_request` voided the transaction using `self.provider_reference`, but voiding creates a new child transaction to carry out the request, and that child never has its own provider reference set. Authorize.Net was therefore called with an empty `refTransId` and rejected the request with "A valid referenced transaction ID is required", making the "Void Transaction" button unusable from the invoice, payment, and sale order. Use `self.source_transaction_id.provider_reference` instead, ma
Original PR description
`_send_void_request` voided the transaction using `self.provider_reference`, but voiding creates a new child transaction to carry out the request, and that child never has its own provider reference set. Authorize.Net was therefore called with an empty `refTransId` and rejected the request with "A valid referenced transaction ID is required", making the "Void Transaction" button unusable from the invoice, payment, and sale order. Use `self.source_transaction_id.provider_reference` instead, matching the pattern already used by `_send_capture_request` and `_send_refund_request`. opw-6311779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277182
Steps to reproduce: ------------------- - Install `mrp` and `sale_management` modules - Enable Units of Measure from settings - Create a storable product configured as a Kit: - Set UoM to Units - Add component and it's UoM in Kg in Product form. - Create and confirm a Sales Order with the kit product - Validate the generated delivery order - Print the delivery slip Issue: ------ The delivery slip correctly displays component quantities in Kg, but also shows an additional conve
Original PR description
Steps to reproduce: ------------------- - Install `mrp` and `sale_management` modules - Enable Units of Measure from settings - Create a storable product configured as a Kit: - Set UoM to Units - Add…
Steps to reproduce:
-------------------
- Install `mrp` and `sale_management` modules
- Enable Units of Measure from settings
- Create a storable product configured as a Kit:
- Set UoM to Units
- Add component and it's UoM in Kg in Product form.
- Create and confirm a Sales Order with the kit product
- Validate the generated delivery order
- Print the delivery slip
Issue:
------
The delivery slip correctly displays component quantities in Kg,
but also shows an additional converted quantity in Units (e.g., 1000 Units),
which is incorrect and misleading.
Cause:
------
During sale order confirmation, the following flow is executed:
`action_confirm → _action_confirm → _action_launch_stock_rule → _prepare_procurement_values`
In `_prepare_procurement_values`, the `packaging_uom_id` is set from the
sale order line UoM (Units) and propagated to the generated stock move:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/sale_stock/models/sale_order_line.py#L296
When the delivery (picking) is created, kit components generate stock moves where:
- `product_uom` is defined in the component’s UoM (e.g., Kg)
- `packaging_uom_id` remains in Units (inherited from the sale order line)
While generating the delivery slip, `_get_aggregated_product_quantities`
computes `packaging_quantity` using `packaging_uom_id`:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/models/stock_move_line.py#L888
In Mrp this calls the template:
`stock_report_delivery_aggregated_move_lines`
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/mrp/report/report_deliveryslip.xml#L60
In this template, a condition renders packaging quantities when
`packaging_uom_id` differs from `product_uom`. As a result, quantities are
converted from the component UoM (Kg) into the packaging UoM (Units).
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/report/report_deliveryslip.xml#L261
For kit components, this conversion is not meaningful and leads to incorrect
values (e.g., Kg → Units resulting in 1000 Units), causing misleading output
in the delivery slip.
Fix:
----
Add a `_compute_packaging_uom_id` override in `sale_mrp` and
`purchase_mrp` that resets `packaging_uom_id` back to
the component's own `product_uom` whenever the move originates from a
phantom BoM line, without touching `sale_line_id`/`purchase_line_id`
themselves.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/5d8b2154-d794-4ce4-90a6-1a0aeaca8604" />
</div>
<p><strong>After:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/79d708de-19e3-452d-9033-322a297c38e9" />
</div>
</details>
---
opw-6136928
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#277015
Forward-Port-Of: odoo/odoo#262705