Friday, September 12, 2025
13 changes · 18.0
Resolved issues and error corrections
Sales orders created from a contact now use the customer's preferred delivery address, matching the behavior in the Sales app. This avoids orders being sent to an older or less relevant address when customers have multiple delivery locations.
Original PR description
## Versions 17.0+ ## Issue When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery…
## Versions
17.0+
## Issue
When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery address. This fix ensures consistent behavior across both.
## Steps to reproduce
*Ensure Contacts app is installed*
*Activate "Customer Addresses" in the settings*
- Go to the Contacts app:
- Create a new contact:
- Name: C1;
- Contacts & Addresses:
- Delivery Address (Add 2 new addresses):
- D1;
- D2.
- Click the "Sales" action button:
- Create a new SO for C1 (pre-filled):
- Invoice Address: C1, D2;
- Delivery Address: C1, D2;
- Add any product with:
- Quantity: 1;
- Delivered: 1.
- Create the invoice and confirm it.
- Go back to Contacts and look for C1:
- Click the the "Sales" action button:
- Create a new SO and see the Delivery Address set to "C1, D1".
- Go to Sales app:
- Create a new SO and select C1 as customer;
- Delivery Address retrieves "C1, D2" as it is the preferred address.
## Cause
Each time an invoice is validated, the corresponding address gets a higher score.
This score is then used in the SQL ordering of customers/suppliers:
https://github.com/odoo/odoo/blob/b523f5c6d8e235a6cedb029f701a0ebd89a5f74a/addons/account/models/partner.py#L347-L354
## Fix
Apply context search mode if first call. This mimics the base behavior: https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/odoo/addons/base/views/res_partner_views.xml#L534
opw-4916381
Forward-Port-Of: odoo/odoo#225189Event email templates now use embedded images instead of web font icons for location markers. This ensures recipients see the correct visual elements in their email clients and avoids confusing duplicate or empty icons when editing event emails.
Original PR description
Font awesome classes must no be inserted into email as external servers do not use them so icons are not displayed and also because some issues occur with the email editor. This commit replaces i tags with font awesome classes in mail by images. Task-5082165
Website sitemaps no longer list the same page more than once when website controllers are customized. This keeps search engine indexing cleaner without changing which pages are included.
Original PR description
When extending controllers (e.g. `WebsiteSale.shop`), sitemap entries were duplicated because deduplication relied on the endpoint function object. Overridden methods result in different function objects but identical sitemap URLs, leading to duplicates. This commit fixes the issue by deduplicating on the generated sitemap location (`loc['loc']`) instead of the function object, ensuring unique URLs in the sitemap even when controllers are extended. Fixes #224193 Forward-Port-Of: odoo/odoo#224406
Fixed how Uruguayan electronic invoices read document numbers that begin with multiple letters. This helps ensure affected credit and debit notes are generated and validated with the correct numbering format.
Original PR description
If UY EDI document has latam document number with more than one letter at the beggining, it is needed to take in consideration all the letters and not only the first one. Task Latam side: 1352 Task Adhoc side: 53173
The journal report test was updated so it no longer depends on a payment reference staying empty in every localization setup. This prevents build failures when Czech accounting localization is installed, improving release stability without changing user-facing functionality.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479
Planning calendar exports now use the correct timezone when a shift has no assigned employee. This prevents exported shift times from being shifted incorrectly, improving calendar reliability for users working with unassigned planning slots.
Original PR description
The test `test_planning_ics_file_without_assigned_employee` failed when running without demo data because the slot timezone was `Europe/Brussels` while the employee timezone was `UTC`.
The previous code in the method `ics_datetime()` converted to the slot timezone and then relabeled it as the employee timezone with `.replace(tzinfo=...)`, which shifted the actual instant.
This change ensures that ICS datetimes are always converted using astimezone to a single target tz:
- employee tz if the slot is assigned,
- otherwise the current user tz or `UTC` as fallback.
The test was also updated to assert the correct fallback `UTC` values:
`DTSTART:20230602T080000Z`
`DTEND:20230602T170000Z`
[runbot-231213](https://runbot.odoo.com/odoo/error/231213)This fix prevents a closed connection from being misread as a different internal error during test and core connection handling. It helps keep error reporting accurate, making issues easier to diagnose and reducing misleading failures.
Original PR description
Followup to 16.0-closed-in-stop-xmo: the condition in `stop` is a `hasattr`, so we need to delete `self.ws` not set it to `None`. Setting it to `None` means the condition passes then blows up as soon as we try to use it, which means we "just" converted all the old `WebSocketConnectionClosedException` to an `AttributeError`. https://runbot.odoo.com/odoo/error/231446 Forward-Port-Of: odoo/odoo#226267
The spreadsheet interface now consistently uses the light theme because dark theme is not supported there. This prevents mixed light and dark styling, giving users a clearer and more consistent experience.
Original PR description
Spreadsheet doesn't support dark theme. This fixes some style where dark and light themes are mixed. Task: 5082593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The automation rule trigger dropdown now uses the correct background color when dark mode is enabled. This keeps the interface visually consistent and easier to read for users working in dark mode.
Original PR description
Steps: - Install `base_automation` - Enable dark mode - Open Automation rules - Create a new rule - open trigger dropdown - the dropdown background is still in light mode This commit apply $dropdown-bg on `o_field_base_automation_trigger_selection` opw-5064357 Forward-Port-Of: odoo/odoo#226116
The journal report test was updated so it no longer depends on a payment reference staying blank in all local accounting setups. This prevents false build failures when Czech localization is installed, improving release reliability without changing customer-facing behavior.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479
The attendance Gantt popup now lets users enter a checkout time for an open attendance directly in the popup. This removes a frustrating blocker for correcting attendance records without leaving the Gantt view.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978
Stripe card payment fields now use the language selected on the website instead of defaulting to the shopper's browser language. This makes checkout more consistent for multilingual websites and reduces confusion during payment.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable Stripe; 2. enable a second language on the website; 3. use second language on website; 3. go to checkout; 4. open card payment method. Issue ----- The card field values are displayed using the current browser's locale instead of the website's language. Cause ----- The `locale` parameter isn't included when connecting to the Stripe API. Solution -------- Include the lang from the `html` element via `_prepareStripeOptions`. If not present, let it fall back on the browser's locale. opw-5024805 Forward-Port-Of: odoo/odoo#226045
Fixed an issue where users with Shop Floor set as their default start page could see an error after logging in. The app now handles reloads more safely, so manufacturing users can access the Shop Floor without interruption.
Original PR description
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback…
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback after logging in. **STEP TO REPRODUCE** 1. Go in debug mode 2. Change the home action of a user to the 'Shop Floor' action (in the user form, in the preference tab). 3. log out, and log in with this user. 4. a js traceback should appear. **CAUSE** In mrp_workcenter_dialog.js, the Shop Floor action uses the `menu` service to get the name of the current app. `setCurrentMenu()` which set the current app in the `menu` service is not called before the `appName` getter is called. https://github.com/odoo/odoo/blob/5c1234085b1c1e227846b24bde55a0392779069b/addons/web/static/src/webclient/menus/menu_service.js#L29-L36 This lead to a traceback because this.menu.getCurrentApp() is `undefined`. **FIX** Workaround if the current app is undefined. We already check what is returned by `getCurrentApp()` where it is used. opw-4926317