This fix allows generating the sitemap (via `website.search_pages`) via
RPC. The changes are necessary as since #99667 the `request` object is
no more available to RPC-executed functions.
See also: the `test_search` test case of `website.tests.test_page`.
closesodoo/odoo#104567
X-original-commit: 8f4e214417cfb1aed7e595b8d6ab71f33a347b29
Signed-off-by: Julien Castiaux <juc@odoo.com>
`is_view_active` relies on the `website` specified in the context.
This commit turns `is_view_active` to a model method, to avoid that its
callers think the `website` on which it is called is the one used.
closesodoo/odoo#103126
X-original-commit: 52d436706bf650bb14f2bc2a398d107ff99f81ea
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Previous commit adapted the URL dependencies screen following the
website frontend > backend merge done at [1] and [2].
It allowed to pass other records than website.page and also added the
multi record capability.
This commit is going a step further, by searching for the URL in all
HTML fields and not only views + pages + menu + blog.
It also let the XML take care of the wording instead of the python.
closesodoo/odoo#103136
X-original-commit: 6ac17b93437868cbefbe13448a6fcbb29953f221
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This is following the website frontend > backend merge done at [1] and
[2].
Before that improvement, the old page manager had a button to delete a
page which was behaving as the one in the page properties dialog: it was
showing the list of (possible) dependencies as a confirm step.
But since [2], that delete button was removed as the action menu of the
list view already has a delete button, which is better as:
- It is hidden and take no space, deleting a page is rare
- It is known by odoo users as all list views have that button
- It handles multi delete
So this commit basically just restore that delete warning step for that
list view delete button, and also make it possible to use that
dependencies warning dialog for multiple pages, not only one.
It also now handles records in a generic way, not only website pages.
It's needed because now, all the main Odoo frontend records are sharing
a list view mixin (see `js_class="PageListController"`).
It also fixes the fact that the text of the collapse were inside a font
awesome class, basically using a weird font.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
X-original-commit: 11db2f6ed81419ac724ff27ac95a4438d670cbd5
Part-of: odoo/odoo#103136
This is basically reverting commit [1] which was done a few years ago
as improvement to [2], but it was a bit overkill IMHO.
Indeed, there is a sort of hack when creating a page with special
extension like "my-page.js" that will actually create a special page
with special arch. The goal is for such pages to be `t-call`ed later.
That's commit [2].
On top of that, when deleting such a special page, we introduced a
mechanism to show the views and pages that would possibly `t-call` the
that page which is requested to be deleted.
That's commit [1].
It basically is mimicking what was already done when you change the URL
of a normal page, we tell the user where that url is actually possibly
used.
But since the recent improvement in Odoo 16 done at [3], the page
manager is now a backend list view. It means that multi delete is now a
thing.
Thus, the page dependencies behaviors (key and url) need to be
refactored to handle multiple given URL/Key and not just one.
We choose to remove the key dependencies part (only used for those
special pages) instead of adapting it:
- That 'hack' is probably almost never used
- It's some code to maintain, eg now we need to refactor it
- We would need some extra code to make it only triggered for website
pages and not all records, unlike the url dependencies screen which
concerns all records
- That's an advanced feature (special pages), if you are using it, you
probably knows how to handle a website and you don't need us to remind
you where this special page's view is used.
[1]: https://github.com/odoo/odoo/commit/a91a3a563338e746d6d23cd57551af30e322e367
[2]: https://github.com/odoo/odoo/commit/727d461e1d2bcec4571665b90b6d1630f671a0a3
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 77f03abc56b147171eeba66bc55df5ee92c8af1a
Part-of: odoo/odoo#103136
*: website_forum, website_hr_recruitment, website_sale
Before this commit, most of the backend redirections to the
WebsitePreview, introduced in [1], were using ir.actions.url with the
get_client_action_url util, which was not optimal.
This commit changes that to use a new get_client_action method, which
returns the ir.actions.client record. It will execute the action
directly, avoid to redirect the router before, and improve performances.
Also, it allows to solve bugs, as:
- The back navigation from the WebsitePreview to the ListViews.
Going through the /web controller would add an entry in the history, and
going back on it would reload the client action.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102991
X-original-commit: 30fb11e479fb7b3db3649e55fcbdb06bfcdb398c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
The /web loading was slow during test when some themes are installed.
This is because without any context and request, the assets are
generated for website 1 before this fix.
With this default website:
_get_active_addons_list returns only addons that are not themes
_get_asset_paths will return less assets
When loading /web, no website is found because the domain is not empty.
This means that the web.assets_backend will have less assets when
generated outside of a request than in a request not matching any
website.
There is normaly no assets for the backend in theme BUT a tour is added
in each theme
('/theme_anelusia/static/src/js/tour.js', 'theme_anelusia', 'website.assets_editor')
('/theme_artists/static/src/js/tour.js', 'theme_artists', 'website.assets_editor')
('/theme_avantgarde/static/src/js/tour.js', 'theme_avantgarde', 'website.assets_editor')
('/theme_aviato/static/src/js/tour.js', 'theme_aviato', 'website.assets_editor')
('/theme_beauty/static/src/js/tour.js', 'theme_beauty', 'website.assets_editor')
('/theme_bewise/static/src/js/tour.js', 'theme_bewise', 'website.assets_editor')
('/theme_bistro/static/src/js/tour.js', 'theme_bistro', 'website.assets_editor')
('/theme_bookstore/static/src/js/tour.js', 'theme_bookstore', 'website.assets_editor')
('/theme_buzzy/static/src/js/tour.js', 'theme_buzzy', 'website.assets_editor')
('/theme_clean/static/src/js/tour.js', 'theme_clean', 'website.assets_editor')
('/theme_cobalt/static/src/js/tour.js', 'theme_cobalt', 'website.assets_editor')
('/theme_enark/static/src/js/tour.js', 'theme_enark', 'website.assets_editor')
('/theme_graphene/static/src/js/tour.js', 'theme_graphene', 'website.assets_editor')
('/theme_kea/static/src/js/tour.js', 'theme_kea', 'website.assets_editor')
('/theme_kiddo/static/src/js/tour.js', 'theme_kiddo', 'website.assets_editor')
('/theme_loftspace/static/src/js/tour.js', 'theme_loftspace', 'website.assets_editor')
('/theme_monglia/static/src/js/tour.js', 'theme_monglia', 'website.assets_editor')
('/theme_nano/static/src/js/tour.js', 'theme_nano', 'website.assets_editor')
('/theme_notes/static/src/js/tour.js', 'theme_notes', 'website.assets_editor')
('/theme_odoo_experts/static/src/js/tour.js', 'theme_odoo_experts', 'website.assets_editor')
('/theme_orchid/static/src/js/tour.js', 'theme_orchid', 'website.assets_editor')
('/theme_paptic/static/src/js/tour.js', 'theme_paptic', 'website.assets_editor')
('/theme_real_estate/static/src/js/tour.js', 'theme_real_estate', 'website.assets_editor')
('/theme_treehouse/static/src/js/tour.js', 'theme_treehouse', 'website.assets_editor')
('/theme_vehicle/static/src/js/tour.js', 'theme_vehicle', 'website.assets_editor')
('/theme_yes/static/src/js/tour.js', 'theme_yes', 'website.assets_editor')
('/theme_zap/static/src/js/tour.js', 'theme_zap', 'website.assets_editor')
Making the bundles for /web different with or without theme, and with or
without website id.
The proposed fix wont return a website if not specified in context and
if not during a request and if not forced to fallback.
The side effect is that the frontend assets where generated with a
website id 1 before that and it won't be the case anymore. This may be
a problem that could slow down frontend call on website 1 when design
theme is installed.
closesodoo/odoo#102690
X-original-commit: a5ed957b37b966bc50ed1219b6af65ed818f04a0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, when one would remove the favicon of a website in
the settings it would crash.
This is because since [1] the introduction of `base64.b64encode()` in
the `_handle_favicon()` method make it crash with `False` value.
Steps to reproduce:
- Settings > website
- Delete favicon
[1]: https://github.com/odoo/odoo/commit/6b8752604898bf2b583b7f5334e35f6a1583595e
opw-2958836
closesodoo/odoo#100399
X-original-commit: 35ce152d7e5c50cb363c0fa7adecf174fede9e46
Signed-off-by: Romain Derie (rde) <rde@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>
- use util method already used in regular theme selector screen
- theme_common is already in hidden category, no need to exclude it
- searching on theme category rather than `theme%` name
- move the uninstallable check in the util, no reason to show those in
the regular theme selector screen either
Fixes#92125closesodoo/odoo#99099
Related: odoo/design-themes#586
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = test_website, website_blog, website_event, website_forum, website_sale,
website_slides
`_search_get_details` extension in other modules can now be performed with
fewer lines of code by updating a search type-to-model mapping, without the
need for method override.
This will also have the benefit of slightly reducing the call stack length,
avoiding some unnecessary `if` statements and list lookups at runtime.
Task-2957361
closesodoo/odoo#98423
Related: odoo/enterprise#30946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* website_event, website_slides
Note that `restricted_editor` is the new technical name used instead of
`publisher`
Before this commit, the `is_restricted_editor()` method was actually
checking for `designer` rights and not `restricted editor` ones.
Indeed, a restricted editor (previously publisher) never had the write
right on ir.ui.view.
Despite the method name being wrong, it was still correctly used where
we actually checked for designer rights and not publisher/restricted
editor ones.
Also, the method was checking for write access on ir.ui.view instead of
checking directly if the user had the related group.
While it wasn't really wrong, it was also including people who would
have the write right on ir.ui.view but were not part of the designer
group.
This doesn't really makes sens, as we don't want someone which received
that write right on ir.ui.view from another module (not related to the
website) to be considered as a website admin -> we don't want to show
them website admin UI and stuff like that.
The method could have simply be renamed to `is_designer()` and could
have just checked for `has_group(designer)`, but having such an helper
seems overkill, we would end up with as many utils as there is groups.
At the end, this PR:
- removes the confusing util method
- replace it by has_group checks
Part-of: odoo/odoo#98200
* 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
Allow the user to select multiple languages in the website creation modal.
task-2745347
closesodoo/odoo#86541
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
For performance reasons, when fuzzy search was introduces it was
decided to limit the number of records used for finding fuzzy terms to
1000. Because of this, when a database contains more than 1000
products matching words that start with the same letter, further
products are not examined. This can lead to searches not finding an
existing exact match.
This commit introduces a fallback mechanism so that, if we are in a
situation where the maximum number of examined records was fetched, we
also explicitly check for a possible exact match across all records.
Steps to reproduce:
- Do not install the pg_trgm extension.
- Have more than 1000 products containing searchable words (name,
description...) starting with the same letter.
- Add one more such product (so that it is not in the 1000 first ones).
- Search for that last product by correctly typing the word.
=> Exact match was not returned.
task-2870947
closesodoo/odoo#97657
X-original-commit: 6d24ea28b236155d542e3d2be3da379b9f4e9ce6
Signed-off-by: Romain Derie (rde) <rde@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>
==== Short version ====
Google is deprecating Universal Analytics in July 2023 and Google
Sign-In in March 2023. Google Analytics Embed API is based on Sign-In,
meaning it won't work anymore. It actually already doesn't work anymore
for accounts created somewhere after mid-2020 apparently.
There is no plan for now for Google to allow Analytics 4 dashboard to be
embed in external website.
We therefore can't do anything to keep the Google Analytics dashboard in
Odoo.
In previous stable version, it was kept but is displaying a warning
about it (as until mid 2023 old accounts can still embed it).
All this is about the embed dashboard, not the tracking in itself for
which Odoo is already adapted in Odoo 15.0 for Analytics 4.
==== Detailed version (following short version, read it first) ====
- Universal Analytics EOL July 2023, see [1].
- It will be replaced by Analytics 4 for which Odoo is already ready and
actually using it since version 15.0 with [2].
- Google Sign-In EOL March 2023, see [3]. Analytics Embed API was based
on it, it won't work anymore.
- There is no plan (for now) for Google to allow Analytics 4 to be able
to be embed in external websites. They seem to just have dropped the
"feature".
This was confirmed by Google here [4] and indirectly here [5] in the
DOC:
`Note: This API does not support Google Analytics 4 (GA4) properties`
- While the EOL is planed for 2023, the dashboard integration is already
not working anymore for new accounts.
- Old projects/keys/accounts can still embed their analytics dashboard.
The threshold seems to be somewhere mid-2020, according to [6].
It seems to be accurate as my own key from 2018 still works, while my
keys from 2021 do not.
==== Fix ====
- In stable, warn user about it in their Odoo Analytics dashboard (this
PR) and also add a warning about that on the doc.
- In master, simply drop the whole google analytics dashboard
integration and remove the doc about it, see [7].
==== Useful links ====
[1]: https://support.google.com/analytics/answer/11583528?hl=en
[2]: https://github.com/odoo/odoo/commit/78bc86cbeccfc5df16218aee2b0d7c501e5c05b5
[3]: https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html
[4]: https://issuetracker.google.com/issues/233738709?pli=1
[5]: https://developers.google.com/analytics/devguides/reporting/embed/v1
[6]: https://support.google.com/analytics/answer/11583832
[7]: https://www.odoo.com/documentation/15.0/applications/websites/website/optimize/google_analytics_dashboard.html
Finally, note that it means that from July 2023 to Octobre 2023, while
Odoo 14.0 is still supported, Google Analytics won't work anymore in
that version as it will still be designed for Universal Analytics and
not Analytics 4.
opw-2710910
opw-2855405
opw-2881515
opw-2892370
task-2790245
task-2820890
closesodoo/odoo#96280
X-original-commit: d065595f77790fb5ab9480f6de5b88549352324b
Related: odoo/enterprise#29666
Related: odoo/upgrade#3698
Related: odoo/documentation#2499
Signed-off-by: Romain Derie (rde) <rde@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>
*: website_blog, website_hr_recruitment, website_sale, website_slides
This commit changes the redirections from the controllers, that were
always redirecting to the frontend before.
Now, we want to open the website in its backend client action most of
the time (for example, when clicking on the "go to website" buttons on
the form views).
For that, a new get_client_action_url is introduced on the website
model.
See merge commit for more information.
task-2687506
The goal of this commit is to add the 'Page Properties' dialog using
the 'website.page' form view.
The PagePropertiesDialogWrapper was updated to work on pages listView
(to clone/remove pages).
A boolean field 'is_in_menu' was added to control if page is in menu on
page properties dialog. This should be refactored later as a wizard.
See merge commit for more information.
task-2687506
Before this commit, the configurator was its own frontend application.
With the website edition UI moved to the backend, it makes also sense to
move the configurator to the backend, as a client action, so that it is
easy to trigger it after installing a website (or the website module),
and returning to the website_preview client action after having
completed it.
This commit adds a new color_palettes.scss file, added in the
assets_backend, that will print the values of the color palettes (so
that some js can handle it). For now, it is needed for the configurator
and the editor. It will probably need to be reviewed later to not put
everything in backend assets.
See merge commit for more information.
task-2687506
Exclude non installable theme from the configurator suggested themes.
Also, exclude themes which are found in the database (sql) but not in
the manifest (files/sources). This was reported after migration where
`theme_beauty_sale` was still in the database but did not exists
anymore.
Note that in prior versions, this was causing a `KeyError`.
closesodoo/odoo#92167
X-original-commit: 6e4faeb136e123e09d74cde06c47f7c822b1fd19
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit add the way to specify the Plausible shared key auth token and
the plausible domain on your website to have the Plausible Dashboard integrated
in your Website > Dashboard > Analytics menu.
Some custom event are already pre-configured as:
Push an event 'Shop' on confirmation on ecommerce (with amount bucket +/- 50)
Push an event 'Lead Generation' on:
'Thank you' page of contactus
Confirmation of subscription for an event
From this way, the end user can just add a goal 'Lead Generation'
or 'Shop' on Plausible to have the Goal values visible.
closesodoo/odoo#91058
Related: odoo/documentation#2007
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A reroute in an internal redirection, the URL on the current request is
changed. The actual changes occurs on the "WSGI environment", a
dictionnary that is populated with the request information by the WSGI
server (werkzeug in our case). Among all the properties there are
PATH_INFO, RAW_URI and REQUEST_URI.
* PATH_INFO is the standard value, it contains a RFC-3986 path.
`request.httprequest.path` is based on that value.
* RAW_URI and REQUEST_PATH are two custom values set by werkzeug to
mimic other popular wsgi servers (gunicorn, uwsgi, mod_wsgi), they
also only contain a RFC-3986 path.
When rerouting only PATH_INFO and RAW_URI are updated. REQUEST_URI is
left as-is in order to keep the original path somewhere. When building
the cannonical path, one must use the original path instead of the
rerouted one.
X-original-commit: 779486c4dff23b946b4b14e3dca164ecca4f85a8
Part-of: odoo/odoo#91034
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Since [1] when the fuzzy search was introduced, the candidate words used
for the fuzzy matching were split on non-'\w' (all non alphanumeric
characters + underscore).
This commit adds '-' (hyphen) to the list of characters that should be
considered part of the same word.
Steps to reproduce:
- Specify a product with name 'micro-vis'
- search for 'micro-vis' or 'microvis'
=> Was not returning any match
=> Now returns fuzzy match even for 'micro-vs'
opw-2801704
[1]: https://github.com/odoo/odoo/commit/c6ba756e4b4704089d02434871788a82d90cb195closesodoo/odoo#88591
X-original-commit: 10d54d3c6ba46afa86abac5275a02c4b5ec7d5a1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit "[IMP] core: don't save visitor default session" moved the geoip
from the session to the request with a deprecation warning. This commit
adapts the remaining modules to use `request.geoip` instead of
`request.session.geoip`.
Geoip is always set on the request but it can be an empty dictionnary in
case the geolocalization failed.
closesodoo/odoo#86015
Task: 2789035
Related: odoo/enterprise#25192
Signed-off-by: Julien Castiaux <juc@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
When serving a page, fetch the requested page and the menu's pages in
one go.
This will only impact pages that do not have a menu entry, which is the
most common form of pages.
So, instead of:
- read page
- read page's view
and later:
- read menu pages
- read menu pages' views
Fetch everything together:
- read served page + menu pages
- read served page's menu + menu pages' views
task-2774979
closesodoo/odoo#85456
X-original-commit: 16bf7cca8e8d452ce9131d9d86ff5b23789da4e1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
We can easily avoid a read on the website table when serving the
homepage by simply caching the website.homepage_id value and then
browsing the record (no query needed) instead of reading it on the
website record.
While this code is not really elegant, it seems like a good tradeoff to
gain a query on this particular homepage serve controller, which is the
main entry point of a website and generally the page the more often
served.
task-2774979
X-original-commit: 69b443b85656c895c66a1f83b235f5d1e53727d4
Part-of: odoo/odoo#85456
Install the website_sale and open '/shop/whatever-9999' in your browser,
the response is a 500 Internal Error instead of a 404 Page not Found.
Because `request.endpoint` has been murdered by the httpocalypse, we
must re-match to get the endpoint later used to re-build the URL. When
an URL contains a record-id but that record does not exists, matching
the URL will raise a `odoo.exceptions.MissingError`.
Part-of: odoo/odoo#85340
Commit [1] introduced a cron that disables outdated js and scss snippets
assets. For example, if a new version of the masonry snippet is defined
with new assets: data-vcss="001" and data-vjs="001", the previous assets
have to be disabled (000.scss and 000.js).
That cron was not handling the scss variables files at all, so when
an outdated snippet was still used in the db and the cron was run, the
000.scss file was activated, but not the 000_variables.scss and it was
crashing the assets.
Now, the XXX_variables.scss assets files are handled alongside the
XXX.scss files.
Also, the regex used in the _is_snippet_used method was only returning
the first match of a snippet in an html field. So if a view had a
snippet up to date and then an outdated snippet of the same type, the
old assets were not activated. The 'g' flag was added to return all the
occurences of the snippet in an html field.
[1]: https://github.com/odoo/odoo/commit/fa1c05e7bb2959c6025a806a4348f69ed225b4ec
task-2775188
closesodoo/odoo#85360
X-original-commit: 644067e80d4ca3f41707cddd15ed8f2807a1e410
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit is the 13th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Here be dragons.
First and foremost, `http_routing` is a technical module that aim to
provide the minimum viable compatibility code between portal and
website. Its primary job is to take care of the lang inserted in the
path of URLs, e.g. `en` in `/en/my_blog`. Both when routing a request
with a lang in the URL and when rendering templates with multilang
support.
Next to `http_routing` is website, the module used by customers to
create pretty web page accessible online. Website uses a different
routing logic than the backend, webpages are **not** registered in the
routing map of werkzeug but instead delivered by website dedicated
code. It means that **all** request targeting a website page thrown at
the werkzeug router **fail** with a HTTP 404 error. The reality is that
website abuses the fallback mechanism (`_serve_fallback`) to deliver
its pages.
Using `_serve_fallback` as the standard way to deliver pages is broken
by design. It is the least crappy way to deliver content as long as
website page don't have a dedicated path prefix. Using a path prefix
(e.g. `p` in `/p/fr/mon_blog`) it would have been possible to route the
request to a dedicated endpoint using the same router as the backend and
with no change to the HTTP dispatching code. Sadly, the business does
not want such prefix so we have to stick with a broken design.
It is broken because prior to serving a page, website needs to setup A
LOT of stuff on the system. It needs to ensure a proper user is set on
the environment, it needs to setup the GeoIP database, it also needs
to determine the lang the user requested the page and it also needs to
save multiple attributes on the request objet itself (`is_frontend`,
`is_frontend_multilang`, `routing_iteration`, `website`, `lang`,
`rerouting` and `website_routing`). Since `base/ir.http@_match()` will
fail, everything must be set either prior to calling this method or in
`website/ir.http@_serve_fallback`.
---
The original implementation was overriding the `_dispatch` method which
was responsible to call the four `_match()`, `_authenticate()`,
`_postprocess_args` and finally `WebRequest._dispatch()`. The override
was very special, here is an attempt to explain it:
1) try to match an endpoint using the backend router, 404-errors are
ignored.
2) include the geoip stuff.
3) authenticate using the `auth` @route argument if an endpoint matched
in (1), otherwise authenticate with the public user.
4) if not endpoint matched or if a frontend endpoint matched in (1):
a) call `_add_dispatch_parameters` which sets many arguments on the
`request` object, including the lang found in the request cookies
b) try to extract a lang from the URL: abort with a redirection when
the lang is missing or wrong, remove the lang from the request
path when it is set (updating both `request.lang` and the cookie).
5) return the result of `super()._dispatch()`
Note that `_serve_fallback()` is called during `super()._dispatch()`
when the path still does not route to an endpoint. Thanks to the
`_dispatch` overrides in http_routing and website, it is garanteed that
the system is setup prior to calling `_serve_fallback`.
---
Because it is now `http.py@Request._serve_ir_http()` that is responsible
of calling the four`_match()`, `_authenticate()`, `_pre_dispatch` and
finally `_(http|json)_dispatch()` it is no more possible to override it
to take over the dispatching to perform the http_routing/website magic.
The prior implementation can not work with the new design thus is has
been refactored too.
To render a website page, there must be a user configured on the
environment (not None) and the various special attributes must be set on
the request object. The special `lang` attribute is popped from the
request path but backend endpoints must be delivered in priority.
Using the new design, it has been decided to override the `_match`
method to implement the lang-in-path logic, to override both
`_pre_dispatch` and `_serve_fallback` to call `_add_dispatch_parameters`
which have been renamed `_frontend_pre_dispatch` and to also grant the
public user in the `_serve_fallback` override.
The `_handle_error` override in website has similar needs, the function
is called upon error (4xx/5xx) in order to render a pretty
website-looking page. Because such error can occurs as early as in
`_match()` (page not found and no fallback), when nothing has been setup
yet, website is yet again responsible for setuping everything: request,
orm, frontend.
Many other small improvement are not described here. Hopefully the added
comments in the source code are enought.
PR: odoo#78857
Task: 2571224
Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.
Steps to reproduce:
- Create an empty database and install website.
- Add an extra lang on website (e.g FR) and visit the website in that
lang.
- Go in settings an create a new website, skiper the configurator,
select a theme.
- Redirect is with enable_editor but nothing happens.
The editor isn't started if not in the source's lang.
This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.
[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107
task-2687416
closesodoo/odoo#85058
X-original-commit: 02e08af7278cd66d768fe6a4f23aa17eb816be3c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] when fuzzy search was introduced, fuzzy search was also used
when the search term contained numbers.
This is a problem for companies where the shop search is used on
references: the fuzzy search does not match against the whole database
and therefore the exact match might not be found.
After this commit the exact search is used whenever the search term is
made of 80% of numbers or more - because it is very likely to be a
reference or an identifier.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
opw-2715647
closesodoo/odoo#84943
X-original-commit: 7b44907c322a7b78ef4a5cb46627df4f72b21240
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.
Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
"Pages and Features"
With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.
[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
task-2687416
closesodoo/odoo#84810
X-original-commit: a0f8fdc65566fafe98dab21f5c2dbab9505c3d5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, when a user searches with an upper case search
term of more than 3 characters, the search was considered as a fuzzy
search even if the result was an exact match.
Since the search is always lowered when there are more than 3
characters, the search is considered as fuzzy only when the search and
fuzzy term are case insensitively distinct.
closesodoo/odoo#84593
X-original-commit: 34362a7c07a2868103b24d16a83a97356ad1f60d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
As an overridable _neutralize model method was added in a previous
commit, the method is now implemented for various models.
closesodoo/odoo#67825
Related: odoo/enterprise#19042
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Avoid to base64 encode, then decode to process assets and images for a ~25% speed improvement.
Change image processing tool to work on images, rather than base64 encoded strings.
Performance is ~25% faster on assets & images:
/web/assets/...frontend.min.css: 13ms to 7ms, base64 enc/dec: 2 -> 0
/web/image/XML_ID: 10ms to 8ms, base64 enc/dec: 3 -> 0
/web/image/res.users/2/avatar_128: 40ms to 20ms, base64 enc/dec: 6 -> 2
closesodoo/odoo#82851
Related: odoo/enterprise#23537
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Julien Castiaux