Thursday, December 4, 2025
16 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 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
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 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 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 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