Wednesday, February 11, 2026
14 changes · saas-18.4
Resolved issues and error corrections
Fleet Officers can now edit the fields used to mark cars and bikes as planned for change. This removes an unnecessary permission barrier so day-to-day fleet staff can manage vehicle availability without needing manager access.
Original PR description
Issue: The 'plan_to_change_car' and 'plan_to_change_bike' fields were restricted to Fleet Managers, preventing Fleet Officers from editing it. Fix: Changed the view-level group restriction from Fleet Manager to Fleet Officer for both fields.. task-5443107 Forward-Port-Of: odoo/odoo#241748
Fixed an issue in the website editor where carousel previews in the snippet dialog appeared too tall. This makes selecting snippets clearer and avoids a misleading preview when building website pages.
Original PR description
Steps to reproduce: - Open the website editor. - Open the snippet dialog. - Look at a carousel snippet preview. => The preview height is too tall. Before this commit, the dialog loads CSS after JS, so "computeMaxHeight" ran on an unstyled DOM and missed the "fit-content" height for the carousel. After this commit, the preview forces "fit-content" in JS so the height matches the final CSS layout. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244295 must be present**
This fixes a display issue where user group fields still appeared editable even when a form or view was set to read-only. Users will now see the correct read-only state, avoiding confusing changes that could not be saved.
Original PR description
Before this commit, the res_user_group_ids field introduced in [1] didn't care about the `readonly` props. As a consequence, when the field (or the whole view, via `edit="0"`) was readonly, the widget still rendered editable SelectMenu. Obviously, editing it and then triggering a save would raise a validation error, so it was only an UI issue. This commit fixes it by properly setting the field in readonly if its props states it. [1] https://github.com/odoo/odoo/pull/179354 task~5922282 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#247802
The full message composer now sorts mention suggestions using the conversation context, so followers appear at the top as expected. This makes it faster and less error-prone for users to mention the right people when writing messages.
Original PR description
Fetch/sort suggestion in the full composer don't receive the thread param which leads to follower not being sorted at the top. task-5917226 Forward-Port-Of: odoo/odoo#247966 Forward-Port-Of: odoo/odoo#247581
Users can now print bank statement PDFs from the Accounting statement list without triggering an access error. The change prevents extra print options meant for journal entries from loading when the selected record is a bank statement, making the print action more reliable.
Original PR description
In Bank Statement list view users may select a statement and download a pdf report. However, currently, the load of extra print options may raise an error. Steps to reproduce: - In Accounting Dashboard, from a bank journal card, 3 dots > Statements - Select a line (it needs to have an id not present in `account.move`) - Click 'Print' button Issue: Access error may occur, stating the record has been deleted or it is inaccessible. This happens because backend method `get_extra_print_items` is called on `account.move` with the id of the `account.bank.statement` On accessing the record fields we get the error A solution is to avoid loading extra print item with loadExtraPrintItems if we are not in the `account.move` model opw-5500506 Forward-Port-Of: odoo/odoo#246292
This change makes an automated barcode scanner test wait for the page to finish updating before checking results. It reduces random test failures, helping keep releases and quality checks more dependable without changing user-facing behavior.
Original PR description
This commit ensure to await the view to be correctly re-rendered. runbot-error-233551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246523
This fix keeps ribbon labels aligned on kanban cards when users press ALT to show selection options. It prevents a visual glitch that could make cards look broken or harder to read, without changing the underlying workflow.
Original PR description
The CSS rules of `.o_record_selection_available` are used to add a selection overlay on kanban cards. These rules relied on `filter: brightness()` to slightly dim all child elements when pressing `ALT`. However, using filter creates a new stacking context. As a result, when a ribbon is present, it no longer sticks to the card border and becomes misplaced. This commit updates the rules to avoid that behavior and keep the ribbon correctly positioned. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248164 Forward-Port-Of: odoo/odoo#247985
This update prevents a crash that occurred when using the budget filter in accounting reports. The issue stemmed from the system incorrectly assuming budget columns were always present, leading to an error. The fix adds a safety check to skip budget comparison when columns are missing, ensuring stable report generation.
Original PR description
**Steps to reproduce:** * In **Accounting**, create a new accounting report. * Set **Root Report** to **Profit and Loss**. * Add a report line with **Figure Type = Percentage**. * set **Computation…
**Steps to reproduce:** * In **Accounting**, create a new accounting report. * Set **Root Report** to **Profit and Loss**. * Add a report line with **Figure Type = Percentage**. * set **Computation Engine = External Value** and **Formula = 0** on report line. * Add a report column with **Figure Type = Monetary**. * Create a menu item for the report. * Open the report and click **Budget**. * Create a new budget filter and click **Create**. **Observed behavior:** * The system crashes with `TypeError: 'NoneType' object is not subscriptable`. * The error occurs while accessing budget column values. **Cause:** * Budget comparison logic assumes required budget columns always exist. * When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway. **Fix:** * Add a safety check to skip budget comparison when required columns are missing. * Prevents the crash and allows budget filters to be created safely. opw-5357339 Forward-Port-Of: odoo/enterprise#104162
This update resolves an issue where saving settings in a Guatemalan company's branch would incorrectly display a 'Missing required field' error. The fix ensures the 'Service Provider' field is correctly populated and required only for the main company, streamlining the setup process for branch offices.
Original PR description
Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no…
Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made. ### **Steps to reproduce:** 1) Install `l10n_gt_edi` and switch to a GT company. 2) Create a branch of the GT company. 3) In the parent company, go to Accounting Settings, set the Guatemala Localization to 'Demo', and save. 4) Switch to the branch company. 5) Open Accounting Settings and click Save. ### **Observed Behavior:** An error occurs because `l10n_gt_edi_service_provider` is empty but required. ### **Root Cause:** The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails. [1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22 ### **FIX:** Update the `required` domain to include `l10n_gt_edi_is_root_company`. This ensures the field is only mandatory in the root company where it is actually visible and configurable and also set the `l10n_gt_edi_service_provider` for branch company same as parent company. **opw-5385819** Forward-Port-Of: odoo/enterprise#106323
This update corrects a bug where the email address for Belgian customers wasn't being included in VAT reports. The fix automatically pulls the email from the customer's contact information, ensuring accurate reporting and compliance. This prevents missing email data in crucial financial documents.
Original PR description
**Steps to reproduce:** - Install l10n_be_reports and contacts - Switch to a Belgian company (e.g. BE Company CoA) - Go to Contacts - Open the company contact (i.e. BE Company CoA) - Add an invoice address withtout email - Create an invoice: * Customer: [a Belgian customer with a VAT number] * Invoice Lines: [a line with a tax] - Confirm the invoice - Go to "Accounting / Reporting / Belgium / Partner VAT Listing" - Export the XML **Issue:** In the XML, "<EmailAddress>" is empty althouth it is mandatory. **Cause:** The email is retrieved from the invoice address, but there is no fallback on the parent contact if it is empty. **Solution:** Fallback on the email of the parent contact as it is the case for the phone. opw-5870750 Forward-Port-Of: odoo/enterprise#106893 Forward-Port-Of: odoo/enterprise#105654
This update incorporates new codes required for Intrastat reporting, aligning with European statistical standards. These codes, sourced from the National Bank of Belgium, ensure accurate reporting of international trade data within Odoo Enterprise. This change improves compliance with regulatory requirements.
Original PR description
This commit adds 2026 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes opw-5504187 Forward-Port-Of: odoo/enterprise#106896
This update resolves an issue where customer display URLs weren't consistently being sent to the IoT device boxes when records were updated. The change ensures that the correct URL is transmitted, improving the functionality of the IoT integration. This fix was triggered by a bug in the update process.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927 Forward-Port-Of: odoo/enterprise#106331
This update fixes an issue where tasks were incorrectly scheduled with shorter durations. Specifically, tasks starting on a date within November were not extending into the following month as intended. The fix removes previously used scheduling intervals to ensure accurate allocation of hours and prevent tasks from being prematurely cut off.
Original PR description
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result,…
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours. Source: When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28). However, these four days are not enough to cover 40 hours. The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December. Solution: Remove already-used intervals before recomputing the schedule. opw-5364327 Forward-Port-Of: odoo/enterprise#106160 Forward-Port-Of: odoo/enterprise#101262
This update fixes an issue where credit notes were displaying negative tax amounts in the tax totals widget. The fix ensures accurate tax calculations are shown, preventing confusion and improving the reliability of financial reporting for Brazilian companies using the Avatax module. This resolves a discrepancy in how taxes were being computed.
Original PR description
Currently, when computing taxes for a credit note, the system will show the included tax as negative in the tax totals widget Steps to reproduce: - Setup a BR Company - Setup a product requiring tax ICMS included in price - Create a credit note with the product - Compute taxes Issue: In tax totals widget the tax amount will be reported as negative, even if the tax line balance is correct. opw-5866180 Forward-Port-Of: odoo/enterprise#106941 Forward-Port-Of: odoo/enterprise#106579