Since [1] it is possible to request that some blocks are not displayed
on mobile devices.
This commit adds a similar option to prevent blocks from being displayed
on desktops (i.e. on non-mobile devices).
[1]: https://github.com/odoo/odoo/commit/9463f0f889f9dd8da6077895c125da4998a933c0
task-2900730
closesodoo/odoo#101483
X-original-commit: 3103e0553011b5c1f4078972d7a88fa3fd4068b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Antoine (anso) <anso@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>
*: website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
The website content list views should act as a page manager (click on
a record redirects to iframe, "CREATE" and "Publish / Unpublish"
buttons, ...).
The goal of this commit is to add a kanban version of these views for
key app models ('website.page', 'blog.post',...) since the same code
can now be used for list and kanban controllers / renderers since [1].
It is especially important in mobile where the kanban views are nicer
than list views by default.
[1]: https://github.com/odoo/odoo/commit/ed09db19c372da8d8be541f365117d1ce8e965ba
task-2889981
closesodoo/odoo#101174
Related: odoo/enterprise#31821
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_hr_recruitment
Add multi-edit on the remaining "pages" list views not using it:
- pages
- blog posts
The only remaining one would be "jobs" but editing the Department field
seems broken at the moment.
Related to task-2889981
closesodoo/odoo#101215
X-original-commit: be58687284884550cc4e6c2ac7255abee4eb1125
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The goal of this commit is to add a 'Publish' / 'Unpublish' button to
the additional actions of the 'website content' list views.
'Archive' / 'Unarchive' options are also removed for the 'website.page'
records.
task-2889981
X-original-commit: de02335b8db1396a24e10b78f8f78ed79fded421
Part-of: odoo/odoo#101215
*: website_blog
The goal of this commit is to update JS code to have the same behaviour
from the 'website content' list view (trigger the 'new content' dialogs
on "CREATE", add a website selector to filter content) on kanban views
too.
The blog post kanban view has been adapted to use this. Other "website
content" related records will receive a kanban view in a further update.
This is is also important so that the mobile UX is nicer.
task-2889981
X-original-commit: ed09db19c372da8d8be541f365117d1ce8e965ba
Part-of: odoo/odoo#101215
The 'addPage' code on website pages list view was duplicated from
'new_content.js'. The goal of this commit is to move this code to the
'AddPageDialog' component.
task-2889981
X-original-commit: 58698f848703395ff680bc7586ecc8eec4fb61ae
Part-of: odoo/odoo#101215
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
Setting width *and* height attributes allows to reserve some space to
avoid layout shift during page loading. Of course, CSS rules set the
height the user chose, while the width is set to 'auto'. But while the
image is loading, it is best to already reserve some width to reduce
layout shift (like making the menu move or even re-render itself into a
"+" menu).
The chosen values for the space reservation are the ones of the default
logo and theme, but it does not really matter as long as they are
coherent. While the image is being loaded, the chosen user height is
still applied and the 'auto' width rule induces a width that respects
the aspect ratio set by the width and height attributes. That could be a
problem if the real logo has a larger height than width, in which case
the layout shift would be increased because of the arbitrary values set
as width and height, but in most cases, this should reduce it.
This also allows to gain some page speed scoring.
Examples:
=# Logo 200 x 100, height set to 50
Before this commit
- while loading: width = 0, height = 50
- once loaded: width = 200 / 100 * 50 = 100, height = 50
-> layout shift of 100 - 0 = 100
After this commit
- while loading: width = 95 / 40 * 50 = 118.75, height = 50
- once loaded: width = 200 / 100 * 50 = 100, height = 50
-> layout shift of 100 - 118.75 = -18.75
=> Shift of 18.75px to the left, way better than shift of 100px to the
right
=# Logo 100 x 100, height set to 50
Before this commit
- while loading: width = 0, height = 50
- once loaded: width = 100 / 100 * 50 = 50, height = 50
-> layout shift of 50 - 0 = 50
After this commit
- while loading: width = 95 / 40 * 50 = 118.75, height = 50
- once loaded: width = 100 / 100 * 50 = 50, height = 50
-> layout shift of 50 - 118.75 = -68.75
=> Shift of 68.75px to the left, kinda the same as a shift of 50px to
the right.
=# Logo 100 x 200, height set to 50
Before this commit
- while loading: width = 0, height = 50
- once loaded: width = 100 / 200 * 50 = 25, height = 50
-> layout shift of 25 - 0 = 25
After this commit
- while loading: width = 95 / 40 * 50 = 118.75, height = 50
- once loaded: width = 100 / 200 * 50 = 25, height = 50
-> layout shift of 25 - 118.75 = -93.75
=> Shift of 93.75px to the left, worse than shift of 25px to the right
but the case of having a 'portrait' logo is considered less common
than having a 'landscape' logo. Ideally, we should choose the
arbitrary values related to the most common aspect ratio.
closesodoo/odoo#101149
X-original-commit: 73786c5c45202914e02325c19a2afaa47d31c341
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit make it possible for design theme tours to define
preconditions based on the CSS variables in order to make sure that
the tour is run within a website that has the specific theme applied.
See https://github.com/odoo/design-themes/pull/590.
task-2687506
closesodoo/odoo#101119
X-original-commit: b29e17765f4e912b2dd472493b5be500b3a32c87
Related: odoo/design-themes#594
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit prevents the "|" between the additional title and the
website or company name from being turned into a translatable `span`.
closesodoo/odoo#101102
X-original-commit: 81c7c4cdf973b36e8ed787f8247da3a4bbf93117
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
To allow increasing page loading performance, websites can now choose to
use system fonts instead of using a google font. It is also the default
in the default theme of Odoo from now on. The option will automatically
be available for all themes whatever way they defined their available
fonts but will only be used as default if explicitly asked by the theme
(as done in the default theme).
task-2993054
X-original-commit: c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
Part-of: odoo/odoo#101068
Before this commit, if a theme wanted to define a main font for their
theme and let the "headings", "navbar" and "buttons" ones use the same
they had to add this in their map:
```
'font': XXX,
'headings-font': null,
'navbar-font': null,
'button-font': null,
```
Indeed, without setting the "null" values, those font would use YYY
which is the first font defined in the theme config, which might be
different from XXX. And if forcing XXX 4 times, like most themes do at
the moment, if the user wanted to change them all, he had to change the
4 ones instead of the main one.
Now, only the 'font' value use the first font defined in the theme
config if not explicitly set. So forcing the null values is not
necessary, it will be the default behavior.
The advantage is thus also functional, as most theme forced all their 4
fonts so changing the main one did not change the others.
task-2993054
X-original-commit: c6b56955f62c6b837b477223daac2d87ab984efb
Part-of: odoo/odoo#101068
Before this commit, if a theme defined in its website values "palette"
"null" as value for the "headings-font" variable, it was properly making
the headings font use the default "body" font as expected but the editor
panel showed an empty value instead of displaying the "body" font value.
Now, that panel UI problem is fixed for the headings, navbar and buttons
fonts. Note that all our current themes force the font for each of those
component so the bug was never visible anyway. That's why it is merged
here in 16.0 and not before but it could be backported if necessary
(although it is only an UI bug which is not really confusing).
Before this commit, for a theme which says "use XXX as main font" and
"let headings follow the main font", the UI displayed:
Main font: XXX
Headings font: /
After this commit, it displays:
Main font: XXX
Headings: XXX
task-2993054
X-original-commit: b07a408f2f80638a2abdda8304e31d3dac9968b3
Part-of: odoo/odoo#101068
What is done in start should be undone in the destroy.
closesodoo/odoo#100904
X-original-commit: a221342ca18db892153bbf4139c0bee7cd1e9bde
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the merge of Bootstrap 5, some data attributes was non converted
to the new syntax for Bootstrap 5 (data-interval -> data-bs-interval).
closesodoo/odoo#100935
X-original-commit: bb9f7542b9dd481c363b593aa97d4a6f2d5ecd1f
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit avoid to have a dict by reference that will be global.
Now get_default_session return a new dict each time for the context key.
From this way the session.context['lang'] is not shared between several
users on the same worker.
To reproduce the bug, restart the server with 2 workers, make request in
lang A on these 2 workers. DEFAULT_SESSION['context']['lang'] now is set
to this lang A.
Now, make request to an url without lang in path and without cookies and
withtout session, you should be redirected to lang B (preferred lang
from the request header) but you will be redirect to lang A due to the
dict session.context that is shared for the worker...
When we initialize the new Session, we get the wrong lang A as value for
context.lang, so we don't recompute the expected lang for the end user.
X-original-commit: 62179de74862210fe2a055d15b367b1850c24263
fwd-port of #100102closesodoo/odoo#100910
X-original-commit: 42e46b2d89dde276f796b980f29e33cc216e7cb2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
- Take them out of `legacy` codebase.
- Group them in a generic `static/src/scss` folder, as those files are
used in webclient but also in public livechat, portal...
X-original-commit: ca2e4fea92b5a26078a412072275a969508358c7
Part-of: odoo/odoo#100759
This commit transfers responsive related customizations for
ControlPanel, SearchView and SearchPanel to community which allows them
to render properly on smaller devices.
Note: a page reload (aka. F5) is required to properly adapt the UI after
a resize to a mobile-like size.
X-original-commit: 26a755610da36b01ba07ca224cc5937a672eb6a8
Part-of: odoo/odoo#100759
Since _checkScrollbar, _setScrollbar and _resetScrollbar doesn't exist
anymore in BS5 and that these functions were removed during the
migration as you can see here: [1], compensateScrollbar is no longer
used for modals. That's why this commit removes the
'compensateScrollbar' function from 'jquery.js' and adds the code of
this function in the 'menu.js' file in Website because that's the only
place we need it now for the affixed header.
[1]: https://github.com/odoo/odoo/commit/0b94da214b7017e8580e671cbaa68ade6de2fbc7#
task-2985702
closesodoo/odoo#100894
X-original-commit: f3f45c93d3e942b224332924d66f2e48fc711002
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This reverts commit https://github.com/odoo/odoo/commit/51939d09f84579f61f1ff77aacd754beba036dc2.
This commit was added to no longer have to compensate the scrollbar
width to display the fixed header. To do this, this commit had changed
the 'fixed' CSS position of the affixed header to 'sticky'. But this
introduced several issues with header effects (the main problem with the
"sticky" position is that Chrome and Firefox don't handle it in exactly
the same way.). For his reasons, we decided to revert the commit and get
back to a situation where everything works correctly.
task-2985702
X-original-commit: ab9a4497c9ade5d91d7661bb3a4f47a683be1c32
Part-of: odoo/odoo#100894
Commit [1] changed the way QWeb templates are loaded for public widgets,
removing the xmlDependencies attribute.
Most of the public widgets' templates were therefore defined in
assets_wysiwyg. This is wrong however, as those assets are only loaded
in specific situations.
This commit removes the templates definitions from the assets_wysiwyg
into specific records defined alongside the snippet templates.
Steps to reproduce:
- Drop the "Image Wall" snippet
- Save
- Visit as a public user (logged out)
- Click on an image from the image wall
- TB
[1]: https://github.com/odoo/odoo/commit/f05adbc8b59c67cbec4847687a1ee07e620c2a7a
task-2984724
closesodoo/odoo#100766
X-original-commit: 39dcd15833afc3860b9c4012a9a4c9da76844a07
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Since [1], as part of the new translation system made with [2], saving
multiple elements in a website page was only saving the first one. E.g.
- Enter edit mode of your homepage
- Add something in the main area of the page
- Add something in the footer
- Save
=> Only the main area is saved, not the footer.
This was actually the same in translate mode... only translation of the
first edited area could be saved.
At least, with the bug fixed version of [1] comes the small advantage
of not saving multiple times the same field (except for view parts).
E.g.: an event's dates are displayed multiple times in different formats
-> in 15.0, 3 RPC were made by date changed, now only one is made.
[1]: https://github.com/odoo/odoo/commit/1b473cf0db4d85c2b523ac87fbab533bce5f3e21
[2]: https://github.com/odoo/odoo/commit/4e82c45abdb0b420edead2bd1d0ba9ff4bb4a224closesodoo/odoo#100762
X-original-commit: c834d151afed0ca633ffb6bcba2f45b544689e74
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: auth_password_policy, bus, calendar, event, mass_mailing, stock,
survey, web_editor, web_tour, website, website_event, website_forum,
website_mass_mailing, website_sale
This commit is a first step towards a potential deletion of the
assets_common bundle, although that step would need more work, specs and
discussions as some layouts kinda only use the assets_common bundle
(some take the full assets_common but parts of the assets_backend one
for example).
The main goal of this commit is to have the assets_frontend bundle
directly include the "common" files we need. As a first step, this
commit only blindly duplicates them all into assets_frontend (without
removing the potentially useless ones). The goal is to have those
advantages:
- Reaching a frontend page only calls two main JS files (one normal and
one lazy-loaded) instead of 4 (two normals and two lazy-loaded). This
may help reach a better google page speed (which is becoming more and
more strict).
- The frontend CSS is built as one: the common SCSS which was using
bootstrap variables, or even Odoo-based SCSS added by mistake in
common instead of both backend and frontend is now computed with the
right bootstrap customizations. E.g. the tempusdominus datetimepickers
use bootstrap grays... after this PR, they use the right grays as
customized by the user on the website.
It was also chosen to not have a common "sub-asset" which is included in
assets_frontend. Making assets_frontend completely independent makes
sense (as it probably will for other "main" asset bundles): we can focus
on adding the files each layout needs without the need of worrying if it
impacts unrelated layouts. Sub-assets (when not strictly necessary) is
also a source of errors: extending the "main" bundle instead of the
right sub-asset it may use (like it was the case with the sub-assets of
assets_common: _assets_common_scripts and _assets_common_styles as
explained in the previous commit). So this is indeed a small drawback of
not factorizing the code for the inclusion of "common" files in bundles
but it seems more explicit and easier to maintain that way. Note that
adding "common" file is not the most common usecase anyway, apps
generally only need files in backend or frontend.
The __manifest__ declaration will also likely evolve in more and more
uses of wildcards to match entire directories. In the future, adding
"common" web-app files in both backend, frontend and other "main"
bundles could just be about one line duplicated into each bundle.
closesodoo/odoo#100314
Related: odoo/enterprise#31394
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Emptying the domain should be setting it to False, not empty string,
which is saved in DB as such.
This was not problematic at all before but since [1] the domain must be
unique. As we removed the "multi website by domain" feature, we then
were able to add that constraint.
But since then, having two website with domain == '' would raise the
constraint error, while null values (False in python) would not.
[1]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d
runbot-5041
closesodoo/odoo#100430
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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>
Some (most?) people keep trying to double click on it to edit it.
The wording was not helping as "Replace this" doesn't really tell the
user how to do it. He actually has to click on the "Edit" button on the
right panel.
Personal experience, the first times I tried that code snippet, I didn't
find that button and it took me a few times before understanding how it
works.
The new wording and the shortcut button to edit it should be more clear.
Another idea was to allow dblclick to enter edit mode, but this seems
overkill and the 2 improvements here should be enough to make it easy to
figure.
Also added a comment about the `
` and one-liner, it is far from
obvious when reading the code..
task-2978786
closesodoo/odoo#99922
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
The mini UI on the frontend as a connected backend user was a bit
confusing: the "Edit" button used the exact same design and wording as
the "Edit" button in the backend but it had not the same effect as it
did not enter edit mode but just redirected the user to the website
preview (client action iframe).
We still want the same behavior, we just needed another button design:
- Change the label from "Edit" to "Editor".
- Change the "pencil" fa icon with the website app icon (same as app
switcher in enterprise).
- Use a dark color instead of the primary color. This reuses a dark
color of the website edit mode.
closesodoo/odoo#100355
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.
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>
With [1] moving the website in backend, it is now possible to display
a backend discuss chat window while browsing your website.
This window is unfortunately hidden behind the SnippetEditor when it is
open.
The choice was made to hide the chat window when the edit mode is
activated, as it could hide some content of the page.
Steps to reproduce:
- Open a Discuss chat window using the systray item from the app grid
- Open website
- Click on Edit
Chat window is hidden.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#100098
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the website service method fetchWebsites was not
clearly defined: it was fetching the user groups, the websites, the
current website and it was also setting the service's current website.
There is a difference between the get_current_website backend method and
the getter from the website service, introduced in [1]: the
websiteService.currentWebsite value referes to the website currently
edited in the WebsitePreview client action. From that value depend other
components visibility (like the contextual menus).
So when a fetchWebsites call was done from outside the client action,
from a PageListController with [2], it was breaking the flow by setting
a currentWebsite outside the client action and it could lead to bugged
flows:
- Go to the "Pages" list view
=> The contextual "This page" menu is not shown, it's correct
- Refresh the page
=> The "This Page" menu is shown (and broken).
To fix that, the fetchWebsites method is divided into a fetchUserGroups,
the searchRead on the websites, and another call to get_current_website,
located in the client action. It allows to load the client action iframe
with the last viewed/edited website.
Also, the menu "This Page" is shown only when there is a pageDocument at
the website service level.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
task-2687506
closesodoo/odoo#100055
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
In this commit, we simply set 'position' to 'sticky' on 'o_header_affixed'
to avoid to manage it's position with 'padding-top' and 'right'.
- 'padding-top' css property was used to compensate the navbar height
at the moment where the stacking context change because of the
fixed position.
- 'right' css property was used to prevent the menu to overlapp
the scroll bar.
Part-of: odoo/odoo#99338
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
Commit [1] introduced t-cache on the footer making it cached depending
on its website id. This is wrong as the footer can be visible or hidden
depending on the page it is currently rendered in.
This commit adapt the t-cache so that the footer is cached based on the
page.
Steps to reproduce:
- Go in edit mode and click on the footer
- Turn off "Page Visibility"
- Save
Footer is now hidden on every page depending on which page rendered it
first.
[1]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466dclosesodoo/odoo#99832
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In this commit two errors in the rendering of the mega menu are fixed:
* the position of the mega menu when the option `Sub Menus` is `On Hover`
this bug is due that we show the mega menu manually adding the `show`
class on the element in our code. However, in the `On Click` mode,
it's Bootstrap's javascript that handle the show/hide state.
Bootstrap adds the `show` class and also adds the attribute
`data-bs-popper="none"` to the element. In `On Hover` mode this
attribute was missing.
* the render of mega menu in the `+ icon` (`o_extra_menu_items`).
This error occurs because in Bootstrap 5 the width is set with the
`width` property and in Boostrap 4 it was `max-width`. In Odoo
`col-XX-YY` CSS rules are overridden when the mega menu is in the
`+ icon`, but the `max-width` was not changed by `width` during the
Bootstrap 5 migration.
closesodoo/odoo#100068
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The history of this one is kind of tricky, to say the least.
A fix in the theme install process was done in 14.0 with [1].
It came with a `standalone` test in the `design-themes` with [2].
It had to be a `standalone` test since it is playing with module
operation, which is forbidden in the regular testing suite (sadly).
Since this new test was the first `standalone` test in the
`design-themes` repository, it actually wasn't even properly tested for
months before we realized it. It was missing some runbot configuration
in the nightly build to include the `design-themes` repository in the
standalone testing suite.
Once the runbot configuration was correctly fixed, the test wasn't
working anymore in 15.3 and later version because of some change in the
httpocalypse [3] which made the `MockRequest` not behaving as expected.
Indeed, with [3] the request's context had to be updated through
`update_context` which wasn't adapted/working with `MockRequest`.
Then, since [1] (merged in 14.0) was ported in saas-15.3 at [4] (where
[3] also exists) it was the first time a test using `MockRequest` was
ending up calling business code doing a request's context change.
The business code doing `update_context` and called through the test in
`MockRequest` was then not doing anything and not changing the
`context`. The test was then failing despite the behavior/normal code
base working properly.
This commit makes the request's context change working with
`MockRequest`.
Some people think `MockRequest` should disappear, but right now that's
how it is, we are still using it as this is really useful to be able to
test business code in a frontend context without going through a tour.
For what it's worth, multiple time the community asked us to move it
outside the website module, but also multiple other internal team in
odoo. So, while it might be better or not correct in some cases (mainly
python super), the tool is useful.
[1]: https://github.com/odoo/odoo/commit/b8a24efa71daea1f96465b780f4f0e384ce74703
[2]: https://github.com/odoo/design-themes/commit/4de16d85b7f7d69212576eede82e8a15190d357b
[3]: https://github.com/odoo/odoo/commit/f61aa39ff1190f66cebb8efb8432723214932161
[4]: https://github.com/odoo/odoo/commit/14387f36438b731753e2e7169f54865b123cdcfaclosesodoo/odoo#100070
X-original-commit: 885ce02a15dc093ff98822f80b22c4415fa9cceb
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Ensure all the `#top_menu` links are unremovable.
This prevent the editor to merge two `<a>` elements together
during delete commands.
task-2967314
closesodoo/odoo#99966
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: web_editor, website_blog
This commit improves the mobile preview of websites. A mobile phone
image has been added around the iframe during the mobile preview. This
image was already used for the themes mobile preview, this is why the
css code has been unified to be used in these 2 mobile previews.
Parallel to this commit, we have modified the websites displayed in the
iframe of the preview of the themes so that the scrollbar of these is
visible (before it was hidden behind the image of the phone) but with a
smaller width in mobile mode.
This commit also improves the button to switch to mobile preview by
coloring it green when mobile preview is active.
task-2890050
closesodoo/odoo#98061
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
