Thursday, May 7, 2026
12 changes · saas-18.2
Resolved issues and error corrections
Opening opportunities from a contact no longer causes archived sales teams, users, tags, or stages to appear when creating a new opportunity. Archived opportunities still remain visible where intended, keeping lists complete without cluttering selection fields.
Original PR description
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and…
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.
`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.
The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.
The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.
Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown
=> Archived teams appear in the dropdown
Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801The LDAP login test has been updated so it no longer leaves unwanted test data behind. This helps keep automated checks reliable and prepares the team to add more coverage for upcoming bug fixes.
Original PR description
The unit test is tagged `-standard` and `database_breaking` because it was leaving left overs in the database. Using an `HttpCase` over a `BaseCase` solves that issue in addition to make the code way simpler. We want to resurrect this unit test class because we plan to add another unit test in that class for a bug fix. Forward-Port-Of: odoo/odoo#261842 Forward-Port-Of: odoo/odoo#261743
The Point of Sale now handles paid orders linked to loyalty cards whose loyalty program has been archived. This prevents an error when staff open the customer list, keeping order lookup and customer service workflows stable.
Original PR description
Backport of https://github.com/odoo/odoo/commit/ffe46084665bb8a64ef9cd9f44b85f7178adf6f7 Before this commit, when loading a paid order with a loyalty card that its program had been archived, an error was raised when opening the partner list due to the missing program. opw-6182368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262575
The website editor test now waits for a product snippet to finish loading before moving to the next step. This reduces false failures in automated checks and helps keep website editing quality assurance reliable.
Original PR description
`test_03_snippets_all_drag_and_drop` was consistently failing on runbot. The tour stopped after removing the snippet `s_dynamic_snippet_products` because no drop zones were found for the next…
`test_03_snippets_all_drag_and_drop` was consistently failing on runbot. The tour stopped after removing the snippet `s_dynamic_snippet_products` because no drop zones were found for the next snippet. **Cause** The public widget `DynamicSnippetProducts` performs an RPC call in `willStart` (~1 second), but it is still possible to delete the snippet while the promise is pending. In this case, the editor is unresponsive until the promise resolves. The tour fails because the snippet is removed while the promise is still pending, the editor is not ready to process the click on the next snippet, and no drop zones are generated. **How to reproduce the problem** This is impossible to trigger manually, but consistently happening on runbot. The easiest way to reproduce the problem is to add a delay in `_fetchData()`. **Fix** Wait for the snippet to finish loading before proceeding with the tour, ensuring the editor is responsive when the next steps runs. runbot-226770 Forward-Port-Of: odoo/odoo#262498
Point of Sale now shows customer change as a negative amount, matching money leaving the shop. This makes checkout screens, receipts, and customer-facing displays clearer and consistent with how payments are recorded.
Original PR description
Steps to Reproduce ------------------------ - Install point of sale. - Do a order and pay more than the amount. Issue ------ - The change amount is displayed as a positive value on the UI. - Typically, amounts going out of the shop (like change given to the customer) should be shown as negative. Cause ------- - The change amount was not correctly represented in the UI. - Since the change flows in the opposite direction of the payment, it should be displayed as the negation of the original amount. FIX ----- - Updated the frontend to display the change amount with the correct (negative) sign. - No backend changes were required, as the correct value was already being handled during order synchronization Enterprise PR: https://github.com/odoo/enterprise/pull/112560 task: 6074620 Forward-Port-Of: odoo/odoo#256776
This update fixes a limitation in how Odoo Enterprise manages its UNSPSC product codes. Previously, new codes required a full module reinstall. Now, an automated upgrade script triggered during module updates adds missing codes to the database, ensuring the system always reflects the latest industry standards. Existing product codes remain unchanged.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#112652
This update resolves an issue where commission plans with negative target values caused errors. The fix ensures the commission calculation logic handles negative targets correctly by applying absolute values within the calculation process. This expands the flexibility of commission plan setup.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644 Forward-Port-Of: odoo/enterprise#116050
This update fixes an issue where Colorado state income tax calculations resulted in a positive value on payslips, which is incorrect. The fix aligns with established payroll tax principles, ensuring that taxes are always withheld from employee paychecks, not returned as refunds. This ensures accurate payroll reporting and compliance.
Original PR description
## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…
## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.
## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**
## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:
> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*
## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).
opw-5999856
Forward-Port-Of: odoo/enterprise#112724This update fixes a minor error in the calculation of Swiss source tax (QST) reversals within the payroll system. Specifically, it corrects a miscalculation of the minimum IS (Insolvenzsumme) during the reversal process. This ensures accurate tax reporting for Swiss businesses using the Enterprise edition of Odoo.
Original PR description
opw 6133391 Fix for the source tax correction following PR #114463 Forward-Port-Of: odoo/enterprise#115585
This update corrects a technical issue within the Odoo Enterprise's Kenyan payroll module (l10n_ke_he_payroll) that caused duplicate XML IDs for a key configuration setting. This duplication was identified and resolved to ensure accurate payroll calculations and prevent potential errors. The fix improves the stability and reliability of the module.
Original PR description
This commit avoids duplicated xml_id for `hr.salary.rule` model. In commit https://github.com/odoo/enterprise/commit/a7d51fa2ee8b1af0e807b3e9cb6e313d8885ff67, key `l10n_ke_employees_salary_pension_contribution` (sequence 72) was deleted and added key `l10n_ke_employees_salary_pension_contribution` (sequence 35). In commit https://github.com/odoo/enterprise/commit/c23243be9ca833acea7089defadbe0eaf869051d, key `l10n_ke_employees_salary_pension_contribution` (sequence 72) was added again. Forward-Port-Of: odoo/enterprise#115696 Forward-Port-Of: odoo/enterprise#85723
This update resolves an error that occurred when the account_followup module was installed without the related payment module. The fix ensures the system doesn't attempt to access a missing payment method, preventing template rendering failures for payment reminder emails. This ensures consistent email functionality.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116079
This update fixes a visual issue in the Point of Sale (POS) system where the displayed change amount was not showing the correct negative value. The change ensures that the POS interface accurately reflects the amount of change given to customers, improving the user experience and reducing potential errors.
Original PR description
In this commit: --------------- - The tours are updated to adapt the change as now frontend display the change amount with the correct (negative) sign. Community PR: https://github.com/odoo/odoo/pull/256776 task: 6074620 Forward-Port-Of: odoo/enterprise#112560