Saturday, February 21, 2026
7 changes · master
Resolved issues and error corrections
Odoo now correctly uses the main database port when no separate replica port is configured. This prevents misleading connection warnings when a replica is simulated on a non-standard database port, improving reliability for database administration workflows.
Original PR description
Start postgres on an alternative port (e.g. 5434), start odoo with `--db_port 5434 --db_replica_host=''`, access /web/database/manager, there's a warning in the logs that says it is not possible to connect to the replica database.
The empty string for the replica host is Odoo 18 way to tell Odoo to simulate a replica database by connecting to the same db as the primary one. It should use `--db_replica_port` and when not set fallback on the same port as `--db_port`. The problem is that in case no `--db_replica_port` is set, the option is set `None` in the config, i.e. `get('db_replica_port', cfg)` was retuning `None` as was not using the fallback.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249291Projects without a customer no longer trigger an error when users open Sales Order Items. Instead, Odoo shows the existing items list and prevents creating new sales items until a customer is set, avoiding disruption in project workflows.
Original PR description
Currently, an assertion error is raised when opening "Sales Order Items" from a project without a customer. **Steps to Reproduce:** - Install `sale_project` module with demo data. - Create a new project using "Sale Order" project template. - Do not set a customer on project. - Project > Task (Kanban) > Show _Top Menu_ > Show _Sales Order Items_. - Click "**Sales Order Items**". Video Ref: https://drive.google.com/file/d/1xgYHZBvIt5Ep9Gt-wALGIb9f7mj4NPh_/view?usp=drive_link Error: AssertionError **Cause:** The sale order line depends on `default_partner_id` from the context to create a sale order when none exists. When the project has no customer set, this value is missing, causing an assertion failure. **Fix:** This commit returns the list view of SOLs and disables the creation when no partner is set for the project. sentry-7220116560 Forward-Port-Of: odoo/odoo#246058
The point of sale now handles attempts to cancel an empty restaurant table without causing an error. This prevents staff from seeing a traceback and keeps the checkout workflow stable when no items have been added.
Original PR description
Steps: --- - Open a Restaurant session. - Open a table with no order. - Click the control button and click Cancel Order. Issue: --- - A traceback occurs when cancelling an order. Cause: -- - The order is cancelled first, and then `isSelectedLineCombo` tries to access the current order, which is already null. Fix: --- - Safely check for the selected order before accessing combo data. - Disable the Cancel Order button when there are no order lines. task-5934004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248639
Opening expanded barcode rule forms in barcode nomenclature settings no longer triggers an error. This helps inventory configuration users edit barcode rules reliably without being blocked by a technical traceback.
Original PR description
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type ==…
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083 Forward-Port-Of: odoo/odoo#249293
This update removes redundant steps in how taxes are applied to invoices, streamlining the process and reducing unnecessary activity. The change prevents excessive logging entries on previously posted invoices, improving system performance. This was identified and corrected by ANDG.
Original PR description
_set_external_taxes() was clearing tax_ids on every line before setting them again in the next loop. This is unnecessary because the write() already uses Command.set() which replaces all existing values. It causes [additional, unnecessary chatter entries on invoices that have been posted before](https://github.com/odoo/odoo/blob/b6d6d129bf284c7cf5f48fa130a7b4522f639401/addons/account/models/account_move_line.py#L1871-L1872). Thanks to ANDG for spotting this.
This update resolves an issue where payroll warnings weren't easily changeable, leading to potential inaccuracies in tax calculations. The change allows for more flexible updates to payroll warning data, ensuring accurate reporting and compliance with Swiss tax regulations. This improves the reliability of the HR payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#107792
This update corrects a technical issue where the timesheet approval reminder email was referencing a deleted action. The change reflects a recent update to the Odoo Enterprise system that consolidated previous week/month timesheet actions. This ensures the approval reminder email functions correctly.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269 Forward-Port-Of: odoo/enterprise#107440 Forward-Port-Of: odoo/enterprise#107385