Thursday, February 26, 2026
33 changes · saas-18.2
Enhancements to existing features
The event website registration process was reorganized so customizations can hook into the preparation step instead of replacing raw page output. This makes future tailored event registration changes easier and safer for implementers, without changing the standard user experience.
Original PR description
Since this controller returns raw markup, it is impossible to inherit. By splitting the controller `registration_new`, allows to manage custom developments with the inheritance of the prepare method instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244156
This update adjusts the Romanian tax reporting within the Enterprise module to align with recent changes in the Core Enterprise (CE) version. The update removes outdated tax codes and adds new ones, ensuring accurate reporting for Romanian businesses. This ensures compliance with current tax regulations.
Original PR description
Some taxes were no longer needed in CE, so they needed to be removed task-5411745 Forward-Port-Of: odoo/enterprise#108374 Forward-Port-Of: odoo/enterprise#106127
Resolved issues and error corrections
Point of Sale sessions now save opening notes even when a cash payment method is not configured. This keeps session records complete and avoids losing important opening information for businesses that do not use cash in their POS setup.
Original PR description
Before this commit: -------------- - When the cash method was not available for config, opening notes values were not being stored in session data. After this commit: -------------- - Opening notes values will be stored in session data even when the cash method is not available for config. task-5474822 Forward-Port-Of: odoo/odoo#243956
Miscellaneous changes
This commit adds the new modules of pos_edi_ubl and l10n_jo_edi_pos to weblate. Forward-Port-Of: odoo/odoo#250324
Original PR description
This commit adds the new modules of pos_edi_ubl and l10n_jo_edi_pos to weblate. Forward-Port-Of: odoo/odoo#250324
Fixed an issue where products assigned to a website category could be saved before their published status was properly applied. This helps ensure product publishing behaves consistently and avoids false failures in the online shop workflow checks.
Original PR description
Error: AssertionError: False is not true self.assertTrue(product.website_published) Cause: Commit https://github.com/odoo/odoo/commit/ca198cfc7c41a8c15b2734518016007aa1c16457 relies on _onchange_public_categ_ids to set website_published=True when a category is assigned. Two issues: 1. website_published was not in the dialog form view, so its onchange value was never tracked or sent to the server on save. 2. The tour clicks Save before the onchange response is received, so the product is saved without website_published=True. Fix: - Add website_published as an invisible field in the dialog form view so its value is tracked and sent on save. - Wait for the category badge to appear before submitting, ensuring the onchange has completed before save. runbot-237976 Forward-Port-Of: odoo/odoo#249027
Invoices for Qatar companies now spell the currency as "Riyal" when showing total amounts in words. This prevents customer-facing invoice text from using the incorrect label "Rial".
Original PR description
Steps to reproduce: 1- Install Accounting and 'l10n_qa' modules 2- Switch to Qatar company and enable "Total amount of invoice in letters" under accounting settings 3. Issue an invoice and preview it The issue: The description of the amount uses "Rial" Expected behavior: The amount should use "Riyal" opw-5919587 Forward-Port-Of: odoo/odoo#250299
This update fixes several issues in Odoo’s automated testing tools so tests run more consistently, report failures more clearly, and clean up properly between runs. The changes help developers detect problems faster and reduce false failures, improving overall product quality without changing end-user features.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247137
Back-in-stock notification emails now use the email address of the website where the customer requested the alert, instead of the product company's email. This ensures customers receive messages from the expected business identity, which is especially important for multi-website or multi-company setups.
Original PR description
…notification # The problem The mail sent to notify a customer that a product is back in stock used the e-mail of the company associated with the product. We would rather use the e-mail of the company associated with the website the notification request was done in. This commit aligns versions 18.0+ with what is done on master (https://github.com/odoo/odoo/commit/8ec57b1115a55e8b59db9b8c1e843c6a1c888db3) opw-5868889 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249299
Fixes a point-of-sale restaurant issue where moving an order to a booked table with no items could cause an error. This makes table transfers more reliable for staff managing reservations and active orders.
Original PR description
Step to reproduce: - Make a pos order - Book a table without orderlines - Transfer the order to the booked table - Traceback Issue: The transferOrder method was retrieving non-finalized table orders that contained order lines using getActiveOrdersOnTable. However, it later checked for the existence of any non-finalized order using tableHasOrders, regardless of whether it had order lines. This caused inconsistent behavior in cases where a table was booked but had no order lines. opw-5965705 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#250407
Time off allocations that started in the previous year but are still valid are now included in the allocation count shown on time off type pages. This removes a confusing mismatch between the displayed smart button count and the actual list of valid allocations.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272 Forward-Port-Of: odoo/odoo#248482
The sales Kanban view now shows order statuses in their natural business sequence when grouped by status. This avoids confusion caused by alphabetical ordering, making it easier for users to follow the sales workflow at a glance.
Original PR description
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as…
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as Cancelled, Quatation, Sale order, Quatation sent. Root cause: --- - When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself. - Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order as `cancel, draft, sale, sent`. Solution: --- - Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly. - This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view. opw-5497664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248776
Duplicating a project task now skips subtasks that were archived. This keeps duplicated tasks cleaner and prevents old or inactive work items from reappearing unintentionally.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009 Forward-Port-Of: odoo/odoo#248167
This fix prevents harmless asset loading errors from being reported after automated website tours have already ended. It reduces false failure reports in testing infrastructure, helping teams focus on real issues.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826 Forward-Port-Of: odoo/odoo#248003
This fix updates website editing dialogs so blank preview frames load correctly in Firefox 148 and newer. Business users benefit from reliable page template and snippet preview dialogs when building or editing website pages.
Original PR description
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing…
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing context goes to about:blank, it completes > synchronously and is no longer replaced by a second parser-generated > document. Commit [e0796020] added the new page dialog in website, and used empty iframes to load each page template. Commit [edf81c13] added the add snippets dialog in website, and used an empty iframe to load the snippets previews. In both cases, before Firefox' fix, it meant we had to wait the recreation of the 2nd document before proceeding. This is no longer the case in Firefox >= 148. [release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/ [e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7 [edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a Forward-Port-Of: odoo/odoo#250592
People booking an event booth with an email already known to the system now see clearer guidance to sign in or create an account. This helps avoid confusion for contacts who exist in the database but do not yet have portal access.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#241445
This fix prevents products used as loyalty rewards from being hidden in the Point of Sale. It helps ensure loyalty promotions continue to work reliably for cashiers and customers.
Original PR description
Before this commit, a product used as a loyalty reward could be hidden in the PoS. opw-5918550 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248481
This fix avoids automatically focusing the delivery location list when the customer has not selected a location. It helps prevent confusing or disruptive checkout behavior, making the delivery selection flow smoother.
Original PR description
Forward-Port-Of: odoo/odoo#250680
Early payment discounts are now calculated consistently across the whole invoice instead of rounding each line separately. This prevents small one-cent discrepancies in accounting entries and exported e-invoice data when cash discount tax reduction is applied on the invoice.
Original PR description
**PROBLEM** There is a rounding issue with early payment discount when cash discount tax reduction is set to always (upon invoice). The move.line created for the discount is computed by applying the discount to each line, rounding each line individually. But the early payment discount is computed by rounding globally. **STEP TO REPRODUCE** 1. Create a payment term, with early discount of 1%, and cash discount tax reduction set to 'Always (upon invoice)'. 2. Create an invoice with 4 identical lines, unit price 4.76€ and tax 15%. 3. set the payment term on the invoice and save. 4. Go to journal item, early payment discount is 0.20€. 5. toggle discount_amount column on the the journal item tab. 6. notice on the last line, that balance - discount_amount = 0.19€ instead of 0.20€ opw-5865308 Forward-Port-Of: odoo/odoo#247996
This update ensures the names of Ecuadorian localization regimes comply with government requirements for electronic invoicing. The change updates the names to Spanish, which is consistently used in all government-submitted invoices, regardless of user language settings. This ensures accurate and compliant invoice generation for Ecuadorian businesses.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update resolves an issue where helpdesk users with limited access were unable to view tickets due to a requirement for read access to stock records they didn't have permission to access. The fix adds a security group to the ticket field, ensuring only authorized users can read this information and preventing access errors.
Original PR description
To reproduce: ============= - install helpdesk_stock - with user having only User rights on helpdesk and nothing on other modules - try to access a ticket -> AccessError Problem: ======== when reading the ticket, the field `suitable_product_ids` is computed, and it requires read access to records the user doesn't have access to, which raises an AccessError. Solution: ========= Add the group `stock.group_stock_user` to the field, so that only users having access can read it. backport of https://github.com/odoo/enterprise/pull/59605 opw-5907657 Forward-Port-Of: odoo/enterprise#108139 Forward-Port-Of: odoo/enterprise#107291
This update ensures that check printing in the Philippines accurately reflects the net payment amount after withholding taxes. Previously, the check amount didn't correctly account for these deductions. A new test case has been added to verify this updated behavior.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108611
This update resolves a technical problem with how Hoot, a key component of the Odoo Enterprise SaaS platform, responds to user clicks. The fix ensures that Hoot's functionality works correctly by preventing keydown events from incorrectly targeting the wrong element. This improves the overall user experience and stability of the platform.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#107286
This update addresses a critical maintenance task – updating the tax codes used in Odoo Enterprise's account module. The tax code definitions hadn't been updated in four years, and this fix ensures continued accurate tax calculations. A future enhancement will allow users to initiate this update automatically, but this immediate fix resolves the current issue.
Original PR description
It's been 4 years since the last update [1]. No codes were removed. At some point it would be nice to add this to the avatax_sync_company_params() method so it can be initiated by the user. But we need to update this file regardless, and the mechanism would need to be smart enough to not cause duplicates when e.g. the user has synced it themselves, we then update the csv and they then update the module. [1] https://github.com/odoo/enterprise/pull/30220 opw-5928245 Forward-Port-Of: odoo/enterprise#108209
This update fixes an issue where warehouse names with only numbers (like '01') were displayed incorrectly in the barcode app. The fix removes a browser setting that caused numerical warehouse codes to be reversed, ensuring they are always shown in the correct order. This improves the user experience when scanning products.
Original PR description
### Steps to detect the bug: - Download stock apps - Enable "storage locations" settings under warehouse index - Change name of warehouse with a name composed only of numbers (ex. 01) - Create a…
### Steps to detect the bug:
- Download stock apps
- Enable "storage locations" settings under warehouse index
- Change name of warehouse with a name composed only of numbers (ex. 01)
- Create a product (with barcode number)
- Insert a number of products available with smart button "on hand"
- Create a new delivery for that product
- Go to barcode app and search for the delivery you just created
- Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.
### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
opw-5730199
Forward-Port-Of: odoo/enterprise#107920This update resolves an issue preventing the SAF-T report from correctly identifying suppliers for fixed assets. The fix ensures that supplier information is accurately retrieved by expanding the data source to include depreciation lines, even for bills created in previous months.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#105987
This update ensures that Website Studio's translation terms are correctly applied only to the HTML/CSS editor when a website is active. Previously, the system used the default language of the first website, leading to potential inconsistencies. This change improves the accuracy and reliability of translations within the Studio interface.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#107459
This update streamlines the process of finding and creating bank accounts within Odoo Enterprise. The changes ensure consistency across multiple modules, reducing potential errors and improving the user experience when managing financial transactions. This enhancement primarily addresses internal operational efficiency.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update fixes an error in the Profit & Loss reports for Spanish fiscal localization packages. Accounts 7950 and 7957 were previously incorrectly placed in section 10, which is now corrected to section 6 according to official Spanish tax regulations. This ensures accurate reporting for Spanish businesses.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108575 Forward-Port-Of: odoo/enterprise#107949
This update resolves an issue where certain Intrastat codes (99450000, 99500000, 99600000, and 99700000) were incorrectly marked as expired. The fix ensures these codes remain active, aligning with official Belgian regulations as outlined in the Intrastat manual. This correction is crucial for accurate reporting of international trade data.
Original PR description
99450000, 99500000, 99600000 & 99700000 were erroneously expired. They are still active : https://www.nbb.be/doc/dd/onegate/data/intrastat_manual_basis_en.pdf page 13 Forward-Port-Of: odoo/enterprise#108451
This update fixes an issue where VAT amounts were incorrectly displayed as zero in XML exports for manual journal entries. The fix removed a filtering condition in the SQL query that was excluding standard journal entry lines, leading to inaccurate VAT calculations. This ensures accurate VAT reporting for manual entries in the MA Company.
Original PR description
## Issue: When creating a manual journal entry with a deductible tax, the entry was included in the XML export, but the VAT amounts were all set to 0 ## Cause: The SQL query used to compute VAT amounts included an extra condition on display_type to be 'tax' However, journal entry lines are standard product lines and should not be excluded by this condition As a result, the amounts (MHT, TVA, TTC) were incorrectly computed as 0 in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA Company - Create a Journal Entry (Any account, Debit: 100, Taxes: 10% 150) - Open the Tax Report for the current month - Export the XML using the gear icon Before the fix, the value for mht, tva and ttc where all 0 opw-5226529 Forward-Port-Of: odoo/enterprise#108644
This update fixes an issue where SII invoices weren't correctly formatted, preventing successful submission. The change updates XML tags related to withholding taxes to align with SII's specific requirements, ensuring invoices are accepted by the SII system. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update resolves an issue where a 100% discount on German Point of Sale (POS) certified transactions would cause an error. The change ensures the system handles this scenario correctly, preventing disruptions to the sales process. This improves the reliability of the German POS certification feature.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/98869 opw-5240429 Forward-Port-Of: odoo/enterprise#108561
A recent test in the payroll system was failing when the 'Attendance' module wasn't installed. This update moved the test to a separate module to ensure it always runs correctly, preventing disruptions and maintaining consistent payroll processing. This fix improves the reliability of our payroll calculations.
Original PR description
Purpose: `test_05_fully_flexible_contracts_payslip` was failing without attendance installed as it creates contracts with `'work_entry_source': 'attendance'` Fix: moved the test to `hr_payroll_attendance` to ensure that it always runs with attendance installed pr introducing the test: https://github.com/odoo/enterprise/pull/93935 task-id: 5902805 Forward-Port-Of: odoo/enterprise#106320