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>
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
-> 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 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>
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 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
This commit fixes the structures of some existing elements (language
selector, etc) and introduces new ones which will be possible to toggle
in each new header templates in following commits.
Note: the fixes may need to be backported in the future somehow.
Note 2: after this commit, some of those elements can appear broken.
This is because they are meant to be used in the new headers templates
in following commits.
task-3060986
Part-of: odoo/odoo#119650
Co-authored-by: Robin Lejeune (role) <role@odoo.com>
*: website_sale, website_sale_wishlist
This commit adds a new header template displayed on mobile screens.
It also introduces the Mobile Alignment feature, allowing the user to
adapt the Navbar alignment to mobile screens. It will replace the
previous "off-canvas" feature also available on desktop. This commit
removes that old feature but the new mobile menu will only be enabled
in each template in next commits.
task-3060986
Part-of: odoo/odoo#119650
*: website_livechat, website_sale, website_sale_wishlist
This commit adapts some templates and tests JS to prepare for the new
headers in the next commits.
task-3060986
Part-of: odoo/odoo#119650
Previous commit(s) did improve the preview of snippets when dragged and
dropped but also the `t-snippet-call` capability of some snippets.
Part of that improvement was to add snippet `onBuilt` JS output in the
snippet XML definition directly.
For google and facebook snippets, it means firing a request to those
websites when entering edit mode.
It's not that bad (considering the trade-off of the preview and
t-snippet-call), but will need to be re-discussed later post freeze to
find a better way to not fire those requests ideally when the snippet
is called in the right panel (but would need the preview to still work).
For the meantime, this request seems to be making a test fail
(`test_01_menu_hierarchies`) due to the gmap API call being returned
after the test has been marked as successful.
Before investigating further, this commit just prevent the iframe to
show up when in test mode so we can merge this work which is needed for
tomorrow freeze.
closesodoo/odoo#138748
Related: odoo/design-themes#726
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, some snippets did not have any or complete preview
when dragging them over a dropzone.
This commit covers `s_website_form`, `s_countdown`, `s_map` and
`o_facebook_page`.
Some elements with class `s_preview` are added to the template. These
elements are removed when the snippet is dropped.
Also, the class o_colored_level was added to snippets so that the
previews matches the snippet dropped.
For "New page templates", an `s_keep_preview` class can be added on a
parent element of an `s_preview` to prevent its removal when creating
the page - thereby making the snippet ready as if is had been dropped
into the page.
Note: `s_chart` and the "dynamic snippet" and its variants are not
covered in this commit.
task-3555325 (was task-2431469)
Part-of: odoo/odoo#138748
Co-authored-by: Benoit Socias <bso@odoo.com>
In [1] when the "New page from template" feature was added,
`background-image: none` was removed from many blocks to avoid having to
handle it when adding an image.
That situation actually never arised, making those removals useless.
This commit removes those attribute removals.
The only impact this has it that it fixes the `s_call_to_action` styles
in `theme_notes` by restoring their images. The `<attribute remove=...>`
actually did separately remove `background-image` and `none`, corrupting
the exiting style.
[1]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7
task-3555325
Part-of: odoo/odoo#138748
Before this commit, the "Table of Content" snippet only got its
navigation part rendered once the block was dropped.
In [1] when the "New page from template" feature was introduced, a
default pre-rendered content was introduced so that the "Table of
Content" snippet was properly rendered in the template previews where it
was used.
This commit moves this pre-rendered content from [1] into the base
definition of the snippet itself.
There is no collision problem regarding the default ids that are
included because the dynamic content is re-generated when the block is
dropped and whenever the headers texts are changed.
[1]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7#diff-bee4662b672e30dbfb9778f8747fee45698d9b8d16282d8f80066d8a30137928R35-R50
task-3555325
Part-of: odoo/odoo#138748
*: mass_mailing
This commit introduces options for the flex column layout and the
horizontal resizing to be used on mobile and be independent from
the desktop layout.
This makes it possible to:
- Have different number of columns on mobile and on desktop.
- Use different column widths and offsets for mobile and desktop.
- Reorder columns independently.
The behavior expected from the columns is:
- In the editor panel, Cols indicate the number of columns per row on
both mobile and desktop. The option is conditional of your environment:
you edit the number for the screen size of your current resolution.
- When columns have different sizes (either because it is the default
behavior of the snippet, or because the user resized some), the counter
should read "Custom". Same when the user changed some offsets.
- If manual modifications were made on width and offset, they are reset
on the current display if the number of elements is updated. This was
decided because an old, specific layout with custom offsets / width
doesn't work well with a different number of elements. (This is also the
default behavior before this PR with desktop-only modifications.)
The expected behavior when reordering is:
- On mobile, it should only affect the mobile layout.
- On desktop, it should affect both layouts.
In order to have a coherent feature on both mobile and desktop as well
as correct some non-ideal but non-blocking behaviors, the commit also
changes the following behaviors:
- When setting a columns count lower than the current number of items in
the `.row` container, extra items are now wrapped on the next flex-rows
(still within the container) instead of being deleted.
- When going from e.g. 3 to 5 columns (and as many items), the change
happens all at once instead of each item being visibly added one by one
on the next row, then brought back to the first row.
- The columns count automatically updates when resizing an item, instead
of updating only after you click somewhere else on the snippet.
This commit also adds a test to validate the new behavior.
task-3097045
closesodoo/odoo#117562
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_event, website_forum, website_livechat, website_mass_mailing,
website_slides
This commit permits to reduce the risk to have a wrong h1 tag or
multiple h1 tags on the same page. This commit replaces some h1 tags
with a h2 in snippets. In addition, this commit removes some font sizes
written in the style attribute and replaces them with a font size class
now that they are possible to use and edit as an user.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: web_editor, mass_mailing
This commit changes the way the font size selector works. Before this
commit, the font size selector applied a hardcoded font size using the
style attribute of the selected element. The purpose of this commit is
to change this to apply a class on the selected element, making it
responsive and customizable.
In all Odoo applications, the font size selector will now apply a class
on the current selection. An exception is made for mass mailing where
the class would not make much sense as not related to the custom heading
sizes (probably needs to be refactored in the future to use the standard
font-size classes) and fonts cannot be responsive in mails anyway (so
there would be a difference between preview and sent mail).
Those classes are:
- `display-N-fs` with N in [1 => 4]. The sizes are stored in the
`$display-font-sizes` map.
- `hN-fs` with N in [1 => 6]. The sizes are stored in the
`$hN-font-size` variables.
- `small` for the small font size. The size is stored in the
`$small-font-size` variable.
The font size selector shows the value of the class (which is dynamic)
that will be applied.
In the website application, the value of each class is configurable
thanks to a previous commit. The user can choose the size of each font
size class in the website settings.
Note that many alternatives were considered for this feature, this is
the chosen compromise. For the record, here is a very short summary of
the alternatives:
- Doing nothing: voted as the worse idea. Users see a font-size selector
they will use it one way or another. The font-size won't be
responsive, breaking their mobile website. And there are real use
cases you could not do: a big "promotion" paragraph on your product
page? Not possible: you either break your mobile page (using the font
size option) or possibly hurt your SEO (using the font-style option
and turning your paragraph into an h1).
- Removing the font-size selector: we did not want the loss of the
feature as there are correct usecases to use it (as mentioned above).
- Using the Bootstrap hN and display-N classes instead of making new
ones. Closed to be the chosen idea but discarded because those classes
comes with colors (that the user can configure) and it would feel
weird to have the color change when changing the font-size. Also, in
the end, we also did not want the line-height, margins, etc of those
classes (only the font-size).
- Instead of X new classes, have only one: o-fs, which would be applied
alongside a bootstrap hN or display-N class, when chosen by the user,
to cancel the unwanted style of those. It works but it forces us to
always have an added `<span>` to apply the font-size, which we don't
want in the future (mainly because of display-N classes, see next
commit). It is actually very needed to be able to use proper
line-height when reducing the font.
- Using a combination of an inline `em` font-size + a class to clamp it
on mobile. Was probably the best next idea but rejected for several
reasons. The main one probably being the inconsistency when changing
the whole size of a title/paragraph (not part of it) and later
changing the related theme size later. E.g. have an `<h1>` followed by
a `<p>`. The h1 is 40px, the paragraph is 20px. Force the title to
20px, because you want it smaller, same size as the paragraph. Real
use case but also users could simply use the font-size controls by
mistake. We would thus apply 0.5em to do that. Later, change the theme
font-size of h1 to 36px (small change). The 0.5em one is now 18px,
smaller than the following paragraph. Preventing that would require
more checks which would "break" other things / possibilities.
- Probably others that were forgotten.
In the end, there was no good or bad answer. "Anything works", as long
as the feature "I want this text smaller/bigger" is there. The
surrounding features are always compromise (some users would expect some
behavior, some users would expect others). This commit focused on
solving the unresponsiveness of those custom font-sizes, which was a
problem for many users.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit adds a set of new options in the theme tab to allow the user
to customize the style of the display-N classes. He can now choose the
font family, the font size, the line height and the margins top/bottom
for the display-N classes (1 to 4). Note that we will not use display-5
and display-6. A further commit will allow the user to use those classes
in their content via the editor UI.
task-1958098
Part-of: odoo/odoo#129791
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit introduces 3 new inner snippets: button, image and video.
What sets these snippets apart is that, once dropped onto the page, they
transform into basic HTML code, just like if they were created using the
editor (no data-snippet etc).
task-3248881
closesodoo/odoo#126717
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: bvr-odoo <bvr@odoo.com>
In commit [1], the Banner snippet has been redesigned in order to be
in grid mode by default, to highlight some cool features of the editor.
However, some grid classes and attributes are missing or not well set:
- the first column has a `g-height-4` class despite having 8 rows: this
causes the vertical resize to not work correctly.
- the row does not have the `data-row-count` attribute, which is needed
to display the background grid correctly.
This commit fixes this by replacing the class by `g-height-8` and adding
the `data-row-count` attribute, which is set to 11 rows.
[1]: https://github.com/odoo/odoo/commit/3cbdf754ff8fac8a77887c4307b658cb86b0be1d
task-3369695
closesodoo/odoo#136683
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, toggling the "Text Cover" snippet to grid mode did
not produce a good-looking result: the column containing the background
image loses all its padding and therefore appears smaller and shifted
compared to the normal mode.
This commit adds a background color to the image column. Indeed, with a
background color, and more precisely thanks to the `o_cc` class, the
padding is taken into account when computing the grid items size, making
them look similar to how they were in normal mode.
task-3369695
Part-of: odoo/odoo#136683
The `display: grid` property allows to modify the spacing (or gaps)
between the rows and columns of the grid with the `row-gap` and `column-
gap` CSS properties. When the grid mode was added with [1], these
properties were deliberately ignored and the gaps were forced to 0px.
This commit adds the "Spacing (Y, X)" option that allows to modify these
grid gaps. A grid preview is also added when using this option, in order
to visualize what is being changed in the grid.
[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
task-3369695
Part-of: odoo/odoo#136683
This commit modifies the "New Page" dialog so that it displays a list
of page templates to pick from in addition to the possibility to create
a blank page.
task-3381714
Part-of: odoo/odoo#126719
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
This commit is a preparation for the new page from template feature.
In order to make it possible for new page templates to be customizable
at several levels from themes, it was decided to create several layers
of primary templates.
Those templates are build from the descriptions found in manifest files
under the new `new_page_templates` key.
The same principle is also applied for configurator pages (described in
manifest files under the `snippet_lists` key) because we noticed that
some of the changes that were made in themes for some blocks were not
supposed to impact the "drag'n'drop" version of the block, but only
the version used inside the pages generated by the configurator. (E.g.
connecting shapes between blocks)
The manifest entries now have the following structure:
```py
'snippet_lists': {
'somepagename': ['s_block_name', ...],
},
'new_template_pages': {
'somecategoryname': {
'sometemplatename': ['s_block_name', ...],
},
},
```
This commit finds those entries in the manifests and creates the
following primary templates:
- `s_block_name`: already exists, this is the block that is drag and
dropped using the website builder
- `configurator_s_block_name`: specialization of `s_block_name` used in
all pages generated by the configurator
- `configurator_somepagename_s_block_name`: specialization of
`configurator_s_block_name` for that specific page
- `new_page_template_s_block_name`: specialization of `s_block_name`
used in all new page templates
- `new_page_template_somecategoryname_s_block_name`: specialization of
`new_page_template_s_block_name` used in new page templates of that
specific category
- `new_page_template_somecategoryname_sometemplatename_s_block_name`:
specialization of `new_page_template_somecategoryname_s_block_name` for
that specific template
For the template pages defined in `website` it also creates primary
templates that assemble `t-snippet-call`s of the most specific block
templates. Those templates are named
`new_page_template_sections_somecategoryname_sometemplatename`.
task-3381714
Part-of: odoo/odoo#126719
*: web_editor
This warning redirects users to the code snippets block and footer/body
code injection. We want to avoid editing the XML code for no good reason
because it complicates upgrades to the next version.
task-3229205
closesodoo/odoo#117051
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit changes the name of the option which changes the color of
the header. Before this option was called 'Colors' this commit renames
it to 'Background'.
task-2904507
closesodoo/odoo#99732
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Morgane (morm)