Daily updates from Odoo
Friday, February 20, 2026
57 changes · saas-19.1
New functionality added to Odoo
This update incorporates essential testing for the HR Expense Stripe module, which was previously missing. The tests ensure the module functions correctly and reliably, addressing a gap in our quality assurance process. This addition contributes to the overall stability and trustworthiness of the Enterprise suite.
Original PR description
Add tests for the module, as it wasn't included in the original task Forward-Port-Of: odoo/enterprise#106191
This update allows administrators to create API keys programmatically, streamlining the process and reducing manual steps. Previously, API keys required interactive creation with a typed password. Now, existing keys can be renewed or replaced automatically, improving efficiency and automation.
Original PR description
Previously, API keys could only be created interactively: the method required an interactive session and a recently typed password. This commit adds a new method on `res.users.apikeys` that allows creating an API key when an existing one is provided. Optionally, in the case of a renewal, the new key can replace the old one, and the provided one is unlinked. Forward-Port-Of: odoo/odoo#246118
Enhancements to existing features
This update allows companies to automatically receive KSeF invoices directly from the tax authority, eliminating the need for traditional paper invoices. This streamlines the invoicing process and ensures legally compliant delivery of sales records. It improves efficiency and reduces manual handling of tax documents.
Original PR description
If a company sell me something, they can send me an invoice. With KSeF, they do not have to send an invoice to me by post or mail - they can send it directly to KSeF. And it is legally delivered to me. Implement fetching bills from KSeF task-5405257 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247812
Resolved issues and error corrections
This update resolves a connection issue that occurred when Odoo was configured to use a replica database. The change ensures Odoo automatically uses the primary database port when a replica port isn't specified, preventing errors and improving database connection stability. This enhances the overall reliability of the Odoo system.
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#249291This update resolves an issue where the AI translation feature in the website builder would fail due to a 10-second timeout. The fix removes this timeout restriction, allowing translations to complete successfully even with large amounts of untranslated text. This improves the user experience for translating website content.
Original PR description
Scenario: - have lot of untranslated text in a page - in a secondary language, open translation editor - click on "Translate to [current language]" in side panel Result: the translation fails completely or partially, and there is a notification saying "A technical issue occurred in the builder, you should save or discard your changes.". Reason: since 6df83abb35c95ab42e55d9a08cf6c411efa64b3e website builder action have a default timeout of 10 seconds to prevent deadlocks. But the /html_editor/generate_text can easily take more than 10 secondes depending on latency and quantity of text to translate. Fix: prevent the timeout when using the AI translation feature. opw-5892402 Forward-Port-Of: odoo/odoo#249464
This update ensures that expense accounts are linked to the correct company when using products. Previously, expenses created for one company would incorrectly use accounts from a different company. This fix resolves a potential issue with inaccurate financial reporting and improves data consistency.
Original PR description
The aim of this commit is to ensure the account select through product is related to the correct company. (ie. the one related to the processed model) Before this commit: If a user has company_a selected as the main company in the company switcher and create an expense for company_b, the account selected from the product will be an account from company_a. (because product is shared between company but the account properties on those are company dependent) This could also happens in other places so we fixed it. After this commit: The account selected from the product will be from the company set on the model. task-4699717 Forward-Port-Of: odoo/odoo#249194 Forward-Port-Of: odoo/odoo#209144
This update corrects a problem where the timesheet approval reminder email was sending to an outdated action. The action was updated to reflect a recent change in how timesheet validation is handled within the Odoo system. This ensures the email reminders function 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
This update corrects a bug where PDFs attached to bills created via email aliases weren't correctly linked. The fix clears a key field when an attachment is removed, preventing misassignment of attachments between bills and XML documents. This ensures consistent attachment functionality regardless of the bill creation method.
Original PR description
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to…
Problem: when a user uploads an XML file containing an embedded PDF to create a bill, the bill is created correctly and the PDF is set as the main attachment. However, when the same XML is used to create a bill via email aliases, the PDF is not set as the bill’s main attachment. Root cause: 1. When an email is received, it's first posted as a message on the bill chatter 2. Posting the email sets its XML as the main attachment of the bill 3. _fix_attachments_on_record from account.document.import.mixin then removes res_id and res_model fields from the XML 4. The PDF is then attached as the main attachment of the bill 5. In documents_account module, when the PDF is set as the main attachment, it mistakenly assigns it as an attachment to the XML document because the XML was assigned as the bill main attachment, resulting in the bill having no attachment actually linked to it. Solution: This commit fixes this issue by clearing the field message_main_attachment_id whenever the attachment in it gets unattached in _fix_attachment_on_record. task-5900088 Forward-Port-Of: odoo/odoo#246991
This update prepares the l10n_eu_iot_scale_cert module for compatibility with Odoo 19.0. It simplifies communication with IoT devices and removes outdated features related to manual quantity adjustments, ensuring accurate certification processes.
Original PR description
This PR adapts the l10n_eu_iot_scale_cert module for the certification in v19.0 1) It adapts the communication with the iot box to use the new iot_http_service 2) It removes the possibility to manually change the quantity on a weighed product 3) It removes the possibility to set a negative tare Related PR in v18: https://github.com/odoo/enterprise/pull/107103 task-5926814 Forward-Port-Of: odoo/enterprise#107123
This update ensures seamless communication between Odoo's IoT boxes and databases, specifically addressing a change in data format between versions 18.0 and 19.1. The update adjusts the IoT box to send both expected data values, resolving compatibility issues and maintaining reliable data flow.
Original PR description
This PR adds the scale commands compatibility for the iot box images in >= saas-19.1 with the dbs in v18.0 and less In v18.0 we read 'value' key sent by the iot box but the iot box doesn't send it anymore in 19.1 This PR makes the iot box send both 'result' as exepcted in v19 and 'value' expected in v18 Enterprise PR: https://github.com/odoo/enterprise/pull/107641
A recent update caused a crash when users tried to undo a duplicated list within the spreadsheet feature. This fix ensures that users can now correctly undo actions, including list duplication, without experiencing unexpected errors. This improves the stability and usability of the spreadsheet functionality.
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 update resolves an issue where upgrades were failing due to delayed constraint definitions. Specifically, when modules loaded in a different order, outdated constraint definitions were causing errors. This patch ensures the latest definition is always applied, improving the stability and reliability of Odoo upgrades.
Original PR description
Current issue: Module A fails to add constraint X with definition D1 -> (X,D1) is delayed Module B loaded after A, overrides constraint X to D2 and also fails to add the constraint -> still (X,D1) are in the delayed queue, instead of (X,D2) In this patch we ensure the delayed constraint gets the latest definition (D2) This issue affects upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249495
This update resolves a technical issue that could cause errors when opening barcode rule forms within the Stock module. The fix removes a dependency on a parent record, ensuring the form loads correctly and preventing unexpected errors. This improves stability and usability.
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 fixes issues with how custom snippets are displayed in the website editor's preview. Specifically, it ensures consistent preview heights for carousel snippets and correctly shows zoom effects for parallax snippets, while also ensuring custom snippet labels are displayed. These changes improve the user experience when creating and managing website content.
Original PR description
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet…
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview height is too small. Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low. After this commit, the preview height uses the layout size so the min-height stays consistent with other slides. ---------- Steps to reproduce: - Open the website editor. - Open the snippet dialog and resize the window. => The parallax preview background shifts to the left. - Save a snippet with a parallax zoom in/out effect as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview shows a top to bottom effect instead of zoom. Before this commit, resizing the snippet dialog could offset the parallax background to the left, and zoom previews looked like top to bottom effects. After this commit, the preview keeps the background aligned and shows zoom in/out effects for custom snippets. Fixed parallax is still not previewed because it would require an oversized background in the dialog. ---------- Steps to reproduce: - Open the website editor. - Save a "Carousel" snippet as a custom snippet. - Open the snippet dialog. => The custom snippet shows no label. Before this commit, custom previews dropped the base label so the dialog showed no tag for custom snippets. After this commit, custom previews reuse the base label. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present** Forward-Port-Of: odoo/odoo#248929 Forward-Port-Of: odoo/odoo#244295
This update fixes an issue where the website filters disappeared when using the 'off-screen menu' style. The change ensures the filters button remains visible when no sort or pricelist options are selected, providing a consistent and user-friendly experience for browsing products.
Original PR description
Versions -------- - 19.1+ Steps ----- 1. Disable all pricelists to hide pricelist filter 2. Go to shop page 3. Change Filters style to "Off-screen Menu" - Note that a "Filters" button appears next to the sort by dropdown 4. Remove the sort by from the toolbar by untoggling it Issue ----- When the filters are set to off-screen and there is no sort by dropdown or pricelist dropdown, the filters button disappears. Cause ----- The div containing the filters button, sort by dropdown, and pricelist dropdown, is set to `d-lg-none` when there is no pricelist dropdown and no sort by dropdown, causing it do disappear. Solution -------- Only allow the div to disappear when the filter button shouldn't appear (`wsale_has_filters_btn` set to False) opw-5933858
This update enables users to remove orderlines when using the LNE certified scale module in Point of Sale (PoS). Importantly, the system still prevents manual quantity adjustments beyond zero, ensuring data accuracy for scale-based transactions. This resolves a previous limitation and improves the usability of the certified scale functionality.
Original PR description
This PR allows the user to delete PoS orderline when using LNE certified scale module while still forbidding to manually set quantity to anything other than 0 Forward-Port-Of: odoo/enterprise#107413
This update ensures the 'first_contract_in_company' field always reflects the employee's earliest contract start date, regardless of when it was created or modified. Previously, this information was unreliable due to a manual process, now it's automatically calculated and updated whenever a contract version changes, improving payroll accuracy and reporting.
Original PR description
Version-19.0 **Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late. We need that information at other places too. ### What This PR Does This PR restores…
Version-19.0
**Issue**: Field `first_contract_in_company` was only set by the archive wizard, which is too late.
We need that information at other places too.
### What This PR Does
This PR restores the reliable computation of the employee's first contract date by:
- Computing the earliest contract start date across all versions of the employee.
- Automatically updating the `first_contract_in_company` field whenever:
1. A new contract is created
2. an existing version changes it start date, or
3. an existing version is deleted for the employee.
### Technical Summary
**Update the first contract date on create/write**
- when an hr.version is created or updated, it will recompute the employee's earliest
`contract_date_start` across all versions.
- The update is performed in `_compute_first_contract_in_company()`, which:
1. fetches all the active versions of employee
2. filter those having `contract_date_start`
3. Computes the earliest start date.
4. Updates `employee.first_contract_in_company` accordingly.
**Result**
The field `first_contract_in_company` is now always accurate and reflects real employee history.
Forward-Port-Of: odoo/enterprise#102198This update corrects a technical issue within Odoo's testing framework related to how webjson responses are processed. Previously, a test was failing due to an unexpected data type being returned. This fix ensures that tests accurately reflect the expected behavior of the webjson functionality, improving overall test stability.
Original PR description
The return value of the patched methods was a MagicMock and not a recordset, and make_json_response was doing funny stuff with that returned MagicMock 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#249496
This update prevents discounts applied to recurring subscription lines from being removed when an upsell is added to the order. Previously, confirming an upsell would reset the discount, leading to incorrect pricing. This change ensures accurate discount calculations for subscription orders with upsells, improving order accuracy and customer satisfaction.
Original PR description
Before this commit, the discount of recurring lines in a sub would be reset in the following case: 1) create a sub, add a discount on recurring line 2) invoice the sub 3) create an upsell, add quanitty on the recurring product, change the start date of the upsell to trigger computation 4) confirm the upsell The discount of the parent order was reset. task-5886270 Forward-Port-Of: odoo/enterprise#105750
This update adds a warning message to the invoice batch wizard when the automated invoice sending cron job is disabled. This ensures users are alerted if their invoices won't be sent, preventing potential delays and improving invoice processing transparency. It addresses feedback from SBR to enhance user experience.
Original PR description
When the Cron responsible of sending the invoices asynchronously is disabled, the user has no clear indication that his invoices won't be sent as they should. Let's add a warning in the batch wizard that notify the user something is wrong. task-none (feedback from SBR) Message when no rights to update cron: <img width="990" height="328" alt="image" src="https://github.com/user-attachments/assets/1100ef6f-d047-49f2-bd8f-c8ef9fd543d8" /> Message when admin: <img width="999" height="308" alt="image" src="https://github.com/user-attachments/assets/28e90295-d225-4785-82a9-65be3ce79621" /> Forward-Port-Of: odoo/odoo#249270 Forward-Port-Of: odoo/odoo#248994
This update resolves an issue where Peppol invoices were incorrectly using the wrong company context, leading to errors and inconsistencies when creating accounting records. The fix ensures invoices are processed with the correct company details, preventing data mismatches and improving data accuracy for cross-company transactions.
Original PR description
Currently, the created move does not always use the company context of the related move/proxy user. As a result, default values may be taken from another company, which can lead to cross-company inconsistencies and access errors. Steps to reproduce: - Set up two companies, A and B - In company A, configure a default value for the partner.company_id field, applicable only to company A - When a Peppol invoice arrives for company B but is processed using the context of company A, and a new partner must be created, the partner is created with company A as the default value - This results in an incompatible companies on record error This fix ensures that the company context of the move or EDI user is used when creating the move, preventing cross-company issues. opw-5473233 Forward-Port-Of: odoo/odoo#249409 Forward-Port-Of: odoo/odoo#249059
This update resolves a bug that caused forum posts to fail to create when the Odoo system was in debug mode. The issue stemmed from incorrect property settings being passed to a key component. By changing 'disabled' to 'isReadOnly', the system now correctly handles forum post creation, ensuring a stable user experience.
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
This update resolves a technical issue that prevented emails from being sent correctly when processing multiple equity transactions. The fix corrects a configuration error within the email template, ensuring accurate record matching and preventing errors during email generation. This improves the reliability of equity transaction notifications.
Original PR description
## Issue Before This Commit A missing record error occurred during email generation when the number of `equity.transaction` records exceeded the `res.partner` records. ## Cause of the Issue The issue was caused by an incorrect `model_id` configuration in the `equity_shareholder_email_template`. This created a mismatch between the template model and the record context passed to the mail compose wizard, leading to a missing record error during template rendering. ## With This Commit The template `model_id` has been corrected `equity.transaction`. This ensures that the mail compose wizard receives the correct model context and prevents missing record errors during email generation. Steps to reproduce : [Video](https://drive.google.com/file/d/19WXbjmYPKh0IjQHcEGU4FdUbGSF4GGlx/view?usp=drive_link) opw-5899070 Forward-Port-Of: odoo/enterprise#107891
This update resolves an issue where changing a partner in Odoo would erase the previously set default payment term for invoices. Now, the default payment term will remain consistent, regardless of the partner being used, ensuring a smoother and more reliable invoicing process. This prevents frustration and maintains data integrity.
Original PR description
When you want to set a default payment term for an invoice, it will be there when you create the invoice. But then, when you change the partner, even if there is no default payment term defined on there, it will empty it, so setting a default does not work. This can even be annoying if you set the payment term first and then the partner. In odoo/odoo#112360 this condition was added for perf issues. opw-5387239 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#242041
This update fixes an issue where the working time assigned to tasks wasn't accurately calculated when switching between companies with and without public holidays. The fix ensures that working time is correctly computed based on the last stage change and considers company-specific holiday impacts.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883 Forward-Port-Of: odoo/odoo#246994
This update corrects a bug where high-priority applicants weren't appearing at the top of the applicant list in the Recruitment module. The fix resolves a technical issue with how applicant priority was being ordered, ensuring that the most important applications are now displayed first.
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 issue where changes made to email marketing records within the form editor were lost when switching between tabs. The fix ensures that the editor correctly saves changes when the focus is lost, improving the user experience and data integrity. This prevents data loss and ensures consistent email marketing campaigns.
Original PR description
Problem: While editing an email marketing record, switching tabs in the form view causes the last changes in the editor to be lost. Cause: The `blur` event on the iframe is not triggered when clicking outside of it. If the iframe is not fully ready when listeners are attached, the required events are not properly registered, so the latest changes are not saved before switching tabs. Solution: Attach the `blur` listener only once the iframe is fully loaded, ensuring that changes are correctly detected and saved when focus is lost. Steps to reproduce: - Create a new email marketing record. - Add a text snippet. - Change the text and save. - Modify the text again. - Switch to another tab in the form view, then return to the "Mail body" tab. - Observe that the last changes are lost. opw-5921800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248974
This update resolves an issue where clicking on certain activity types (like 'Eat cookies') in the calendar view would cause a technical error (traceback). The fix ensures that these activities can now be properly viewed, improving the user experience and preventing disruptions.
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
This update fixes an issue where Italian company data (like tax ID and address) wasn't being properly transferred when creating a company from an ecommerce order. Previously, the system didn't consistently populate the required Italian tax fields. This change ensures that all necessary Italian business information is correctly recorded, improving data accuracy and compliance.
Original PR description
**STEP TO REPRODUCE** 1. Create a ecommerce order on a shop page of a italian company. 2. Goes to the checkout page, enter info (company_name, l10n_it_codice_fiscale, l10n_it_pa_index). 3. On the contact created, click on create company. 4. Notice l10n_it fields are not propagated to the company. opw-5477372 Forward-Port-Of: odoo/odoo#248524 Forward-Port-Of: odoo/odoo#246785
This update optimizes the master production schedule to significantly reduce order processing times. The previous system was pulling unnecessary data, leading to delays. This change improves efficiency and responsiveness for order fulfillment.
Original PR description
When traversing X2many fields (bom_ids, bom_line_ids) during prefetching in filtered, the _prefetch_ids data grew excessively. Prefetching bom lines pulled in IDs for lines belonging to all boms across all associated products, even though _skip_bom_line in this case only operates on the current product's context. Use prefetch() with no args to avoiding unnecessary record loading for unrelated boms. Benchmark: | |Before |After| |-----------------|-------|-----| |action_replenish |Timeout|577ms| Related ticket: opw-5928055
A recent update allowed users to confirm dialogs with CTRL+Enter, but this caused a double confirmation issue. This fix prevents the dialog from being confirmed twice, ensuring that only one floor is created when a user uses CTRL+Enter. This resolves a data inconsistency issue.
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
This update resolves a technical issue within the Luembourg payroll module that was causing incorrect calculations for employee pay. The fix ensures accurate payroll processing, maintaining data integrity and compliance. This change primarily impacts payroll reporting and employee compensation.
Original PR description
Forward-Port-Of: odoo/enterprise#107635
This update automatically calculates and transmits the 2050 pension contribution for employees in Switzerland using the Swissdec standard. This ensures accurate and compliant payroll processing, addressing a previous calculation error and streamlining the process for our Swiss clients.
Original PR description
task-5166226 Forward-Port-Of: odoo/enterprise#104140 Forward-Port-Of: odoo/enterprise#103453
This update fixes a potential issue in Australian payroll tax calculations by ensuring that historical data is used, not current employee settings. Previously, tax calculations relied on the employee's current information, which could lead to inaccuracies when an employee's details changed. Now, payslips correctly reference the historical configuration data for each pay period, guaranteeing accurate tax and withholding calculations.
Original PR description
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields…
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values. This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state). This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period. The following rules/fields are updated to use the version object: - Tax Treatment Category - Additional Withholding Amount - Extra Pay - TFN Declaration - Medicare (Reduction, Exemption, and Levy) - Training Loans - NAT 3093 Amount (Tax Offset) - Child Support (Garnishee and Deduction) A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates. Task-5002697 Forward-Port-Of: odoo/enterprise#107568 Forward-Port-Of: odoo/enterprise#106550
This update corrects a bug where snippet placement within the Forum editor was unreliable. The fix ensures that dropzones are correctly activated based on the selected snippet, resolving issues where snippets were incorrectly available or unavailable due to sanitization rules. This improves the user experience and allows for consistent snippet integration within Forum content.
Original PR description
Before this commit, the dropzones activated would not always be correct clicked on a group and then selected a snippet. The dropzones would be determined based on a default section and not based on the selected snippet. Therefore, even though there could be rules preventing a snippet from behing in a certain dropzone, the dropzone would still be activated because the snippet chosen would not be taken into account. This commit fixes the issue by using the chosen snippet to activate the dropzones. task-5428387 Forward-Port-Of: odoo/odoo#240547
This update resolves an issue where the 'Expenses Report' feature in the HR module would fail when encountering encrypted PDF attachments. The fix skips these encrypted files and adds a note to the report, ensuring reports can be generated without errors. This improves the reliability of expense reporting.
Original PR description
**Steps to reproduce:** - Install hr_expense - Create an expense - Attach several receipts with at least one encrypted PDF - Create Report - From cog menu, print "Expenses Report" **Issue:** A traceback is raised while trying to add the attachments to the report: "File has not been decrypted". **Cause:** The encrypted file cannot be appended to the report PDF. **Solution:** Skip encrypted files and log a note with the reason in the report. opw-5194501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249365 Forward-Port-Of: odoo/odoo#248869
This update corrects a visual bug in the HTML editor where the cursor placement after using backspace was incorrect. Specifically, after backspace, text was inserted after the button instead of within it. This fix ensures the cursor behaves as expected, improving the user experience when editing text within the editor.
Original PR description
When using backspace after a button, the cursor is visually displayed as being inside the button, but it a character is typed, it is inserted after the button, while it should be inside. What actually happens is that after backspace after a button, the selection is set around the FEFF that follows the button. This commit fixes this by putting the selection before the FEFF inside the button instead. Steps to reproduce: - Go to a "To do" note - Insert a button - Insert text after the button - Put cursor before text after button - Press backspace: the cursor is displayed inside the button - Type a letter => The letter was inserted after the button. task-5928806 Forward-Port-Of: odoo/odoo#249285 Forward-Port-Of: odoo/odoo#248179
This update resolves an issue where imported vendor bills with a product price of $0.00 were incorrectly increasing the total price due to floating-point calculation errors. The fix ensures that the product price remains accurate, aligning the Odoo total with the original XML invoice total. This prevents overcharging and maintains data integrity.
Original PR description
Whenever a line with price `0.0` with `AllowanceCharge`s got imported, Odoo used to update the `price_unit` to the sum of price, allowance and charges, because of a wrong float comparison condition between this sum and the XML total. So the product price was increased, but the allowances were maintained. The total imported in Odoo became double the one in the XML. Step to reproduce: - Import vendor bill from XML with a product: - price: `0.00` - quantity: `1` - an AllowanceCharge, amount: `0.2` - an AllowanceCharge, amount: `0.1` - `0.0 + 0.2 + 0.1 (sum of price and allowances) != 0.3 (subtotal)` (but `float_compare(0.1 + 0.2, 0.3, precision_digits=4) == 0`) - `price_unit` is updated to `0.3` - Total in Odoo is `0.6` Ticket [link](https://www.odoo.com/odoo/project.task/5499525) opw-5499525 Forward-Port-Of: odoo/odoo#249357 Forward-Port-Of: odoo/odoo#248043
A previous error during the Payroll data update process has been fixed. This issue occurred because a necessary file was accidentally removed, causing the system to fail. This update ensures the Payroll data is correctly refreshed after module installation.
Original PR description
When the ``Payroll: Update data`` cron is executed after installing the ``l10n_lu_hr_payroll`` module, a traceback is raised. Steps to reproduce the error: - Install ``l10n_lu_hr_payroll`` module - Run the ``Payroll: Update data`` cron Traceback: ```py FileNotFoundError: [Errno 2] No such file or directory: '/home/odoo/src/enterprise/saas-19.1/l10n_lu_hr_payroll/data/hr_payslip_input_type_data.xml' ``` In commit [1], ``hr_payslip_input_type_data.xml`` file was removed. However, it is still being referenced in the code below here. https://github.com/odoo/enterprise/blob/4174108cb98a9fd84a012ff9dca81ae322c5f338/l10n_lu_hr_payroll/models/hr_payslip.py#L209 As a result, when the ``Payroll: Update data`` cron runs, the system attempts to update a file that no longer exists, causing a FileNotFoundError. [1]: https://github.com/odoo/enterprise/commit/0fecd57652c8c72a4fb91d44bd0c5d75f621541a sentry-7278209115
This update resolves an issue where printing Italian fiscal receipts was failing due to a missing currency setting in the order. The fix ensures the ticket is printed only after the order has been fully synced, guaranteeing the correct currency information is available. This prevents printing errors and ensures accurate fiscal receipts for Italian POS users.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced. 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
This update resolves a problem that prevented Italian fiscal printers from working correctly. The fix ensures the order's currency information is properly synced before printing the receipt, guaranteeing accurate and reliable printing for Italian businesses using Odoo Enterprise.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced.
This update resolves an issue where demo data in the Project module created duplicate personal stages (like Inbox) when new tasks were created. The fix ensures personal stages are loaded before tasks are assigned, preventing this duplication and improving the consistency of demo data. This ensures a better experience for users testing the Project module.
Original PR description
Steps to reproduce: -- 1. Install the Project module with demo data enabled. 2. Create a new private task. Issue: -- The personal stages (Inbox, Today, This Week, etc.) are duplicated. Cause: -- In project_demo.xml, some tasks assigned to users (introduced in https://github.com/odoo/odoo/pull/224307) were defined before the personal stage records. Creating these tasks triggered the automatic stage generation logic (_populate_missing_personal_stages) because the personal stages in demo data were not loaded yet. This resulted in a duplicate set of stages being created once the demo data records were processed. Fix: -- The personal stage definitions in project_demo.xml have been moved higher up in the file so they load before any user is assigned to a task. task-5454658
This update adds a back button to the combo product configuration screen, making it easier for users to navigate and adjust settings. The change also improves the readability of the code. This enhancement streamlines the user experience for managing product attributes.
Original PR description
The goal of this pr was to always have a Back button visible on the combo product configuration. I also change method name to be more readable. task: 5877219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245870
This update ensures payslips display the employee's actual start date with the company, rather than the contract's start date. This corrects inaccuracies when employees transition between roles or contracts within the organization, providing a more reliable and accurate record of their employment history.
Original PR description
In the paysplip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Here we create a new function, similar to _get_first_version_date() which returns the beginning of the contract tied to the first version of the period, instead of the beginning of the version itself, which might be before or after the actual date of the start of the contract. We call this function _get_first_contract_date(). Task: 5909637 Enterprise PR: https://github.com/odoo/enterprise/pull/106692 Forward-Port-Of: odoo/odoo#248598
This update ensures payslips accurately reflect an employee's start date with the company, regardless of internal job changes. Previously, payslips used the current contract's start date, which was inaccurate for long-term employees. This change, primarily impacting payroll in Switzerland and the UAE, provides a more reliable and accurate representation of employee tenure.
Original PR description
In the payslip definition, the current contract's start date is used. But if a person changes job or contract internally we don't want this value to change and we want it fixed to when the person joined the company. Notably, if a person worked at the same company in two well distinct periods, we want to consider the beginning of this period and not of the previous one(s). Since Switzerland uses a custom report for the payslip, the same change is applied there. Task: 5909637 Community PR: https://github.com/odoo/odoo/pull/248598 Forward-Port-Of: odoo/enterprise#106692
This update addresses a bug that prevented users from successfully executing commands (like '/help') within Odoo's AI chat channels. The fix corrects an error where the 'message' data was unexpectedly undefined, ensuring commands now function correctly. This improves the AI chat experience for all users.
Original PR description
When trying to use commands (for example '/help') in 'ai_chat' channels, an error occurrs. This happens because the 'message' returned from Thread.post method is undefined in that case.
This update resolves an issue where users without write access to the `ir.sequence` model would encounter an error when generating serial numbers for manufacturing orders. The change simplifies the serial number generation process by using `sudo()` to increment the sequence, eliminating the need for write permissions.
Original PR description
## Issue When generating a batch of serial numbers, an AccessError is raised if the user does not have the *Write* access on the `ir.sequence` model. ## Steps to reproduce 1. Install *Manufacturing*…
## Issue
When generating a batch of serial numbers, an AccessError is raised if the user does not have the *Write* access on the `ir.sequence` model.
## Steps to reproduce
1. Install *Manufacturing* (`mrp`)
2. In Settings, enable *Lots & Serial Numbers*
3. Create a Product P
- Tracked *By Unique Serial Number*
- Create a BoM for product P
5. As a user without *Write* access on the `ir.sequence` model:
- Create and confirm a Manufacturing Order for product P - Quantity >= 2
- Click *Generate Serial*, *Generate*, *Apply*
6. **An Access Error is displayed, stating that you are not allowed to modify 'Sequence' records.**
## Cause
Commit https://github.com/odoo/odoo/commit/3ff0f2e3ef4f (and https://github.com/odoo/odoo/commit/9cd0c4affeb1) changed the way the serial sequence was updated by replacing `IrSequence.next_by_id()` with manual incrementation (`IrSequence.number_next_actual += 1`). The former method requires read access but does not require write access, whereas the latter does.
https://github.com/odoo/odoo/blob/8f0a5d31d62ea6fc2a1c94be8501735a01323954/odoo/addons/base/models/ir_sequence.py#L272-L275
Since the write access should not be required to generate serial numbers, the sequence is incremented using `sudo()`.
(related to)
opw-5882578
Forward-Port-Of: odoo/odoo#249662This update fixes a bug preventing users from searching the Colombian Daily Journal (Libro Diario) effectively. Previously, report lines were missing key information, resulting in an unusable search bar. The fix ensures all journal entries are searchable by move, partner, account, and label, improving reporting accuracy.
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 fixes an issue where OCR-extracted expense amounts were incorrectly converting to USD, forcing a 1:1 exchange rate. The change ensures that expenses with foreign currencies are accurately converted to the company's base currency, improving the reliability of financial reporting. This resolves a discrepancy in total amounts displayed for expenses.
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 resolves an issue where the delivery amount was being calculated twice during Stripe express checkout, leading to incorrect order totals. The fix focuses on excluding delivery lines from the tax calculation process, ensuring accurate pricing for customers using express payment methods like Apple Pay or Google Pay. This improves the reliability of the checkout experience.
Original PR description
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay…
Versions: --- - 17.0+ Issue: --- Delivery amount is doubled in stripe express payment checkout. Steps to reproduce: --- 1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay) 2- Set fixed price on standard delivery: 10 3- Navigate to website: add a product to cart. Use express checkout. Outcome: The delivery price is calculated twice which is wrong. Cause: --- This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount. Then we add delivery carrier `minorAmount`: https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice. Fix: --- We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines. opw-5424398 Forward-Port-Of: odoo/odoo#249340 Forward-Port-Of: odoo/odoo#248415
This update corrects a technical issue where delivery and invoicing addresses weren't being displayed correctly on reports using the 'lines' layout. The fix ensures that address information is now consistently shown, improving the accuracy of reports for customers. This was part of a larger effort to refine the layout and spacing of information blocks.
Original PR description
The `information_block` is always false on the `external_layout_lines` this means that when a delivery address and invoicing address is specified they are not rendered. Reviews the spacing of the bubble layout `information_block` task-5951799 Part of task-5949213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical error where employee and resource IDs were incorrectly mixed during holiday calculations, leading to inaccurate results. The fix ensures that these IDs are correctly distinguished, preventing potential scheduling conflicts and improving the reliability of holiday planning. This change was identified and addressed as a priority.
Original PR description
Employee and resource ids were the same during testing. These were mixed in the function. runbot-240926 Note: https://github.com/odoo/odoo/pull/248661 aims to avoid such errors in the future --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue in how the point-of-sale system handles client payments. Previously, change amounts were always rounded for cash transactions. Now, the system correctly accounts for different payment methods (like cards) and ensures change is accurately calculated, regardless of the payment type. This improves the accuracy of financial reporting within the POS.
Original PR description
We extract the condition into a getter so we can override it elsewhere. For now, it is overriden in `pos_settle_order`. See below for explanation. `change` is the amount we return to the client, so it's in cash, and therefore, we always round it if `cash_rounding` is true. However, in pos_settle_order, when a client 'deposits money', the order `change` is what we get paid by that client, and he might choose a payment method different than cash (card for e.g.). We change the `shouldRoundChange` logic to count for such cases. opw-5222985 Forward-Port-Of: odoo/odoo#248787
This update ensures that the amount due for customer deposits is rounded correctly based on the selected payment method. Previously, rounding was applied regardless of the payment type, leading to inaccurate amounts. This change now respects cash rounding configurations for deposits, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the…
Steps to reproduce: ------------------- 1. Enable cash rounding, only for cash payment method - Rounding method doesn't matter, I tested with 0.05 nearest rounding 2. In PoS, make an order with the customer account, such that the total amount is not divisible by 0.05, i.e. when rounded, it's not the same amount. For instance, $5.27. 3. Close the session and reopen it, then select that customer, and click settle due 4. Select the Bank payment method, so a NON-Cash payment method. Notice that the amount is being rounded, even though we have only enable rounding for cash methods. If we take my example of step 2, the amount became $5.25 instead of $5.27. That is understandable when we settle with Cash, however, for Bank (non-cash), we should not round. The fix ------- Now when choosing a payment method to settle due, we also round the amount if needed, in `getTotalDueOfPartner`. Before, we always set the exact amount, regardless of the payment method and the rounding settings. We now also apply rounding on the payment screen based on the selected payment method. Previously, the change was always rounded whenever rounding was enabled, ignoring whether rounding was restricted to cash methods. This behavior made sense for normal orders—where change is typically given in cash—but not when settling a due amount, since the customer can pay using any method. During due settlement, the change represents the amount the customer must pay, so rounding must follow the rules of the chosen payment method. opw-5222985 Forward-Port-Of: odoo/enterprise#105368 Forward-Port-Of: odoo/enterprise#100278
This update resolves a visual glitch preventing live chat visitors from adding reactions on mobile. The fix removes an outdated override of quick action counts, allowing the emoji picker to display properly. This ensures a smoother and more functional live chat experience for all users.
Original PR description
Before this commit, live chat visitors in mobile could not add a message reaction due to visual glitch. This happens because there's an override in livechat to show 3 quick message actions rather…
Before this commit, live chat visitors in mobile could not add a message reaction due to visual glitch. This happens because there's an override in livechat to show 3 quick message actions rather than 4, and this patch also applies in mobile where there's only 1 with the "..." button. The "Add reaction" message action in mobile, when shown as a quick action, is buggy: click on it glitches the visual of message in a way that disrupt the viewing of message... And this doesn't show the emoji picker. This commit fixes the issue by removing the override of quick action count of live chat visitors. This overrides was added a long time ago when the "Add reaction" and "View reactions" had the same icon, and playing with the amount of quick actions was a way to avoid showing these 2 actions as quick actions with similar icons [1]. Also quick actions in chat window has been tweaked to show 2 actions at most in desktop, which is the best presentation in chat window. Removal of the override let it use this better quick action count. [1]: https://github.com/odoo/odoo/pull/140335 Task-5953287 Before / After <img width="399" height="767" alt="Screenshot 2026-02-19 at 17 41 21" src="https://github.com/user-attachments/assets/4f1fb8e7-fa0b-4c8c-8f41-552432224064" /> <img width="401" height="771" alt="Screenshot 2026-02-19 at 17 56 20" src="https://github.com/user-attachments/assets/5aadc9df-d858-49ec-b894-d2c424396f54" /> Forward-Port-Of: odoo/odoo#249550
The Time Off balance report was incorrectly calculating remaining time off days due to how allocations were aggregated. This fix reorders allocations by their start date to ensure accurate calculations, particularly when employees have multiple allocations across different periods. This ensures the report accurately reflects available time off.
Original PR description
The balance report aggregates allocations regardless of the period in which they occur resulting in wrong information when an employee has two allocations in different periods and a filter is used in the report Steps to reproduce: 1. Install Time Off app 2. Open Time Off app and go to Management > Allocations 3. Create a new allocation of 100 days for employee "Mitchell Admin" of time off type "Paid Time Off" with a validity period from 01/01/2027 to 31/12/2027 and approve it 4. Activate debug mode 5. Go to Time Off > Reporting > Balance 6. The number of days left for "Mitchell Admin" for "Paid Time Off" is 120 days even though the default filter is on the period of 2026 Solution: Refactor the entire query: we order the allocations by date_from so we can subtract taken leaves from the allocations in that order opw-5156142 Forward-Port-Of: odoo/odoo#249512 Forward-Port-Of: odoo/odoo#245860
This update resolves an issue preventing successful processing of Dutch tax (OB) and ICP reports by Digipoort. The report templates have been updated to the final 20251210 NT20 taxonomy, ensuring compatibility and accurate data submission.
Original PR description
Update the Dutch tax (OB) and ICP report templates from the 20251210.a pre-release to the final 20251210 NT20 taxonomy to ensure successful processing by Digipoort. Fixes: https://github.com/odoo/enterprise/commit/5becacff48f1a2490ce2f57a4679020615b6b8c2 opw-5911496 Forward-Port-Of: odoo/enterprise#108126