*: web_editor, website
Prior to this commit, the template structure for declaring the snippet
options used in a specific context (website, mass_mailing, ...) made it
hard to easily modify SnippetOptions defined in web_editor.
Indeed, the structure was as below
```xml
<template>
<t t-call="web_editor.snippet_options" />
... Additional Options ...
</template>
```
If someone wanted to alter the behaviour of an option from web_editor
for their module, they had 2 solutions
- To extract that option inside another template, extend that template
inside their own module, remove its call from web_editor and instead
call manually the option inside each module (preferred method)
- To impact the web_editor template directly with an extension instead
of a new primary template or override JS options using include or
replacing an option inside the registry.
The second solution was often used but created extra code to make sure
that other modules were not impacted... and it was often not properly
done. For example:
- [1] and [2] introduced javascript code inside the web_editor options
and isolating it by checking if they are in fact, inside mass_mailing.
- [3] adds code in mass_mailing mentioning JS classes of website, and
actually broke parallax for website (after [5]).
- [4] broke the image transform option for website (after [5]).
- [6] added some shapes for mass mailing images but ended up adding them
for the website builder too.
- [7] created different images options for mass_mailing... but ended up
impacting website options too. Half of those can actually either be
put in web_editor to improve everything or just in mass_mailing to not
break the website.
- ...
This commit tries to fix everything "the right way" in master (and will
be backported for the recent 16.0). Other stable fixes will need to be
made to restore the website options in a stable way.
To fix that, this commit changes the structure to
```xml
<template inherit_id="web_editor.snippet_options" primary="True">
<xpath ...>
... Change existing options ...
</xpath>
<xpath expr="." position="inside">
... Additional options ...
</xpath>
</template>
```
This allows each module to modify the existing web_editor templates
without impacting it and each other. They can even change the JS
behaviour by using an XPath to replace the data-js of an option, and
changing it to their own extended version of the JS option.
[1]: https://github.com/odoo/odoo/commit/f296992317e96562c66bd7ad59a5080d6c551ed5#diff-df5e4ff426027c53ebe6e25c25820fb92237c17a036f6202a93e5ca681ec8c16R134-R138
[2]: https://github.com/odoo/odoo/commit/cd403480f90cf7103651f3be818a14b06d3c73ca#diff-df5e4ff426027c53ebe6e25c25820fb92237c17a036f6202a93e5ca681ec8c16R175
[3]: https://github.com/odoo/odoo/commit/e9237ae8004502a3071e8ceb132d9dac11fe00b3#diff-df5e4ff426027c53ebe6e25c25820fb92237c17a036f6202a93e5ca681ec8c16R372
[4]: https://github.com/odoo/odoo/commit/ff422df49201be6ed7baa11ef3deb5b9a41042a7
[5]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[6]: https://github.com/odoo/odoo/commit/24a4c7f897d4db6bdf0f3cbfc91a3ce7351241a2
[7]: https://github.com/odoo/odoo/commit/d0c2d8e9a1436a8eaf263797c790329f81d7615bclosesodoo/odoo#99850
Related: odoo/design-themes#597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Prior to this commit, the dynamic snippet would only start sliding after
the first interaction.
This commit makes it slide right away.
task-2677203
closesodoo/odoo#80128
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the Dynamic Snippet options would modify the DOM
at places were it is not supposed to.
PR [1] aimed at making it more stable, but the changes required to make
the option conform to the framework cannot be done in stable as some
methods' signatures needed to be changed (Changing a sync function to
async).
This commit aims at making the option follow the flow of an option:
- Modify the target's DOM either on build or on a change of option
- Modify the UI either during willStart or updateUI
To do so, the methods that fetch the template data needed to be split
from the methods that creates the buttons.
The benefits of this commit are that the option is less likely to cause
race condition and errors while performing its tasks.
[1]: https://github.com/odoo/odoo/pull/82222
task-2677203
Part-of: odoo/odoo#80128
This commit improves the design of dynamic products templates.
It introduces templates using multiples rows and fine tunes the
design of the other ones.
To make thumbnails work in the template selector, an extra
data-attribute can now be processed by the snippet option.
- data-thumb: it references the location of the thumbnail for a
template. If present the option will show the svg / img.
If not it will display the name of the template.
task-2677203
Part-of: odoo/odoo#80128
Co-authored-by: Arthur Detroux <ard@odoo.com>
*: website_sale
Previously, on the debug dynamic snippet, you could choose a product
filter and a template that had an add2cart button but that button
would not work.
This commit fixes that by creating a widget per card and moving the
card specific code to this widget.
task-2677203
Part-of: odoo/odoo#80128
*: website_blog, website_event
Commit [1] introduced new templates. This commit's goal is to build on
that template system to provide more flexibility for designers.
It adds new data-attributes to set on the first node of a template.
- data-row-per-slide: Allows for the template to tell a dynamic snippet
carousel how many rows of cards it should display.
- data-arrow-position: Allows for the template to tell a dynamic snippet
carousel where the arrows should be positioned.
(for now just bottom, or side)
- data-extra-classes: give the template the possibility to add extra
classes to the dynamic snippet instead of just the card.
This commit also removes options to select the amount of elements
displayed on each row. This is now only changeable through templates, or
by directly editing the snippet's DOM through debug tools. This was done
to reduce the amount of options visible, so that the user just chooses
a template and it is ready to go.
[1]: https://github.com/odoo/odoo/commit/49bd79b0bdca76415780bdfa199195371c2692e5
task-2677203
Part-of: odoo/odoo#80128
In some place the search params are mandatory in the route.
We now add the search and hash params to the editedObjectPath to
avoid having an error when trying to go back.
task-2993826
closesodoo/odoo#101996
X-original-commit: 2bed20392084bcbec2683939e5659b03e3ea7acf
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_blog, website_forum, website_hr_recruitment, website_sale,
website_slides
The goal of this commit is to set the missing 'view_ids' on some
actions linked to website 'pages' tree/kanban views.
Linking a form view to actions will make the 'Edit' & 'Configuration'
buttons work correctly (on kanban record dropdown for 'hr.job' &
'slide.channel').
The website url on "product pages" kanban should start on a new line
after this commit too.
Related to task-2889981
closesodoo/odoo#101814
X-original-commit: a61e730cd9f92b2c343646f33f3e59cef518c3bf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_hr_recruitment
After [1], the multi-edit was added on the pages list views not using it
except 'hr.job' records since editing the 'Department' field leads to a
traceback.
The goal of this commit is to fix this issue by setting an invisible
'company_id' (to be available in domains since necessary to change
'Department') and add multi-edit on the view.
The 'home' icon for 'home page' records on list view should be hidden
after this commit (on multi edit mode) to edit the fields correctly.
[1]: https://github.com/odoo/odoo/commit/be58687284884550cc4e6c2ac7255abee4eb1125
Related to task-2889981
X-original-commit: d101be46a2a9c392e2d63f491fcc5ccec2d65c78
Part-of: odoo/odoo#101814
Before this commit, the WebsitePreview document title was not completely
replaced with the iframe's one: it was still prefixed by 'Odoo - ' by
the title service.
Now, the WebsitePreview, introduced in [1], is adapted to remove the
'zopenerp' part when replacing the title (and adding it again when
unmounted). While doing this, the backend's favicon is also changed with
the frontend's one, to be consistent with displaying the frontend
document title only.
This commit also adds an effect on the Optimize SEO dialog, so that the
document title matches the user's input.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#101972
X-original-commit: 52ec7d1279144b9cd38f8444648b8246df694b9c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
Before this commit, for the following flow:
- Add arabic language (or any other rtl language),
- On one of the websites, set it as the only website's language,
- Reload and go to the client action,
=> The frontend is correctly displayed in rtl,
- Click on edit,
=> The frontend, in the iframe, is reverted to ltr,
The WysiwygAdapter, introduced in [1], was not passing the correct
direction option to the OdooEditor, which would revert the editable to
the default 'ltr' direction.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
X-original-commit: 2f463ca65b149122c85a04b20b4f82e0be479fc8
Part-of: odoo/odoo#101972
Before this commit, the Editor Menu was confusing when opened for a
translatable website: it would list the menus in the user's language,
not in the displayed website's language.
First, this commit shows that menu only for websites in their default
language, as the user should edit his website structure in the default
language.
Secondly, the 'get_tree' and 'save' requests on the website menus are
done with the website's language, not the user's language.
This commit also fixes a bug introduced with [1]: the website override
of the start method of the SnippetsMenu was incorrectly done.
In translate mode, it should not activate snippets on clicks, otherwise,
the LinkPopover was instantiated when clicking on navbar menus, allowing
to edit the menus from the translate mode, and breaking it.
[1]: https://github.com/odoo/odoo/commit/df1869153a90898bad3e0b61e5fc43a9ed3d59c9
task-2687506
X-original-commit: 4266966a9b0fa452b5991d9bea0fe914aca85f4d
Part-of: odoo/odoo#101972
This commit fixes 2 issues with the position of the dropdown with the
suggested links in the url picker input of the snippet options. (e.g.
redirect url input of the countdown snippet) and the one for the input
of the link editor.
1- Before this commit the dropdown went over the input while editing the
url.
2- Before this commit the position of the dropdown (when above the
input) was a little too low if there were images in the dropdown. It was
because the images are loaded after the positioning of the dropdown and
no height was defined for these images.
task-2900529
closesodoo/odoo#101815
X-original-commit: 774a42ff18651a20b09a5e34222665216b19c8ec
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The cookies bar default templates are designed in order to guide the
user towards selecting the option that will provide the best user
experience.
This raises security concerns (see discussion in PR for details).
This commit adapts the buttons of the default cookies bar templates so
that both options are shown with the same style, forcing the user to
take a decision.
task-2800976
closesodoo/odoo#101845
X-original-commit: 32d88f47a67679b7e90fa58e25089846484b48ca
Signed-off-by: Romain Derie (rde) <rde@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>
Prior to this commit, the WysiwygAdapter would crash with a TB if an
event reached the wysiwyg_adapter when the websiteRootInstance was no
longer accessible (in case of a PageReload while an event in the mutex
is still trying to fire events).
Note that normally, events should not be sent when the
websiteRootInstance is gone as the editor should be destroyed. But
since "widgets_start_request" triggers also implement a "onFailure", it
seems right to use that in such case.
closesodoo/odoo#101687
X-original-commit: 0cc206f94151e2da646064e265e14a341daff58a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Use system fonts for backend and web-editor's UI.
This commit removes references to proprietary fonts and allows the OS
to use the system ones. The aim is to reduce http request and the
general footprint (see enterprise counter-part).
The new font-stack:
- apple-system (San Francisco): iOS Safari, macOS Safari, macOS Firefox
- BlinkMacSystemFont (San Francisco): macOS Chrome
- Segoe UI: Windows
- Roboto: Android, Chrome OS
- Helvetica Neue: old OSX versions
- Ubuntu: Ubuntu
- Liberation Sans: Linux (others)
- Arial: Any
- sans-serif: General fallback
This was actually already introduced for the website default theme and
as a general option with [1] but it was not complete: if reaching the
need to use Roboto of the font stack, the repo Roboto was used instead
of the potential system one. It was not shown during testing with the
previous font stack. With the new one, on Ubuntu, it was revealed as
the Ubuntu font comes after Roboto.
[1]: https://github.com/odoo/odoo/commit/c0f2f670eb087991cc9a6a67f4beea5f12bd15f2
task-2995248
closesodoo/odoo#101533
X-original-commit: 9f8f8f2ef88aee746819469c918b2d31ec29d031
Related: odoo/enterprise#31985
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
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>
