Daily updates from Odoo
Friday, July 17, 2026
9 changes · master
Resolved issues and error corrections
Employees can now access and sign signature requests sent to their private email address. The request remains linked to the employee’s existing contact record, avoiding access problems while still delivering the email to the private address.
Original PR description
Before, when a signature request was sent to an employee's private email address, a new partner was created with the private email address and the signature request was linked to that new partner. Since there is a security rule where an employee cannot access a sign request item unless the partner on it matches partner for that employee, the employee is not able to see the sign request as the linked partner to the sign request item is an entirely new partner that is not linked to the employee. To fix the issue, the sign request is now linked to the employee's partner but the email itself is sent to the employee's private email. Task-5358107
Fixes translation-related issues in accounting screens so users see consistent guidance and correctly ordered labels in their chosen language. Bank Matching now keeps the same empty-state help after reloads or language changes, and the fiscal year wizard can use natural wording in languages such as French.
Original PR description
The empty-state message in Bank Matching differs depending on how the view was reloaded. In particular, after changing language from inside the view, the message loses the sentence explaining that users can create or import bank transactions. Ensure the Bank Matching empty-state help remains consistent across all reload flows. --- The fiscal year setup wizard was building the tax periodicity label from two separate translated parts. This produces an incorrect word order in some languages, such as "TVA Périodicité" in French which is supposed to be "Périodicité TVA". Use a single translatable label instead, so translations can place the tax label where it belongs in the sentence. task-6265141
This fix ensures the Avalara tax connection is disabled when a database is neutralized, such as in test or copied environments. It helps prevent those environments from accidentally connecting to the live tax proxy service.
Original PR description
Community: https://github.com/odoo/odoo/pull/272495
This change removes unused template markers from Helpdesk knowledge base search results and eCommerce subscription product pages. It prevents harmless backend warning messages during page rendering, keeping system logs cleaner without changing the customer-facing experience.
Original PR description
When rendering specific server-side pages (Knowledge Base search results and the eCommerce subscription product page), the Python QWeb engine logs the following warning:
"Unknown directives or unused attributes: {'t-key'} from..."
The `t-key` attribute is an OWL-specific directive required for client-side `t-foreach` loops. It is not recognized by the backend Python QWeb engine and serves no purpose in server-rendered templates.
This commit removes the inert `t-key` attributes from these Python-rendered templates.
task-6385543Automatic bank reconciliation now retries failed statement lines once before discarding them. This helps avoid losing reconciliation work when temporary system issues, such as database conflicts, cause a failure.
Original PR description
The auto reconcile cron drops the lines whenever they raise an error which is an issue for things like serialization errors. Now the code retries failed lines once before dropping them to make sure it's an issue with the lines. task-6273202 Forward-Port-Of: odoo/enterprise#119383
This fix ensures Belgian payroll eco vouchers are calculated using the correct start and end date boundaries. It helps avoid incorrect voucher amounts for employees whose eligibility depends on precise payroll period dates.
Original PR description
Forward-Port-Of: odoo/enterprise#124073 Forward-Port-Of: odoo/enterprise#120166
This fix makes map pin popovers open reliably after selecting a record from the pin list. It removes a timing issue that could cause the popover to disappear unexpectedly during automated mobile testing, improving stability without changing user-facing behavior.
Original PR description
Clicking a record in the "PinList" opens a marker popover. Until now this was handled by `centerAndOpenPin`, which closed the pin list popover and then, after two `delay(0)`, centered the map and…
Clicking a record in the "PinList" opens a marker popover. Until now this was handled by `centerAndOpenPin`, which closed the pin list popover and then, after two `delay(0)`, centered the map and opened the marker popover. This was racy. Closing `pinListPopover` triggers a re-render of the view, during which all markers are removed and re-added. If that re-render happened after the popover was opened, the marker element the popover was anchored to no longer existed, and the popover closed itself through `Popover.onTargetMutate()` (which closes the popover when its target element leaves the DOM). Depending on timing, the popover would sometimes be destroyed right after being opened, making the test flaky and leaving no popover open in the browser. To fix this, `centerAndOpenPin` is split in two parts: * it now only closes `pinListPopover` and raises a `shouldOpenMarkerPopover` flag; * on the next `onPatched`, once the markers have been re-rendered, the new `centerAndOpenPinOnPatched` method centers the map on the marker and opens the popover. Opening the popover after the re-render guarantees the marker element is present, removing the race condition. runbot-error-944199
This fixes an issue where opening a Belgian Dimona declaration could fail if an employee's private street information was missing. The change ensures payroll users can continue the declaration process without an unexpected error.
Original PR description
action_open_dimona guards on `self.employee_id.private_street` but then runs re.findall on `self.private_street` Forward-Port-Of: odoo/enterprise#124029
New planning slots now use the company’s working hours in the company timezone, so default start and end times appear correctly. This prevents schedule entries from being shifted by timezone differences when no resource is selected.
Original PR description
Issue: ---------------------------------------- When creating a new slot, no resrouces are set so we use the calendar of the company but the hours are offset because of the timezone. Steps to reproduce: ---------------------------------------- - Have planning Installed - Have an hour based calendar, from 8 to 16 each day for example - Have the company timezone in UTC+2, same for you the user - Go in Planning "Schedule By Resource" view - Click "New" - The default start and end time are 10am and 6pm (2h offset) Cause: ---------------------------------------- `default_get()` calls `_company_working_hours()` to get the company calendar hours. But they are returned in UTC, so when displaying them they are converted to the user timezone and are offsetted. Solution: ---------------------------------------- `_company_working_hours()` should return the compny hours in the company timezone. opw-6333993 Forward-Port-Of: odoo/enterprise#123033