Steps to reproduce the bug:
- In Website edit mode, drag and drop an "Images Wall" snippet onto the
page.
- Click on the first image of this snippet.
- In the "Animation" options of the image, select "On Hover".
- Save the page.
- Click on the first image of the "Images Wall" snippet.
- Bug: The image in the slideshow still has the overlay that appeared
due to the hover effect.
This commit fixes this issue by resetting images to their original
source in the slideshow.
task-3562305
closesodoo/odoo#139695
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Prior to this commit, the button with the search icon, inside the search
bar, was `primary, which is not consistent with the filters that are
`light`.
Part-of: odoo/odoo#137729
Prior to this commit, when you removed a social link in the header,
there was an error.
This is because `website.header_social_links_no_color` targets selectors
that do not exist in this situation.
task-3572219
closesodoo/odoo#139883
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website, web_editor, website_sale
The goal of this commit is to replace all Dialog in the Website Editor
flow with OWL Dialog. This uses the new `bindService` and `call` methods
available on legacy widgets. The replacements mainly use the
ConfirmationDialog component, but some had to have custom-made dialogs.
closesodoo/odoo#138947
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
This code was use in 14.0 to allow users to edit the Company Information
visible on the /contactus page. It is no longer needed as the page is
now fully editable and the t-field has been replaced with static text.
Part-of: odoo/odoo#138947
In this commit, we will remove "closestScrollable", "compensateScrollbar"
and the last usage of "scrollFixedOffset" outside of dom.js.
closesodoo/odoo#140181
Part-of-task: 3439226
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
-> This commit add/change the name of the page corresponding to the string
attribute because To be able to detect a field, Knowledge needs to be able to
read its page name.
For more reference: Task-3501211
Task-3524474
closesodoo/odoo#137428
Related: odoo/enterprise#48315
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit introduces some adjustments to the dark mode color scheme
and the use of bootstrap classes in Community.
- Mini calendar contrast -
The colors were not using variables, making them non dynamic
and breaking the contrast in dark mode.
- Avoid !important rules spreadsheet -
Prior to this commit, spreadsheet top bar was using a `bg-white` class,
making it pure black in dark mode.
Since spreadsheet is designed with light colors and we don't provide a
dark mode for it, we remove that class and set a `background-color`
property using CSS in Enterprise.
- Input color -
This commit fixes the focus behavior on the searchbar in the control
panel, the `command_palette_search`, and the `start a conversation` in
discuss.
- Copy clipboard field border color -
Make use of the `text-primary` color for the copy to clipboard field
We use the o-theme-color function to avoid an undefined since primary
doesn't exist in the o-theme-text-color map in white mode.
- Web_editor toolbar variables -
The toolbar was using the `o-brand-primary` variable
which was set to a darker shade. This caused issue when activating an
option due to how vibrant the color is.
- Improve the controls on border-color -
Introducing a custom property on the border-color to allow
further control on individual components (such as the popover).
- Improve setting tabs colors use -
Prior to this commit, the colors of the settings tabs menu were kinda
inverted. The menu was light in dark mode and dark in light mode.
We fix this by changing the values associated to the CSS variables in
use.
- Make model field selector dark mode proof -
Fixing the design of the model field selector popover in both
light and dark mode. Since the popover was using custom style with
arbitrary values, it was not designed for the dark mode and had a lack
of consistency.
To improve the design, we use variables rather than custom style, and
make sure the desired render is as close as before.
- Sign colors use -
This commit aims to improve the sign module in both light and dark mode.
There were some readability issue with some `btn-light` having poor
contrasts in both light and dark mode, and the use of some classes was a
bit unexpected (e.g `card-header` to set a grey background with some
padding).
- Improve buttons design inside listview -
Prior to this commit, this button was using custom CSS to make it look
like a primary button, while it was using classes related to secondary
buttons.
We remove the custom CSS used to style it correctly and keep our button
design consistent.
- Messaging menu layout in mail -
This commit aims to improve the design of the notifications displayed
in the messaging menu. Prior to this commit, the notifications dropdown
was using custom CSS variables overriding the regular behavior
of our dropdowns.
In fact, the layout was generating some friction:
1) Marking a notification as read would turn its background into a
darker color
2) Effects like `:hover` were all based on the custom CSS variables
resulting in an inconsistent layout.
- Multi company selector adaptations -
In darkmode the multi company selection was using the btn-light which
creates a weird effect and overrides the dropdown default hover behavior
This commit uses the btn-link to display an hover effect on the
company switch and on the checkbox while blending with the background
and the default dropdown hover effect.
- Adapts default badge design -
Improve the design of the default badges in dark mode.
If you open the light mode, these badges are dark grey with a white
text. If you switch to dark mode, they are dark grey but with a dark
text, which makes them look either muted or off.
We make use of SCSS variables to handle the color of the component,
providing a good styling in both modes.
- Fix kanban cards borders inside dropdown -
Fixes the issue with the divider inside the kanban dropdown menu not
showing in dark mode.
To ensure it is visible, we assign it the `$dropdown-divider-bg`, which
is the color it should use, as the horizontal divider above uses.
- Fix tour pointer design for dark mode -
This commit aims to insert the tour pointer and its content inside the
styling we applied to our tooltip.
To do so, we make sure it uses CSS variables, allowing more control and
consistency, plus we replicate the overall look of our tooltips.
- Fix `text-primary` on action background contrast -
This commit improves the readability of our `text-primary` classes when
it's used on a `$o-component-active-bg` background.
Prior to this commit, the `text-primary` was not meeting the contrast
standard, mainly when you were using the `CMD+K` shortcut on the
app switcher.
To prevent that, we changed the background to a `$o-component-active-bg`
background with an opacity ensuring our text provides a good contrast.
- Fix input states -
Prior to this commit, the `--o-input-border-color` CSS variable was
using the `$o-form-lightsecondary` variable to define the standard color
of the `border-bottom` property of our inputs.
This was conflicting since `$o-form-light-secondary` is also used to
define the `background-color` of our table on focus.
With this commit, we separate these two element with different variables
to make sure they don't affect each others.
- Fix kanban ghost background -
Before this commit, if you created a project without any stage or element
in it, the ghost cards that act like placeholders would be pure `#000` in
dark mode, due to the `bg-white` class.
This commit replaces that class with a `bg-light`, providing a better
visual result in both light and dark mode.
- Fix new message design -
Improve the design of the new message element while
inside Discuss, using our danger color, ensuring a good visual result in
both modes.
task-3201038
closesodoo/odoo#139966
Related: odoo/enterprise#49666
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: chgo-odoo <chgo@odoo.com>
Co-authored-by: stefanorigano <sri@odoo.com>
Steps:
- In website, click on a link to edit it
- Type "/" in the LinkTools URL input field
- Pick a URL among the suggested ones
The chosen URL was supposed to be applied to the link, but it is not.
The same applies for the LinkDialog (create a link with the "/link"
command).
Reason:
It might be a little confusing, but the `_onURLInput` method actually
means "update UI according to the URL" (more specifically, display/hide
the "Open In New Window" and "Autoconvert To Relative Link" buttons).
The `__onURLInput` (two underscores) method, on the other hand, is the
actual handler for input events in the URL field. In this case, picking
a URL from a drop-down menu needs the same treatment as inputting text,
that is, the `state.url` property must be set to the new value.
task-3552700
closesodoo/odoo#140061
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit fixes two bugs with the sidebar header.
Steps to reproduce the 1st bug:
- Go to "/shop" and edit the page.
- Click on the header.
- Open the header selector.
- Choose the "sidebar header".
- Bug: infinite loader (or traceback from V16).
Steps to reproduce the 2nd bug:
- Go to "/contactus" and edit the page.
- Click on the header.
- Change the "Header Position" option to "over the content".
- Save the page.
- Go to the homepage and edit the page.
- Click on the header.
- Open the header selector.
- Choose the "sidebar header".
- Save the page.
- Go to /contactus.
- Bug: the "sidebar" header is broken on the "/contactus" page.
The first bug was caused by triggering the deactivation of the "Overlay"
header from a location other than a website.page (in this case, the
"/shop" page in the steps to reproduce). In this place, the "Overlay"
header option isn't available.
However, while trying to fix this, we noticed the second bug => When we
activate the "sidebar" header (which is a general option for all pages),
we were deactivating the "Overlay" header only on the current page (this
option is specific to the page). It was done since this commit [1].
This doesn't make sense because the "Overlay" header should be
deactivated on all pages, not just the current one.
To address this in the simplest way, we modified the CSS so that the
"Overlay" header doesn't have an impact when the sidebar header is
activated. Without this change, we would have needed to add an RPC to
remove the "Overlay" header on all pages, which wouldn't have been worth
it.
[1]: https://github.com/odoo/odoo/commit/618fd49642310c7b97ef3b9e6c01f8f691c7b12f
task-3454161
closesodoo/odoo#139955
X-original-commit: b27279492fea98f2cd6bfba962bfd570e464d361
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Currently creating a record with 'is_published' being False (aka not published)
crashes when people can't publish. However 'is_published' being False is the
default value, and create should work in both cases.
It now correctly checks that published records could effectively be published.
This allows to remove a small workaround done in eLearning.
See odoo/odoo@4086f344d8 for ref.
Only failing use case would be having
def _default_is_published(self):
return True
def _compute_can_publish(self):
for record in self:
record.can_publish = self.env.user.has_group('something')
But this would not be a really valid use case: not being able to publish
but having default publish to True makes no sense: what matters is publishing
records as it gives more visibility to records, not the flag change itself.
Followup of odoo/odoo#70291
Task-3299702
closesodoo/odoo#137900
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously proposed formating was trying to normalize extra in one part
of the path. This means that no extra needed a placeholder.
The implementation was meant to be more generic and extendible since a
part of the logic has to be in website.
A suggestion was made to make it more restricted but explicite by
keeping the url simple in web/controllers/binary.py but adding a
controller in website to add this extra part.
The base extra direction is now in the extension, as the min part.
Initial urls:
/web/assets/{unique}/[{website_id}/][rtl/]{bundle_name}[.min].{extension}
New urls:
/web/assets/[{website_id}]/{unique}/{bundle_name}[.rtl][.min].{extension}
Managed by two routes:
/web/assets/<string:unique>/<string:filename>
/web/assets/<int:website_id>/<string:unique>/<string:filename>
Where filename is in the format {bundle_name}[.rtl][.min].{extension}
Multiple possibilities where proposed
- /web/assets/website/<int:website_id>/<string:unique>/<string:filename>
More explicit but prefixing by /website was considered
- /website/assets/<int:website_id>/<string:unique>/<string:filename>
This one is a litle painfull to match similar attachement, where
website is ignored.
- /website/<int:website_id>/assets/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
- /web/assets/<int:website_id>/<string:unique>/<string:filename>
Almost accepted but subjective, and anyway two previous solution breaks
the cdn mecanism and would need a migration
This last solution was not ideal to match without unique
/web/assets/%/<string:filename> can match both
/web/assets/123456/<string:filename>
and
/web/assets/1/123456/<string:filename>
Anyway, matching without unique shouldn't be supported for al (even if
it is kind of supported with any right now) but it will work by changing
unique wildcard to a more specific one (_ * 7)
closesodoo/odoo#131353
Related: odoo/enterprise#47313
Related: odoo/design-themes#730
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The generation inside the rendering has some drawbacks:
- `commit_assetsbundle` is needed for reports rendering because the
template rendering may generate some assets that will be accessed by
another transaction before the transaction is committed. But this
solution is not ideal since the transaction is committed in the middle
of the request
- when the first rendered page is a 404, the assets are not committed
and the page is broken.
- when starting, deleting an attachment can create a concurrent update
error and the request is retried. This will occur once per attachment
and for all worker trying to access the same resource. The whole
transaction is rollbacked, even the previously created assets bundle.
- The cold page load is a slower since there is more work to do.
- Implementing a readonly request is difficult because it could be
transformed to read write and re-executed if the assets bundle does not
exist.
Generating assets when needed solves those issues. The concurrency
when deleting an assets could still occur but only once per bundle, and
in a smaller transaction. This could be solved with a lock now that we
have more control on the transaction. The commit_assetsbundle can be
removed and 404 page should have a correct layout. The cold page load
could be a little faster because the assets bundle can be generated in
parallel requests instead of sequentially when rendering the page.
Part-of: odoo/odoo#131353
The main motivation is to be able to generate assets bundle outside
the t-call-assets call.
The need of an id in the url makes it mandatory to have an attachment
when adding the url in the page. Without this restriction, we can guess
the url without generating the assets.
This can also have other useful side effect:
There are corner case when a worked could have an invalid url in
cache because, if the transaction is rollbacked or if another request
generates the same attachment at the same time. This should be
partially solved by removing the id: The url remains valid even if the
attachment does not exist.
Note that the extra part of the url was made explicit, always there and
taking one / to remove complexity and ambiguity.
Note that an additional query appeared in .test_50_perf_sql_web_assets
because of the search, this but two of them were in _find_record. One of
them was an `exist`, not making much sense since we are not getting the
id from the attachment url anymore but from a search, and the other one
was prefetch of the "public field" since the call to _find_record does
not go in other cases (xmlid, website published, access token, ....). A
attachment of a asset is always public, and this part of the security
was moved to the search domain. The final result is one less query:
- one query to search
- one query to read the fields (_get_stream_from) (the prefetch could
actually be set to avoid prefetching everything)
Part-of: odoo/odoo#131353
Since [1], `qweb.render` was replaced in all Odoo by `renderToElement`
and `renderToFragment`. However, in the case of the template
`website.delete_google_font_btn`, if the font is served from Google, the
template contains multiple root elements, which means it should be
rendered by `renderToFragment`. This commit fixes that.
Steps to reproduce:
- Install Website.
- Go to website and start edit mode.
- Go to theme menu and open the "Font Family" menu.
- Click on Add custom font.
- Add a Google font (e.g. https://fonts.google.com/specimen/Tilt+Neon).
- Make sure serve from Google is selected.
- Try to open the theme menu again.
=> Traceback
[1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b
task-3557794
closesodoo/odoo#138927
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
This commit implements a way to expose any model publicly on the website. Both manual and
existing models can create such pages called 'Model Pages'.
A manual model is a model that has been created by the user at runtime, via the technical menu,
via studio, or with an xml declaration.
The main interface to easily create such page is in Studio, in the tab Website Integration. But a
partner or developer could easily import those without studio installed. That's the reason most of
the code to handle the display of such pages is present in the website module directly.
The listing can handle two display modes (Grid or List). Once the user changes the display mode,
the latest value is set in the session to be remembered for the next visit of the page.
A default_layout can be set and is customizable in the website editor or from the backend of Website.
This value is linked to the page to display, so each listing page can use a different layout by default.
The route on which the models are exposed is:
"/model/<string:page_name_slugified>",
With the derived routes:
"/model/<string:page_name_slugified>/page/<int:page_number>",
"/model/<string:page_name_slugified>/<string:record_slug>"
task-id-3231144
Part-of: odoo/odoo#130544
Co-authored-by: Florent Dardenne (dafl) <dafl@odoo.com>
Co-authored-by: Luca Vitali (luvi) <luvi@odoo.com>
This commits add a signature to the website_form.
The purpose of this modification is to allow the controllers to be
able to verify that the form was originally generated from the view.
This prevent the end user to submit arbitrary values to the website_form
controller.
In this commit, email_cc and email_bcc are treated as the same fied as
it holds the same function
This does not offer protection against submission replay. Previous versions
of the form are not invalidated by editing the view.
If one need to completely reset that protection and invalidate the
previously generated website_form, the only solution is currently to
change the database secret.
closesodoo/odoo#139701
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
This commit removes the promise extension which added the function
`guardedCatch`. It was used to filter server and connection errors from
javascript errors. Instead of using guardedCatch, we should use catch
and check if the reason is a server or connection error if needed and
re-throw the error if it's not handled.
closesodoo/odoo#137702
Task: 3439226
Related: odoo/enterprise#48451
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The goal of this commit is to replace the "Toggle underline" option
from the website's text editor by a new "Highlight effects" option which
should allow applying some highlights on the selected text and setting
their color & thickness. Also, the text editor "Toggle strikethrough"
option will be moved to the list of highlight effects in the new option.
For this purpose, the JS code used for text animations will be updated
to be more generic and handle text highlights too. Moreover, The "Text
Highlight" options will be applied by adding a SVG to the targeted text
element (allowing to adjust their `stroke` and `stroke-width`).
To simplify adapting highlights when the text content is updated,
we follow this generic structure:
```
<span class="o_text_highlight">
<span class="o_text_highlight_item">
line1-textNode1 [line1-textNode2,...]
<svg.../>
</span>
[<br/>]
<span class="o_text_highlight_item">
line2-textNode1 [line2-textNode2,...]
<svg.../>
</span>
...
</span>
```
Rendered line breaks in text nodes are detected using range client
rectangles (see: `text_processing.js` > `splitNodeLines()`), and the
highlights are updated on window resize...
We also need to adjust highlight SVGs to fit an updated text in "edit
mode" (mainly using editor's commands), a `MutationObserver` is used
for this purpose (we only redraw the SVG for each text unit).
A simple SVG path generator was implemented in this commit (see:
`text_processing.js` > `drawPath()`) to build highlights. It applies a
list of SVG path commands according to text dimensions in a specific
mode (E.g. on "pattern" mode, we repeat the same elementary path to fit
targeted text node...).
Remarks:
- The `--text-highlight-width` and `--text-highlight-color` properties
are used to control the highlight effect's thickness and color.
- We build the highlight option preview in the same way as text content.
To achieve this, a hack was used (we open the `<we-select/>` first since
we need the right `getBoundingClientRect()` dimensions to correctly draw
highlight SVGs).
task-3285817 (rd-website)
task-3269759 (rd-design)
closesodoo/odoo#122751
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Chrysanthe (chgo) <chgo@odoo.com>
*: web_editor, portal
This adds a button to add language in theme tab. When clicked, opens
the "add a language" wizard.
If the website has only one language, the options to enable language
in header & footer are hidden.
When an user add a language, the default behavior is Header: dropdown
& Footer: inline.
Also provides two more rendering options : Language Code and Flag +
Language Code.
task-3457554
closesodoo/odoo#119650
Related: odoo/design-themes#651
Related: odoo/upgrade#5214
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
When we set a border on a header, its 4 sides are affected. For most
templates, it doesn't make sense to have borders on the top, left and
right sides.
This commit applies a border-bottom-only style by default to headers,
and adds two classes `.o_full_border` and `.o_border_right_only` to
override the default behavior. As their names imply, they respectively
apply borders on the 4 sides or on the right side only.
task-3474743
Part-of: odoo/odoo#119650
Currently, the template headers all have the same default behavior, you
cannot define different default behaviors for header A and header B
(e.g. have header A appear over the content and header B fixed).
This commit allows to specify other behaviors than the default ones for
each header template. It should be noted that, as it currently stands,
most options trigger a reload of the page, which prevents simpler
solutions like using `data-trigger` attributes to tie some options to
the header selection.
Specifically, this commit:
- defines a header visibility for each header with `data-trigger`. This
is actually the only option of the 3 concerned by this commit that could
be handled that way, for the aforementioned reasons. Only the visibility
of the `header_rounded_box` template is actually modified, but to allow
switching back and forth between the different templates and still have
the intended Odoo experience, a trigger is specified for each header
choice (the other ones having the default visibility).
- applies the "pills" link style for the `header_rounded_box` template
and introduces a `customizeWebsiteVariables` public method to do so.
This method, called through the `data-customize-website-variables`
attribute, allows to specify additional variables that should be
modified by selecting the option. It is as of now only used in that
specific case, but could be used with a number of other options which
are defined in a similar way, such as the scroll effect, alignment,
font, logo height...
- uses the default link style to apply it to each template by default
through the use of `data-default-variables`. This is needed (1) to make
sure that the `header_stretch` template can never have another style
than the default one, as the option is hidden when it is selected, and
(2) to go back to the default behavior when switching between headers.
Both `data-customize-website-variables` and `data-default-variables` use
the same syntax: a list of `variable: value` separated by a comma.
e.g. `header-links-style: pills, header-scroll-effect: fixed`
- removes the "Round corners" option field and border-radius for headers
sales_one, sales_two, sales_three and sales_four, because the option
does not play well with their layouts.
task-3474743
Part-of: odoo/odoo#119650
Following the redesign of website template headers, this commit
introduces a new class `.o_header_hide_on_scroll` to hide some part of
the header when scrolling.
task-3474743
Part-of: odoo/odoo#119650
Following the redesign of website template headers, this commit applies
a few fixes and modifications to the behavior:
- It separates some elements' options into their own option sections:
brand logo, language picker, searchbar.
- It disables interactive elements in the header (search modal, language
dropdown, logout button) while in edit mode.
- It solves the following bugs introduced by the headers redesign:
- Displaying the language selector with an inline style and flags
only is working.
- Social links are now unmovable and unremovable (other than by
clicking on the "Show/hide social links" expressly made for it), as
their place in the templates is fixed, as allowing the snippet to be
moved caused several tracebacks, and as removing it through the
options and trying to show it again caused a server error.
- The CTA button is made unremovable (other than clicking on the
"show/hide button" expressly made for it) for the same reasons.
- It was possible to write in spaces where it shouldn't have been
(search icon, mobile menu closing icon): they are made not editable.
task-3474743
Part-of: odoo/odoo#119650
Prior to this commit, the dropdown of the search bar which was displayed
in a navbar had a static position when the viewport was below lg.
This dropdown pushed the navigation down instead of being in front of
it, creating a layout issue in the offcanvas menu.
To fix this, this commit forces the `dropdown_menu` of the search bar to
be in absolute position.
task-3060986
Part-of: odoo/odoo#119650
Prior to this commit the id used for the main navigation wasn't
descriptive enough.
This commit fixes this issue.
task-3060986
Part-of: odoo/odoo#119650
Prior to this commit, dropdown menus floated in offcanvas menus. This
can create an UX issue on mobile when you want to click/tap on a
link that is behind the open dropdown menu.
To fix that, this commit removes the floating style and lets the
dropdown menu extend below the parent button.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
This commit allows the user to show and hide the menu items they want
using the web editor.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
This commit removes the following templates:
- template_header_image
- template_header_hamburger_full
- template_header_magazine
New templates were added by previous commits. Those old 3 do not have
an equivalent anymore and are simply removed.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "sales_three" header will however
be the closest one to the "contact". A related upgrade script will be
made to treat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "sales_two" header will however be
the closest one to the "slogan". A related upgrade script will be made
to treat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
*: website_sale, website_sale_wishlist
The new header is quite different from the old one, the xml_id of
the header will thus change. That new "search" header will however be
the closest one to the "centered_logo". A related upgrade script will be
made to threat this as a simple xml_id renaming.
task-3060986
Part-of: odoo/odoo#119650
Louis (wil)