Friday, December 12, 2025
20 changes · saas-18.4
Resolved issues and error corrections
This update resolves a problem that prevented users from correctly configuring their tax returns within the Accounting module. Previously, a step was skipped during installation, leading to an error. Now, the necessary setup is completed, ensuring a smooth experience when setting accounting periods for tax returns.
Original PR description
From **saas-18.3**, when installing the accountant module, after [this PR](https://github.com/odoo/enterprise/commit/49aca723c2422fedcc8bda963a6346a172825617#diff-c703c688dc3f80644a43c96657cb2db0122b83cee9bcfa417554b0c7f1e4f550L22) the `_initiate_account_onboardings()` was not called anymore for companies that already had a chart template. This caused a traceback while configuring the Accounting Period on the Tax Returns journal: `ValueError - Expected singleton: onboarding.progress()` We now fix this behavior by ensuring that `_initiate_account_onboardings()` is called when installing the chart_template, filling the gap that was introduced. **Steps to Reproduce:** 1. Install `accountant` module without demo data. 2. Accounting > Dashboard > _Tax Returns_ Journal, click on the **"Tax Returns"** button. 3. Set an **Opening Date** in the wizard and try to apply the **Accounting Periods**. sentry-7064593163 Forward-Port-Of: odoo/enterprise#101442
This update fixes inconsistencies in how nested s_card snippets are edited, specifically related to cover images. Previously, changes to one snippet would unintentionally affect others. The fix ensures that image settings are applied correctly only to the currently edited snippet, improving the user experience and preventing unexpected visual changes.
Original PR description
This commit fixes three issues occurring when editing nested s_card snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover-image option…
This commit fixes three issues occurring when editing nested s_card snippets. **Problem 1 - Incorrect cover image detection** Issue: An `s_card` without a cover image displayed the cover-image option if it contained a child `s_card` with a cover image. Cause: `CardImageOption` and `CardImageAlignmentOption` relied on `querySelector`, which could detect images inside child snippets. Fix: The cover image detection now checks that the closest `s_card` element corresponds to the snippet being edited. **Problem 2 - Ratio settings applied to all child cards** Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested `s_card` elements. Cause: The `BuilderSelect` in `CardImageOption` targeted `.o_card_img_wrapper`, causing `classAction` to apply to all descendants. Fix: The selector is now `:scope > .o_card_img_wrapper`, ensuring the option acts only on the current snippet. **Problem 3 - Parent image positioning leaking to children** Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images. Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements mathcing `.o_card_img_wrapper`. Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`. task-5349540
This update resolves an error that occurred when users edited combo configurations on order lines. Specifically, removing the combo name and clicking the 'Edit Configuration' button triggered a technical issue. The fix ensures the configuration option is only displayed when a product template is associated with the combo, improving usability.
Original PR description
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management`…
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management` with demo and create a new SO. - Add a combo product and remove the combo name and click Edit Configuration (pencil icon). Error: `TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'` Cause: - When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered. Solution: - Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present. Similar PR for reference: https://github.com/odoo/odoo/pull/217464 [1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238536
This update fixes a bug in Odoo's logging system that caused errors when handling complex log messages, specifically those containing mappings. The fix moves the message formatting logic to a more robust location, ensuring consistent and reliable logging across the system. This improves overall system stability and reduces the risk of unexpected errors.
Original PR description
When `lower_logging` encounters a `LogRecord.args: Mapping`, it fucks up and strips out all the values keeping only the mapping keys (as a tuple), which then breaks when trying to format it in `LogRecord.msg`. Fix the issue by moving the entire message munging into, appropriately, the formatter: `getMessage` will do the `str.__mod__` call at which point we don't need to deal with the args at all, then `formatMessage` generates the full message line (not including the stack traces from `exc_info` and `stack_info`, those are added in the second half of `Formatter.format`). https://runbot.odoo.com/odoo/error/234669 Forward-Port-Of: odoo/odoo#239560 Forward-Port-Of: odoo/odoo#239410
This update corrects an issue where customer addresses were duplicated when printing Sale Orders using the DIN5008 document layout. This occurred when the 'Customer Addresses' setting was disabled. The fix ensures addresses are only displayed once, improving the clarity and accuracy of printed documents.
Original PR description
## Issue: When DIN5008 is selected as the document layout, printing a Sale Order may show the customer address twice ## Cause: The address is first added by `external_layout_din5008`, then again by `report_saleorder_document` This duplication only makes sense when the partner address differs from the invoice or delivery address If the Customer Addresses setting is disabled, displaying it multiple times is unnecessary ## Steps to reproduce: - Install a company using DIN 5008 (e.g., l10n_de) - Select the DE company and go to Settings - Disable `Customer addresses` and ensure the document layout is set to DIN 5008 - Create a Quotation with any customer and product - Print the PDF → the address appears twice before the fix opw-5176593 Forward-Port-Of: odoo/odoo#235441
This update ensures the tests within the Web Studio module accurately reflect a recent change in how suggested recipients are handled. The change allows the method to return the recipient's display name under specific conditions. This update maintains the stability and reliability of the Web Studio functionality.
Original PR description
From the related community commit, the _message_add_suggested_recipient method is modified to also return display name under certain condition. This commit adapts the test inside web_studio to align with the method's change. Task-4812554 Forward-Port-Of: odoo/enterprise#96219 Forward-Port-Of: odoo/enterprise#91003
This update ensures that a 'partner ID' is always provided when creating SEPA payments. Previously, missing this ID caused errors during batch payment creation, potentially disrupting payment processing. This change improves the reliability and stability of our payment system.
Original PR description
When doing a payment with SEPA as the payment method, and then create a batch payment out of it. It could happen that the partner_id of the payment was not set. That would cause a traceback because in the _get_CdtTrfTxInf we do a browse on the partner to use it later on. But since the partner is False, we have an empty record set. task-5213880 Forward-Port-Of: odoo/enterprise#98249
This update resolves an issue where adding a second tax to a bank reconciliation line would remove the first. Previously, the system couldn't handle multiple taxes on a single line, leading to data inconsistencies. This change ensures accurate tax calculations for bank reconciliation reports.
Original PR description
This commit will allow to add multiple taxes on a move line in the bank rec widget. For the moment, when having a line with a tax, and then add one more. The previous tax get deleted. task-5081786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226867
This update resolves a limitation preventing non-administrator users from utilizing the delivery_usps_rest module. By implementing sudo() calls, the module now grants necessary access to the USPS Rest API, expanding functionality without requiring elevated user permissions. This improves usability for a wider range of users.
Original PR description
Non-admin users are currently unable to use the delivery_usps_rest module because several fields are limited to the "base.group_system" group. It's obviously not feasible to give everyone the "Role / Administrator" role. This PR makes necessary sudo() calls the same way that delivery_ups_rest does. Forward-Port-Of: odoo/enterprise#101163
This update resolves an issue where users were encountering an error when adding an XML encoding declaration in the studio XML editor. The fix prevents this error by displaying a clearer error message, improving the user experience. This change ensures consistent XML editing within Odoo.
Original PR description
Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor. **Steps to produce:** - Install the `web_studio` module and enable `developer mode` - Open `Apps`…
Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor. **Steps to produce:** - Install the `web_studio` module and enable `developer mode` - Open `Apps` > `studio` > `view` > `</> xml` - Declare encoding as: `<?xml version='1.0' encoding='utf-8'?>` and click `save` **Error:** `ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.` **Root cause:** At [1], an error is raised when the XML declaration contains an `encoding` attribute, as encoding declarations are invalid in Unicode strings. **Fix:** This commit ensures that a `UserError` is raised, improving the error message clarity. A similar fix was applied in https://github.com/odoo/odoo/pull/205324. [1]: https://github.com/odoo/odoo/blob/8a22b6ca09e1da3ccba3540bc4851a5174e035cc/odoo/tools/translate.py#L316 sentry-6981234548 Forward-Port-Of: odoo/odoo#239743 Forward-Port-Of: odoo/odoo#233571
This update fixes a potential issue where users wouldn't receive a clear notification when attempting to close a POS session without selecting a cashier. Now, a notification will appear, preventing confusion and ensuring a smoother user experience. This enhances the reliability of the POS system.
Original PR description
After this commit, when attempting to close a POS session, if the logged-in employee is not selected, a notification will inform the user. This prevents confusion. opw-5244818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234741
This update resolves an issue preventing non-Point of Sale users from archiving products. Previously, a lack of POS access rights triggered an error, even if the product wasn't linked to any sales. This change ensures all users can archive products, improving workflow flexibility and testability.
Original PR description
### Steps to reproduce: - With Admin open a pos session - With an other user without pos access rights archive a product unrelated to pos (e.g. not used in the session) #### > Access error: You are…
### Steps to reproduce: - With Admin open a pos session - With an other user without pos access rights archive a product unrelated to pos (e.g. not used in the session) #### > Access error: You are not allowed to access 'Point of Sale Session' (pos.session) records. This operation is allowed for the following groups: - Point of Sale/User ### Cause of the issue: Since 985fd5821fe1e8633503d713f1f1c3650bcf0c91 the `action_archive` of products, check that the product is not used by an order of any opened `pos.session` before allowing the user to archive it: https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_product.py#L51-L53 https://github.com/odoo/odoo/blob/2011885246f5473ddc16fe5bd17db98ebff712f3/addons/point_of_sale/models/product_template.py#L313-L320 However, if the user does not have any pos access rights he can not access the pos session to check if the product is used which raises an access error even if the product is un-used. ### Note: This is notably problematic as it makes it impossible to archive products via the `action_archive` in unrelated stock tests relying on a non-admin user. opw-stock-tests --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239490
This update fixes an issue where the Partena export file incorrectly used the active company's code when generating reports for inactive companies. The change ensures the correct Partena code is included in the export file, resolving a potential reporting discrepancy. Tests have been added to verify this fix.
Original PR description
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install…
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company - Make sure the company has a "Partena Affiliation Number" - Create an employee for this company, with a "Partena code" - Create a contract for this employee, set it a running - Create a new Belgian company with a different "Partena Affiliation Number" - Activate both Belgian companies, but set the second one as active - Payroll > Reporting > Export work entries to Partena - Create a new one, populate it with the employee just created - Click "Generate Export File" ### Cause: When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values. ### Solution: Use `self.company_id` instead of `self.env.company_id`. Also adds the test class with basic tests. opw-5345786 Forward-Port-Of: odoo/enterprise#101110
This update fixes a minor issue where the website's interactive tour wouldn't always function correctly after a page redirect. Now, the tour automatically hides the menu after each step, providing a smoother and more intuitive user experience. This ensures new users can easily navigate the website's features.
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
This update fixes a visual issue where the reschedule button remained visible in projects with task dependencies disabled. The fix ensures the button is hidden when dependencies are turned off, providing a cleaner and more consistent user experience. This improves project management clarity.
Original PR description
Steps to reproduce: - Install the project_enterprise module. - Go to project configuration and enable task dependencies. - Open project settings and disable task dependencies. Issue: The reschedule button remains visible even when task dependencies are disabled for the project. Cause: The visibility check for the reschedule control did not consider the project’s task dependency. Fix: Hide the reschedule button when task dependencies are disabled at the project. task-5150621
This update resolves an issue where long text inputs within the Odoo Web Studio editor would overflow, causing display problems. Now, long text is automatically truncated, ensuring a clean and functional user experience. This improves usability and prevents data loss.
Original PR description
**Before this commit:** Long input text overflowed and was not truncated. **After this commit:** Long input text is now properly truncated, preventing overflow. task-5240113 Forward-Port-Of: odoo/enterprise#99535
This update fixes an issue where users without assigned tasks were not visible in the Gantt view when searching or filtering. The fix simplifies a conditional check within the project task search logic, ensuring the Gantt view accurately displays all users, regardless of task assignments. This improves the user experience and data visibility.
Original PR description
**Steps to reproduce:** Go to Project Go to All Tasks. Switch to the Gantt view. Search for an assignee who has no tasks assigned. **Cause:** The method was adding multiple conditions for the same field because both if statements were being applied. This made the domain incorrect when searching for users or custom filter on user **Issue:** The searched user’s row did not appear in the gantt view if they had no tasks. **Fix:** Changed the second if to elif so only one condition is applied at a time, ensuring the correct domain is used and the user row is visible. Task-5076701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239541 Forward-Port-Of: odoo/odoo#230319
This update ensures that user rows are always visible in the Gantt view, even when they have no assigned tasks. Previously, users without tasks were hidden. Now, searching by assignee correctly displays all tasks, including unassigned ones within a specific project, improving task management clarity.
Original PR description
**Before this commit:** When searching for an assignee in the gantt view, the corresponding row was not displayed if the user had no tasks assigned. Similarly, when applying a custom filter on the assignee also not working properly. **After this commit:** When searching or filtering by an assignee, the corresponding user row is now always visible in the gantt view, even if the user has no assigned tasks. Custom filters on assignee also work properly. task-5076701 Forward-Port-Of: odoo/enterprise#101855 Forward-Port-Of: odoo/enterprise#96531
This update resolves an issue where unscheduled shifts weren't immediately reflected in the Gantt view, requiring a page refresh. The fix ensures that shifts are updated in real-time after being unscheduled, improving scheduling accuracy and reducing user frustration. This enhances the overall planning process.
Original PR description
**Steps to reproduce:** Go to planning gantt view. Click on shift. Click on unschedule button on popover. **Issue:** When clicking on Unschedule button on a shift popover, sometimes the shift still appears and again clicking on that it cause missing error occured until the page is refreshed. **Cause:** The record wasn’t updating in the view after a shift was unscheduled, so the unscheduled shift was still showing. **Fix:** Modified the method to reload the model and notify the view immediately after calling action_unschedule, ensuring shifts reflect the latest server state without requiring a manual refresh. task-5075381 Forward-Port-Of: odoo/enterprise#97108
A small bug was causing the debugger to display incorrectly in some JavaScript files. This update ensures that whitespace is correctly preserved during the process of converting JavaScript code, preventing this visual discrepancy. This improves the consistency and reliability of our development tools.
Original PR description
Steps to reproduce
==================
- Create a js file with a blank line followed by an unnamed import
```js
import { mailModels } from "@mail/../tests/mail_test_helpers";
import "@account_accountant/components/bank_reconciliation/list_view/list_view_many2one_multi_edit";
import "@account_accountant/components/bank_reconciliation/list_view/list";
debugger;
```
- Open the devtools
=> The debugger will be off by one line
Cause of the issue
==================
When remplacing unnamed imports by a require statement, the leading whitespace was not preserved.
Solution
========
We add back the captured space. This is done for every other replacement.
Forward-Port-Of: odoo/odoo#239531