Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] keeps the snippet cache alive through different
instance of the website snippet menu.
This allows for the user to switch pages, even apps, while
keeping the snippets in cache, decreasing the startup time of the
snippet menu.
However, the cache is not invalidated when switching website or
installing a new theme.
This commit adds a `invalidateSnippetCache` property to the
websiteService. If this property is set to `true`, the cache will be
invalidated next time the menus loads its snippet.
This property is currently set to `true` when changing website and
switching theme.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
X-original-commit: bb503962a36f3798c50049f2844e7b288b632955
Part-of: odoo/odoo#102799
If an user modifies a theme value through the "Theme" tab of the website
builder, a custo of the related SCSS file is made. To make a SCSS custo,
the related python methods need to know for which bundle the custo is
made. This is to ensure that if a file appears in multiple bundles, the
custo targets the right one (amongst other things). For those automatic
SCSS custo made via the website builder, the given bundle does not
matter as those are custo made in variables SCSS files, which appear in
all bundles, more precisely in a sub-bundle included in all bundles. The
code should be more robust to leverage that fact.
When the "assets_frontend" received all "assets_common" files in order
to only use one unique bundle for main frontend pages with [1], it was
though smart to leave that given bundle to "assets_common" although
"assets_common" is not used on the frontend anymore as it would allow
to not care about migration of those automatically edit SCSS files and
it was also "not wrong" as you effectively cannot edit those files
without impacting all bundles.
It was although very wrong as editing those variables files via the SCSS
editor automatically considers them as part of "assets_frontend" and not
"assets_common". So editing them via the SCSS editor would create/update
the files relying on the fact the related bundle is "assets_frontend"
but the website builder would create/update them relying on the fact the
related bundle is "assets_common". This would lead to creating two
ir.asset records trying to replace the same file in the sub-bundle which
is used by both those assets... and thus to make the database crash.
The work done at [1] actually forgot about other things related to all
this. Those will of course be fixed but they are less urgent. This
commit here just fixes the SCSS edition issue described above for now.
[1]: https://github.com/odoo/odoo/commit/08dcbc8f1def06476d025b110049ee596e906816
task-2994071
closesodoo/odoo#101312
X-original-commit: 15e503a841d757e622c8ef2070043b766b28bfde
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1], as part of the new translation system made with [2], saving
multiple elements in a website page was only saving the first one. E.g.
- Enter edit mode of your homepage
- Add something in the main area of the page
- Add something in the footer
- Save
=> Only the main area is saved, not the footer.
This was actually the same in translate mode... only translation of the
first edited area could be saved.
At least, with the bug fixed version of [1] comes the small advantage
of not saving multiple times the same field (except for view parts).
E.g.: an event's dates are displayed multiple times in different formats
-> in 15.0, 3 RPC were made by date changed, now only one is made.
[1]: https://github.com/odoo/odoo/commit/1b473cf0db4d85c2b523ac87fbab533bce5f3e21
[2]: https://github.com/odoo/odoo/commit/4e82c45abdb0b420edead2bd1d0ba9ff4bb4a224closesodoo/odoo#100762
X-original-commit: c834d151afed0ca633ffb6bcba2f45b544689e74
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, only a website.page could be used as a custom
homepage ('custom' meaning other than '/').
But it is a real use case and requirement for our users to be able to
select a controller as homepage.
For instance, an ecommerce would want its homepage to be the shop and
not a regular page from where you then have to navigate to the shop.
Right now, this can (almost) be achieved by doing some technical
advanced operations:
- Move the 'Shop' menu first in the menu navbar of the website
- Delete the specific '/' website.page for the website
- Delete the generic '/' website.page (no website_id)
That way, the system will redirect `/` to `/shop`, which is not ideal as
it should remain `/` in the URL.
That's because, until now, the homepage (`/` controller) serve order
was:
- Serve the website.page set as homepage (`website.homepage_id`),
happens when one did select another page as homepage through the page
properties dialog
- Serve the website.page having `/` as URL (default)
- Serve the first accessible menu if there no `/` page or other page set
as homepage, it acts as a last resort attempt to not serve a 404 and
to try serving relevant content (the first menu of a website is most
likely always better than a 404)
- Serve 404
This commit allows to introduce an URL as homepage, instead of only a
website.page. It can be done through the website settings in the
backend.
There is 2 main points to keep in mind about serving the homepage:
- make sure we don't serve a 404 as the website homepage. This is the
website entry point, serving a 404 is terrible. That's why we have
some fallback mechanism like serving the first menu.
- We need to serve / before fallbacking to the first menu, as a lot of
site just remove the 'Home' first menu since it is a duplicate of the
logo, which also redirect to the homepage. In such cases, it doesn't
mean that the user want his first menu to be the homepage. We
shouldn't rely on such a behavior, it should just be used as a last
resort.
With this commit, the homepage serve order is now:
- If homepage URL is set (empty by default), serve the website.page
matching it
- If homepage URL is set (empty by default), serve the controller
matching it
- If homepage URL is not set, serve the `/` website.page
- Serve the first accessible menu as last resort. It should be relevant
content, at least better than a 404
- Serve 404
Most DBs will just have a website.page with '/' as URL and keep the
homepage_url setting empty.
task-2969683
closesodoo/odoo#99100
Related: odoo/upgrade#3876
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
* website_sale
That tour keeps failing. A fix attempt was made with [1] but wasn't
enough.
The tour was actually useless as since [2] google analytics dashboard
was not part of the website dashboard anymore (due to google not
allowing GA4 dashboard to be embed).
The tour, which was initially made to ensure that google analytics was
correctly shown even if not yet connected to was then not useful
anymore.
The opportunity is also taken to rename the misleading ID of related
records still mentioning Google.
[1]: https://github.com/odoo/odoo/commit/1a191357e3ac0c4542b2fc7c3a2aee18dc54699d
[2]: https://github.com/odoo/odoo/commit/985e49bdb5e22fa197ba267aa41d7a8ba7e50550
runbot-4498
runbot-4499
runbot-4466
closesodoo/odoo#98090
Related: odoo/upgrade#3774
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] changed the way styles are handled. Now that the edition of
website is done in an iframe, the styles are computed inside the iframe
instead of the top window / global document element.
But for computing the gray colors, a base style defined
by `web_editor/color_palette.scss` is needed. This style is not part of
the frontend assets, so using the iframe to fetch it creates bogus gray,
which results in the feature not working.
Steps to reproduce:
- Go on the website editor
- Select the THEME tab
- At the bottom expand the gray color picker
- Use the settings
- The preview is not updated while sliding.
- The colors are not updated in the page.
This commit fixes the bug by fetching the base style from the top
window (where backend assets are present).
[1]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
task-2687506
Part-of: odoo/odoo#94564
Commit [1] moved the website builder in the backend and in doing so
transferred event handling to the wysiwyg_adapter from the edit button
widget. Unfortunately, during that process, handling of event for
cloned snippets was forgotten.
This commit restores that and adds a test.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#94564
The tour .test_03_backend_dashboard was failing inconsistently with a
"failed to fetch" error (which happens when fetching the frontend
assets, from the iframe).
The test is adapted to start directly in the backend, which seems to
prevent that error from happening.
It is also adapted to [1] which was merged during the investigation of
that error.
[1]: https://github.com/odoo/odoo/commit/985e49bdb5e22fa197ba267aa41d7a8ba7e50550
runbot-4418
runbot-4003
Part-of: odoo/odoo#95890
Before [1] was merged, for this flow:
- Drop a snippet in the page
- Click on some paragraph
- Click on a snippet option's widget
=> The text selection was lost on Chrome, but kept on Firefox.
With [1] instantiating the SnippetsMenu on a different document than the
snippets one, it was possible to keep the text selection (the snippets
document selection) when clicking on the snippets options (on the global
document).
Some code was added to preserve the Chrome behaviour and lose the text
selection. This code is reverted to keep the Firefox behaviour.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#96401
Just a nice to have. It will prevent those errors to be replicated when
copy pasted and will help reading the files in the IDE.
closesodoo/odoo#97282
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since this commit [1], when you select the Header position option and
set it to "Over The Content", the change is not saved if you did not
edit something else in the page too.
Indeed, now that the "save" works correctly (and that it no longer saves
the page every time). It does not detect the change made by this option
which is to add a class on the '#wrapwrap' element. (The editor looks
for changes inside the wrapwrap but not on it).
This commit checks if any page option is dirty on save on top of
checking if the content of the page has been modified.
Additionally, this commit fixes a bug that would occur on Firefox based
browsers where the hidden input used to display the status of these
options would be auto-completed by the browser in some conditions.
(https://bugzilla.mozilla.org/show_bug.cgi?id=520561).
This could result in an incorrect state being displayed.
To reproduce:
- Change the option, click on cancel, start the editor
- the incorrect state is displayed
A test is also added by this commit to verify that all the page options
works correctly.
[1]: https://github.com/odoo/odoo/commit/bab673488e185ddd7792aedecc3870663290fed3
task-2871426
X-original-commit: ea7a69b344d970cc2b31555f4cd8fd7c5e2fc6d2
Part-of: odoo/odoo#94949
Before this commit, the tours default_shape_gets_palette_colors and
edit_link_popover were not using the tour utils function
registerEditionTour, that starts a tour on the iframe, in edit mode,
with a timeout on the first step.
Because this timeout was not there, loading the iframe and the snippets
menu could take longer than the default timeout and the test would fail
inconsistently.
task-2687506
closesodoo/odoo#96164
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Introduced with [1] the goal of this tour was to check some lazy loading
stuff regarding the edit mode.
It was then "wrongly" adapted with [2] where the tour actually still
started in the frontend and then clicked on a the new UI button (top
left floating icon of the frontend > backend task) to indirectly enter
edit mode.
While it was working, that's not what the test was aiming to test. The
test should remain as it was, testing the edit mode. While the edit btn
is now in the backend and not the frontend, the tour should just start
there.
Note that this commit is required as the behavior the tour was now
relying on is removed by the previous commit: the Edit button is not
entering edit mode anymore.
Instead of adding a new step to click on the Edit btn, let's just start
the tour as before on the step where you can click on Edit.
It will make the test less dependent of other behavior. This is
especially true since that frontend "Edit" button will most likely
change again or be removed (and introduced back?). We don't want the
tour to rely on this.
If those new UI button need to be tested, it should be in another test.
[1]: https://github.com/odoo/odoo/commit/6f4c60fe1bb6e460ec6da00c59a9825271893729
[2]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35closesodoo/odoo#95002
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
This is an attempt at fixing a runbot "race" condition.
A first attempt was done in [1] but the selector introduced to make
sure the page was reloaded after the assets were changed was wrong.
This commit fixes that selector.
During the investigation of the problem, it was also discovered that the
SCSS change could take quite a long time on a busy server becasue it
triggers the SCSS compilation each time.
To reproduce that problem locally, run the `stress` command while
executing the `test_html_editor_scss` test.
E.g.:
```sh
$ stress --cpu 32 --timeout 120
```
The error that shows up in that case is misleading because it makes it
look like the confirmation popup was not clicked on.
What is actually happening is the following:
- the Reset button is clicked on
=> the confirmation popup is shown
- the confirmation is clicked
=> the popup is closed and the RPC call is made
- the RPC does not respond within the tour step's timeout
=> the last step is not shown as succesful and the screenshot shows the
non-reset state since the server response did not arrive yet
To be safe on busy servers this commit also increases the timeouts
related to steps that follow updates of SCSS files so that they can be
recompiled on time.
[1]: https://github.com/odoo/odoo/commit/b35f127c86c1d271a76dae7186a96190e8558c73
runbot-3744
closesodoo/odoo#91725
X-original-commit: e04c4f06086ff4287ef4acfc65d5b3d957396ae7
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Current behavior:
When an admin user modified a file with the HTML/CSS/JS editor in a
website, users that had "editor and designer" right couldn't access
the HTML/CSS/JS editor anymore.
Steps to reproduce:
- Have user 1 (U1) admin
- Have user 2 (U2) with website access set to "Editor and Designer"
- U1 modify the css user_custom_rules.scss with the HTML/CSS Editor
- U2 can't open the editor of that website because he is not in the
setting groups or the one that created it
opw-2733109
X-original-commit: d20468c3463927a54c34688769a22b3949c5c465
Part-of: odoo/odoo#89211
Co-authored-by: roen-odoo <roen@odoo.com>
Before this commit, this bug was present in edit mode:
- Go into edit mode on an empty page.
- Click on the THEME tab on the right.
- Click on the empty "DRAG BUILDING BLOCKS HERE" area.
- Click on the THEME tab again.
- The content of THEME is empty.
It was because since this commit [1], clicking on an 'oeStructure'
activate the Blocks tab but without updating the options in the tabs.
Another similar bug was present when clicking the style tab and then
clicking on the theme tab.
About the first bug, actually a call of '_updateRightPanelContent' is
already done in '_activateSnippet()' (and the Blocks tab is activate by
default) so we only have to use '_activateSnippet(false)' to activate
the Blocks tab. This commit also remove '_updateRightPanelContent' from
the click event of the Blocks tab where it was not necessary.
For the second bug, we can't do the same fix, because it's not possible
to activate the options tab with only '_activateSnippet(false)' so we
had to combine the two functions.
[1]: https://github.com/odoo/odoo/commit/fbe048c202ff7878984adf26bef0651a45851f0a
task-2794266
closesodoo/odoo#88537
X-original-commit: 52d32e26c34bef10823582ef5c1f840492b73d7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Those steps were removed with [1] to avoid a indeterminist timeout, but by
doing so that part of the feature was not tested anymore.
Sadly, it was broken by [2] without being noticed for a long period of time.
The error was discovered by fixing multiple lang issues in the website
configurator in master.
Note that by creating a new lang instead of using an existing one will avoid
the timout error that lead to the removal of those steps with [1]. Indeed, as
no .po files will be found for that lang, it won't spend time on processing
those files.
[1]: https://github.com/odoo/odoo/commit/a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
[2]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2aclosesodoo/odoo#83420
X-original-commit: 0b43f52116fd9a58fb0a123db576d822fd541043
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
There was an issue when saving the LinkDialog with invalid data.
The _DialogLinkWidget.save methods return values were not consistent.
Also, tests are added for the regular menus edition.
The existing mega menu edition test was not played from the python test
suite.
task-2513588
X-original-commit: 725cad3478e5ab12ad7f0cf5166a2b968a1373da
Part-of: odoo/odoo#81351
Co-authored-by: Arthur Detroux (ard) <ard@odoo.com>
Before this commit, there was an issue with the edition of links that
were already in the page, via the link tools.
1/ In edit mode, drag and drop the s_image_text snippet and save,
2/ Click on edit, click on the "learn more" button,
3/ From the link tools, change the style to secondary,
4/ Click on save again, the button is still styled with as primary.
[1] added a history step to the link creation via the link tools. As the
editor observer is set to unactive at the start of the link tools, the
changes made to the link with the link tools were not processed by the
EditPageMenu observer, and the block was not set as .o_dirty (the
changes were therefore not saved).
This bug was hidden by our use of bootstrap popovers. The
aria-describedby attribute, managed by bootstrap when showing/hiding a
popover, would be recorded as a change from the EditPageMenu observer,
which would set the view as dirty.
Also, changing any other element of the page would set the page as dirty
and hide the bug.
It only became visible when [2] changed the popover initialization from
'focus' to 'manual'. With that, the aria-describedby attribute was
modified inbetween the LinkTools.start and LinkTools.destroy (and was
therefore not recorded at the EditPageMenu level).
To record correctly the changes made from the link tools to the link, we
activate the editor observer when applying the changes to the DOM.
This commit also introduces some tests for the link tools.
The listener on customizable links from the wysiwyg was changed from
mousedown to click for simpler tests.
task-2680461
[1]: 6db6134f97
[2]: 161c5fc8e742294e8d85c889b4bf8d3d8cd484f5
closesodoo/odoo#80763
X-original-commit: c29fe9fa8fc8ff4a5e6f042607ef9b3070d1d339
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A bug currently makes the carousel snippet collapse/disappear when its
active contents are removed. This happens because after the removal,
the carousel no longer has an active item.
The solution that was chosen was to not allow the removal of slides
unless using the dedicated option which is there for that. This solution
has the advantage to also allow users to create empty slides (using a
background image for example) by simply removing the columns inside.
Note: Newly created carousels will include the oe_unremovable class on
their slides. As such they will no longer depend on isEmptyAndRemovable
checking them for having a carousel-item class on the parent.
task-2506165
closesodoo/odoo#79892
X-original-commit: 0cf36a227e7b90fb64b1bc8024de813894d10d14
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The flow has been broken multiple times across the years. Let's add a
test in all stable versions.
For the 14.0 forward-port, the test came with a fix which restores the
13.0 flow which we tried to change in 14.0... but only ended up broking
it. Indeed, with [1], the 13.0 was fixed. And, with [2], we tried to
simplify the flow... but the explanation given by the commit is just
wrong: the flow was just broken and the simplification that was to be
done in fact practically never occurs. The more the reason to add a
test, proving how the flow is working. The simplification may be done
someday but not sure it is really worth it.
For the 15.0 forward-port, another fix was needed because of [3] which
introduced a bug which makes the onBlur method be called multiple times
when hiding a whole editor hierarchy.
[1]: https://github.com/odoo/odoo/commit/076992bdf099f3a645c9a1ef6df2cdcccbf1c2b2
[2]: https://github.com/odoo/odoo/commit/5c007305c9998ade32c6677cac5552101c3a96af
[3]: https://github.com/odoo/odoo/commit/806a8db35b5e0e6a461422f5bba7c97180c3ef29closesodoo/odoo#79734
X-original-commit: 0acc5e784b15d9c963660da3781763448503f33e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A bug currently prevents opening the editor from a translated version
of the homepage, for example /nl_BE (it works for other paths though).
Before this commit the url computed by _goToMasterPage was:
/website/lang/default?r=/nl_BE?enable_editor=1&rde=2
which will first redirect to the default language and then again to the
translated version. The bug was introduced by commit
119d9437e0 which chose an url without a
trailing slash as the canonical one for the homepage.
However, the bug can already be reproduced in 13.0 since commit
269aa59411 if the user manually
navigates to /nl_BE instead of /nl_BE/. No flows are redirecting to the
url without trailing slash in our codebase before 14.4, so the problem
is rarely seen.
When clicking on the "Edit in master" button, _goToMasterPage now
correctly removes the language code and redirects to the master
version, solving the problem.
task-2622270
closesodoo/odoo#76837
X-original-commit: 141c15d5dae137df11a73146ff4c991add7a2ff3
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
*: web_editor
Provide the user with an option to hide or display a section tag
depending on the visitor's location (if geoip enabled), language,
utm_medium, utm_source and utm_campaign.
Users can use a M2M widget to select different records. These will be
used to create a CSS selector on save that will hide the section tag
depending on the various options they selected.
This CSS selectors will be applied, as well as various data attributes
when the page loads to hide the targeted tag. All of these operations
are handled client side.
The geoip country had to be added to the session for the feature to work
with countries.
Part of https://github.com/odoo/odoo/pull/67140
task-2381049
closesodoo/odoo#67140
Related: odoo/enterprise#19907
Related: odoo/upgrade#2658
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit, the routing map generated and used would be the one from
the website the request is performed, instead of the one from the `fw` website
ID which will be the one we redirect the user to.
This issue was introduced with the routing map by website, be8fc2296b and is
restricted to a single case: a publisher using the website switcher, and it
won't happen on next page naviguation/refresh as the `fw` website id will be
the same as the current website's ID. Thus there won't be any routing map
mismatch.
Step to reproduce:
- Create a page on website 2, set it as homepage
- Naviguate to website 1 on '/' url
- Naviguate to website 2 on '/' url
This will raise a werkzeug error about `EndPoint not iterable`.
----- Technical analysis ------
This is the current flow:
1. `_dispatch()` is setting `website_routing` to `get_current_website()` -> 2
2. `_dispatch()` is calling `_match()`
3. `_match()` is calling `routing_map()` with key = `website_routing`, which
was set to 2 in step 1.
4. `routing_map()` is calling `_generate_routing_rules()` which generate the
rules based on `website_routing`, which was set to 2 in step 1.
5. `_dispatch()` authenticate the user by calling `_authenticate()`
6. `_dispatch()` is calling `_add_dispatch_parameter()`, where URL param `fw`
is forced in session, so `get_current_website()` now return the correct
`website_id` -> 1
The issue: in order to handle the `fw` URL parameter (step 6.), we need to
check the rights to ensure we can allow the website switch.
To check rights, user need to be authenticated (step 5.), which is done after
generating the routing map (2. & 3. & 4.).
The routing map is generated based on the current website (step 1.)
Step 6 depends of steps 5 which depends of steps 2/3/4 which depend of step 1,
but step 1 should depend of step 6, which is an impossible cycle.
closesodoo/odoo#70397
X-original-commit: 4eb26497a774e934d7e1a6be9f505400fd9e2cdb
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
*: website_form
This commit introduces a simple & light popover/tooltip (as in Google Doc) when
editing a link.
It will be used:
1. (web_editor) On every page links.
2. (website) In the website navbar, when clicking on a menu, it will replace the
popup shown to ask the user what he wants to do (edit the menu or go to the link
or do nothing). That popup was a bit invasive and old-fashioned.
Part of https://github.com/odoo/odoo/pull/64756
task-2439860
closesodoo/odoo#64756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit changes the way assets are declared in Odoo modules.
Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.
Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.
Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.
More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).
Task: 2352566
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
This test at least ensures that a SCSS edition through the editor can
properly be done and indirectly tests that the assets order is correct
(in prevision of a future asset refactoring).
closesodoo/odoo#64770
X-original-commit: fe19b48831df17352ea7dbb0b7fa2497ac2da38f
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal of this commit is to update the default theme
tour (steps, changes on snippets...) as in other themes tours.
The url was changed in "registerThemeHomepageTour" function since
the homepage tours are supposed to start in edit mode.
task-2375011
closesodoo/odoo#63850
X-original-commit: b8b394f3824a1f07d76bed5f277b935f619dacbf
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: barcodes, mail, mass_mailing, note, test_website, web, web_tour,
website, website_blog, website_event, website_form, website_forum,
website_mail_channel, website_mass_mailing, website_profile,
website_sale, website_twitter, doc
New solutions are being investigated in master. For the moment, it seems
better to remove Jabberwock to unlock difficult forward-port between
14.0 and 14.1/master, until we decide what to do once and for all in
a later master. We may un-revert this later but that would be way easier
than reverting Jabberwock in a few months.
This was done as safely as possible by removing any commit related to
Jabberwock, then resolving conflicts, then reforcing commits from 14.0
that were hugely adapted for 14.1/master, then forcing the whole diff
over a rebased 14.1/master. The only possible miss (other than me making
a mistake) would be commits that were not forward-ported to 14.1 thanks
to Jabberwock handling the issue on its own (I know we had such commits
in website, which I manually included in this revert, see below).
For reference:
Commits which were reforced to their 14.0 version:
- https://github.com/odoo/odoo/commit/1a916fc2362c0b006460d94a219366ade1cce058
- https://github.com/odoo/odoo/commit/fd9e58a675bb7ec1bf97cb77b21b3c65369d51fe
- https://github.com/odoo/odoo/commit/bdfddace29b16404c06a7ebfc0cc242463a0e768
- https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
- https://github.com/odoo/odoo/commit/710784da1f02d45cbe898da426ba7e2ac63dc711
- https://github.com/odoo/odoo/commit/597585c9b8b1350bcfd84e8433ea6c82060bcc3d
- https://github.com/odoo/odoo/commit/333a9124608ff655bd9ad5e63044a5cb7ef9c636
Commits that were not forward-ported to 14.1/master and now are:
- https://github.com/odoo/odoo/commit/55ff2d971b672dec5f103215be39101c88856b6c
- https://github.com/odoo/odoo/commit/ebbb3de1e5f363689a5ba1647bb4c26416e42d5b
+ Adapt this forward-port: https://github.com/odoo/odoo/pull/60976 (as
it was simplified for non-stable master version relying to the
Jabberwock implementation and now needed to be adapted to the
summernote implementation).
See `!$el.data('oe-expression') && $el.data('oe-xpath')`
+ Revert https://github.com/odoo/odoo/pull/60477 and reforce original
14.0 fix https://github.com/odoo/odoo/commit/746bf53b4aecfc601f0581a948d7cb7153812c82
Note: this also means that any good refactoring that was done by the
Jabberwock-related commits is lost for now. Once the revert reaches
master, I'll try and restore what we want from those commits. Here
are their references (but obviously they have the opposite conflicts
than those resolved during this revert):
e766842a92b6 [REM] web_editor,website: empty summernote files
08c94c986e09 [REF] web_editor,web: adapt to new jabberwock editor
1546c1b74713 [REF] mass_mailing: adapt to new jabberwock editor
fd0b963c6028 [REF] website: adapt to new jabberwock editor
0113d05c6c94 [ADD] web_editor: add new Jabberwock editor lib
d0c88a396493 [FIX] web_editor: don't change background color out of the website editor
d52d3d67d4e1 [FIX] web_editor : better icon in text style dropdown
61cb2f0d21da [FIX] web_editor: should not ask if want to leave the page twice
c42012b863b5 [FIX] web_editor: trigger a resize when use the mobile preview
d934d05d6e39 [FIX] web_editor: need to build the snippet before commit it into vDom
495bea924745 [FIX] web_editor: remove box shadow on the #wrap container
bffb5612e689 [ADD] field_html: add resizer in most field_html
f3c94e40cccf [IMP] web_editor: update Jabberwock library to commit 41e4063
cc87dea3ef32 [FIX] web_editor: update header change position to work with JW
5d9b25f66704 [FIX] web_editor: do not insert chars around step icon on click
70d3f0e4630c [IMP] web_editor: update Jabberwock library to commit 0bd94881
a57f13891f82 [FIX] web_editor: open media modal in appropriate tab on dblclick media
5b7537397e08 [IMP] web_editor: update Jabberwock library to commit a7ba7c34
a8d7ec235eeb [FIX] web_editor: adapt iframe Qunit test to new editor
5f794eac7209 [FIX] mass_mailing: hide all panels on show themes
551d45641d19 [IMP] website: remove unused reference
10580e1c102f [IMP] wesbite: add comment in tour
c17049f6b764 [FIX] web_editor: Fix description toggle in pricelist snippet
18a428e854b1 [IMP] web_editor: update Jabberwock library to commit 43a10003
58a161c645a5 [REF] web_editor, website: use editor helper setClass
62dd0bd3bc66 [FIX] web_editor: properly deactivate snippets and reactivate the last
99eebcaa34cb [FIX] web_editor: disable snippet in preview mode on mouse leave options
a84216932958 [FIX] web_editor: fix the image gallery snippet
f8dd4ea3e7d5 [FIX] web_editor: fix shadow selector for Safari
e50a4f3a16de [IMP] web_editor: update Jabberwock library to commit de13ed7e
4a2718f7a5ba [FIX] web_editor: ensure dom is properly cleaned at end of save test
03684c004a4e [FIX] website: ensure reset of bg-image on add bg-video
d63397159708 [FIX] web_editor: fix image remove from images wall
82fa5142f1a5 [IMP] note: restyle note without sheet or resizer
8b9f1ce603d5 [FIX] web_editor: properly mock createWysiwygIntance (sic) in tests
fc2183b66305 [FIX] web_editor: image overlay did not update with changes
cd0d2f5791cd [FIX] web_editor: add color preview to color picker
28a168172454 [FIX] web_editor: restore removal of spinner
67c90dd3b946 [FIX] website_forum: properly initialize editor
920dfe2a430a [FIX] website_forum: better css in the JW toolbar
43f33fd651af [IMP] web_editor: update Jabberwock library to commit 6853b60
71246c92f8de [FIX] Web_editor: table options button should be inside the toolbar
12b9e5916692 [FIX] web_editor: properly update the image options on replace image
e889cf8583da [FIX] website, website_sale: properly save filter id of dynamic snippets
e0fd11e36e45 [IMP] web_editor: update Jabberwock library to commit 4b2c903b
8f2b7ba35614 [FIX] web_editor: properly stop snippet option changed event propagation
a30c2c4105c7 [FIX] website: fix megamenu snippet editor behavior
312091cf822b [FIX] web_editor: fix overlay that is not reappearing
9f1d03dda613 [FIX] web_editor: table picker not fully displayed
814ddada6124 [IMP] web_editor: remove message before leaving page if editor is destro
4f38e26af7da [FIX] web: allow saving copyright footer
01e947b6123b [FIX] web_editor: only save translations that changed
103676072c50 [FIX] web_editor: prevent traceback on open crop dialog
5844ff66d4a0 [FIX] web_editor: apply image crop in jw on save dialog
1b435652e4a0 [FIX] website_forum: ensure media modal opens on click button
4f4a6ca0b8ac [FIX] web_editor: ensure valid default html value
51e22026ac7b [IMP] web_editor: update Jabberwock library to commit ab1184f8
2413fa19be0e [FIX] web_editor: Qunit test properly wait for editor stop
aa89e1ea3e97 [FIX] web_editor: properly save view blocks with an id
e2e90b53992e [FIX] web_editor: ensure language selector is non editable
0efd72089d5c [IMP] web_editor: clean useless lines
f54dfc7631f9 [IMP] web_editor: remove useless comment
3995ab1b84f2 [IMP] web_editor: update Jabberwock library to commit b8d73691
0834b1e5740a [IMP] web_editor: withDomMutations
f1459fb7b45c [FIX] web_editor: fix non-deterministic error in QUnit wysiwyg tests
6e8acc6c8cc7 [IMP] web_editor: update Jabberwock library to commit 3bbb175c
18a0c95d51cb [FIX] website, web_editor: #wrapwrap in body
4686a92e742c [FIX] website_form: allow edition of success message
78cc4da075cc [FIX] web_editor: allow edition of branded nodes only
bcffa7353448 [FIX] web: dialog should not use field value footer items
67ff56e14746 [FIX] web_editor,website_mass_mailing: display the popup preview
3cb9bea50c20 [IMP] web_editor: update Jabberwock library to commit a20492ea
518f03e6f1c9 [FIX] web_editor: use withIntangibles to find ZoneNode
d0ad6a568f49 [FIX] website: move sidebar out of theme
d690f5da13ea [FIX] website: properly save popup id
43b3433df3e6 [FIX] web_editor: fix non-deterministic error in QUnit wysiwyg tests
4ee8f4dedc30 [FIX] web_editor: prevent deadlock when removing child snippet of popup
850be198ef6d [FIX] web_editor: prevent traceback on reposition background image
4c3eaba41f5d [FIX] mass_mailing: adapt tour to the new editor design.
496d3ea272ed [FIX] web_editor: properly position sidebar scrollbar
5be4de703074 [FIX] web_editor: Show the toolbar when select the text in forum edition
closesodoo/odoo#63768
Related: odoo/enterprise#15458
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now that we will write tour by theme, this part is useless.
We just keep the old steps that will be not covered by future theme tour.
task-2172208
X-original-commit: 02e1b1f659d5f588cc4e52f48217f8e2c7771ad4
Add the width option for each slides in the carousel snippet.
Remove share links from the third slide of the carousel.
Part of https://github.com/odoo/odoo/pull/45096
task-2162952
* = mass_mailing, web_editor, website_crm, website_event, website_form,
website_forum, website_hr_recruitment, website_mail_channel,
website_mass_mailing, website_sale, website_slides
When an outdated snippet's option are activated we display a warning
in the left panel that inform the user about the potential
malfunctions.
To do so the snippet's template key is added to the snippet as
data-snippet.
If a snippet is "t-call" inside another snippet, it will need to use
t-snippet-call instead of t-call to have the key on himself.
Those unique keys are used on snippet selection to retrieve the
snippet's version in the left panel and compare it with the currently
selected snippet's version. Versions are describe with data-vcss,
data-vjs and data-vxml. If a snippet's key is not in the left panel we
consider that snippet as outdated.
Added some tests to ensure that t-snippet and t-snippet-call really have
their template key as data-snippet
Adapted the views to the data-snippet changes adding
data-snippet="tmpl_key".
Part of: https://github.com/odoo/odoo/pull/44569
task-2189669
closesodoo/odoo#50254
X-original-commit: 28a6cd49b6e87b75c2e70771e241c41778bf9e87
Related: odoo/enterprise#10236
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If for some reason someone wanted to develop a textarea using the
editor which is supposed to work as a public user (like we are trying
to do on Odoo.com), it was not possible. The code was "designed" to
allow it but there was one problem: the lazy loading of the editor
assets required a `render_template` call to the server... which cannot
be done from a public user.
This commit solves the issues by allowing the lazy loading of assets
to use a custom route if required. That route is then used by the editor
"root". That route performs the render_template as a superuser provided
that the view's xmlid is whitelisted.
Note: there was another unauthorized call for public user: the
colorpicker. This was solved by disabling the colorpicker template rpc
for public user, they will still get the default summernote one.
Part of https://github.com/odoo/odoo/pull/48981closesodoo/odoo#48981closesodoo/odoo#49398
X-original-commit: e84a0bfdc99c21406861b88c02b11c925d92f927
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
During the rte_translator tour, the step that adds and loads the fr_BE
language lasts a very long time. This time depends of the loading of
`.po` files.
For un unknown reason the temporary postgresql table created in
ir_translation.py may takes more times than usual. This, repeated for
each `.po' files, in enterprise, leads to a timeout of this step (more
than 60 sec).
As this seems linked to postgresql (or another external factor) and as
the purpose of this test is not to test the translation loading, the
present fix is to simply activate `fr_BE` translation for the website on
the server side before starting the tour.
The loading of translation is tested in test_translation_import module.
closesodoo/odoo#48621
X-original-commit: a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
5ac269d722f fixed 7e2b0ebe799 that prevented the website menu to actually be
visible, since the JS in charge of displaying the menu was 'crashing'.
A test was missing to avoid that issue to appear ever again, since it is quite
a critical problem.
Note that it might look strange that breaking such a mechanism does not make
the runbot red, but since the menus are actually considered visible, the tests
are able to 'see' it in DOM and click on it.
They are actually hidden through an opacity 0 & height 0 while the JS process
them.
task-2093679
closesodoo/odoo#47138
X-original-commit: 0dc00a252dfe7fee658579a60dc7b1b1ca71a661
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This test goes to the public homepage and directly logs a 'test
succesful'. It's useless as many other tests use the public homepage and
therefore, those tests will crash if the homepage is unavailable.
Moreover, it happens to trigger random failures due to the fact that
some RPC may occur between the cookies cleaning and the termination of
the browser.
Typically a "GET /web/webclient/locale/en_US" can be triggered right
after the clearing of the browser cookies, cache ...
closesodoo/odoo#46004
X-original-commit: 3aded126e78b18f8bb753f1b57b827667ca99d18
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
*: web
Before this commit, when a widget declared assets to lazy load through
the assetLibs key, the asset was loaded through a context-less call to
the server through the base `rpc` function. This caused problems in
website: the website ID was not given to the called route and the loaded
assets were then stripped of their specific-website parts.
This commit solves the problem by allowing the `loadLibs` and
`loadAsset` functions to receive an extra argument: an extra `context`
to use for the actual call to the server. The method is now available
in the ajax service, so that website can add its custom context
automatically, the same way it does it for normal `_rpc` calls.
Part of https://github.com/odoo/odoo/pull/44596closesodoo/odoo#44596
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When loading a page on an existing starting database, registry is not
fully loaded causing potential error when trying to access model
existing in database (views, menitem, ...) since model added in last
loaded module does not exist in registry.
Thus, executing browser js test may lead to errors when executed during
an update on a database with other modules installed.
HTTPCase should be executed post_install to ensure that registry is
fully loaded to avoid this problem.
Since HTTPCase are slower than other test, it is also a good idea to
execute them at the end, in order to prioritize fast fail.
With this commit, a warning is isued if such a test class is tagged to
run at install time.
While at it, remove deprecated at_install and post_install helpers and
remove the deprecated phantom_js alias.
closesodoo/odoo#39462
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Arthur Detroux (ard)