Thursday, September 24, 2026
14 changes · saas-19.1
Resolved issues and error corrections
This fixes monetary displays for currencies such as Japanese yen so whole-number amounts keep all their digits. Business summaries and project updates will no longer show misleading values like 100 as 1 or omit zero amounts.
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-pr
Forward-Port-Of: odoo/odoo#290374This fixes an issue where an autocomplete dropdown could reopen and remain visible after a user selected a suggestion. The change prevents delayed searches from running after the dropdown is closed, reducing failed automated checks and avoiding confusing form behavior.
Original PR description
Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to…
Before this commit, the autocomplete dropdown of a many2one could open again right after a suggestion was picked, and stay open. The step of mail_template_dynamic_placeholder_tour waiting for it to close then times out:
FAILED: [8/36] Tour mail_template_dynamic_placeholder_tour
Step Wait for the drop down to disappear
(trigger: div[name="model_id"] .o-autocomplete:not(:has(.ui-autocomplete)))
TIMEOUT step failed to complete within 10000 ms.
This happens because the search filling the dropdown runs 250ms after the last keystroke, so a suggestion of the previous search can be picked while the next search is still scheduled. Picking a suggestion only closes the dropdown. The scheduled search then runs, opens the dropdown on the selected value, and nothing closes it after that.
This commit fixes the issue by discarding the scheduled search when the dropdown closes.
https://runbot.odoo.com/odoo/error/233574
https://runbot.odoo.com/odoo/error/237744
https://runbot.odoo.com/odoo/error/944454
https://runbot.odoo.com/odoo/error/945517
https://runbot.odoo.com/odoo/error/947141
Forward-Port-Of: odoo/odoo#290317
Forward-Port-Of: odoo/odoo#287888This fix prevents Point of Sale from reusing a receipt number that still belongs to an unpaid or unsynced order. It reduces the risk of duplicate receipt or invoice references being printed or sent to fiscal integrations, especially when users reload or open the same PoS in multiple browser tabs.
Original PR description
Steps to reproduce: - Add a product to a draft order, do not pay - Open the same PoS in a second tab of the same browser (the first tab is sent to the backend), or reload while a draft is being…
Steps to reproduce: - Add a product to a draft order, do not pay - Open the same PoS in a second tab of the same browser (the first tab is sent to the backend), or reload while a draft is being removed - Pay the restored draft, then make and pay a new order Issue: Both orders carry the same pos_reference (e.g. 264-3-000701). The number is printed on both receipts and sent to fiscal integrations that use it as the unique invoice number. Cause: The receipt number is issued client side by DeviceIdentifierSequence, a per-device counter kept in localStorage that all tabs of a browser share. When a draft is removed, its number is pushed on `unsynced_number_stack` to be reused by the next order. `removeOrder` pushes the number synchronously, then deletes the order from IndexedDB without waiting for the transaction. If the page unloads before it commits (the tab is closed by another tab opening the same PoS, a redirect to the backend, a reload), the next load restores the draft from IndexedDB with its number while the stack hands that same number to the next new order. Both are then created on the server with different uuids and the same pos_reference: the server only deduplicates by uuid. Fix: Before a new order takes a number, drop from the reuse stack the numbers still used by the unsynced orders this device holds: a draft restored from IndexedDB, or one whose copy another tab removed, still owns its number. The push stays synchronous, so a cancelled order is still replaced by one reusing its number. opw-6558992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287667
This fixes an internal data handling issue where temporary related many-to-many fields could incorrectly reuse a database relationship. The change prevents unrelated fields from influencing each other, helping ensure records show the correct category or role information.
Original PR description
When we setup a many2many field which is not stored, it must not have a relation. This is already done for nonrelated fields, but we must do it also for related fields. Otherwise, we may have…
When we setup a many2many field which is not stored, it must not have a relation. This is already done for nonrelated fields, but we must do it also for related fields. Otherwise, we may have side-effects like finding sibling fields in 20.0: in the code below, reading categories would fill roles.
```py
model_id = self.env["ir.model"]._get("test_new_api.foo")
fields = [{
"name": "x_partner_id",
"ttype": "many2one",
"relation": "res.partner",
}, {
"name": "x_role_ids",
"ttype": "many2many",
"relation": "res.partner.category",
}, {
"name": "x_partner_category_ids",
"ttype": "many2many",
"relation": "res.partner.category",
"related": "x_partner_id.category_id",
"store": False,
"readonly": True
}]
for f in fields:
f["model_id"] = model_id.id
self.env["ir.model.fields"].create(fields)
env['test_new_api.foo']._fields['x_partner_category_ids'].relation # should be None
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#290286
Forward-Port-Of: odoo/odoo#290067French companies can now send multiple invoices at once without the sending wizard crashing. This restores the expected batch sending flow for users working with French electronic invoicing.
Original PR description
Sending several invoices at once from the list view of a French company crashes instead of opening the batch sending wizard. Steps to reproduce: - Activate French Electronic Invoicing - Create a French customer with a valid PDP endpoint - Post two invoices for that customer, select them in the invoice list and click 'Send' Issue: The batch sending wizard raises ``` AttributeError: 'account.move.send.batch.wizard' object has no attribute 'company_id' ``` opw-6558940 Forward-Port-Of: odoo/odoo#289666 Forward-Port-Of: odoo/odoo#289547
Fixed an issue where all-day calendar events created from approved time off could become incorrectly shortened after their start time changed, such as during Google Calendar sync. This keeps multi-day absences accurately represented in calendars and avoids confusion for employees and managers.
Original PR description
**Problem:** When modifying the start time of an all-day Calendar Event created from the Validation of a Time Off Request, the end time will be shortened dramatically, no longer spanning the correct…
**Problem:** When modifying the start time of an all-day Calendar Event created from the Validation of a Time Off Request, the end time will be shortened dramatically, no longer spanning the correct timespan. In the case of the ticket referred to below, this occurs during Google Calendar sync. **Cause:** When a Calendar Event is created from a Time Off Request being Validated, its duration is set according to the amount of days the Time Off Request spans multiplied by the employee's daily work hours as defined on their contract, even if the Calendar Event will be an all-day event. When the start time of a Calendar Event is modified, the end time is recomputed according to the duration added to the new start time. As such, if the duration of the Event does not match the duration of the dates covered, it will be shortened dramatically. **Purpose:** Modify the values defined when creating a Calendar Event as a result of a Validated Time Off Request so that, if the created Event will be an all day Event, the duration is computed according to `calendar.event._get_duration`. **Steps to Reproduce in Runbot:** 1. Create and Validate a Time Off Request of the Paid Time Off leave type spanning multiple days. 2. Modify the start time of the Calendar Event that is created as a result of the validation. (This step will likely require a nonstandard flow as the start time field is normally hidden for all-day Calendar Events) opw-6426586 Forward-Port-Of: odoo/odoo#289512 Forward-Port-Of: odoo/odoo#284552
Hungarian electronic invoice exports to NAV no longer include cash rounding as a separate invoice line. This keeps reported invoice data aligned with Hungarian legal requirements and avoids treating rounding differences as taxable goods or services.
Original PR description
Global cash rounding can be applied to customer invoices. Before this commit, the rounding would be included in the XML file sent to NAV. It would be included as a new invoice line (same as the products lines) and the ATK tax is applied on it. As stated in the legal Hungarian Documentation, an invoice line should always relate to the supply of a good or the service provided. In this case, a cash rounding (which is not a financial advantage or disadvantage) will be considered by the law as a settlement difference, that is not part of the invoice. So, this commit removes cash rounding lines from the NAV XML. Moreover, it uses base_lines for the amounts computation instead of line_ids. task-6527383 Forward-Port-Of: odoo/odoo#286258
This fix ensures that if a user is not allowed to subscribe to one editor-related update channel, the system skips only that channel instead of failing the whole subscription request. This helps keep unrelated real-time updates working reliably for users.
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
German tax report XML exports now correctly fill the reporting period when the company uses quarterly tax returns. This helps ensure quarterly filings contain the expected period information and avoids incomplete tax report exports.
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#132824 Forward-Port-Of: odoo/enterprise#132593
This fix prevents Planning from showing an access error when users schedule shifts after changing their active company access. Overlap checks now only consider shifts from companies the user can currently access, avoiding crashes and preventing hidden company data from affecting scheduling.
Original PR description
Steps to Reproduce --- 1. Log in as a user with access to multiple companies (e.g., Company A and Company B). 2. Ensure both companies are ticked in the top-right multi-company widget. 3. In the…
Steps to Reproduce --- 1. Log in as a user with access to multiple companies (e.g., Company A and Company B). 2. Ensure both companies are ticked in the top-right multi-company widget. 3. In the Planning app, create a shift for an employee from 09:00 to 17:00 in Company B. 4. Remove the access of Company B 5. In the Planning Gantt view, click the same empty cell to schedule the same employee at the same time for Company A. Issue --- The _compute_overlap_slot_count method uses raw SQL to find overlapping shifts. However, this raw SQL fetches overlapping slot IDs from shifts belonging to companies the user has currently deselected or does not have access to. Current behaviour --- The raw SQL populates the conflicting_slot_ids field with inaccessible record IDs (the shift from the deselected Company B). This triggers accessError. Expected behaviour --- The system should only calculate overlapping shifts for companies the user currently has active in their environment. It should not leak the existence of shifts in deselected/unauthorized companies, and it should open the new shift dialog without crashing. Fix --- Add company_id to both raw SQL queries (for existing records and new virtual records) inside _compute_overlap_slot_count. Pass company id to ensure the database only returns conflict IDs that are valid within the user's active multi-company context. task - 4554813 Forward-Port-Of: odoo/enterprise#132745 Forward-Port-Of: odoo/enterprise#109027
Australian Payroll users can now be added to or removed from payroll groups through the Groups form without causing an error. These membership changes are also audit-logged correctly, improving compliance tracking without changing existing workflows.
Original PR description
#### Description of the issue/feature this PR addresses:
Adding a user to a group from the Groups form crashes on an Australian Payroll-API database, and removals from that form are never audit-logged.
#### Current behavior before PR:
The audit-logging mixin reads the changed users out of the raw write command with vals.get("user_ids")[0][2], which assumes a 3-element command tuple. The Groups form sends the 2-element (4, id) LINK command, so the write raises an IndexError; UNLINK commands are silently not logged for the same reason.
#### Desired behavior after PR is merged:
Group membership changes made from the Groups form are audit-logged for both additions and removals, regardless of the command used to write user_ids. The mixin reads the members before and after the write instead of interpreting the command. No field, model or method-signature change, so it is safe in stable.
opw-6397011
Forward-Port-Of: odoo/enterprise#125124The Luxembourg reports module now uses a working download link for the FAIA XSD file. This prevents failures caused by the previous link returning an empty file, helping users access the required compliance file reliably.
Original PR description
The old link points to a file with zero bytes. opw-6344914 Forward-Port-Of: odoo/enterprise#132582
When Colombian localization users update contact data in a multi-company setup, any newly created child contact now automatically receives the same company as its parent contact. This prevents contacts from being left unassigned and helps keep company records consistent.
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
Opening a previously sent signing template with no fields no longer triggers an access error. This prevents disruption for users reviewing or managing sent templates while keeping existing access rules intact.
Original PR description
Version: 19.0 Steps to reproduce: - Create a sign template with no sign fields - Send a sign request using that template - Open that template from Templates Issue: After a sign request is sent, record rules make the template read only for sign items (create/write only when there are no sign requests). On open, if the template has no signers, the UI auto creates a dummy signer. For an empty sent template, that create is denied by those rules and raises an Access Error. Fix: Guard the auto create signer flow with a sign requests check so that a sent template does not try to create a new signer on open. Task: 6591146 Forward-Port-Of: odoo/enterprise#132516