Friday, December 12, 2025
17 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where users were encountering errors when adding an XML encoding declaration in the Odoo Studio XML editor. The fix ensures that the system gracefully handles this invalid input by displaying a clear error message, preventing the application from crashing. This improves the user experience and stability of the Studio environment.
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#239630 Forward-Port-Of: odoo/odoo#233571
This update resolves an issue where users encountered an error when removing a combo name and then attempting to edit its configuration. The fix ensures that the 'Edit Configuration' option is only displayed when a product template is associated with the combo, improving usability and preventing unexpected errors.
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 resolves an issue where Odoo's logging system incorrectly handled log records with complex data (like mappings). The fix moves the message formatting process to a more reliable location, ensuring consistent and accurate logging output. This improves overall system stability and reduces potential 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 a printing issue where customer addresses were duplicated on DIN 5008 Sale Order reports. The fix ensures addresses are only displayed once, specifically when the 'Customer Addresses' setting is disabled, streamlining report output and improving data clarity.
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 resolves an issue where the applicant's email address was incorrectly duplicated in recruitment communications. The fix ensures that the latest email address associated with an applicant is used, preventing confusion and improving the accuracy of email notifications. This enhances the overall applicant experience.
Original PR description
Steps to reproduce: 1- Create a job position and then create an applicant for the position with an email address. 2- Change email from the applicant form. 3- Use the chatter to send an email. 4- As seen, both old email and new email address are used as recipient addresses which shouldn't be the case. The cause was that it failed to save the new email on the partner_id associated to the hr_applicant. This was fixed by modifying the inverse function to allow the values to be modified even if already existant. task-5269650 Forward-Port-Of: odoo/odoo#236208
This update ensures payments processed with SEPA have a required 'partner ID' set. Previously, missing this ID caused errors during batch payment creation, potentially disrupting financial transactions. This change improves the stability and reliability of our payment processing 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 corrects a bug where review messages were incorrectly displayed for administrators. The fix ensures that administrators always edit their own review messages when using the 'Edit Review' button. This improves the user experience for administrators managing reviews.
Original PR description
How to reproduce: - Log as Mitchell Admin - Edit Marc Demo review using the contextual edit button - Click on save to update the review - Click on the button "Edit Review" on the top The review modals opens with the message of Marc Demo instead of the message of Mitchell Admin. The fix ensures you always edit your review message when clicking on "Edit review" button. Note: this is only possible with admin user as other users cannot edit messages of other users. So unfortunately, we had to create a new tours as we can't add steps to test_course_reviews_elearning_officer (not running as admin). An alternative would have been to extend test_fullscreen_slide_text_highlights and rename it. Task-5170310 Forward-Port-Of: odoo/odoo#238944 Forward-Port-Of: odoo/odoo#232696
This update ensures that coupon emails sent to customers display the expiration date in the localized format (e.g., yyyy-MM-dd) based on their language settings. Previously, the emails used a technical date format, leading to confusion. This change improves the customer experience and ensures accurate information delivery.
Original PR description
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount…
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount & loyalty 5. Create a record with program type coupons 6. Generate a coupon for that AU contact with an expiration date Issue: The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format. Cause: We are not using a formatted date according to the customer before: Customer with English AU language <img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" /> <img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" /> After: <img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" /> <img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" /> opw-5247621 Forward-Port-Of: odoo/odoo#237880
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.
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 fixes a potential user confusion during POS session closure. If a cashier doesn't select an employee, a notification is now displayed, guiding them to complete the process. This ensures a smoother and clearer experience for staff managing point-of-sale transactions.
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 where long text inputs within the Odoo Web Studio application would overflow, causing display problems. Now, long text is automatically truncated, ensuring a clean and usable interface for users. This improves the overall stability and user experience of the Web Studio.
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 a technical issue that prevented users from saving changes to their Point of Sale configuration. The problem stemmed from an infinite loop when updating fiscal position settings, impacting the ability to manage POS settings. This fix ensures stable configuration updates.
Original PR description
**Steps To Reproduce:-** 1. Install point_of_sale in 17.0 2. Activate flexible taxes setting 3. set default fiscal position and after that archived that fiscal position. 4. try edit and save the POS…
**Steps To Reproduce:-**
1. Install point_of_sale in 17.0
2. Activate flexible taxes setting
3. set default fiscal position and after that archived that fiscal position.
4. try edit and save the POS config any operation below mentioned recursion error will come.
**Issue :-**
Due to archived record of fiscal postion is keep updating due to not satisfying this condition [config.default_fiscal_position_id.id not in config.fiscal_position_ids.ids](https://github.com/odoo/odoo/blob/62652ba3a7a90699e7aa8ff98e2d4980f1b43694/addons/point_of_sale/models/pos_config.py#L529) here ``config.fiscal_position_ids`` on this active filter is applying and it coming empty and going to update many2many field this process goes infinite due to archive fiscal position record
**FIX:-**
adding the check of active record fiscal position
```
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
self.sudo()._set_fiscal_position()
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
self.sudo()._set_fiscal_position()
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
self.sudo()._set_fiscal_position()
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
records.write({self.name: write_value})
File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
return super(PosConfig, self).write(vals)
File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 418, in write
result = super(PosConfig, self).write(vals)
File "/data/build/odoo/odoo/models.py", line 3820, in write
field.write(self, value)
File "/data/build/odoo/odoo/fields.py", line 4287, in write
return self.write_batch([(records, value)])
File "/data/build/odoo/odoo/fields.py", line 4308, in write_batch
return self.write_real(records_commands_list, create)
File "/data/build/odoo/odoo/fields.py", line 4835, in write_real
old_relation = {record.id: set(record[self.name]._ids) for record in records}
File "/data/build/odoo/odoo/fields.py", line 4835, in <dictcomp>
old_relation = {record.id: set(record[self.name]._ids) for record in records}
File "/data/build/odoo/odoo/models.py", line 6007, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/data/build/odoo/odoo/fields.py", line 2824, in __get__
return super().__get__(records, owner)
File "/data/build/odoo/odoo/fields.py", line 1270, in __get__
return self.convert_to_record(value, record)
File "/data/build/odoo/odoo/fields.py", line 4199, in convert_to_record
corecords = corecords.filtered(Comodel._active_name).with_prefetch(prefetch_ids)
File "/data/build/odoo/odoo/models.py", line 5496, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "/data/build/odoo/odoo/models.py", line 5496, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "/data/build/odoo/odoo/models.py", line 5493, in <lambda>
func = lambda rec: any(rec.mapped(name))
File "/data/build/odoo/odoo/models.py", line 5470, in mapped
recs = recs._fields[name].mapped(recs)
File "/data/build/odoo/odoo/fields.py", line 1299, in mapped
return self.convert_to_record_multi(vals, records)
File "/data/build/odoo/odoo/fields.py", line 942, in convert_to_record_multi
return [convert(value, record) for value, record in zip(values, records)]
File "/data/build/odoo/odoo/fields.py", line 942, in <listcomp>
return [convert(value, record) for value, record in zip(values, records)]
File "/data/build/odoo/odoo/models.py", line 5844, in __iter__
yield self.__class__(self.env, (id_,), self._prefetch_ids)
RecursionError: maximum recursion depth exceeded
```
**OPW** - 5208462
**UPG** - 3248441
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#239727
Forward-Port-Of: odoo/odoo#233358This update fixes an issue where users without assigned tasks weren't visible in the Gantt view when searching or filtering by assignee. The fix streamlined the search logic to ensure the correct user rows are displayed, improving the usability of the project task visualization.
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 don't have assigned tasks. Previously, users without tasks weren't displayed, and searching by assignee was inconsistent. Now, the Gantt view accurately reflects all users and their tasks, improving project 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 fixes an issue where unscheduled shifts weren't immediately reflected in the Gantt view, requiring a page refresh. The fix ensures that changes to shift schedules are updated instantly, improving the accuracy and usability of the planning tool. This prevents confusion and ensures data consistency.
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
This update corrects a potential issue where an update failure could cause the IoT Box to incorrectly believe it's up-to-date. By retaining the original branch name during update attempts, the system avoids this misinterpretation and ensures accurate status checks.
Original PR description
We used to renamed the Odoo branch name before running the update script in order to get the target branch name easily inside it. Issue is if for any reason the update fails, when the IoT Box will restart, the branch name will be the target one, so it will assume it's up to date. Task: 5407662 Forward-Port-Of: odoo/odoo#239758 Forward-Port-Of: odoo/odoo#239508
A minor bug in the code's transpilation process was causing the debugger to display incorrectly in test files. This update ensures that whitespace is preserved when converting unnamed imports to require statements, resolving this display issue. This ensures consistent debugging behavior in our test environment.
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