Thursday, September 24, 2026
6 changes · 19.0
Resolved issues and error corrections
This 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
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
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