`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
make searching translated field language dependent
add an extra filter using trigram index to speed up '=' and 'like' search
X-original-commit: 5b6f0a9e5f9d60735e306709a3e7d7ac46a586be
Part-of: odoo/odoo#103031
*: 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>
The goal of this commit is to add some fixes on page properties dialog
after the Owl REF [1].
- XML: use default form view style (remove </group>).
- Move the '/' back into the non editable part of the URL.
- Prevent python code from creating a different URL (and optionally
setting "website.rewrite" record for it) when the new URL is the same
as the initial one after slugify.
- 'useAutofocus()' on the first page properties field.
[1]: https://github.com/odoo/odoo/commit/61a9d7bd2abc6081b321a51d329f9e85209215e5
task-2687506
closesodoo/odoo#102869
X-original-commit: 1165dfcd4fd5677d14f3d3329ad7c62be847b31a
Signed-off-by: Romain Derie (rde) <rde@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>
When loading a registry from route with auth="none" and where module
'website' is set as 'to install', request.env will be None and install
will crash as follows:
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/registry.py", line 88, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-15.3/odoo/modules/loading.py", line 303, in load_module_graph
module.write({'state': 'installed', 'latest_version': ver})
File "/home/odoo/src/odoo/saas-15.3/addons/website/models/ir_module_module.py", line 78, in write
if request and request.context.get('apply_new_theme'):
File "/usr/lib/python3/dist-packages/werkzeug/local.py", line 348, in __getattr__
return getattr(self._get_current_object(), name)
File "/home/odoo/src/odoo/saas-15.3/odoo/http.py", line 1029, in context
return self.env.context
AttributeError: 'NoneType' object has no attribute 'context'
```
closesodoo/odoo#102343
X-original-commit: fcf6e462e116d13533014e31d4191763354811cf
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
*: im_livechat, survey, utm, website_crm_iap_reveal, website_forum,
website_livechat, website_sale, website_sale_comparison
Before this commit all cookies were considered essential.
This commit makes some of them optional. It also makes it possible for
the website visitor to only accept the essential cookies.
task-2800976
X-original-commit: 9a8a9463289a7446e9be0ef62ff895feb37a4de4
Part-of: odoo/odoo#101845
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit, the only possibility when adding a google font was
to use google servers to serve the font.
This was not ideal as some people really want to serve it themselves
without the need of their visitors to reach google servers.
That's especially true since recently where it seems like German clients
are receiving letters about that to tell them it's illegal and this
should be changed, as it wouldn't respect the GDPR.
Somehow, it seems related to the fact that google knows you visited a
website by just downloading the font, because they very well know with
just your IP who you are exactly.
It's yet unsure if that issue is well-founded or not, but since German
courts seem to be sanctioning people about this, there is no reason to
not at least provide a workaround.
What is sure is that it makes a lot of noise and more and more people
seem to be impacted by this as many opw are getting opened, as well as
github messages.
Whether it is well-founded or not is thus not really our problem
anymore, we should just provide a way for our users to protect
themselves against this "German law problem" (or at least think they are
protecting, if Odoo thinks that's a non issue or the German court is
wrong or ambiguous).
Note that a cookies banner to inform users would not be enough for that
"problem", as the user would already have accessed your website and thus
the related problematic fonts.
Another solution which is not something we want (at all) would be to
serve local system fonts while the user did not consent about google
fonts, or having a blocking screen page telling people visiting the
website will fetch google fonts. Obviously those 2 possibilities are a
no go as it leads to terrible UX.
Finally, note that:
- in Odoo 16, the default fonts will be the system fonts, meaning there
won't be any call to google by default, regardless of this pr
- there is a work in progress to improve the current cookies bar to
differentiate essential and non essential cookies and to allow user
to accept only one or both (task-2800976).
Useful links:
- https://github.com/odoo/odoo/issues/83638#issuecomment-1054470699
ODO detailed point of view about this
- https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
The German law about this
Closes#83638
task-2756486
opw-2970167
opw-2960466
opw-2960555
opw-2952427
opw-2800976
opw-2748647
(possibly many more)
Courtesy of @bso-odoo for the regex part which was inspired by another
of his google font fix attempt
closesodoo/odoo#101826
X-original-commit: b06ce21eba6388ce34bbffffadcb489f0e8557dd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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>
The goal of this commit is to:
- Tweak the website filter (on website pages list added at [1]) to make
it work for all website content records (page, blog, ...).
- Update the 'New Page' dialog to be able to select the website_id for
the new page.
- Tweak the '_compute_is_homepage()' method to set 'is_homepage = True'
on website's '/' page when 'homepage_url' is not set in settings.
[1]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
task-2889981
X-original-commit: d6014c60acc4231a5e56d492d2a39deaf789cbe8
Part-of: odoo/odoo#101215
*: 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>
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>
When creating an account from the website (through the link "Don't have an
account?") while having been previously identified, the creation lasts a very
long time and ends-up with a http 502 error (actually a timeout). Same when
logging although being already logged.
Technical note: The problem was due to a database deadlock because of going
twice through authentication. A record was deleted in one transaction while
being written in another (_merge_visitor deletes it and _update_visitor_last
visit writes it but with different environment).
Task-2950241
closesodoo/odoo#99723
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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.
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
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>
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
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>
Before this commit, there were multiple issues related to the creation
of `theme.website.menu` records in a theme:
- Not possible to add a menu in the existing website's navbar
- When one would try to create a `theme.website.menu` that menu would be
created for every website when instaling the theme on a particular
website, which is terribly wrong as it goes against the multi-website
holy grail rule: when editing a website, do not impact other websites.
- Not possible to create a mega menu
Now, one can create a menu:
- as a navbar top menu
- as a child menu of another theme menu
- as a whole new menu hierarchy (top level container)
This is not possible to create a menu as a child of a website.menu, like
adding 2 submenu to the existing contact us menu.
First, this is technically impossible to do without introducing yet
another hack code in the `website.menu` write. Indeed, there is no way
to identify a generic menu's website copies. Neither through a direct
DB field, neither through a persistent info like we do with the `key`
attribute of views. So there is no reliable way to tell the system to
add a menu below the "Contact Us" menu of the website, as this is just a
menu copied when the website was created. We could obviously later add
a `key` field or something like that to identify an XML menu's copies.
Second, there is a workaround as one has to recreate the website.menu
and delete the original one (through a `<function/>` record).
Third, this should not be the main use case about menu creation in
themes.
----------
Some fields were also missing regarding the `website.page` model.
----------
A stable attempt is done at [1], this is where the current commit
originates from.
As the Odoo 17 release is quickly approaching, it was decided to first
write the proper IMP in master from which we will see what can be
backported and how, if needed.
[1]: https://github.com/odoo/odoo/pull/86669
Part-of: odoo/odoo#99099
website: get_base_url was not working with unprivileged users
Before this commit, when a unprivileged user tried to generate a report
(in sale for example), he could not access to the field website_id on ir.ui.view
An access error would be raised. This commit allows to read the base_url for all users.
Misc: UI for sale order templates
Before this commit, the sale order template information was not clear enough.
Note: these changes were merged into a single commit to ease the manual FW port of
changes in 15.3 for sale_subscription
taskid: 2942621
After [1], the frontend website page manager was replaced by a custom
'website.page' list view and, with following commits on this PR, this
view will be used with other website content models records (blog,
event, forum, ...) too.
The goal of this commit is to adapt the pages list code to the new Owl
view system.
Other changes (related to the view's behavior) were added in this
commit:
- "Page list action buttons" are removed, we keep only the action that
triggers the form view of 'page.view_id' in debug mode. Page properties
and SEO dialog can be accessed via the website iframe after clicking on
the page entry in the list. The clone button should be later restored as
part of the main website backend menu, still when viewing the iframe.
Meanwhile, it is accessible in page properties. The 'delete' button is
still accessible via page properties too but the standard "delete"
button when selecting records in the list view will later be improved to
act the same way.
- The "website switcher" on top of the list view (to filter records
which impact one website, generic + specific records) is added as part
of the search view. Limitation: it will only be shown for pages at the
moment.
- A standard "Create" button is added and displays the form view dialog
to create a new content record as with "+ New". Known bug: it only
allows to create on the first website at the moment.
- The click on page/content record should redirect to the corresponding
url/website_url in iframe. This is now achieved via the new possibility
of defining an action on the <tree> tag in the view definition. Known
bugs/inconsistency: depending on the model, this opens in edit mode, in
a new tab, ... behavior to unify in a future update.
- The 'PagePropertiesDialogManager' is removed since the code is in Owl
and we don't need page properties dialog on the list view anymore.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2889981
Part-of: odoo/odoo#98937
Steps to reproduce:
- Install website_sale module
- Create a new company X
- Create a new product Y and set company to X
- Create a website Z and ensure it's linked to a company but NOT X
- Go to website Z homepage and edit it
- Add a `Products` block then save
(should be by default on filter `Newest`)
- Select product Y in the block
Issue:
The product should not be displayed and when clicking on it, we have
an access right error.
Cause:
Not taking into account the company of the website when preparing
values to render in the snippet therefore the product is displayed
while it should not.
Solution:
Update `_prepare_values` to add the website company to the domain if
the filter's model has a company_id field.
Same issue occure with latest_sold filter (for ex.) so must
apply same fix to `_get_products` for filters that use a server action.
opw-2956186
closesodoo/odoo#99181
X-original-commit: dab7fed0c396d3dd6e2e2ad8560c706d5c2e89fb
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Current Behavior:
When we get the access token for a website visitor, we check if the
`self.env.user` is a public user. If it is, we return his id.
Expected behavior:
We should check the `request.env.user` instead since the visitor can
only be created through the frontend.
opw-2956186
Part-of: odoo/odoo#99181
* = 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_sale_wishlist
When request.website exists, it is supposed to be the same as the
get_current_website() result as that's exactly where it comes from.
The dispatcher, if the request is a frontend one, is setting the
get_current_website() result as the request's website.
closesodoo/odoo#98200
Related: odoo/enterprise#30691
Related: odoo/upgrade#3808
Related: odoo/design-themes#582
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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>
Purpose is to ease finding server actions code and views. We just rename
some files and move some code, nothing should change functionally.
Task-2613245 (Server actions cleaning and mail update)
Part-of: odoo/odoo#75906
Since [1] when the search bar was refactored, a search facility was
added on website pages and the rendering of those search results did
not correctly handle the HTML escaping.
This is related to the fact that the `ir_ui_view`'s `arch_db` field is
stored with this double escaping on text nodes, which is done by
`wysiwyg.js` through the `_getEscapedElement` method since [2].
This commit unescapes the last layer of `&` before extracting the
page's text for generating the search results.
Steps to reproduce:
- Add some "&", "<" or ">" characters in a page.
- Use the search snippet to lookup for the page.
=> The results in both autocomplete and the results pages display the
content with an extra unwanted escaping (&...)
[1]: https://github.com/odoo/odoo/commit/9f9c4bb7e40233e633f97c60fb00ae191e9077af
[2]: https://github.com/odoo/odoo/commit/f5acea7f9ce232773ec3adf1828a3d18bbedee1e
opw-2908645
closesodoo/odoo#97748
X-original-commit: 2b95dcdb0d8b49bac8ee38a8d062112468124012
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@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>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@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>
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>
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_modules
This commit restores the display of the website loader (the "Building
your website" GIF) during the installation of a module from the new
content modal, or after completing the configurator flow.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
Part-of: odoo/odoo#81485
Before this commit, switching websites with custom domains was not
properly done: the client action should redirect to the custom domain if
there is one, instead of only redirecting the iframe.
The redirection was not correct for the "go to website" buttons either:
in that case, the url was incorrectly generated for the redirection (the
custom domain was passed in the path parameter of the client action).
See merge commit for more information.
task-2687506
*: 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
Benoit Socias