Thursday, September 24, 2026
14 changes · 19.0
Resolved issues and error corrections
This fix makes an automated check for email template placeholders wait until the selected model is fully loaded before continuing. It reduces false test failures caused by slow server responses, helping keep releases and validations more stable without changing user-facing behavior.
Original PR description
Before this commit, mail_template_dynamic_placeholder_tour could fail when the server answers the onchange of "Applies to" slowly: Tour mail_template_dynamic_placeholder_tour failed at step Check if…
Before this commit, mail_template_dynamic_placeholder_tour could fail when the server answers the onchange of "Applies to" slowly:
Tour mail_template_dynamic_placeholder_tour failed at step Check if
the dynamic placeholder popover is opened
(trigger: div.o_model_field_selector_popover)
This happens because the tour waits a fixed 200ms after picking "Contact" before typing "#" in the subject. The popover needs the model, and the record only holds the model once the onchange answers. On runbot the answer came after 230ms, so "#" showed the "select a model" notification instead of the popover.
This commit fixes the issue by waiting for the internal link button of the many2one, which only renders once the record holds the model.
Note that this step relies on "[FIX] web: cancel the pending search on autocomplete select": without it, a search still pending on the picked value marks the input as edited, which hides that button.
https://runbot.odoo.com/odoo/error/947209
Ref commit: https://github.com/odoo/odoo/pull/287888
Forward-Port-Of: odoo/odoo#290283
Forward-Port-Of: odoo/odoo#290185This fix ensures that changes to a company’s default income and expense accounts are correctly reflected in product category fallback values when Stock Accounting is installed. Existing databases are not automatically adjusted, to avoid changing behavior unexpectedly for companies already using the system.
Original PR description
- **[CLA] Corporate signature for Scalizer SAS** - **[FIX] stock_account: missing super call** Description of the issue/feature this PR addresses: The super call was missing in the override of res.company._set_category_defaults() in stock_account. Current behavior before PR: When stock_account is installed, changing income and expense accounts in the settings *isn't* reflected on the product category fallback values. Desired behavior after PR is merged: When stock_account is installed, changing income and expense accounts in the settings **is** reflected on the product category fallback values. No migration is added: an existing database's settings aren't fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where the mail reply box could reopen its mention suggestion list after the user had closed it with Escape. This prevents the Escape key from being intercepted incorrectly, so users can reliably discard replies and automated tests are more stable.
Original PR description
Before this commit, the composer suggestion list comes back on its own after Escape closed it, as soon as the server answers the mention search. The re-opened list takes the next Escape, and the reply is never discarded. The test "reply: discard on pressing escape" fails that way on runbot: ``` Failed to find 0 of ".o-mail-Composer" (Timeout of 10 seconds). Found 1 instead. ``` This happens because NavigableList opens on every new set of options: the list first opens on the partners the store already holds, and the answer brings the ones it does not. The fetch is debounced by 250ms, so it lands between the two Escapes only on a loaded machine. This commit fixes the issue by ignoring the fetched suggestions once the user closes the list, until the search changes. Note that the test now flushes the debounced fetch right after Escape, so the race happens on every run. https://runbot.odoo.com/odoo/error/947267 Forward-Port-Of: odoo/odoo#290163
Managers assigned as an employee's Time Off approver can now access that employee's Time Off shortcut, even if they do not have broader Time Off permissions. This ensures approvers can manage the requests they are responsible for without needing unnecessary access rights.
Original PR description
Issue: A user without any rights on Time Off should still be able to manage the requests of the users he's manager of. However, the computation for `show_leaves` only considers Time Off Officers/Admins and the employee themselves, while it should also consider the employee's Time Off approver. Fix: Include the employee's Time Off approver when computing `show_leaves`, allowing them to access the employee's Time Off smart button. Reproduction Steps: 1. Set a user (e.g. Marc Demo) to "No" for Time Off. Note: If reproducing in v19, Administrator rights on Employees are also needed to access the private employee form view where the issue occurs. 2. Set that user as another employee's Time Off approver. 3. Log in as that user and open the employee's form view. 4. Observe that the Time Off smart button is not visible. Related Tickets: opw-6445714 Forward-Port-Of: odoo/odoo#281589
The contact merge process now correctly checks for linked user accounts across all selected companies before allowing a merge. This prevents multiple portal users from being accidentally attached to the same contact when company visibility settings differ.
Original PR description
Switching companies can let a contact merge bypass the check that prevents multiple users from ending up linked to the same contact. ### Steps to reproduce 1. As a user with Contact Creation rights…
Switching companies can let a contact merge bypass the check that prevents multiple users from ending up linked to the same contact. ### Steps to reproduce 1. As a user with Contact Creation rights and access to companies A and B, select company A. 2. Create two contacts with no company set and grant each portal access. 3. Select only company B. 4. Merge the contacts. The merge succeeds and links both portal users to the surviving contact. With company A selected, the same merge is correctly rejected. ### Cause The wizard checks that the contacts have at most one linked user in total, including archived users. However, it reads `user_ids` with the acting user's permissions. Company record rules hide both portal users when only B is selected, so the check finds none. The subsequent SQL update still moves both users' contact links to the surviving contact. ### Fix Use `sudo()` only for this check, since it must count every user whose link the merge would move. Retain `active_test=False` to include archived users. Add a regression test covering both company selections. opw-6586945 Forward-Port-Of: odoo/odoo#290296
Email links now keep the correct link format when copied and pasted in the HTML editor. This prevents pasted email addresses or mail links from appearing as broken links or plain text, improving content editing reliability.
Original PR description
**Current behavior before PR:** **Issue 1:** Steps to reproduce the issue: - Create a mail link in editor. - Copy link via link popover. - Paste it anywhere in editor. - Click on it to open popover. Notice that newly created link is not a correct mail link. **Issue 2:** Steps to reproduce the issue: - Copy a mail URL from google docs or from some other website. - Paste the copied link in editor. Notice that URL is pasted as plain text instead of link. This happens because when a link is copied with HTML content, `handlePasteText` is called after `handlePasteHtml`, and it ends up being pasted as html content. **Desired behavior after PR is merged:** This PR aims to ensure that mail URLs are being pasted correctly in editor. task-6462998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282954
This fixes how Odoo displays currencies with no decimal places, such as Japanese yen, when optional trailing zeroes are hidden. Amounts like 100 and 0 now remain accurate in project monetary summaries instead of losing important digits.
Original PR description
Description of the issue/feature this PR addresses: In Odoo 19.0, format_amount(..., trailing_zeroes=False) removes significant integer zeroes when the currency has no decimal places, such as JPY.…
Description of the issue/feature this PR addresses:
In Odoo 19.0, format_amount(..., trailing_zeroes=False) removes
significant integer zeroes when the currency has no decimal places,
such as JPY. Project update monetary summaries use this formatter
with trailing_zeroes disabled.
Steps to reproduce in an Odoo shell with the default JPY configuration:
```python
from odoo.tools.misc import format_amount
currency = env.ref('base.JPY')
format_amount(env, 100, currency, trailing_zeroes=False)
format_amount(env, 0, currency, trailing_zeroes=False)
```
Current behavior before PR:
The numeric part of 100 becomes 1, and the numeric part of 0
disappears. Grouped amounts can also lose digits and leave an
incomplete thousands group.
Desired behavior after PR is merged:
Preserve all integer digits for currencies without decimal places.
Only strip trailing zeroes when a fractional part is present.
Regression coverage includes zero, positive, negative and grouped
amounts, both currency symbol positions, and languages with distinct
or identical decimal and thousands separators.
Validation:
- Before the fix: the new regression test fails in 20 subcases.
- After the fix: all 9 tests in TestFormatAmountFunction and
TestFormatLangDate pass on an isolated PostgreSQL 16 database.
- git diff --check passes.
Test selection:
--test-tags=/base:TestFormatAmountFunction,/base:TestFormatLangDate
This PR also includes my signed Individual Contributor License
Agreement in doc/cla/individual/ysnkucuker.md.
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents one unauthorized editor update channel from stopping all real-time subscriptions in the same request. Users should experience fewer broken live updates because inaccessible channels are skipped instead of causing the full subscription process to fail.
Original PR description
`_build_bus_channel_list` should never raise. Otherwise, the entire request is aborted, meaning the client fails to subscribe to *all* channels, including completely unrelated channels. Instead, if a client do not have permission to subscribe to a channel, the channel should just be skipped. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287142
This fixes an error that could prevent the Leave Gantt view from opening when employee unavailability was calculated. Leave intervals are now merged in the supported way, so HR users can view schedules without interruption.
Original PR description
Description of the issue/feature this PR addresses: The `Intervals` class does not support combining two `Intervals` objects using the `+=` operator, causing a `TypeError` while adjusting employee leave intervals. Current behavior before PR: Opening the Leave Gantt view can raise the following error when employee unavailability is computed: ```text TypeError: unsupported operand type(s) for +=: 'Intervals' and 'Intervals' ``` Desired behavior after PR is merged: Adjusted leave intervals are correctly merged using the supported bitwise OR (`|=`) operator, preventing the `TypeError` and allowing the Leave Gantt view to load normally. Fixes #281190 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
German quarterly tax report XML exports now correctly include the reporting period field. This helps companies using German localization submit complete tax return files and avoids missing period information in exported reports.
Original PR description
The `Zeitraum` tag was not set when the tax return periodicity is `quarterly`. The `account_tax_periodicity` field defines `trimester` as the key for the `quarterly` label. In [account_generic_tax_report.py] though, the code compared the periodicity with the `quarterly` label instead of the `key` trimester. **Steps to reproduce**: - Install the `l10n_de_reports` module and switch to the DE Company. - Go to Accounting settings and set `Tax Return Periodicity` to `quarterly`. - Navigate to Accounting > Reporting > Tax Return. - Export the tax report as `XML`. - Open the generated XML file and observe the `Zeitraum` tag. [account_generic_tax_report.py]: https://github.com/odoo/enterprise/blob/338630decbec76580766dd3b38c3241ecfb4c77a/l10n_de_reports/models/account_generic_tax_report.py#L54 Ticket [link](https://www.odoo.com/odoo/project.task/6581536) opw-6581536 Forward-Port-Of: odoo/enterprise#132593
Invoice confirmation in Ecuadorian electronic invoicing now avoids a crash when the company partner uses a VAT number that is valid internationally but not a local RUC. This keeps users from hitting an unexpected error and ensures authorization numbers are only built from the correct Ecuadorian identification type.
Original PR description
When the VAT of an Ecuadorian company's partner contains characters other than decimal digits, confirming an invoice raises a traceback. Steps to reproduce the error: - Install ``l10n_ec_edi`` module…
When the VAT of an Ecuadorian company's partner contains characters other than decimal digits, confirming an invoice raises a traceback. Steps to reproduce the error: - Install ``l10n_ec_edi`` module and switch to EC Company - Open the partner of EC Company > Set the VAT to ``BE0477472701`` - Create a new invoice > fill the required fields > Confirm Traceback: ```py ValueError: invalid literal for int() with base 10: 'E' ``` After this [commit], companies outside the EU can use European VAT numbers. Consequently, an Ecuadorian partner can have a RUC number such as ``BE0477472701``, which is valid as a Belgian VAT number but not as a RUC. During invoice confirmation, ``_l10n_ec_set_authorization_number()`` method is called to generate the authorization number at [1], It builds the ``key_value`` using the vat of company's partner at [2]. The generated ``key_value`` is then passed to ``_l10n_ec_get_check_digit`` method, which converts each character of ``key_value`` to an integer using ``int()`` at below line. https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L830 When the VAT contains a character that cannot be converted to an integer, It will raises the above traceback. To build the ``key_value``, the company's partner vat should be RUC consisting of 13 digits. Ref: https://www.sri.gob.ec/o/sri-portlet-biblioteca-alfresco-internet/descargar/fb95cafc-a8ca-4a4c-afb6-12c4153165f0/FICHA%2520TECNICA%2520COMPROBANTES%2520ELECTR%25C3%2593NICOS%2520ESQUEMA%2520OFFLINE.pdf Solution: If the identification type of the company's partner is not RUC, return an empty string. [commit]: https://github.com/odoo/odoo/commit/a2afe3292e1cd0a4f339dc47707e469653d13ea0 [1]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L806 [2]: https://github.com/odoo/enterprise/blob/799e9e94efcc338a8f3a6b7ab85cf77f9898f005/l10n_ec_edi/models/account_move.py#L825-L826 sentry-7642961403 Related Community PR: https://github.com/odoo/odoo/pull/280047 Forward-Port-Of: odoo/enterprise#126519
This fix prevents Bulgarian SAF-T report tests from failing in environments where the optional IBAN validation component is not installed. It keeps the affected IBAN-specific scenario isolated so routine testing remains reliable without changing real customer behavior.
Original PR description
Fixes an issue that make most tests fail when the base_iban module is not installed. The BG SAF-T report requires additional information for non-iban bank accounts and thus raises errors when they are not present. If the base_iban module is not installed, the iban verification never happens and an iban account can never be flagged as such. As there is insufficient information on that iban account, it raises validation errors in most other tests. The module is automatically installed when a Bulgarian fiscal localisation is added so the problem will not occur in a real situation. It only affects the tests. To fix the issue in stable, we cannot add the module to the dependencies. The workaround to keep most of the testing logic intact is to isolate the scenario with iban accounts in its own test and skip it if the 'base_iban' module is not installed. runbot-945995
When Colombian contact data is updated in a multi-company setup, newly created related contacts now inherit the parent contact's company. This keeps customer records correctly assigned and prevents confusion or access issues between companies.
Original PR description
Problem: In l10n_co, when updating a contact's data using the "Update data" feature in a multi-company setup, the company of the newly created child contact isn't set. Solution: Set the child contact's company to match the parent contact's company when creating the record, ensuring both contacts belong to the same company. Steps to reproduce (runbot v18): 1. Install l10n_co 2. Set up two companies (Company A and Company B). 3. Create a contact with an email and NIT, and set its company to Company B. 4. Click the "Update data" button. 5. Open the newly created child contact and check its company. The company of the newly created child contact is not set. opw-6528295 Forward-Port-Of: odoo/enterprise#131049
The Luxembourg reports module now uses a working download link for the FAIA XSD file. This prevents users from receiving an empty file when preparing Luxembourg reporting files, helping compliance workflows continue smoothly.
Original PR description
The old link points to a file with zero bytes. opw-6344914 Forward-Port-Of: odoo/enterprise#132582