Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
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>
*: auth_password_policy, bus, calendar, event, mass_mailing, stock,
survey, web_editor, web_tour, website, website_event, website_forum,
website_mass_mailing, website_sale
This commit is a first step towards a potential deletion of the
assets_common bundle, although that step would need more work, specs and
discussions as some layouts kinda only use the assets_common bundle
(some take the full assets_common but parts of the assets_backend one
for example).
The main goal of this commit is to have the assets_frontend bundle
directly include the "common" files we need. As a first step, this
commit only blindly duplicates them all into assets_frontend (without
removing the potentially useless ones). The goal is to have those
advantages:
- Reaching a frontend page only calls two main JS files (one normal and
one lazy-loaded) instead of 4 (two normals and two lazy-loaded). This
may help reach a better google page speed (which is becoming more and
more strict).
- The frontend CSS is built as one: the common SCSS which was using
bootstrap variables, or even Odoo-based SCSS added by mistake in
common instead of both backend and frontend is now computed with the
right bootstrap customizations. E.g. the tempusdominus datetimepickers
use bootstrap grays... after this PR, they use the right grays as
customized by the user on the website.
It was also chosen to not have a common "sub-asset" which is included in
assets_frontend. Making assets_frontend completely independent makes
sense (as it probably will for other "main" asset bundles): we can focus
on adding the files each layout needs without the need of worrying if it
impacts unrelated layouts. Sub-assets (when not strictly necessary) is
also a source of errors: extending the "main" bundle instead of the
right sub-asset it may use (like it was the case with the sub-assets of
assets_common: _assets_common_scripts and _assets_common_styles as
explained in the previous commit). So this is indeed a small drawback of
not factorizing the code for the inclusion of "common" files in bundles
but it seems more explicit and easier to maintain that way. Note that
adding "common" file is not the most common usecase anyway, apps
generally only need files in backend or frontend.
The __manifest__ declaration will also likely evolve in more and more
uses of wildcards to match entire directories. In the future, adding
"common" web-app files in both backend, frontend and other "main"
bundles could just be about one line duplicated into each bundle.
closesodoo/odoo#100314
Related: odoo/enterprise#31394
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Emptying the domain should be setting it to False, not empty string,
which is saved in DB as such.
This was not problematic at all before but since [1] the domain must be
unique. As we removed the "multi website by domain" feature, we then
were able to add that constraint.
But since then, having two website with domain == '' would raise the
constraint error, while null values (False in python) would not.
[1]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d
runbot-5041
closesodoo/odoo#100430
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Website: the context install_filename='dummy' is used to prevent
arch_updated from becoming True while updating translations of
ir_ui_view.arch_db (if arch_update becomes True, test_inherit_specific
fails)
Fuzzy search for jsonb translated fields has been adapted in the case of
website. It may require some refactoring later.
Short summary:
- People can now use the snippets option to show/hide based on country
- We never use / test / maintain this feature, if it still works since
its introduction 4 years ago that's by luck
- It is probably barely used, we never got a single question or issue
about it
-----------
When we introduced the multi-website feature, it came with 2 main use
cases:
1. Multi website by domain -> Every website has its own domain and based
on that we serve the expected website
2. Multi website by geoip -> Multiple website can have the same domain
and based on GEOIP/country we serve the expected website
We never really supported, highlighted or promoted the geoip case.
We actually never use it ourselves when doing tests, and we don't
consider it when doing specs / improvements.
At most, only a very few people know about it in Odoo.
That GEOIP case is probably not useful at all, as displaying a whole new
website based on lang is not easy since nothing can be shared out of the
box -> Every website has its own COW records.
For instance, one could think of having its main website A and another
website B on which he just added 3 products specific to that website B
country.
But such a case won't even work properly, as any adaption on website A
won't be reflected on website B (design, theme etc).
closesodoo/odoo#99938
Related: odoo/upgrade#3892
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
Since [1] the 403 pages displayed when a website page is restricted to a
different group of users is the default one instead of the website one.
After this commit 403 fallback errors are rendered by the default error
rendering.
Steps to reproduce:
- Go to a page. (e.g. "Contact Us")
- Select "Page Properties" in the "Pages" menu.
- Go to the "Publish" tab.
- Define visibility as "Some Users".
- Select a user group. (e.g. "Administration / Access Rights")
- Access to the same page in an incognito window.
=> The displayed 403 error page was the generic one instead of the
website one (with the navigation header...)
[1]: https://github.com/odoo/odoo/commit/eb7eecec976570ae3301c17a04adc9c110d5b14a
task-2963843
closesodoo/odoo#99671
X-original-commit: fc0a0c2ccea83b3a9a5df0e300eac1fe7eb7a2a2
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@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>
Since the bootstrap 5 merge at [1], when you click on an image in the
Image Wall block, the modal no longer opens. This commit restores that
and adds a test to make sure this problem does not happen again.
Steps to reproduce:
- Drop the "Image wall" block in a page
- Save
- Click on an image
-> The modal does not open
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
task-2937538
closesodoo/odoo#97053
Signed-off-by: Quentin Smetz (qsm) <qsm@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
This commit gets rid of the iframefallback in test mode. It is not
helpful there and slows down the tests as it involves some HTTP
requests.
Its purpose is only for the end users to have a smoother UX during page
transition. It is irrelevant in tests. Note that it means the tests
wouldn't break if that iframe fallback was to be breaking something in
real use cases.
task-2687506
closesodoo/odoo#96229
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
This test is quite long as it is testing all the website form behaviors
in edit mode.
It is sometime failing due to the tour taking longer than 60 seconds.
runbot-4257
closesodoo/odoo#97336
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
After [1] moved the website edition in the backend, we feel that the
code required to make the additional debug icon in the footer of the
frontend still work is not worth it.
Before this commit, on a website page, it was not working: clicking on
it from the WebsitePreview client action would only remove the debug
mode of the frontend, and the backend would keep it.
The user can now leave the debug mode from the debug menu systray item
and we consider that leaving debug mode as a visitor (from the
frontend) is not a feature worth keeping.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#95499
Related: odoo/upgrade#3721
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Cause:
The test fails because there is some demo data that added additional
website(s) and when trying to retrieve the current website without
domain, it might retrieve the wrong one.
Solution:
Unlink unused website(s).
opw-2899680
closesodoo/odoo#96810
X-original-commit: 45dfbae7301effe0d96163d67218a7854c3bde6f
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
When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.
This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.
Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.
task-2885882
closesodoo/odoo#96248
X-original-commit: 317eea48186c948009399daedf70dd407f6a9ca8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
Since frontend to backend commit [1], links having `enable_editor=1` to
enable edit mode were not working anymore in certain cases.
Case 1 [OK]*:
From frontend, click on `enable_editor=1` link without `/@/` in it.
Case 2 [OK]:
From frontend, click on `enable_editor=1` link with `/@/` in it.
Case 3 [KO]*:
From backend, click on `enable_editor=1` link without `/@/` in it.
Case 4 [KO]:
From backend, click on `enable_editor=1` link with `/@/` in it.
This commit fixes case 4 and adds a test for all cases, while leaving
case 3 commented as it will be fixed later with a larger fix related to
URL change listener.
* Note that we will probably change the behavior for case 1 and 3: if
the version with /@/ + enable_editor=1 enters edit mode properly in
both frontend and backend contexts (case 2 and 4), it's probably not
worth having code to support case 1 and 3.
The issue for case 4 was that it was trying to load the whole Odoo app
inside of website preview iframe instead of making the parent window
load that URL.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#96054
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Install multiple langages, each time translating the website. In a
private browsing session access /contactus, show the page source, the
multiple alternate URL (`<link rel="alternative">` in the `<head>`) are
all pointing the canonical URL instead of the alternative.
closesodoo/odoo#95683
X-original-commit: 3d4b4d3dcff864613a9e7038137e21674425ed08
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
*: test_website
Issue: The url is cached and no longer depends on the url. This part
should not be cached.
closesodoo/odoo#95222
X-original-commit: 4b255ed129b0e458d3cf7f432d076913b14d5450
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages. If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.
In module purchase_stock, add depends on report.stock.quantity. This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.
closesodoo/odoo#66938
Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@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>
The website architecture has been refactored for the internal users and
admins with [1].
Now, they can access the website in the backend inside the website app.
Long story short, the website will be displayed in an iframe in a client
action. The URL of the browser will be tweaked to reflect the iframe one
instead of the real one (which is something like /web#action=..).
It had a few drawbacks:
- On page refresh (F5 or browser button), the user would land on the
frontend version of the website instead of remaining in the backend.
- When the user edited the URL (Like removing `/shop` and typing `/jobs`
instead, he would land on the frontend version too.
- Impossible to directly go to the backend version of the website.
Those are improved with this commit by using a slightly different URL
when we are in the backend. A `/@/` will prefix the iframe URL.
If logged in, the user will land on the backend. If not, it will simply
redirect to the frontend version of the website.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#94580
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
As we have more and more standalone tests related to the website app, it
has been decided with the runbot team to introduce a unique tag to
easily identify those tests.
The goal is to make the runbot build config easier to manage, without
the need to add the new tag name in the command.
Instead, this build will be fired by finding and testing all the
`website_standalone` tests.
The other tags are kept to easily identify what are the test related to.
Command without this (which need to be edited for each new tag):
```
--standalone cow_views,cow_views_inherit,theme_views,theme_upgrade
```
Now:
```
--standalone website_standalone
```
X-original-commit: a28c181b7f934bed06adccd2678d6c6db47422fe
Part-of: odoo/odoo#93109
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closesodoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
Rationnals
----------
Web servers can serve some resources (e.g. static files) right away
without any interaction with the web application. The network model of
most web servers makes them capable of handling thousands of
simultaneous requests when it comes to intensive IO operations such as
streaming data from a file. The network model of Odoo is different: it
is capable of a lot of processing power but can only serve a handful of
requests at a time, i.e. Odoo (with some help from postgres) is
optimized for CPU operations, not IO.
Some users don't configure their web server, they use a basic
configuration that relay all requests to Odoo. The result is that many
Odoo HTTP Workers can be busy streaming static files instead of
processing other requests. This can lead to a worker starvation, i.e.
all workers are busy streaming files and cannot process new requests.
X-Sendfile
----------
In this work, we add the support for the [X-Sendfile] header family,
they are multiples http headers that can be used by the web application
to communicate with the web server in order to delegate the delivery of
files stored on the file system. Odoo still receives the request but it
does no more stream the file content from within its HTTP worker,
instead it skips the response body altogether and sets the `X-Sendfile`
special header with the path of the file on the filesystem. The web
server intercepts that special header, open the file and stream it.
Using those headers, we can use the best of both the web application and
the web server. The web application is still responsible to locate the
resource and verify the access rights, the web server is still
responsible of streaming the content.
Using X-Sendfile is opt-in via the `--x-sendfile` CLI flag. We set both
`X-Sendfile` (apache) and `X-Accel-Redirect` (nginx). If you are using
apache, make sure `mod_xsendfile` is enabled. If you are using NGINX
you have to add the following location block:
location /web/filestore { # custom path, hardcoded within Odoo
# Prevent access from the outside world, i.e. makes this
# route only accessible via X-Accel. MANDATORY!!!
internal;
# Give access to the filestore using this server's
# permissions. Odoo is in charge of verifying the access
# rights.
alias /path/to/odoo/data-dir/filestore;
}
The Odoo [deployment documentation] has been updated accordingly.
[X-Sendfile]: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
[deployment documentation]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments
Changes to the API
------------------
To benefit most from X-Sendfile, all APIs related to streaming content
over HTTP has to be adapted. They are: (1) `request._serve_static`,
(2) `ir.http._serve_fallback`, (3) `/web/content` and (4) `/web/image`.
Each used it own way to deliver content: (1) `_serve_static` was using
`send_file` (flask's send_file that as been vendored with odoo 10
years ago and not maintenained since then), (2) _serve_fallback was
handcrafting a `werkzeug.wrappers.Response`, (3) /web/content-image were
using the "binary server" `ir.http.binary_content` API.
I has been decided to remove all 3 APIs and to merge the code inside of
the new `http.Stream` object and the `ir.binary` helper model.
A Stream wraps what is going to be sent to the browser, it can be a path
to a file on the locale filesystem, a blob of raw data or an URL to an
external resource. The Stream also holds various metadata that are
mainly used for caching. The preferred way to create a Stream is via one
of its three factories so that all the metadata are set. The factories
are: `from_path`, `from_attachment` and `from_binary_field`. A stream
instance exposes a single method `get_response()` used to create the
corresponding HTTP response object out of the stream.
Inside of `ir.http` were a few methods that were not related to the http
routing and formed what was called the "binary server". All those
methods have been removed and the feature have been refactored inside of
the new `ir.binary` model. The removed methods are:
- `_xmlid_to_obj`
- `_get_record_and_check`
- `_binary_ir_attachment_redirect_content`
- `_binary_record_content`
- `_binary_set_headers`
- `binary_content`
- `_response_by_status`
- `_get_content_common`
- `_content_image`
- `_content_image_get_response`
- `_placeholder_image_get_response`
The new `ir.binary` abstract model exposes the following utilities:
**`_find_record`**
Find an attachment or a record with a binary-field out of an xmlid or
out of a pair record-model/record-id. Check the access rights and the
access token.
**`_get_stream_from`**
Create a Stream from an attachment or a record with a binary-field.
**`_get_image_stream_from`**
Same as `_get_stream_from` but adapted for images. It sets a sensible
ETag on the stream and has image resizing support.
**`_placeholder`**
Get the image placeholder blob.
Testing
-------
It is possible to test the web server configuration using the
`test_http` module. Install the module then run the unittest using the
`webserver` test-tag. By default it attempts to connect to a web-server
running on `http://localhost:80`, you can change this URL by setting the
`WEB_SERVER_URL` environment variable.
odoo-bin -i test_http --stop-after-init
WEB_SERVER_URL='http://localhost:80' odoo-bin --test-tags webserver --stop-after-init
closesodoo/odoo#88134
Task: 2801675
Related: odoo/documentation#2083
Related: odoo/enterprise#26191
Signed-off-by: Julien Castiaux <juc@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>
Configuring the email_to field on the contact us page was not working
anymore. The email was always sent to the company email whatever the
user chooses in edit mode. This was due to [1] which gave the priority
to the data-for and prefill system over default values. While this makes
sense in general (e.g. if the URL on the contact us page contains
?name=John, then the form is prefill with "John" whatever the value that
is set as default), it does not make sense for the email_to field which
is always prefilled with the company email.
The data-for/prefill system priority probably has to be reviewed in the
future. Meanwhile, this commit will make the email_to field as an
exception for this system and only use the data-for value if nothing
has been configured by the user.
This commit also handles another case. Indeed "if nothing has been
configured by the users" is currently kinda broken as just clicking on
the form and saving will force the value "info@yourcompany.example.com"
as the email_to value... thus making the form use it instead of the
company email. We will make that as an exception of the exception: use
the data-for value (company email) if what was configured by the user is
the dummy default value "info@yourcompany.example.com".
A test for each of those two exceptions has been added (only the first
test breaks before this commit as [1] made the second test pass by
chance).
[1]: https://github.com/odoo/odoo/commit/7b23d3aacd22f87cb0c22ecd0478eba4a17b4bf3
opw-2842211
Original idea for the first exception:
closesodoo/odoo#91407
X-original-commit: a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Ivan Yelizariev <iel@odoo.com>
It may happen than the routing map is cleared while rendering a qweb
view. For example, if an asset bundle is regenerated, the previous one
is unlinked, which causes a cache clearing.
Previously-generated EndPoint objects aren't found any more in the new
routing map, so `request.endpoint` cannot be used any more after a cache
clearing.
This commit adds hash and comparison magic methods on http.EndPoint so
that EndPoint objects created by a previous routing map generation can
still be used after a cache clearing.
Two tests were added: one to test the comparison and hash methods, and
the other to test them in a real-case rendering.
Commit 80a04f7ebed fixed this bug too, but introduced another issue
which caused many OPW, so it was quickly reverted by deb23450f18 along
with its performance improvement 33167b3928c. This commit replaces
80a04f7ebed with another way to fix the issue.
A third test has been added in order to avoid reintroducing this other
issue.
By the way, this commit also removes the EndPoint.arguments attribute,
as commit 17f1992698 removed all usages of this attribute in Odoo 9.0,
but left this initialization here.
OPW-2834546
OPW-2834549
OPW-2834625
X-original-commit: bdc45422f5c715782b147eecda2403386ba7eb4a
Part-of: odoo/odoo#91034
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>
Xavier-Do