Wednesday, October 22, 2025
11 changes · saas-18.4
Resolved issues and error corrections
Shopee orders marked as delivered but awaiting buyer confirmation will no longer be treated as delivery errors in Odoo. This prevents unnecessary error states and helps teams track fulfillment more accurately.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
Saudi e-invoices now keep the negative value of 0% tax invoice lines instead of converting it to a positive amount. This prevents unnecessary ZATCA validation warnings and helps businesses submit cleaner compliant invoices.
Original PR description
Adding a negative line with 0% tax on an invoice will make the validation succeed with a warning Steps to reproduce (with a SA company setup): - Create an invoice - Add a negative line with 0% tax - Confirm and send to Zatca Issue: The following warning can be observed in chatter [202] BR-O-08 : [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject to VAT' the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not subject to VAT'. This occurs because in the e-invoice, the tax base is transmitted in absolute value opw-5072577 Forward-Port-Of: odoo/odoo#231737
This fixes duplicated screenshots and screen recordings when automated tests fail, reducing clutter and avoiding a failure in the reporting process itself. It also saves recording frames directly as readable images, making test failure evidence more reliable if a crash interrupts processing.
Original PR description
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok`…
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok` unconditionally does the same on test failure. Do a bit of rejiggering to fix things up: - in `_wait_code_ok`, only take a screenshot for general errors, under the assumption that the log/exception code already took a screenshot for other cases (with a possibly better timing) - only save the screencast in `_wait_code_ok`, saving the screencast later should be no issue, we just might get a few more frames Also fix a screencast issue revealed by this double saving: in case where the screencast was not saved fast enough by the first trigger, `_wait_code_ok` would try to save it again and blow up as the screencast info would be half destroyed already. And finally remove the saving of screencast frames to base64 files, save them as PNG directly: writing out the files costs orders of magnitude more than base64 decoding, so we can decode upfront and avoid a bunch of faffing about, and that way if the entire thing crashes before we can `save` the screencast we do get all the frames as readable PNGs. Forward-Port-Of: odoo/odoo#232472
This fix prevents module updates from failing when default marketing tracking labels such as LinkedIn have been customized or duplicated by users. It preserves user-managed tracking data during updates, reducing disruption for teams using link tracking and live chat attribution.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
This fixes a visual inconsistency where certain website badges appeared larger than standard badges after a prior styling change. Badges now keep the expected text size, improving visual consistency across website pages.
Original PR description
| saas-18.4 and above | This PR | |--------|--------| | <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img…
| saas-18.4 and above | This PR | |--------|--------| | <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img width="437" height="392" alt="image" src="https://github.com/user-attachments/assets/b6896545-34b5-4816-a35f-5c2605d4153b" /> | Prior to Commit[^1], the front-end badges using `.badge.o_tag` were receiving a `12px` font size, which came from a rule defined in portal. This looked fine, although odd, since a style from portal was affecting the entire front end. After Commit[^1], this rule no longer exists, meaning that `.o_tag` now falls back to `0.875rem` (14px by default), while standard badges use a default font size of `0.75em` (12px by default) Since using `.badge.o_tag` never allowed overriding the `font-size` value, we fixed the issue by assigning the `--badge-font-size` CSS variable directly to the badge definition, ensuring the correct visual result. task-4900376 [^1]: https://github.com/odoo/odoo/commit/8f8a370a84d136f3d2316eb1a55c7168b7ae6ccf#diff-23677f06a9aaf2e3395e957cfb9580ce6fcc9aba2635b560fe8f15fa27707313L29 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when settling an invoice in Point of Sale if the customer’s commercial partner details were not fully loaded. The system now uses the already available partner ID, making invoice settlement more reliable for cashiers and staff.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-5112883 Forward-Port-Of: odoo/enterprise#96828
Contacts in the Dominican Republic can now use valid 11-digit Cédula tax ID numbers, not only 9-digit RNC numbers. This prevents valid customers or partners from being rejected during VAT checks.
Original PR description
**Issue** When inputting a VAT number with a length different from 9 digits, the check fails, even if the number is a valid Dominican RNC. **Steps to Reproduce** 1. Install Dominican localization and the VAT check module (base_vat), along with Contacts. 2. Go to Contacts, create a new contact for the Dominican Republic. 3. Insert "152-0000706-8" as the VAT. **Root Cause** The `check_vat_do` method only validated 9-digit RNC numbers via `stdnum.do.rnc.validate()`. 11-digit Cédula numbers are not supported. **Fix** - Updated `check_vat_do` to: * Validate 9-digit RNC numbers using `stdnum.do.rnc.validate()`. * Validate 11-digit Cédula numbers using `stdnum.luhn.validate()`. Opw-5004221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228077 Forward-Port-Of: odoo/odoo#224507
Fiscal position tax mappings now ignore inactive taxes, preventing invoices from automatically using taxes that should no longer be available. This helps keep invoice tax calculations aligned with current tax settings and reduces the risk of incorrect accounting entries.
Original PR description
With this commit we exclude inactive taxes from the tax mapping of fiscal positions. Steps: - Create a fiscal position FP that maps an active tax to an inactive one - Create an invoice, set FP and create add an invoice line with a product having the active tax -> The tax mapping is applied and the inactive tax is set, it shoudln't opw-5117775 Forward-Port-Of: odoo/odoo#231462 Forward-Port-Of: odoo/odoo#230729
A typo in Web Studio’s new field list was corrected from “Multine” to “Multiline.” This improves clarity for users creating or editing views and avoids a small but visible labeling mistake.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
Invoice terms and services now refresh in the selected customer language when that language is changed during invoice creation. This prevents customers from seeing outdated or untranslated terms on invoices, improving communication accuracy.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933 Forward-Port-Of: odoo/odoo#230800
Features or functions removed from Odoo
An obsolete setup component for advance invoicing in external tax sales was removed because it is no longer used. This reduces maintenance overhead while keeping the process aligned with Odoo's standard behavior.
Original PR description
The `wizard/` folder contained only `sale_make_invoice_advance.py`, which overrode `_prepare_down_payment_lines_values` but is no longer used. All functionality now relies on Odoo's standard implementation. Forward-Port-Of: odoo/enterprise#95608