Daily updates from Odoo
Navigate
Branch
Sunday, July 19, 2026
32 changes
3 changes
Enhancements to existing features
Online payment initiation now includes the payer's bank account information, such as account number and account holder name, when required by certain banks via Powens. This helps payment providers process bank payments more reliably and reduces failed or incomplete payment setups.
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
A Studio approval rule could incorrectly stop a user from confirming a sales order when the rule checked a field the user was not allowed to see. This fix lets the approval check run correctly in that situation, preventing unnecessary access errors while keeping the approval rule in place.
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
6 changes
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#2627054 changes
Resolved issues and error corrections
Steps to produce: --- - Install the `Sales` module. - Go to Invoicing > Configuration > Accounting > Taxes. - Open the 0% Exports tax and set a value in the `Label on Invoices.` Field under the Advanced Options tab. - Create a sale order with multiple sections, apply the 0% Exports tax to the order lines, and enable `Hide Composition` on one of the sections. - Preview the sale order. Issue: --- - The tax displayed in a collapsed section summary differs from the tax shown on regular or
Original PR description
Steps to produce: --- - Install the `Sales` module. - Go to Invoicing > Configuration > Accounting > Taxes. - Open the 0% Exports tax and set a value in the `Label on Invoices.` Field under the…
Steps to produce: --- - Install the `Sales` module. - Go to Invoicing > Configuration > Accounting > Taxes. - Open the 0% Exports tax and set a value in the `Label on Invoices.` Field under the Advanced Options tab. - Create a sale order with multiple sections, apply the 0% Exports tax to the order lines, and enable `Hide Composition` on one of the sections. - Preview the sale order. Issue: --- - The tax displayed in a collapsed section summary differs from the tax shown on regular order lines for the same tax. Root cause: --- - At [1], `_get_grouped_section_summary()` only returns `tax_labels`, which are then used when rendering the collapsed section summary. As a result, the invoice label is displayed instead of the actual tax name. Solution: --- - Add `tax_names` to the values returned by `_get_grouped_section_summary()` and use them when rendering the collapsed section summary, ensuring consistent tax information across the preview. - Also removed the unnecessary fallback in the return statement, as `res` is always populated. [1]https://github.com/odoo/odoo/blob/be0bf1365e054521ece224f5e3a4b7cbce402315/addons/sale/models/sale_order_line.py#L1572-L1604 Before: --- <img width="1068" height="156" alt="image" src="https://github.com/user-attachments/assets/8030c35e-5c73-4fed-9feb-c4729add7894" /> After: --- <img width="1057" height="143" alt="image" src="https://github.com/user-attachments/assets/336030ed-68b2-4d14-b26f-ff391257d6d4" /> opw-6294141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270544
Steps to reproduce: - Open tasks from any project or open a task form, go to the Blocked By tab, and click Add a line to open the task selection view. - Apply the `Templates` filter - Observe that non-template tasks and tasks from template projects are also shown. Cause: - The domain condition checks for `default_project_id` and falls back to `Domain.TRUE`, allowing non-template tasks and tasks from template projects to bypass template-specific filtering. Fix: - Remove the `default_p
Original PR description
Steps to reproduce: - Open tasks from any project or open a task form, go to the Blocked By tab, and click Add a line to open the task selection view. - Apply the `Templates` filter - Observe that non-template tasks and tasks from template projects are also shown. Cause: - The domain condition checks for `default_project_id` and falls back to `Domain.TRUE`, allowing non-template tasks and tasks from template projects to bypass template-specific filtering. Fix: - Remove the `default_project_id` condition and enforce only `has_template_ancestor = True` in the domain, ensuring that only actual template tasks are shown. task-5966601 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260624
`_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
Miscellaneous changes
When an incoming move of an AVCO product is validated with outgoing moves in the same batch, `_set_value()` falls back to a full standard price recomputation through `_run_average_batch(force_recompute=True)`, which searches every valued move of the products since the beginning of the history (or since their last manual valuation). In that method, the line dropship_moves = moves.filtered(lambda m: m.is_dropship) reads `is_dropship` on the whole recordset. Each read prefetches *all*
Original PR description
When an incoming move of an AVCO product is validated with outgoing moves in the same batch, `_set_value()` falls back to a full standard price recomputation through `_run_average_batch(force_recompute=True)`, which searches every valued move of the products since the beginning of the history (or since their last manual valuation).
In that method, the line
dropship_moves = moves.filtered(lambda m: m.is_dropship)
reads `is_dropship` on the whole recordset. Each read prefetches *all* stored fields of `stock.move` for the records, and nothing invalidates the cache between batches. With a large history, this materializes the entire stock.move table slice in memory before ever reaching the carefully batched loop below ("PERF avoid memoryerror").
opw-6393223
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2768841 change
Miscellaneous changes
When an incoming move of an AVCO product is validated with outgoing moves in the same batch, `_set_value()` falls back to a full standard price recomputation through `_run_average_batch(force_recompute=True)`, which searches every valued move of the products since the beginning of the history (or since their last manual valuation). In that method, the line dropship_moves = moves.filtered(lambda m: m.is_dropship) reads `is_dropship` on the whole recordset. Each read prefetches *all*
Original PR description
When an incoming move of an AVCO product is validated with outgoing moves in the same batch, `_set_value()` falls back to a full standard price recomputation through `_run_average_batch(force_recompute=True)`, which searches every valued move of the products since the beginning of the history (or since their last manual valuation).
In that method, the line
dropship_moves = moves.filtered(lambda m: m.is_dropship)
reads `is_dropship` on the whole recordset. Each read prefetches *all* stored fields of `stock.move` for the records, and nothing invalidates the cache between batches. With a large history, this materializes the entire stock.move table slice in memory before ever reaching the carefully batched loop below ("PERF avoid memoryerror").
opw-6393223
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2768841 change
Enhancements to existing features
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
17 changes
New functionality added to Odoo
Odoo now supports direct submission of German tax returns to Elster, reducing manual steps for companies filing with German tax authorities. This helps accounting teams complete compliance workflows from within Odoo and improves efficiency for German localization users.
Original PR description
This module enables users to submit their tax returns to Elster directly from Odoo. see IAP: https://github.com/odoo/iap-apps/pull/1513 task-5193637 Forward-Port-Of: odoo/enterprise#121805
Enhancements to existing features
This update adds or activates product classification codes required by Peru's SUNAT validation rules taking effect on 2026-08-01. It helps prevent Peruvian e-invoices for affected goods from being rejected because a required code is missing or inactive.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
Resolved issues and error corrections
This fixes an issue where attendee emails could show an outdated event start date after a multi-day event was rescheduled. Event registration details now refresh correctly when event dates change, helping avoid confusing or incorrect communication with attendees.
Original PR description
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to…
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to attendee and Click on Send by Email Observation: ------------------------------------------------ The event start date displayed in the email body is not updated after the event dates are modified. Issue: ------------------------------------------------ In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58 However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f * `event_begin_date` is made stored for cohort view grouping * However, the base compute method only depends on `event_id` and `event_slot_id` https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180 * When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`) * Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work * Stored computed fields only recalculate when their explicit dependencies change Solution: ------------------------------------------------ * Corrected the dependencies of `_compute_event_begin_date` to recompute value on changing the date of the event opw-6284576 Forward-Port-Of: odoo/enterprise#120184
Belgian payroll salary simulations now ignore earlier payslips from the same month when calculating amounts such as the employment bonus. This prevents past payroll data from skewing simulated results, giving HR teams a clearer estimate before running payroll.
Original PR description
Some computations such as the employment bonus rely on the previous payslips of the month. In case of salary simulation, we shouldn't take these into account to have an accurate result. task-6385091 Forward-Port-Of: odoo/enterprise#124314 Forward-Port-Of: odoo/enterprise#124081
This fixes an issue in the Sign app where signing requests could fail in debug mode when extra page comments were present. Users and testers should experience a more reliable signing flow without unexpected errors.
Original PR description
Use lastElementChild when retrieving the sign item from the target element. In debug mode, inherited templates may introduce HTML comments into the DOM. Since lastChild return a comment node, accessing classList on the returned node raises an error. Using lastElementChild ensures that the last HTML element is always retrieved, regardless of comment nodes in the DOM. Forward-Port-Of: odoo/enterprise#123991 Forward-Port-Of: odoo/enterprise#122106
Payroll frequency labels such as monthly or weekly are now marked for translation across core payroll and multiple country-specific payroll modules. This ensures employees and payroll users see these options in their selected language, improving clarity in localized employee forms.
Original PR description
Issue: ---------------------------------------- The values of the field `schedule_pay` aren't translated. Steps to reproduce: ---------------------------------------- - Switch the language to French - Open an employee form, "Paie" tab - The selection in the "Salaire" tab is not translated to French Cause: ---------------------------------------- When the selection values were moved to a method in 7a123d71925b25f26ba0a8abff0c4a159147bdd0. The strings were not declared as translatable. opw-6359395 Forward-Port-Of: odoo/enterprise#124661 Forward-Port-Of: odoo/enterprise#123718
The Rental Kanban view now correctly shows the New button alongside the custom dashboard. This removes a conflict that could prevent users from creating new rental records from that view, improving day-to-day usability.
Original PR description
The code that adds the custom dashboard conflicted with the code that adds the New button. The fix was already implemented for the list view but not for the Kanban view. This commit applies the same solution used for the list view to the Kanban view. original-task-6088445 Forward-Port-Of: odoo/enterprise#124625
Payroll processes now explicitly use only active employee-related versions when looking up records. This avoids incorrect results if inactive records are included by default, helping payroll and paid time off allocation stay accurate.
Original PR description
We cannot assume in methods that the active_test is set. Therefore, we should always add active=True in search domains. Forward-Port-Of: odoo/enterprise#124542 Forward-Port-Of: odoo/enterprise#124459
Users opening the template picker from an audit report article without a parent article will no longer see an error. Instead, the picker now opens normally and shows that no article template is available, keeping the audit report workflow usable.
Original PR description
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to…
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to reproduce: 1. Install `accountant_knowledge`. 2. Create and open a new audit report. 3. Delete all content from article (the root). 4. Click the "Load a Template" button in the helper. => Crash with `AssertionError: Invalid falsy real id.` The issue occurs because the method responsible for loading the annex to display (see: `get_suggested_templates`) expects at least one record in the recordset. When the article has no parent, the recordset is empty, causing the method to fail. Before attempting to load a template, we will check whether the article has a parent article. If no parent exists, no template will be provided to the template picker. In that case, the picker will display a helper message indicating that no article template is available to load. Task [link](https://www.odoo.com/odoo/project.task/6333859) Task-6333859 Forward-Port-Of: odoo/enterprise#121807
This fixes how salary contract updates choose the right template. When updating a contract, the system now uses the current contract version's template when available, or falls back to the offer's contract template, helping avoid incorrect document setup during HR contract changes.
Original PR description
contract update template should come from current version if any or from the offer's contract template. Task-6094733 Forward-Port-Of: odoo/enterprise#124638 Forward-Port-Of: odoo/enterprise#123450
Colombian electronic invoice XML imports now treat the listed price as the actual unit price, matching DIAN rules. This prevents incorrect negative discounts on vendor bills when imported products use quantities greater than one.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466 Forward-Port-Of: odoo/enterprise#124802 Forward-Port-Of: odoo/enterprise#122313
Fixed a display issue where numeric column headers in financial reports had incorrect padding. This improves readability and keeps report columns visually aligned for users reviewing statements such as the Balance Sheet.
Original PR description
Due to `padding: 0.25rem 0.75rem !important;` To reproduce: - Open Balance Sheet - Check the Balance column numeric-header Forward-Port-Of: odoo/enterprise#124615
This fix prevents unrelated screen filters from interfering when payment documents are generated for Mexican electronic invoices. It avoids an error that could block users from updating payments after reconciling invoices, making the accounting workflow more reliable.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124578 Forward-Port-Of: odoo/enterprise#124074
This fixes an issue where Chilean point-of-sale receipts could fail to print when they included the official SII barcode. Businesses using Chilean electronic invoicing in POS can now complete sales and provide compliant receipts without this crash.
Original PR description
Steps to reproduce: - Have a Chilean company with DTE configured (a resolution number/date and a signed boleta/factura, so the order's move has an SII barcode) - Open a PoS session, pay an order and validate it Issue: The receipt fails to render and printing crashes with: `TypeError: ctx.image.l10n_cl_sii_barcode_image.to_base64 is not a function` Cause: Commit 0b50021bdae adapted this template as part of the BinaryValue migration (odoo/odoo#244421), calling `to_base64()` on the barcode image. However `l10n_cl_sii_barcode_image` is a computed `fields.Char` that already holds a base64 string (`_pdf417_barcode` returns `b64encode(...).decode()`), not a Binary, so it is never wrapped in a `BinaryValue`. Moreover, this template is also rendered client-side by the PoS QWeb engine, where the value loaded from the server is a plain string with no `to_base64` method either. opw-6389718 Forward-Port-Of: odoo/enterprise#124660 Forward-Port-Of: odoo/enterprise#124438
Refreshing an accounting report now clears any previous search stored in the session, so exported XLSX files match what users see on screen. This prevents confusion where a report appears to show all partners but the downloaded file still contains only results from an earlier search.
Original PR description
**Steps to reproduce:** - Install account_reports - Open "Partner Ledger" (make sure there are several partners) - Make a search to only display 1 partner - Download XLSX - Without changing the search text, refresh the page - Download XLSX again **Issue:** After refresh, the search text is empty and all the partners are displayed in the report. However, in the XLSX file, only the partner from the previous search is present. **Cause:** The current search is kept in the session and used when getting the XLSX. When refreshing or leaving the page, it's still kept in the session even if the search bar has been reset. opw-6333212 Forward-Port-Of: odoo/enterprise#124685
Code cleanup and technical improvements
This update removes duplicate leave-handling logic from Planning because the same behavior is already provided by a dependency. It reduces maintenance risk without changing expected user behavior.
Original PR description
After commit https://github.com/odoo/enterprise/commit/e0b126cb1ec80743ef06784e230320a1c50041e9, `_handle_flexible_leave_interval` is already implemented in `hr_holidays_gantt` and covers the same case previously handled in `planning_holidays`. https://github.com/odoo/enterprise/blob/7ed917c1de11e29257a726efd4dafe403b9efba1/hr_holidays_gantt/models/resource_calendar.py#L17-L20 Since `planning_holidays` depends on `hr_holidays_gantt`, the duplicate implementation in `planning_holidays` is no longer necessary. **opw-6243778** Forward-Port-Of: odoo/enterprise#124477 Forward-Port-Of: odoo/enterprise#119229
This update modernizes internal user interface references across Enterprise apps so they work with the newer Owl 3 framework. It is mainly a technical cleanup that helps keep accounting, banking, reporting, and related screens stable and maintainable, with no intended functional change for end users.
Original PR description
Enterprise counterpart of the community `master-tref-pr-3-nby` migration.
Convert bridged Owl-2 refs to native Owl 3 signals across the enterprise addons:
- `useRef("x")` -> `const xRef = signal(null)`
- `t-custom-ref="x"` -> `t-ref="this.xRef"` (expression)
- `this.xRef.el` -> `this.xRef()`
Enterprise call sites of the signal-aware community shared hooks (useAutofocus,
useDateTimePicker, useStudioRef, usePosition/useSortable, useVisible,
useActiveElement, …) now pass signals; files consuming inherited/forwarded
community signals read them via `()` instead of `.el`.
Left on the bridge to match community's PR-3 residuals (not migrated in
community either):
- ai/*, knowledge/* embedded components using `useEditableDescendants`
- planning `PlannedDateRangeWithAllocatedHours` xpath into `web.DateTimeField`
- `compiled_view_root` `useRef` in stock_barcode and web_studio form renderer
related-pr: https://github.com/odoo/odoo/pull/274706