Thursday, May 16, 2024
4 changes · saas-17.2
Resolved issues and error corrections
The spreadsheet component was updated to a newer version with performance improvements. Users should experience faster formula evaluation and smoother spreadsheet handling, especially in larger or more complex sheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/57e89fa88 [REL] 17.2.7 Task: 0 https://github.com/odoo/o-spreadsheet/commit/025172800 [PERF] evaluation: faster spreading invalidation Task: 3925565 https://github.com/odoo/o-spreadsheet/commit/280fdca8f [PERF] tokenizer: avoid useless array map Task: 3920705 https://github.com/odoo/o-spreadsheet/commit/119b199b5 [PERF] tokenizer: avoid regexp match Task: 3922347
Fixed a checkout error that could occur when shoppers added a subscription product with only one pricing plan to their cart. This ensures customers can complete purchases for simple recurring products without encountering a server error.
Original PR description
**Steps** [website_sale_subscription] - Settings > Website, set "Add to Cart" behaviour to "Go to cart" - Create a recurring product with only one recurring price. - Go to shop, choose the recurring product and try to add it to the cart ** Error 500 ** **Issue** In case there's only one plan, no menu to select a plan is displayed and plan_id is NaN in that case. https://github.com/odoo/enterprise/blob/7d160198be779095660e7f6fb68ae231e4621972/website_sale_subscription/static/src/js/website_sale_subscription.js#L15 Which is going to be problematic later https://github.com/odoo/enterprise/blob/7d160198be779095660e7f6fb68ae231e4621972/website_sale_subscription/models/sale_order.py#L21 introduced by 7d160198be779095660e7f6fb68ae231e4621972 **Fix** We do not pass a plan_id if there's only one existing plan and use the fallback. opw-3891366
Portal users can now refresh or reopen shared Knowledge article pages without being sent back to their homepage. The fix keeps article access working with the updated URL system while still respecting each user's permissions.
Original PR description
This commit fixes an issue with the portal user and the new URL system recently added. The issue is that the portal user accesses a similar view to the internal one. With the old URL it was possible to access specific articles as the router always added the id of the article to the `/knowledge/home` route. Now with the new URLs, this is replaced by an internal one => `/odoo/knowledge/<article_id>` which shouldn't be accessed by portal users. This behavior leads to the portal user to be redirected to its homepage when the browser is refreshed. Now we are adding a new home route inside the knowledge's portal controller that parses the url for a subpath, this subpath is then checked to see if we last came from an article. If that's the case we then rerender the corresponding template if he has access to it. If not, then we let the other controllers to handle it. task-3833518
Fixes a web navigation issue where clicking links that point to a section on the same page could unexpectedly reload the app and send users back to the home menu. These links now behave as expected, improving reliability when navigating within pages.
Original PR description
When we changed client-side routing to be path based, we broke the behavior that allowed anchor-only links to scroll to the element with the corresponding id. It would instead cause the webclient to…
When we changed client-side routing to be path based, we broke the behavior that allowed anchor-only links to scroll to the element with the corresponding id. It would instead cause the webclient to attempt to load the state and end up on the home menu. This is caused by the fact that clicking on anchor links fires a popstate event, but that popstate event has no associated state. To fix this, we need to be able to differenciate a popstate event from an anchor click from other popstate events. Initially we considered simply setting a local variable when the user clicks on an anchor link, and checking that variable in the popstate handler, but this is both prone to race conditions and also causes issues when a link is clicked but preventDefault is called on the click event, preventing the popstate from occuring. As such, we decided instead to use the fact that the state on the popstate event from anchor clicks is null. The state is only null in two cases: when you click on such a link, or when you use the back button to go back to the first entry in history where the webclient was loaded. In the second case, this was purely incidental: we actually parsed the state from the URL and when the action mounted, it wouldn't touch the state because the new url was the same as the old one. In order to differenciate from the anchor link click, we now replace the state when the urls are identical. This will incidentally save us from parsing the url again if the user navigates back to this history entry, as the corresponding state will have been saved. Enterprise: https://github.com/odoo/enterprise/pull/60741