Tuesday, April 23, 2024
29 changes
Resolved issues and error corrections
A test in the profiling system was failing randomly due to unexpected data in the test assertions. The fix removes the unreliable final checks from the test, focusing only on the data that matters for validation. This makes the test more stable and prevents false failures.
Original PR description
This test can sometimes fail randomly
```
FAIL: TestProfiling.test_sync_recorder
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder
self.assertEqual(stacks_methods, [
AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']]
First differing element 11:
['__exit__', '_remove']
['__exit__', 'stop']
First list contains 2 additional elements.
First extra element 12:
['__exit__']
[['a'],
['a', 'b'],
['a'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a'],
[],
['__exit__'],
- ['__exit__', '_remove'],
- ['__exit__'],
['__exit__', 'stop']]
```
Since we don't care about the last lines, just remove them from the assertion.A recent theme update in version 17.0 broke the visual appearance of the Odoo mega menu title underlines, making them appear faded or invisible. This fix restores the proper colors to these underlines by adjusting how the styling is applied, ensuring the website navigation menu looks correct again.
Original PR description
Those were broken by the theme update for 17.0, in particular at [1]. Indeed the underline colors were defined using `text-XXX` classes to use the theme colors, relying on the fact that the default color of HR elements used the `currentColor`. Now they use the `currentColor` but very faded... making those underline colors uglier and for one of them, basically invisible. As a stable fix, this updates the XML to make the border use the `currentColor` as before in new mega menus... although they do not work as well in 17.0 as they did in 16.0. This will be reviewed in master to use better colors and a more reliable and beautiful way. [1]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364e
This fix resolves an issue where users navigating through grouped list views would lose their page position when opening a record and returning via breadcrumb. Previously, clicking back would reset to page 1 instead of maintaining the current page offset. Now the page position is correctly preserved when navigating back to the list.
Original PR description
Issue: Have a grouped list view with several page, go to the next page, open a group and click on a record to open it in form view. Click on the breadcrumb to go back to the list: the offset is lost, and we're back in page 1. After this commit, the offset is correctly kept. opw~3851390 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162904 Forward-Port-Of: odoo/odoo#162844
The color picker tool was appearing in the wrong position when editing mass mailing templates. This fix adjusts how the positioning library handles elements within the editor's iframe, ensuring the color picker displays correctly when users try to change text colors in their campaigns.
Original PR description
Issue: ====== Colorpicker doesn't appear in mass mailing Steps to reproduce the issue: ============================= - Create a new mass mailing with a some template other than plain text - Try to…
Issue: ====== Colorpicker doesn't appear in mass mailing Steps to reproduce the issue: ============================= - Create a new mass mailing with a some template other than plain text - Try to change the color of some text - The position of the colorpicker is wrong. Origin of the issue: ==================== When wysiwyg was converted to owl in [1], an effort was made to speed up the loading of the iframe in mass_mailing. One of the changes that were done in that regard was to remove assets from the iframe to make it load faster. This required to create the sidebar (SnippetsMenu) outside of the iframe since the iframe did not have the required files anymore, and insert it back in the iframe afterwards, since it was designed to work inside the iframe. This change actually had an impact on the positioning of the colorpicker, and basically anything that relied on popper.js for positioning, because since popper.js was outside of the iframe then the checks it did based on `instanceof HTMLElement` were returning false for every node inside the iframe. At the time of [1] this went unnoticed because the chatter was not yet in the side of the screen for mass_mailing, so the wrong positioning of the colorpicker was actually only slightly off the right position, thus being hard to catch while not specifically looking for that particular issue. As soon as the chatter was made to be on the side even in the case of mass_mailing, the wrong colorpicker position became visible but the issue went unnoticed at the time as well, probably because the two changes were completely unrelated. This went live in saas-16.4 and is the case in 17.0 as well. However, the issue does not exist anymore in saas-17.1 due to the refactor of mass_mailing to have the sidebar (SnippetsMenu) working from outside of the iframe instead of inside. Solution: ========= Fixing this issue properly would require huge changes to how the SnippetsMenu is constructed and would most likely require going back to the slow iframe with all the assets inside. That would not be a desirable outcome, especially in a stable version. With that in mind, and considering the issue doesn't exist in saas-17.1, we decided it was a prime example where a local change in the popper.js library was actually the best fix. The library is very unlikely to be updated in a stable version and the change won't reach saas-17.1. [1]: https://github.com/odoo/odoo/commit/76d4f98 co-authored with dmo-odoo task-3614965 Forward-Port-Of: odoo/odoo#160505