odoo/odoo#154358
Created by Guillaume Dieleman (gdi)
Statuses:
- legal/cla: Contributor License Agreement check
- ci/runbot: Odoo Test Suite
- ci/upgrade_enterprise: Test upgrades for enterprise master
- ci/template: Contact runbot team on discord for help.
- ci/style: Optional style check. Ignore it only if strictly necessary.
- ci/security: Required security check. Can only be ignored by security team.
- label
- odoo-dev:16.0-fix-cache-active-menu-item-gdi
- head
- ae59f3c09ffa1db01ee978afefebfe3df6302e35
- merged
- 1 year ago by Romain Derie (rde)
| odoo/odoo | odoo/enterprise | |
|---|---|---|
| 16.0 | #154358 | |
| saas-16.3 | #157897 | #58853 |
| saas-16.4 | #158998 | #59316 |
| 17.0 | #159006 | #59321 |
| saas-17.1 | #159080 | #59358 |
| saas-17.2 | #159191 | #59399 |
| 18.0 | ||
| saas-18.1 | ||
| saas-18.2 | ||
| saas-18.3 | ||
| saas-18.4 | ||
| master | #159361 | #59467 |
[FIX] website: fix cache for navbar active element
Since this other commit, the style indicating the active nav item
stopped working if the user added record pages to the navbar. This was
due to the cache system not being invalidated when switching from one
record page to another.
This commit fixes the issue by disabling the cache for the navbar if
there is a record page in the menu.
Other potential solutions were considered but ultimately rejected:
1. Using the record as a t-cache key. However, this would mean that if
you have 60,000 visible forum posts, you would end up with 60,000
different caches.
2. Activate the correct element using JavaScript. This would lead to a
duplicate logic in the JavaScript and the Python code, and it would
introduces a slight lag to add the active class on the correct nav item
(due to the time it takes to load and execute the JavaScript).
The chosen solution is the best compromise, as it maintains the cache
for most cases (website menu without records page links in it), nothing
change with this commit. For problematic cases (record pages in the
website menu), this commit disables the cache, which is a reasonable
trade-off.
Steps to reproduce the bug fixed by this commit:
- Edit a website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This commit fixes the issue (a update of the website module is needed)
and adds a test to prevent regressions.
Notes:
- To see the issue locally, remove the --dev xml or --dev all arguments.
- The same issue was occurring with other record pages (blog posts, ..).