Friday, November 28, 2025
18 changes · 18.0
New functionality added to Odoo
This update expands Odoo's payroll support to include payroll calculations for eight additional US states: Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon, and North Carolina. This enhancement ensures accurate and compliant payroll processing for businesses operating in these regions.
Original PR description
With this, we add support for 8 more states in the US payroll: Vermont, Illinois, Virginia, Washington D.C., Arizona, Idaho, Oregon and North Carolina. Task: 5247501
This update adds demo tax data and sample invoices to Odoo's Arabic localization (l10n_ar) module. This allows internal teams and reviewers to quickly test and confirm that legal tax requirements are correctly displayed without needing to set up complex tax configurations. It streamlines the verification process for new tax regulations.
Original PR description
**Purpose of the PR** This PR introduces demo data to facilitate testing of the legal requirement implemented in v16 and forward-ported to all supported versions. **What it does** - Provides demo taxes (e.g., national, other categories). - Adds demo invoices combining different taxes. **Why** The demo data allows users and reviewers to quickly verify that the correct legal legend is displayed without having to manually configure taxes and create invoices. References: Adhoc task 53768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr CLA PR: https://github.com/odoo/odoo/pull/226715
Enhancements to existing features
This update clarifies the Peppol settings within the Odoo configuration by adding a label that displays the current operating mode (demo, test, or production). Previously, users lacked clear visibility into their Peppol mode, which could lead to configuration errors. This change improves usability and reduces the risk of misconfiguration.
Original PR description
Before this PR : The Peppol settings section in the settings page did not show the current mode (demo/test/prod). Users had no clear indication of the active mode, which could lead to mistakes. After this PR : A small label is now displayed in the Peppol settings section to clearly indicate the current mode when not in production. task-5149768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves an issue where scanning invalid GS1 barcodes caused Odoo to crash. The fix corrects a formatting error in the error message, ensuring that users receive a clear and informative message when an invalid barcode is entered, improving data entry reliability.
Original PR description
**Steps to reproduce:** 1. Install Inventory. 2. Open Inventory → Configuration 3. Barcode Nomenclature and select the default GS1 Nomenclature. 4. Open Barcode → scan the code:154105510000000244.…
**Steps to reproduce:** 1. Install Inventory. 2. Open Inventory → Configuration 3. Barcode Nomenclature and select the default GS1 Nomenclature. 4. Open Barcode → scan the code:154105510000000244. **Observation:** - Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback. **Cause:** - The translated ValidationError message uses the wrong interpolation syntax: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58 and therefore fails during rendering. - Correct syntax should be: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647 **Fix:** - Fix faulty interpolation placeholder in ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly. **opw-5253564** Forward-Port-Of: odoo/odoo#236858
This update ensures that all B2C invoices generated by our Saudi Arabia localization module (l10n_sa) now correctly display "Simplified Tax Invoice" as the invoice title. Previously, this requirement was only applied to phase 2 invoices, creating a discrepancy. This change ensures compliance with Saudi regulations and improves invoice clarity for our customers.
Original PR description
For B2C invoices, the invoice's title must be "Simplified Tax Invoice". This was only applied to phase 2 ZATCA in "l10n_sa_edi". This change makes sure to apply the same requirement for phase 1 invoices. Task-5322118 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#237505
This update fixes a previous issue where website theme previews were always displayed in English, regardless of the user's selected language. Now, the theme previews automatically translate to the user's preferred language, improving the website creation experience for all users. This change was made as part of a broader effort to enhance localization within Odoo.
Original PR description
Before this change, when a user is creating a website, the three theme previews that appear at the last step are always in english, even if the user installed another language. Steps to reproduce: - Go into the user preferences and install any other language - Switch to that language - Install the website app and follow the creation steps => When you reach the theme preview step, the themes will be in english even if another language was selected After the change, the theme previews get translated and appear in the language chosen by the user. design-themes PR: https://github.com/odoo/design-themes/pull/1098 task-3415840
A test case in the account module was failing due to differences in state management between the community and enterprise versions of Odoo. This update moved the test case to the enterprise environment to ensure it accurately reflects the expected behavior, resolving the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453
A test case in the Odoo Enterprise accounting module was failing due to differences in payment state handling between the community and enterprise versions. This change moved the test case to the enterprise environment to ensure it accurately reflects the expected behavior, resolving the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453
This update corrects a visual issue in check printing for US layouts, preventing the payment date from overlapping the table below it. The fix ensures the date is always displayed correctly in the generated PDF, regardless of the bill details.
Original PR description
In the Accounting app, users can print checks created to pay Vendor Bills. When using any of the US Checks Layout (from `l10n_us_check_printing`), the payment date would overlap the table beneath it…
In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.
<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />
This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.
https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34
By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.
### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
- Set any Vendor
- Set any Bill Date
- Add any Product (with a positive price, the total price of the bill must be positive)
- Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.
This fix moves the date right above the table.
<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />
opw-5165112
Forward-Port-Of: odoo/enterprise#100487This update fixes an issue where form fields without labels were not being submitted when a user clicked the 'send' button. Now, all form fields, including those without labels, are correctly transmitted, ensuring data is captured accurately. This improves the overall user experience and data integrity for website forms.
Original PR description
Before this commit, a form input without a label would not send its data when clicking send. Steps to reproduce - go to the website editor - add a form - choose any field - delete the field label - save and exit the editor - now in the website, fill the form and click send => the fields without a name label are not sent After this commit fields without a label get sent with a placeholder "unknown_field" task-5062575 Forward-Port-Of: odoo/odoo#225545
This update ensures that the selection options for payment methods in the Point of Sale module are properly translated. Previously, these options weren't designed for internationalization, leading to potential issues with localized versions of Odoo. This change improves the user experience for customers in different languages.
Original PR description
The field `payment_method_type` got its selection values from a function that did not translate the labels. In order to make them translatable, we wrap them in a `env._()` call, so they are properly exported in the POT file and translated at runtime.
This update prevents errors when users create or modify fields with incorrect domain settings. The fix wraps a domain evaluation process in error handling, gracefully raising a validation error instead of crashing the system. This improves the reliability of field configuration within the base module.
Original PR description
Currently an error is generated when the user tries to create or write fields with wrong domain. Steps to produce an error - Install sale_management and create a new field with the below detail -…
Currently an error is generated when the user tries to create or write fields
with wrong domain.
Steps to produce an error
- Install sale_management and create a new field with the below detail
- Model: `Sales order`
- Field Type: `one2many`
- Related Model: `sale.order`
- Relation Field `partner_id`
- Domain: `[('sale_order_id', 'in', sale_order_ids)]`
- Click on save
This error occurs because we have a constraint in the domain, and it is triggered
when the user modifies the domain at code line [1]. Inside this constraint, we use
`safe_eval` to evaluate the domain. During this evaluation, an error is raised because
the user entered an incorrect domain.
This commit fixes the above issue by wrapping `safe_eval` inside a `try–except`
block and raising a `ValidationError` with an appropriate message when an error occurs during domain evaluation.
[1]- https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/odoo/addons/base/models/ir_model.py#L651-L654
sentry-6964956583This update fixes an issue where image gallery indicators would become invisible on light backgrounds when the gallery was cleared. The fix ensures indicators remain visible regardless of the gallery's content, improving the user experience for all website visitors. This resolves a visual inconsistency.
Original PR description
Steps to reproduce: - Drag and drop an “image gallery” snippet. - Click the “remove all” button in the options. - Add 3 new images to the image gallery. - Indicators and arrows become white (and therefore not visible on a light background). The issue is that the class used to determine whether the indicators should be dark is located on the carousel element, but once the snippet is emptied of images, this carousel element no longer exists. As a result, the contrast of the indicators is computed while this element is missing, causing the issue. task-5261756
This update resolves an issue where pasting formatted content (like bold or small tags) into existing regions would create nested, amplified styling, resulting in overly emphasized text. The change unwraps these nested tags to prevent this exaggeration and ensure consistent formatting.
Original PR description
### Description of the issue/feature this PR addresses: - When pasting formatted content (like `<strong>` or `<font>`) into a region that already had same formatting, it caused nested identical tags, leading to exaggerated styling (e.g., "double bold"). ```html <!-- User pastes <strong>text</strong> inside <strong> --> <p><strong>text []</strong></p> <!-- Resulting HTML --> <p><strong>text <strong>text</strong>[]</strong></p> ``` ### Desired behavior after PR is merged: - Prevents unwanted style amplification by unwrapping nested identical formatting tags. ```html <!-- Resulting HTML --> <p><strong>text text[]</strong></p> ``` task-5138472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230915
This update resolves an issue where freezing a spreadsheet containing empty data rows incorrectly reported the data as text. The fix ensures that empty strings are handled correctly when freezing, preventing inaccurate reporting and improving spreadsheet reliability. This ensures data is displayed accurately when sharing spreadsheets.
Original PR description
Steps to reproduce: - insert a list - expand the list beyond the number of records in order to have ODOO.LIST with no result - add =ISTEXT( <a reference to an empty ODOO.LIST> ) -> the result is TRUE - Freeze and share the spreadsheet => the result of ISTEXT is FALSE in the frozen version task-5360561 opw-5359100 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#237511
This update resolves a bug where account alerts weren't being computed correctly in certain situations. The fix prevents unnecessary recalculations triggered by the wizard's initial setup, avoiding a loop of computations and ensuring alerts are displayed accurately. This improves the reliability of account alerts.
Original PR description
Due to a wrong computation chain/dependencies in some cases the alerts were not correctly computed. Indeed, when the wizard opens, the `sending_method_checkboxes` are the first computed, this compute should not be re-triggered afterwards since it only depends on `move_id`. That method was using `_get_sending_settings` which gives the setup of the **current** wizard instance. It made no sense to do that since at this point in the computation it should be mostly empty, and it was therefore triggering the compute of most attributes, that themselves depends on the sending method and ended up into a loop of computation with inconsistent state. This commit also clean up a bit useless depends & "or" fallback. task-none (found while testing)
This update corrects a previous issue where the system incorrectly remembered the first invoice sending method chosen for a partner. This meant users would be repeatedly offered the same method, even if they wanted to switch to a different option like PEPPOL. This change ensures users can now easily set their preferred invoice sending method without unintended defaults.
Original PR description
Before this commit, we were setting the preferred invoice sending method on the Contact depending on what was in the first Send & Print to this specific partner. It's a bad idea because user don't know about this setting and when they want to switch the default method (example email -> peppol) the wizard will keep propose them to send it by email only and they don't know why since they never knowingly set it to "email". task-none (feedback from AVW)
This update resolves a crash that occurred when users attempted to validate signatures on employee contracts. The issue stemmed from a missing field in the system after the 'Sign, Employee Contracts, and Documents' app was uninstalled. The fix adds a safeguard to gracefully handle the absence of this field, ensuring a stable user experience.
Original PR description
The system will crash with an error when the user tries to validate the signature.
**Steps to produce:**
- Install `Sign, Employee Contracts, and Documents` apps with demo data.
- Go to Apps and uninstall the `hr_contract_sign`module.
- Send any employee a sign request for a document.
- When the employee tries to validate and send the document, the error appears.
**Error:**
`KeyError: 'sign_request_ids'
ValueError: Invalid field hr.employee.sign_request_ids in condition ('sign_request_ids', 'in', [1])`
**Cause:**
- When `sign` route is called, then we try to search field `sign_request_ids` in `hr_employee`. but we can see the field `sign_request_ids` is defined in `hr_contract_sign` module.
- And user removed the `hr_contract_sign` module, so the field no longer exists. in the hr_employee model.
**Solution:**
- Added a graceful bypass when `sign_request_ids` is missing,
**sentry-6819182542**
Forward-Port-Of: odoo/enterprise#95449