Monday, June 17, 2024
9 changes · 17.0
Enhancements to existing features
This update improves the performance of the invoice reconciliation feature by optimizing how the system searches for matching invoices. The change reduces query execution time by 70% (from 7.5 seconds to 2.3 seconds) on large databases, making the reconciliation process significantly faster and more responsive for users working with many transactions.
Original PR description
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query…
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query with 6 subqueries (a general query with 6 UNION ALL). This can become quite slow on database with lots of amls. Because for each of these 6 "subqueries" the FROM, JOIN and WHERE clauses are the same, we can extract all of them in a single CTE. Thanks to that the CTE is executed only once and each UNION ALL simply scans the CTE to get the correct columns + performs an additional filtering. This reduces the average execution of the query by a factor of 3-4 on hot-cache. Since the onchange is triggered each time we do something in the reconciliation widget, on average the cache is expected to be hot so the average speedup boils down to the hot-cache scenario. #### speedup Customer 17.0 database with 7M account_move_lines and 8000 accounts, the query execution, given a st_line and with both numerical and exact tokens: 7.5s -> 2.3s ##### dalibo [Standard](https://explain.dalibo.com/plan/0a6fe16h503614e0) vs [CTE](https://explain.dalibo.com/plan/495a777ef95d2980) There is also a speedup achievable with a partial multicolumn index but that's more of a case by case index. opw-3938995 Forward-Port-Of: odoo/enterprise#64433
Resolved issues and error corrections
The help center was displaying empty sections for knowledge articles that don't have names. This fix filters out unnamed articles so only valid articles appear, improving the visual presentation and user experience of the help center.
Original PR description
Currently in the help center, knowledge articles without names are not sorted out, leading to empty divs being displayed. This PR will fix this by excluding articles without name in the _compute_latest_articles(). task-3940889
Fixed an issue where users couldn't open document previews by clicking on the upper part of cards in the split tool when using Safari or Firefox browsers. The fix involved adjusting the CSS styling to ensure the clickable area works properly across all browsers.
Original PR description
Bug === 1. Open Safari or Firefox 2. Open the split tool 3. We can not open the preview by clicking on the upper card of the card Technical ========= The hover effect was done with CSS trickery, so we added a new div to remove the CSS `transform` trick. Task-3863428
This fix corrects how documents are counted and displayed in project updates. Previously, the system was incorrectly filtering out documents linked to closed tasks, showing an inaccurate document count and hiding documents when users clicked to view them. Now all documents are visible regardless of task status, giving users a complete view of project documentation.
Original PR description
Steps to reproduce: - Install `documents_project` - Go to one of the task and add a document - Close it Issues: In the project update the number of documents is shown however it is wrong, as it compute it by retrieving all the tasks without taking into account the state of the tasks. When clicking on the documents button you don't see documents linked to task that are closed, the desired behaviour is to see all of them and not take into account the state of the tasks. The behaviour was due to the way the domain is set on the `task_ids` in the project model. https://github.com/odoo/odoo/blob/174cb193592f12c7f4167eb34642665778deb208/addons/project/models/project.py#L332-L333 Because of this when we retrieved the documents we didn't have all the tasks. https://github.com/odoo/enterprise/blob/0e98a5fdf5e4f32eeae769552284297b9233088c/documents_project/models/project_project.py#L204 opw-3921156 Forward-Port-Of: odoo/enterprise#64603
This fix ensures that reversed asset entries are properly reflected in the depreciation schedule. Previously, when an asset entry was reversed in the past, the depreciation schedule would show incorrect cumulative depreciation amounts because reversed entries were not being included in the calculations. This update corrects the reporting to accurately account for all reversals.
Original PR description
Create an asset Reverse an entry in the past => In depreciation schedule, if we take the current period, initial amount in Depreciation does not correspond to the cumulative depreciation in the Depreciation Board of the asset. The reversed entry are not taken into account, which was normal before, but now we take reversal entry into account so these should be too. opw-3890144 Forward-Port-Of: odoo/enterprise#64564 Forward-Port-Of: odoo/enterprise#63821
This fix resolves an error that occurred when creating invoices between companies using products that are only defined for one company. The system now properly handles company-specific products during inter-company transactions, allowing automatic invoice generation to work correctly without access errors.
Original PR description
…efined Steps to reproduce: - Have a company A - Have a company B - Have a Product A defined only for Company A - Activate intercompany and automatic invoice/bills in both Company A and Company B - In Company A, create an invoice with Product A and Company B as the customer - Confirm Issue: An access error is raised Cause: Because of the new access rules introduced by branches, `account.move.line` have `_check_company_auto = True` https://github.com/odoo/odoo/blob/14db39961c445a8243c2cc7af44132320a655594/addons/account/models/account_move_line.py#L23 Triggering the check at https://github.com/odoo/odoo/blob/e30853b9fbde28cd4b1dc9948e12fe2be0b03abc/odoo/models.py#L4324-L4325 Creating inconsistencies at https://github.com/odoo/odoo/blob/e30853b9fbde28cd4b1dc9948e12fe2be0b03abc/odoo/models.py#L3745-L3750 Solution: Set the product on the bill only it has no company_id set on it opw-3875354 Forward-Port-Of: odoo/enterprise#63086
This update fixes a technical issue in the Documents module where certain calculated fields used for sharing documents were missing their required dependencies. This ensures that these fields update correctly when their underlying data changes, improving the reliability of document sharing functionality.
Original PR description
Task-3924439
This update fixes how the Amazon sales connector handles subsidiary and multi-company setups. Previously, the system had issues managing Amazon accounts across different company entities within the same Odoo instance. The fix ensures that Amazon sales orders and inventory are properly synchronized across all company structures, improving reliability for organizations with multiple subsidiaries.
Original PR description
opw-3935664
This update enables credit card accounts to be treated as liquidity accounts in bank journals, allowing them to be used in the bank reconciliation process. The change updates the reconciliation wizard and Romanian SAFT reporting to properly recognize credit card accounts alongside traditional bank accounts.
Original PR description
*l10n_ro_saft According to the related community commit, we consider the account type `liability_credit_card` also as a liquidity account for bank journals. We adapt the reconciliation wizard and Romanian SAFT code to take this into account. task-3891250 Related to https://github.com/odoo/odoo/pull/166258 Forward-Port-Of: odoo/enterprise#63367 Forward-Port-Of: odoo/enterprise#63259