Tuesday, October 21, 2025
7 changes · saas-18.2
Resolved issues and error corrections
This fix improves how product image fetch jobs are scheduled by replacing a fragile duplicate-check mechanism with a safer cleanup before scheduling. It reduces unnecessary processing overhead and helps ensure image fetch timing works as intended, especially when multiple records are handled at once.
Original PR description
Remove `_check_image_cron_is_not_already_triggered` because: - It doesn't work in batch mode due to `self.cron_id.id`. - It increases the cost of creating a cron trigger because the reference lookup (`ref`) makes at least one extra query. (We want to keep cron trigger creation efficient since it is used everywhere.) - Because of this constraint, there is an extra commit in `_trigger_fetch_images_cron` that is inefficient and error-prone, serving no purpose. Keep the intended effect of the constraint by removing the existing cron trigger before the new one is created, ensuring the time offset is respected.
This fixes an issue where users could not turn debug mode on or off from the command palette while using the Documents app. The app now uses the latest navigation state when building links, so the debug setting updates correctly without requiring manual URL changes.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056 Forward-Port-Of: odoo/enterprise#96275
This fix ensures Italian point-of-sale receipts are printed correctly when the cash drawer option is enabled. It prevents sales from being disrupted for businesses using Italian fiscal printers with connected cash drawers.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480 Forward-Port-Of: odoo/enterprise#97379
Trial Balance PDF exports now respect the search filters entered by users, including account names, account codes, and account group names when hierarchy is enabled. This prevents exported reports from showing unrelated lines and helps finance teams produce accurate filtered PDFs.
Original PR description
### Issue: No filter is applied when exporting a PDF, although a filter from the filter_search_bar is provided. ### Step to reproduce: - Create an account group (e.g. Group_101 from 101 to 101) -…
### Issue: No filter is applied when exporting a PDF, although a filter from the filter_search_bar is provided. ### Step to reproduce: - Create an account group (e.g. Group_101 from 101 to 101) - Create some AML in an account related to the previously created group (e.g. in 101501 Cash) - Go to the Trial Balance - Add a filter including either an account name or account code (e.g. Cash), - Export to PDF - In the Options, select "Hierarchy and subtotals" - Add a filter including your group name (e.g. Group_101) - Export to PDF ### Current behaviour: - all lines are displayed in both PDF as the backend doesn't apply the filter ### Expected behaviour: - lines are displayed using groups and accounts names and codes to filter ### Cause: From the refactor of Trial Balance (see: https://github.com/odoo/enterprise/pull/73298), filter from filter_search_bar wasn't applied anymore. ### Solution: Bring back the domain to apply the filter that was used in the general ledger before the refactor. If hierarchy is enabled, fetch accounts where filter matches either account or group. As Group_id isn't stored, it requires an explicit computation. Some tests were made to merge the query from the field compute method and the one from this commit. However, as their `FROM` and `WHERE` clauses differ, it was a bit messy. opw-4906593 Forward-Port-Of: odoo/enterprise#93634 Forward-Port-Of: odoo/enterprise#90403
This fixes an internal payroll test that failed because newer Chrome versions changed how certain text styling details are reported. The change keeps payroll test checks reliable without affecting payroll features or the user experience.
Original PR description
Since either 140 or 141[^0] Chrome uses compact serialization rules for text-decoration, as a result of w3c/csswg-drafts#12486. This was merged [on August 12th][CL-6824265] and Chrome 139 was cut on August 5 so couldn't have had this change. The new serialization rule means values which can be ommitted from a shorthand (default or fallback) should be, so the default `text-decoration-line` and a `text-decoration-color` matching the `color` won't be serialized in `text-decoration` anymore. Instead of matching the shorthand, match the actual stored properties. [^0]: 140 was not deployed on chrome next so it may or may not have been broken then [CL-6824265]: https://chromium-review.googlesource.com/c/chromium/src/+/6824265 Note: this commit is a backport of odoo/enterprise@eddbdb2d9593b331c5ef641b7747ec61c736d84d
This fix ensures write-off entries created during journal item reconciliation are always treated as standard journal entries. It prevents errors in customized setups where a different default entry type could require extra information or reject certain accounts.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028
UPS shipment requests now include the sender and customer VAT information, so commercial invoices generated for cross-border deliveries show the correct tax details. This helps businesses avoid missing VAT information on UPS documents and reduces manual follow-up.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356