Friday, February 13, 2026
13 changes · saas-18.4
Resolved issues and error corrections
Website domain redirects now preserve all link parameters instead of dropping information after the first parameter. This prevents broken appointment editing flows and ensures users arrive at the correct page with the required context intact.
Original PR description
Scenario from 17.0:
- set domain on website
- go to website /website/force/1?path=%2F%3Fa%3Db%26c%3Dd with another
domain
=> you are redirected to {domain}/?a=b instead of {domain}/?a=b&c=d
Scenario from 18.0:
- set domain on website
- go to /appointment/1 on other domain, select person date and time
- click on "Editor"
=> you get error:
> TypeError: AppointmentController.appointment_type_id_form() missing 1
> required positional argument: 'duration'
Cause: the /website/force/ domain redirection doesn't encode the
parameter when redirecting, so we lose parameters after the first one.
Fix: encode parameters when redirecting domain in /website/force/ route.
opw-5441957
Forward-Port-Of: odoo/odoo#248190
Forward-Port-Of: odoo/odoo#242252This fixes partner records so that when a customer's country is changed, the available identification type is updated to match that country. It prevents inconsistent records, such as a Colombian partner retaining an Argentina-specific ID type, which helps maintain cleaner localization and compliance data.
Original PR description
**PROBLEM** PR: https://github.com/odoo/odoo/pull/179078 Removed _onchange_country_id() which was used to set the identification type according to the country of the partner. This PR reintroduce it, so id type and country remains consistent. **STEP TO REPRODUCE** 1. install l10n_ar and l10n_co. 2. create a new partner. 3. set its country to Argentina, and select an argentinian id type. 4. set the country to Colombia and save. You end up with a partner from Colombia, with a id type that is used for Argentinian partners which shouldn't be possible. opw-5801824
Fixes an issue that could crash vendor bill editing when multiple purchase order lines were added and then one line was removed. This keeps billing workflows stable when working with larger sets of imported or linked lines.
Original PR description
Steps to reproduce ================== - Edit the Vendor Bill form view to set a limit of 2 on the invoice_line_ids field. - Create 2 purchase orders with the same vendor and 4 products - Create a vendor bill - Set the same vendor - Using the autocomplete field, select the first purchase order - Save the form - Select the other purchase order in the autocomplete field - Delete the record before the last one => Got duplicate key in t-foreach: datapoint_12 Cause of the issue ================== Before inserting the last 4 lines: `this._currentIds = [1, 2, 3, 4]` After the second insert, we have `this._currentIds = [1, 2, virtual_1, 3, virtual 2, virtual_3, virtual_4, 4]` Only the first record is inserted at the correct place, following ones are off by one. opw-5264594 Forward-Port-Of: odoo/odoo#248451
This fixes an issue in the HTML editor where selecting all content and deleting could remove only the last character when a non-editable item, such as a toggle list control, appeared first. It also corrects toggle list button styling so it no longer interferes with code block controls, improving editing reliability and visual consistency.
Original PR description
Description of the issue this PR addresses: - When an element with `contenteditable="false"` is the first node in the editable, pressing Ctrl+A followed by Delete does not remove the entire selection and instead deletes only the last character. Desired behavior after PR is merged: - Ensure that the selection is anchored to the deepest editable position when performing a select-all operation so that the full editable content is correctly selected and removed. Steps to reproduce: - Insert a toggle list using `/togglelist` in a new todo - Add one or more paragraphs below it and enter some text - Select all content using Ctrl+A - Press Backspace to delete the selection - Observe that only the last character is removed Backport of: 67e6a617def3bf4f9eb6b63b0850f5cfc773bccc task-5363926 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241696
Vendor invoice XML files with comments inside amount fields are now read correctly. This prevents blank invoices from being created when importing Peppol or other XML invoices that contain harmless comments.
Original PR description
Issue: Comments in node with data as text may cause issue while reading data Step to reproduce: - In European company create an invoice to a company in the same country - Send it with peppol - Download the XML of the invoice - Add a comment right before the value in TaxExclusiveAmount like this <cbc:TaxExclusiveAmount><!-- -->0.00</cbc:TaxExclusiveAmount> - Go to accounting Dashboard - Click on "Upload" in the vendor dashboard - Select the previously modified XML Current behavior: - an empty invoice is created as the invoice builder failed Expected behavior: - Invoice should be recognized Cause: lxml treat data like this: <parentNode>parent_text<childNode>child_text</childNode>child_tail</parentNode>parent_tail So `tax_exclusive_amount_node.text` return '' instead of `0.00` opw-5462664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247549
The self-ordering page now shows a clear error message if corrupted local data prevents it from loading. Users can clear stored local data and refresh directly from the page, reducing white-screen failures especially on mobile devices.
Original PR description
Inconsistent data in the localDB or local storage can cause the pos_self_rder to fail before it can get initialized. When this happens the page just stays white. Now when an error happens while initializing an error message will show up and give the user the option to clear all local data and refresh the page. This should be especially useful for users on mobile where it's a pain to refresh the local data manually. Task-[5420544](https://www.odoo.com/odoo/project/1737/tasks/5420544) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247167 Forward-Port-Of: odoo/odoo#246925
This fix ensures account code checks also consider archived accounts, not just active ones. It helps prevent duplicate account codes that could cause data issues if an archived account is restored later.
Original PR description
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#248439
Fixed a problem that prevented users from changing the address in a website Google Maps block. The map now saves the selected location correctly and refreshes without getting stuck, improving reliability for website editors.
Original PR description
When we add the google map block and try to change the address, we're unable to do so because of the infinite loop. The issue is due to the onPlaceChanged call inside the onPlaceChanged. We'll use commitPlace instead to commit place's coordinates, then re-render the map to reflect it. Steps to reproduce: 1. Add a google map block. 2. Try to change the address. It doesn't work due to the maximum call size exceeded due to infinite loop. opw-5386094
Fixed an issue where combo products without a free item could show an incorrect total price in Point of Sale. This helps ensure customers are charged accurately and sales totals remain reliable.
Original PR description
If a combo product is configured with no free item, the parent product's price was not computed in total correctly. opw-5241225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234766
Saudi Arabia invoice reports now show company-currency totals using the proper exchange-rate conversion when invoices are issued in a foreign currency. This prevents printed invoices from displaying unadjusted foreign-currency amounts as if they were company-currency totals.
Original PR description
After 267a876451da8b39ab8c5885e7198ebfeb841573 invoice report will not show the correct amount in company currency Steps to reproduce: - With SA Company setup - Create invoice in foreign currency - Print Issue: Amount in company currency have not been rate adjusted. This occurs because amount_untaxed and amount_total are expressed in foreign currency. 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#245840
This update fixes an issue where invoices sent to DIAN or Carvajal were incorrectly flagged with a warning if the invoice date was within a specific range. The change adjusts the allowed date range to align with Colombian regulations, ensuring invoices are processed correctly and avoiding unnecessary errors.
Original PR description
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid.…
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the `CO company`. - Go to `Invoicing` and create a new invoice with `taxes`. - Set the `Invoice Date` to 6 days before today. - Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice. - Observe the warning message. **Observation:** `The issue date can not be older than 5 days or more than 5 days in the future.` **Root cause:** At [1] and [2], the allowed invoice date range is incorrectly computed, using `5 days in the past` and `10 days in the future`. This does not match the Colombian regulations and triggers incorrect validation errors for valid invoice dates. These checks are intentionally implemented in both modules because they apply at different stages and for different providers: 1) `l10n_co_dian` When `DIAN: Free service` is selected as the `Electronic Invoicing Provider` from the `Invoicing Settings`, the date constraint is evaluated at `send time`. After the invoice is created, the validation is performed when the user sends the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the invoice date is outside the allowed range. 2) `l10n_co_edi` When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same rule is checked `at the confirmation time` of the draft invoice. In this case, the validation results in a `chatter message`, not a blocking send-time error. **Fix:** This commit updates the date constraint logic to allow invoices dated up to `6 days before and 6 days after` the current date, in accordance with the DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, page 59, at [3]. <img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" /> [1]: https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679 [2]: https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555 Forward-Port-Of: odoo/enterprise#107255 Forward-Port-Of: odoo/enterprise#105763
This update corrects a discrepancy in the calculation of car tax (ATN) for employees in Belgium within the Odoo Enterprise system. The update incorporates tax rates and regulations up to 2026, ensuring accurate payroll processing for Belgian businesses. This fix improves compliance and reduces the risk of errors related to car tax deductions.
Original PR description
TaskID: 5932573 Forward-Port-Of: odoo/enterprise#107237
This update resolves a bug that prevented users from correctly applying amounts to bank reconciliation lines. The fix ensures that amounts are calculated using the correct currency (amount currency) instead of balance, improving the accuracy of reconciliation processes. This change impacts how users handle both full and partial amount applications.
Original PR description
In this commit: We broke the way the apply amount work, this commit will solve that. For the apply full amount, we modified the field fetch by fetchReconciledLines and also the substraction of the amount currency to use the amount currency and not the balance For the partial, keep it like before we actually take the value of the suspense so it's ok. opw-5925046 Forward-Port-Of: odoo/enterprise#107377