Friday, February 20, 2026
23 changes · saas-18.4
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 deployments using alternate PostgreSQL ports.
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#249291Large category images in the Point of Sale product selector no longer crowd out the category name. The layout now keeps images and text in balanced proportions, making categories easier for cashiers to recognize and select.
Original PR description
Before this commit, when a category image was too large, it would overflow and take all the space dedicated to the category name. Now we set the width of the image to 1/3 of the button and the name to 2/3, so that the image never takes too much space. task-id: 5462315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242515 Forward-Port-Of: odoo/odoo#242054
Users in the Invoicing & Banks group can now access basic accounting reports, including statement reports. This aligns reporting access with the intended permissions in enterprise environments and reduces unnecessary access restrictions for finance staff.
Original PR description
In enterprise, we are allowing the Invoicing & Banks group to have access to basic reports, including 'Statement Reports' task-5925567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249338 Forward-Port-Of: odoo/odoo#249006
This fix ensures high-priority job applications appear at the top of their stage in the Recruitment kanban view after a page refresh. It helps recruiters focus on the most important applicants first and restores the expected priority-based ordering.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any…
Steps to reproduce: ---------------------------------------- 1. Install the Recruitment module 2. Navigate to Recruitment > Applications > All Applications 3. Go to Kanban view 4. Make any application Very High Priority (3 star) 5. Refresh the page Observation: ---------------------------------------- Applications marked as Very High Priority are not displayed on top, Applicants with higher priority should be displayed first within the same stage. Issue: ---------------------------------------- The `_order` attribute on the applicant model is declared twice, causing the intended priority-based ordering to be overridden by `sequence`. https://github.com/odoo/odoo/blob/6fed805389d878558e4139b270ee7a70269af767/addons/hr_recruitment/models/hr_applicant.py#L28-L41 Solution: ---------------------------------------- Reorder the fields in the `_order` attribute so that priority is applied before sequence, ensuring higher-priority applicants are shown first opw-5893371 Forward-Port-Of: odoo/odoo#247779
This update fixes an automated website editor test that could behave unpredictably depending on browser timing, scrolling, or computer load. It makes the test consistently bring the relevant page section into view, helping reduce false failures and improve release confidence.
Original PR description
Specific steps in the snippet_popup_and_animations tour work around the fact that the three columns snippet is visible or not while depending on the scroll position to hide/show its third column and test the related animation. This introduces some indeterminism around the actual timing of the animated column when no scroll is actually performed (and the element actually in the viewport). This commit forces the scroll to be performed and the snippet to actually be visible. Note: this issue appears more frequently since Chrome 144+ and depending on the CPU load. runbot-238402
Opening an expanded Barcode Rule form could fail because the form depended on missing parent context. This fix uses the rule's own nomenclature information instead, so users can view and edit barcode rules without hitting an error.
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 fix prevents spreadsheets from crashing when a user duplicates an Odoo list and then uses undo. It makes the spreadsheet list workflow more reliable and reduces disruption during data analysis.
Original PR description
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 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#249475 Forward-Port-Of: odoo/odoo#248969
This fixes a flaky automated website test by making sure the relevant page section is brought into view before the test interacts with it. The change improves confidence in test results and reduces false failures during validation.
Original PR description
The snippet_popup_and_animations tour relied on the visibility of the s_three_columns snippet, which depends on scroll position to trigger its animation logic. Since no explicit scroll was performed in some steps, the snippet could already be in the viewport, introducing indeterminism in animation timing and visibility checks. This caused flaky behavior in the tour, especially around assertions using :not(:visible). This PR introduces a dedicated scrollToSnippet helper and explicitly scrolls to the s_three_columns snippet before interacting with it. Visibility checks are simplified accordingly. By ensuring the snippet is properly scrolled into view before each interaction, the tour becomes deterministic and more reliable. The commit in PR is backport of: https://github.com/odoo/odoo/commit/9adee50e runbot-238402
This fixes an issue in the Website Forum where creating a new forum post could crash when debug mode was enabled. The change updates an internal setting name so the tag selector receives the expected information, improving reliability for forum contributors and administrators.
Original PR description
Following rewrite in odoo/odoo@33206fd1941ae, this commit update passed props (`disabled` -> `isReadOnly`) to avoid a crash when creating a new forum post while being in debug mode: `OwlError: Invalid props for component 'WebsiteForumTagsWrapper': unknown key 'disabled'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249477 Forward-Port-Of: odoo/odoo#244063
Users can now open standalone activities from the calendar view without encountering an error. This keeps activity management smooth for tasks that are not linked to a specific document or record.
Original PR description
Steps to reproduce ================= 1. Go to “View all activities”. 2. Switch to calendar view. 3. Click on an activity not linked to any model (e.g. “Eat cookies”, “Send Email to Alfred”). 4. Click…
Steps to reproduce ================= 1. Go to “View all activities”. 2. Switch to calendar view. 3. Click on an activity not linked to any model (e.g. “Eat cookies”, “Send Email to Alfred”). 4. Click “View” in the popover. => Traceback Reason ====== The commit [1] allow activities without a linked model and from commit [2] such activities can be opened in the activity form view. In the calendar view, the action is retrieved from the model and executed using `doAction`. Since the action does not define `views`, and the `doAction` depends on `action['views']`, an error occurs when the action service attempts to copy it. After this commit ================== This commit fixes the issue by modifying the action returned from `action_open_document` for non-linked models to include `views`, similar structure used when a model is present. [1] https://github.com/odoo/odoo/commit/165b060473be8a5d33d62d311f0dc55ed6332d69 [2] https://github.com/odoo/odoo/commit/abeac135b9bb7aec4bcddd84fb0705743297f80d Task-5857887 Forward-Port-Of: odoo/odoo#246442
Fixed an issue where the Contact Us button for zero-priced products failed to navigate to a selected page section when an anchor link was used. This ensures customers are taken to the intended content instead of the link being disrupted by extra product information in the URL.
Original PR description
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work…
Issue: ------- When a zero price product is created and the contact us button on the product page is intended to redirect to some snippets created through drag and drop then the button doesn't work as intended meaning it doesn't redirects to the desired snippet even after putting the correct anchor. for ex: `#snippet-anchor` in the `Button URL` field in the settings. Cause: -------- This works fine for the pages having '/contactus' or '/'. Issues raise only when we try to redirect to a snippet. Now, if the we try to redirect to any snippet on click of the button(Contact Us) by placing the corresponding anchor, it will not redirect/work as intended. This is because of the appending`?subject=product_name` that took place. Solution: ------------ To concatenate the `subject=product_name` conditionally if the url has '#' in it If yes, we just use the `url` in the URL so that it redirects as intended else concatenate the subject & so on. This is because for redirecting to snippets we use anchors such as '#Let's-Connect'. So, In an anchor the '#' will definitely reside. Steps to reproduce: ----------------------- 1. Create a db in version 18.3 with website_sale installed. 2. Enable the `Prevent Sale of Zero Priced Product` checkbox in the settings. 3. Create a zero price product and few snippets under it and copy the anchor of one of the snippets to redirect when clicked on the 'Contact Us' button. 4. Use the Anchor(for ex: '#Let's-Connect') in the 'Button URL' field of settings. 5. Navigate to the created product and click on the 'Contact Us' button. Nothing happens & no intended redirection to the desired snippet. Ref PR: ---------- https://github.com/odoo/odoo/pull/189049/changes#diff-39e02d03a8b765b4e3afc68627aeb33f11b587163638fedfb92ed5657c3336e7R398-R399 Attachments: ----------------- **Before Fix:** [vokoscreenNG-2026-02-06_17-36-37.webm](https://github.com/user-attachments/assets/a09101d4-13df-415d-a902-420a28aedef0) **After Fix**: [vokoscreenNG-2026-02-06_17-38-37.webm](https://github.com/user-attachments/assets/a6256d0f-d8cb-4146-b95e-33452a0a79c5) - OPW - [5494517](https://www.odoo.com/odoo/project/70/tasks/5494517) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247587
This fixes how electronic invoicing customization settings are inherited for UBL/PINT formats. It helps ensure invoices use the correct country-specific electronic invoice configuration for regions such as Australia/New Zealand, Japan, Malaysia, and Singapore.
Original PR description
no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249192 Forward-Port-Of: odoo/odoo#248992
This fix stops requiring buyer endpoint identifiers for BIS3 invoice files unless the invoice is actually being checked for Peppol compliance. This helps businesses using BIS3 XML files for consumer invoices share those files with accountants without unnecessary validation errors.
Original PR description
…peppol checked Some people are using BIS3 files even for B2C. They give the xml files to the accountant for him/her to import the file and generate the invoice in the accounting software. In that case, since it's a B2C transaction, the EndpointId might not be set but that's ok since it's only used to generate the invoice. opw-5952109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249751
This fixes an issue where a user's typing indicator in Odoo Discuss could remain visible indefinitely after rapid typing updates. The indicator now reliably clears after the expected timeout, reducing confusion in chat conversations.
Original PR description
Typing expiration was indirectly tied to typing timestamp updates. Typing timestamps are second-precision, so two consecutive typing events can carry the same timestamp value. In that case, the timestamp field may not be considered updated on the client. The expiration timeout is then not re-armed even though typing is set to true. When that happens, the typing indicator can remain visible indefinitely unless an explicit "stop typing" event is received. This change makes timeout registration depend on typing state updates directly. Expiration is always scheduled when typing becomes active, regardless of timestamp equality. [task-4922630](https://www.odoo.com/odoo/project/1519/tasks/4922630)
This update resolves a display issue in the employee offer screen for the Belgium payroll localization. Previously, a contract type field was incorrectly shown, which has now been corrected by adding a new field to the model. This ensures the correct display of offer information for Belgian employees.
Original PR description
Bug reproduction: Ensure that belgium payroll localization is not installed, go to offer of employee, contract type field is not there. Bug cause: Contract type field does not exist in the model, it was adding to the view by l10n_be_hr_payroll. Bug solution: I added new field contract_type_id to the hr_contract_salary_offer model (to show it on UI). Solved from 17.0 Note: I need to fix after version 19.0, because by starting from 19.0, the Belgium one will try to add the same field to the view again task - 5500488 Forward-Port-Of: odoo/enterprise#107755 Forward-Port-Of: odoo/enterprise#104578
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated as part of a larger change in 17.3 to consolidate previous week/month actions. This ensures the approval reminder email functions correctly, sending to the appropriate timesheet records.
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
This update corrects a technical issue related to the transmission of 13th month payroll data for Swiss clients using the LPP (Lump-Sum Payment) base. The change ensures accurate reporting and compliance with Swiss tax regulations, specifically addressing a requirement for including the 13th month payment in the LPP calculation.
Original PR description
Forward-Port-Of: odoo/enterprise#107908
This update resolves an issue where Invoicing and Banks users were unable to access key financial reports. The change adds necessary security permissions, allowing these groups to view basic reports like partner ledger and aged receivable/payable, improving their ability to manage financial data.
Original PR description
* Revert commit https://github.com/odoo/enterprise/commit/86c3c212bb79fbc2becac46f4d83b6f2fc381854 that introduced having Accounting features, menu items, and Account on invoice lines available for Invoicing users. * Allow Invoicing & Banks group to access basic reports * Backport missing access rights to properly open the reports without an access error. task-5925567 Forward-Port-Of: odoo/enterprise#107851 Forward-Port-Of: odoo/enterprise#107654
This update resolves an issue preventing accurate report generation within the l10n_au_hr_payroll_account module. The change adjusts the report domain to use .ids instead of NewId, ensuring the reports correctly identify payroll records. This improves the reliability of financial reporting.
Original PR description
Domains do not support NewId, so we change the report domain to call .ids instead. [Runbot Error - 115303](https://runbot.odoo.com/odoo/error/115303)
This update fixes an issue where OCR-extracted expense amounts weren't correctly converting to the company's standard currency (USD). The change ensures that the 'Total' amount accurately reflects the original receipt total after applying the correct exchange rate, improving the accuracy of expense reporting.
Original PR description
Steps to reproduce: 1. Initialize an expense with a foreign currency (e.g., EUR). 2. Trigger OCR extraction on a receipt with a specific total. 3. Observe that both 'Total In Currency' and 'Total' (USD) are set to the same value. 4. The exchange rate is forced to 1.0, ignoring the system's exchange rate. Cause: The _fill_document_with_results method assigned the OCR total to both 'total_amount_currency' and 'total_amount' as a placeholder. This triggered the field's inverse logic during the write() call, causing Odoo to treat the input as a manual exchange rate override of 1:1. Solution: Remove the 1:1 placeholder assignment. The method now explicitly calculates 'total_amount' using the _convert() helper once the currency is identified, ensuring the company currency total reflects the actual system exchange rate. opw-5437611 Forward-Port-Of: odoo/enterprise#107862 Forward-Port-Of: odoo/enterprise#107534
This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. The issue was caused by missing data in the search field, which blocked the search bar from returning results. Now, all journal entries are searchable by move, partner, account, and label.
Original PR description
Steps to reproduce: 1. Open the Colombian Daily Journal (Libro Diario). 2. Type a move name or partner in the search bar. 3. Observe that no results are returned. Cause: Report lines were generated with an empty 'name' attribute. The accounting report framework uses this field for client-side filtering. Empty names make the search bar non-functional. Solution: Populate the 'name' field with move, partner, account, and label data. This enables the frontend search bar to match against these strings. opw-5495558 Forward-Port-Of: odoo/enterprise#106179
This update corrects a discrepancy in payslip calculations related to the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves payroll accuracy and reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#107576 Forward-Port-Of: odoo/enterprise#106753
Miscellaneous changes
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212134