Thursday, September 3, 2026
15 changes · saas-18.4
Enhancements to existing features
Financial reports now avoid an unnecessary counting step in common cases, allowing large Balance Sheet-style reports to run much faster. This improves responsiveness for companies with high accounting transaction volumes while preserving the same results.
Original PR description
On standard AML-backed domain-engine queries, `id` is unique. `COUNT(DISTINCT id)` is therefore redundant and prevents PostgreSQL from using a partial hash aggregation. Analytic-groupby and cash-basis modes retain `DISTINCT`, as their temporary AML relations can contain duplicate AML IDs. Benchmark on the Balance Sheet query, 5 runs per size: | Matching AMLs | Before | After | |---:|---:|---:| | 2.3M | 3.19 s | 2.06 s | | 5.8M | 6.51 s | 2.91 s | | 11.5M | 9.78 s | 3.64 s | | 17.2M | 15.63 s | 4.67 s | | 23.0M | 16.01 s | 4.68 s | At 23M AMLs, execution time drops from 16.01 s to 4.68 s (3.42x). Result sets are identical before and after. opw-6459372 Forward-Port-Of: odoo/enterprise#128404
Resolved issues and error corrections
Uploading BIS3 electronic vendor bills no longer fails when the supplier country is missing from the XML. The system now checks for the missing country and uses the country saved on the partner record as a fallback, helping businesses process supplier bills more reliably.
Original PR description
Steps to reproduce: - Install accounting and create BE company - Create BIS3 xml where there's no country for AccountingSupplierParty - From BE company, upload the xml vendor bill Current behavior: Error when trying to upload xml Expected behavior: No error Cause of issue: Currently there's no check to see if a country exists in the BIS3 xml. This PR adds a check and adds a fallback to get the country attached to the partner record if there's none present in the xml opw-6498830 Forward-Port-Of: odoo/odoo#284862 Forward-Port-Of: odoo/odoo#284554
Code cleanup and technical improvements
This update removes an unnecessary special lock and manual save step when uploading final PDFs for Greek e-invoicing. Because the upload can safely be retried, it now follows the standard Send & Print process, reducing complexity and making retries more reliable.
Original PR description
The final PDF endpoint is idempotent and is safe to call repeatedly with the same invoice identifiers. Remove the unnecessary PDF-specific lock and explicit commit, let the upload status follow the normal Send & Print transaction and retry the idempotent upload when needed. Related: https://github.com/odoo/odoo/pull/281739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285889
This fixes a case where the website HTML builder could fail to recognize the currently selected option when that option had a lower internal priority. The change helps ensure editor settings are reflected correctly, especially for combined editing actions.
Original PR description
The function `useSelectableComponent` looked for the selected option by searching for the option with the highest priority among the options that are applied. The search for highest priority implicitely excluded options with negative priority. This case happens with `composite` action when the inner actions have no definition of `getPriority`. This commit initialize the "highest priority found so far" as `-Infinity` instead of 0. task-5245362
This fixes an internal test for Canadian payment processing so it produces consistent results every time. It helps prevent false build failures and keeps delivery pipelines reliable without changing customer-facing behavior.
Original PR description
Sorts the expected items in `test_cpa005` to ensure consistent ordering. runbot error: https://runbot.odoo.com/odoo/error/941567 Forward-Port-Of: odoo/enterprise#127703
This fix prevents invoice-specific analytic plan rules from being incorrectly applied in unrelated areas such as Work Centers or Employee views. Users will now see the intended default analytic applicability when a screen does not provide a business context, reducing incorrect mandatory analytic distribution prompts.
Original PR description
### Issue: When an analytic plan has applicability lines with a company filter, the applicability is incorrectly applied on views that do not define a `business_domain`, such as Work Centers or…
### Issue: When an analytic plan has applicability lines with a company filter, the applicability is incorrectly applied on views that do not define a `business_domain`, such as Work Centers or Employee views For example, if a plan has: - Default Applicability: Unavailable - A line with Domain: Invoice, Company: My Company, Applicability: Mandatory Opening the analytic distribution on a Work Center shows `Mandatory` instead of the default `Unavailable` ### Cause: In commit https://github.com/odoo/odoo/commit/ffcf2ee1a3185ef73db93bfd95625844506692c5 `_get_score` was updated to return `0.5` when the applicability line's company matches the caller's company, even when no `business_domain` is provided In `_get_applicability`, the loop selects the first rule whose score exceeds the current minimum, which starts at `0`: https://github.com/odoo/odoo/blob/710e056e5171af2ab72d7d7793da3518f12faf5e/addons/analytic/models/analytic_plan.py#L255-L264 A score of `0.5` is enough to win over the default applicability, so a company-only match on a domain-specific rule incorrectly overrides the default when no `business_domain` is passed ### Steps to reproduce: - Install `mrp` and `accountant` with demo data - Enable Analytic Accounting in Settings - Open the Internal analytic plan and edit its applicability line: -- Remove the account prefix -- Default Applicability: Unavailable -- Domain: Invoice, Company: My Company (SF), Applicability: Mandatory - Go to Manufacturing > Configuration > Work Centers - Open any work center and click on Analytic Distribution Before the fix, Internal is shown as Mandatory instead of Unavailable Removing the company from the applicability line confirms the issue opw-6404884 Forward-Port-Of: odoo/odoo#280312
This update prevents an error when users drag an image and drop it back in the same place in the HTML editor. It keeps the editing experience stable in Chrome by handling the cursor position safely during the drag-and-drop action.
Original PR description
Steps to reproduce: - Insert an image as the last child of a paragraph. - Drag and drop it below or after itself. Description of the issue: - A traceback occurs. Cause: - When dropping an image below or after itself `document.caretPositionFromPoint()` computes a drop offset equal to the current node size. - The image is then removed from the DOM before being reinserted. Since it is the last child of its parent, removing it shrinks the parent, making the previously computed offset out of bounds. - Restoring the selection at that stale offset results in a traceback. Solution: - Treat dropping the image at its current position as a no-op and skip the remove/reinsert process, since it would not change the DOM. - Clamp the drop offset to the current node size before restoring the selection preventing out-of-bounds offsets. task-6435091 Forward-Port-Of: odoo/odoo#280612
The Helpdesk SLA Status Analysis report now calculates “Hours Open” from ticket creation to closure, matching the Ticket Analysis report. This gives managers a more accurate view of how long tickets remain open and avoids confusing it with assignment time.
Original PR description
1. Open Helpdesk > Tickets and create a ticket on the team "Customer Care", assigned to yourself 2. More than an hour later, move it to the "Solved" stage to close it 3. Open Helpdesk > Reporting > Ticket Analysis, switch to the pivot view and pick the "Hours Open" measure -> the ticket holds the hour it stayed open 4. Open Helpdesk > Reporting > SLA Status Analysis and pick the "Hours Open" measure as well -> the ticket holds nothing, as it was assigned as soon as it was created odoo/enterprise#47454 added the "Hours Open" measure of the ticket analysis to the SLA status analysis, but computes it up to the assignment date instead of the closing date. The measure therefore holds the hours until the ticket was assigned, which the report already offers as "Working Hours to Assign". With this commit, both reports count the hours from the creation of the ticket to its closing. Forward-Port-Of: odoo/enterprise#130170
This fixes cases where changing default values in website forms or translations could not be properly undone. It also prevents stale date values from remaining visible when switching form field types, making website editing more reliable for users.
Original PR description
The `value` property of the elements is not tracked by the history plugin, because `MutationObserver` does not produce mutations for that. This commit uses custom mutations when the `value` is changed, to restore the previous value on undo. Steps to reproduce: - Open website builder - Add a form - Set a "Default Value" on a text field - Press enter (to end preview) - Undo (with the button, or with focus out of the option's input) - Bug: The value shown in the page did not revert with undo Similar bug in translate mode task-6229671
This update corrects how Adyen payment information is read from incoming payment messages. It helps ensure payment transactions use the right values, reducing the risk of incorrect payment processing or status updates.
Original PR description
opw-6512723 Forward-Port-Of: odoo/odoo#284773
Odoo now handles requests with overly long web addresses more gracefully. Instead of triggering an internal error while preparing the rejection response, the server safely returns the expected response, improving reliability for edge-case traffic.
Original PR description
- When the request URI is too long, the HTTP server rejects the request before parsing the headers. As a result, `self.headers` is not available when the WebSocket compatibility code in `send_header()` and `end_headers()` is executed. - Access `self.headers` safely to avoid an AttributeError while handling the 414 response. **opw-6501275** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286046 Forward-Port-Of: odoo/odoo#285870
This fix closes a loophole that allowed portal users to change a customer's name by creating another invoice contact. It helps keep customer records consistent and prevents unauthorized name edits during the sales process.
Original PR description
Before this commit it was possible to update name by creating an other invoice partner. The AND condition was wrong here. Forward-Port-Of: odoo/odoo#285537
This fixes an automated test for website rentals that could fail late in the UTC day because the test dates crossed into a different pricing period. The change sets a fixed date for the test, improving reliability without changing customer-facing rental pricing behavior.
Original PR description
Scenario:
- be (or switch your computer) at time between 21:01 and 23:59 UTC
- run test test_product_attribute_value_config_get_combination_info
Result:
This error is happening:
Traceback (most recent call last):
File "…/tests/test_website_sale_product_attribute_value_config.py",
line 106, in test_product_attribute_value_config_get_combination_info
self.assertEqual(combination_info['price'], price_3_hours)
AssertionError: 6.42 != 15.0
Cause: since the time range is on multiple day, we favor a weekly price
that is more interesting and the result is not the 3 hours price.
Fix: set the date for the test.
runbot-227695
Forward-Port-Of: odoo/enterprise#130062This fixes an installation problem in the Polish bank verification module that could cause failures for companies with many payment records. The change avoids unnecessary processing during setup, making installation safer and more reliable for larger databases.
Original PR description
account.payment model computes every record l10n_pl_verification_id at module installation (l10n_pl_bank_verification), causing crash in case of db with a large number of records wrong method name correction: _auto_init instead of init and call super after creating the db column see odoo/odoo#282504 Forward-Port-Of: odoo/odoo#285968
UPS shipments could be rejected when a customer's invoicing address did not have its own name. This fix uses a fallback name for invoicing details so affected deliveries can be confirmed successfully.
Original PR description
Issue ----- By default, invoicing addresses of existing partners are created without a name. This leads to the deliveries being rejected by UPS. Steps to reproduce ----- - Set Up UPS - Create a Customer - Create an invoicing address with no name - Create a SO for the partner & confirm - UPS delivery - Open the picking and confirm it > UPS rejects the shipment /!\ I could not reproduce in testing environment, so this is based off user steps in their production DB. /!\ Cause ----- The partner being used in `_set_invoice` was changed in #119747 but this use case was missed due to the error not occuring in test mode. ----- Ticket: opw-6485164 Forward-Port-Of: odoo/enterprise#128933