Daily updates from Odoo
Thursday, December 4, 2025
23 changes · 19.0
Resolved issues and error corrections
This update allows Odoo to utilize a broader range of testing VAT numbers provided by our EDI partner, following increased usage of the EDI integration. Previously, we only supported a limited set of VATs, but this change ensures compatibility with the latest testing options offered by our provider. This improves the accuracy of VAT processing when using the EDI feature.
Original PR description
When we merged EDI for Guatemala we allowed two specific testing VATs [1]. Because our EDI is proving popular our EDI provider has now created a specific range of testing VATs just for Odoo. We allow them explicitly because they're not valid VATs. [1] 6ef9c1085cd648ad2bbd78caf4a83fe30c969d59 opw-5381791 Forward-Port-Of: odoo/odoo#238541 Forward-Port-Of: odoo/odoo#238459
This update prevents the import process from accidentally changing the names of existing journal codes. Previously, importing journal data would overwrite the original names, causing confusion and potential data inconsistencies. This fix ensures journal names remain accurate and consistent after importing data.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Go to **Accounting > Configuration > Settings**. * Download the **Import Journal Items** template. * Keep the default journal codes in…
**Steps to reproduce:** * Install the **Accounting** module. * Go to **Accounting > Configuration > Settings**. * Download the **Import Journal Items** template. * Keep the default journal codes in the template (e.g. *MISC*, *SAL*, *BNK*). * Import the file containing these existing journal codes into it by **Accounting > Configuration > Settings > Initial Setup > Import > Import Journal Items > Upload data file**. **Observed behavior:** * Existing journals have their names overwritten by the values provided in the import file. * For example, a journal with code **MISC** and name *Miscellaneous Operations* is updated to name **MISC** after import. **Cause:** * Journals are looked up by their `code`, but `_load_records()` passes both `name` and `id` for all rows. * As a result, existing journals are updated instead of preserved. **Fix:** * Pass only `id` for journals already found by code. * Pass `name` only when creating new journals. * This prevents unintended updates to existing journal names. opw-5345876 Forward-Port-Of: odoo/enterprise#100143
This update resolves an issue where the website editor could fail to open correctly under certain network conditions. By ensuring the iframe fully loads before the editor initializes, the change makes the website editing process more consistent and reliable for users. This prevents unexpected errors and improves the overall user experience.
Original PR description
In this commit, we fix a non deterministic behavior by ensuring the iframe is loaded before it try to open editor. runbot-232846 Forward-Port-Of: odoo/odoo#238054
This update fixes a confusing error message related to Acerta codes in the Belgian payroll system. The previous message was unclear, leading to potential user confusion. The fix provides a more precise and understandable validation message, ensuring accurate code entry and reducing the risk of errors.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_acerta 2. Switch to a Belgian company 3. Go to Payroll → Configuration → Work Entry Types 4. Edit a record and enter an Acerta code with only 2 characters Issue: - The validation message is missing a space between `that` and `is` - The message wording is ambiguous (PO request - fdav) Fix: - Updated the validation message to: `The following work entry types have an Acerta code that is not between 3 and 6 characters` opw-5347488 Forward-Port-Of: odoo/enterprise#100432
This update fixes an issue where Colombian e-invoices were failing validation due to incorrect tax reporting for plastic bags (INC Bolsas). The changes add specific logic to generate the correct XML format, ensuring compliance with DIAN requirements and allowing invoices with this tax to be successfully submitted.
Original PR description
Before PR: -The plastic bags tax (INC Bolsas) was not handled by a specific flow. -This resulted in incorrect XML generation for Colombian e-invoices, leading to validation errors from the DIAN. After PR: -Dedicated logic flow has been added to correctly handle the INC Bolsas tax. -Generated XML now correctly reports this tax in a separate `TaxTotal` block. -It populates the `BaseUnitMeasure` and `PerUnitAmount` fields with the fixed tax rate per bag. Impact: -Colombian e-invoices that include plastic bags tax are now generated correctly. -Ensures compliance with DIAN's specific requirements for this nominal tax. -Prevents validation errors and allows for successful submission of invoices containing this tax. task-5086926 Forward-Port-Of: odoo/enterprise#100391 Forward-Port-Of: odoo/enterprise#95311
This update fixes inconsistencies in how tax unit reports are generated, particularly for OSS reports. It ensures that multiple companies within a tax unit are correctly consolidated, and that tax returns are always linked to the appropriate main company, leading to more accurate financial reporting.
Original PR description
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit…
This PR delivers multiple fixes to ensure consistent and accurate behavior when working with tax units across OSS and standard tax return reports: [FIX] l10n_eu_oss_reports: Correct Tax Unit Detection for OSS Reports OSS reports lack a country, causing _get_available_tax_units to return no results. As a consequence, only the environment's main company was considered. This fix ensures that when multiple companies belong to the same tax unit, their OSS reports are correctly consolidated under that shared unit. [FIX] account_reports: Link Tax Unit Returns to the Main Company When generating domestic tax returns for a company that is part of a tax unit, the main company of the unit should be used since it is responsible for filing. This update ensures tax return generation is always aligned with the appropriate main company. [FIX] account_reports: Enforce Main Company When Generating Report Options get_options previously relied on the order of companies within a tax unit, assuming the first entry was the main company. Because this order is not guaranteed, the call is now explicitly scoped using with_company to ensure the main company is always used when preparing report options. Forward-Port-Of: odoo/enterprise#99715
This update restores automatic follower copying from parent sales orders to subscription renewals and upsells, aligning with expected business processes. Previously, this feature was removed for all users, but now it's specifically enabled for subscription-related orders. This ensures consistent tracking of customer relationships across the sales cycle.
Original PR description
In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181 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
This update ensures that calendar invitation emails are sent using the specified `email_from` field in the template, rather than defaulting to the event organizer's email. Previously, if the template's `email_from` was blank, the email would be sent by the organizer. This change improves email consistency and allows for customized sender addresses for calendar invites.
Original PR description
Problem: The `email_from` field of the mail template is not considered while sending calendar invites. Steps to reproduce: - Log in as admin and install `calendar`. - Open the email template named `Calendar: Meeting Invitation`. - Change the `email_from` to `"ABC" <abc@example.com>`. - Create an event with the admin as the organizer. - Add Marc demo as an attendee. - Check the invitation email: the email to Marc demo is sent by the admin instead of ABC Solution: The `email_from` field of the mail template is rendered and passed to `message_notify`. If the rendered value is empty, `None` is passed so that `_message_compute_author` computes a fallback using the `author_id`’s email (i.e. calendar event organizer or current user), ensuring the email is always sent with a valid sender. Task-5082075 Forward-Port-Of: odoo/odoo#228018
This update resolves an issue preventing the payroll demo data installation from working correctly at the start of the year. The fix sets a fixed past year for Mitchell Admin's contract, ensuring accurate demo data generation. This resolves a technical error (runbot 234612) and improves the demo's reliability.
Original PR description
Before this commit, the relative date used to generate Mitchell Admin's contract was always at January 1st of the current year, making the payroll demo data install fail when at the start of the year. This commit sets a fixed year in the past for Mitchell's contract. runbot error 234612
An issue was preventing users from uploading attachments during e-learning reviews. This update resolves a bug that occurred after a specific code change, ensuring attachments are properly transmitted with the necessary access tokens. This improves the e-learning review process and prevents upload failures.
Original PR description
Bug === Since bf759408dd63b3d6004d588251acb7bcbd2e2dee when we upload an attachment with portal in a review in e-learning, an error is raised. Task-4687269
This update fixes an issue that prevented users from successfully duplicating multiple repair orders. The previous code design couldn't handle multiple records at once, leading to errors. Now, the system correctly duplicates multiple repair orders without errors, improving the usability of this key functionality.
Original PR description
## Current behaviour: Duplicating multiple repair orders raises an error due to direct access to record fields without iterating on each record. ## Expected behaviour: Duplicating multiple repair orders should work without errors. ## Steps to reproduce: 1. Open runbot. 2. Select multiple repair orders. 3. Click "Duplicate". 4. System raises an error. ## Cause of the issue: The create/write methods assume a single record and fail when multiple records are processed at once. ## Caused by: https://github.com/odoo/enterprise/commit/16e1a97d85fc8227c73ce4a1507ab92ab7ed8486 The commit introduced logic that accesses values directly without looping over each record. ## Fix: Loop over records in create and write to handle multi-record operations. opw-5382657
This update resolves a bug that occurred when the tax upgrade script was run in different languages. The script relies on translated strings, and a mismatch in language settings caused errors. This fix ensures consistent and accurate translation during the upgrade process.
Original PR description
The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade,…
The script triggers a recompute of tax.repartition_lines_str, a tracked field that contains translated strings[^2]. If the local script is running in a different language as the rest of the upgrade, those strings will be translated in different languages and will trigger an error[^1] when they cannot be accessed in the dict. This can also fail during a local upgrade, not necesarily during an upgrade in the platform.
```
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 477, in _message_log
self._message_log_repartition_lines(tracked_value_id[2]['old_value_char'], tracked_value_id[2]['new_value_char'])
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in _message_log_repartition_lines
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 423, in <listcomp>
diff_keys = [key for key in old_value if old_value[key] != new_value[key]]
KeyError: 'Akun'
```
[^1]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L423
[^2]:https://github.com/odoo/odoo/blob/bf83a4efefedae61e06a6b29ad82e647fd673ce2/addons/account/models/account_tax.py#L393-L397
Forward-Port-Of: odoo/odoo#238368This update fixes an issue where cart notifications were incorrectly showing prices without tax, even when 'Tax Included' pricing was enabled. The fix ensures that notifications accurately reflect the total price, including taxes, for products with tax-included settings. This improves the customer experience and ensures accurate pricing information.
Original PR description
**Steps to reproduce:** * Install the **website_sale** module with demo data. * Go to *Website → Settings → eCommerce* and select **Tax Included**. * Create a product with specific **tax_ids** and…
**Steps to reproduce:** * Install the **website_sale** module with demo data. * Go to *Website → Settings → eCommerce* and select **Tax Included**. * Create a product with specific **tax_ids** and publish it on the website. * Navigate to *Website → Shop*, open the created product page. * Click **Add to Cart** to trigger the cart notification popup. * Observe the price displayed in the top-corner notification. **Observed behavior:** * The notification displays the **list price without tax**, even though *Tax Included* pricing is enabled. **Cause:** * The notification computes the price as *list_price × quantity* without checking whether taxes should be included or excluded. * Issue occur from this [commit](https://github.com/odoo/odoo/pull/184320/commits/04b7dc893039087e0f764e242c21076ce249bebf) **Fix:** * Add logic to detect whether prices should be shown tax-included or tax-excluded and assign the correct computed amount accordingly. --- opw-5350375 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the ChatGPT plugin button was disabled when no text was selected in the HTML editor. Now, the button correctly opens the chat window with the appropriate AI options, regardless of whether text is selected or not. This ensures consistent and reliable access to the plugin's features.
Original PR description
This PR fixes an issue with the toolbar button. Before when no selection were applied in the HTML Editor, the button would be disabled. This PR introduce a fix that makes the button enabled in two scenarios: - Either the user has no selection, clicking the button will then open the chat window without any AI button, as it does with the powerbox buttons, - Or the user has a selection, then clicking the button will result in opening the chat window with the AI buttons as it was already the case. If the user has a selection that is empty, then the button remains visible but is disabled.
This update resolves a problem where the departure holiday attest form in the Belgian payroll module (l10n_be_hr_payroll) was not functioning correctly. The fix ensures that employees can accurately complete and submit the necessary paperwork related to their departure holiday attestations, improving payroll processing accuracy.
This update fixes an issue where zero margins and spacing settings in reports were being ignored by the system. Now, users can accurately set all margins and spacing to zero when generating reports using wkhtmltopdf, providing greater control over report design. This ensures reports are formatted as intended.
Original PR description
When constructing the wkhtmltopdf command arguments, the system retrieves values from the `specific_paperformat_args` dictionary using get and checks whether the returned value is falsy. Because 0 is a falsy value in Python, margin and header spacing values explicitly set to 0 are mistakenly ignored. As a result, the system incorrectly falls back to the default paperformat values instead of honoring the overrides provided in `specific_paperformat_args`. This commit updates the conditional checks so that values from `specific_paperformat_args` correctly override the paperformat defaults even when the override is 0. This allows users to intentionally remove all margins and spacing defined on the report. Task-5079740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237284
This update corrects a previous issue where an IoT printer was still loaded when both an IoT and ePos printer were set up. The system now automatically prioritizes the ePos printer, ensuring the correct printer is used as intended. This improves the user experience and prevents errors in order processing.
Original PR description
When setting an IoT printer and an ePos printer, a message is displayed to inform the user the ePos printer will be used. However, this is not the case and the IoT printer is still loaded. We now avoid loading if there already is a printer. Forward-Port-Of: odoo/enterprise#101130
This update fixes an issue where the HTML editor incorrectly treated non-base container elements (like divs) as splittable. The change ensures the editor respects a configuration setting that defines eligible base containers, preventing unintended splitting behavior. This improves the stability and accuracy of the editor.
Original PR description
Since commit [1], the editor's configuration can include an array of nodes that are eligible to be base containers. That array has to be a subset of the constant `SUPPORTED_BASE_CONTAINER_NAMES`. But in some cases we failed to take the configuration into account and matched against the constant instead. In practice, this led to `div`s that aren't base containers to be considered splittable as if they were, whereas they shouldn't be. [1]: https://github.com/odoo/odoo/commit/f6bae187fbef6e7b87e10c057f721b36b551a72a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where duplicate and incorrect account rules were being created during transfer record setup. By simplifying the rule creation process, the system now accurately assigns account IDs, improving data reliability and reducing potential errors in account transfers.
Original PR description
## Steps to reproduce: 1. Create a new transfer record 2. Add more than one account to the Accounts field or add a rule with condition on Account or remove account from an Account condition with multiple accounts set ... (various other actions when adding/removing accounts) ## Before: Redundant and incorrect rules are created and an incorrect value is assigned for account_ids due to the faulty sync between the two. ## After: Removing the onchange mechanism that creates the rule with condition on Account whenever an account is added to the Accounts field, this information is redundant for the user. Also removing the onchange mechanism of the reverse (adding accounts to the Accounts field when a rule with condition on Account is added) as it cannot account for nested rules and any/all conditions. opw - 5160635
This update resolves a bug that prevented users from correctly navigating tax returns on mobile devices. The fix ensures proper data selection by adding a necessary class, preventing errors and improving the user experience when viewing returns in the mobile tax returns view.
Original PR description
To reproduce the error : Occurring in 19.0 and maybe before Open the tax returns view on mobile view Click on a return Click on the arrow to go back to the returns view Fix : The class was not there so the props was getting a null. Solution : Added the class to be selected correctly task: 5334639
This update fixes an issue where the Christmas Bonus payslip incorrectly used a standard periodicity. The change ensures the 'periodicidad_pago' is set to '99' (other periodicity) for extraordinary payroll types, accurately reflecting the bonus payment schedule. This corrects a reporting discrepancy related to Mexican payroll.
Original PR description
For the Christmas Bonus, the 'periodicidad_pago', the periodicity of the payslip, should be 99, i.e. other periodicity. Right now, it takes the periodicity from the version which is not correct. Fix: when the structure is of payroll type extraordinary, put 99 in the 'periodicidad_pago'. Task: 5344050
This update fixes an issue where category logos weren't displaying properly on the website due to spacing in the category names. The team applied a fix to ensure category names with spaces are rendered correctly, improving the visual presentation of product categories.
Original PR description
**Steps to produce:** - Install `website_sale` module. - Website > Shop > open editor > click on category of shop page. - In editor set: - content width: Full - In Categories, set style as grid. -…
**Steps to produce:** - Install `website_sale` module. - Website > Shop > open editor > click on category of shop page. - In editor set: - content width: Full - In Categories, set style as grid. - Now write the category name continuously with a space until 3 lines come in the category. - Save the changes, and set the browser window to 80% or 90%. **Issue:** - The image does not come up properly. **Root cause:** - Because our text contains spaces, and `white-space: nowrap;` is not applied It wraps the text at each space. **Solution:** - We forced the text to stay on one line using `white-space: nowrap;`. Before: <img width="159" height="116" alt="before" src="https://github.com/user-attachments/assets/a8506355-d84f-475a-be28-35e46ebe18b7" /> After: <img width="253" height="189" alt="after" src="https://github.com/user-attachments/assets/28d42d87-f128-4c7d-98ab-b76608b83989" /> **opw-5262851** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure that occurred when the demo data was used. The change ensures the test doesn't disrupt the demo environment, preventing build errors and maintaining the stability of the Odoo Enterprise system.
Original PR description
Some tests were failing when the demo data were installed. This commit fixes the test so that it doesn't interfere with demo data. Related build error: https://runbot.odoo.com/odoo/runbot.build.error/234529 task-5386529