Those were broken by the theme update for 17.0, in particular at [1].
Indeed the underline colors were defined using `text-XXX` classes to use
the theme colors, relying on the fact that the default color of HR
elements used the `currentColor`. Now they use the `currentColor` but
very faded... making those underline colors uglier and for one of them,
basically invisible.
As a stable fix, this updates the XML to make the border use the
`currentColor` as before in new mega menus... although they do not work
as well in 17.0 as they did in 16.0. This will be reviewed in master to
use better colors and a more reliable and beautiful way.
[1]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364eclosesodoo/odoo#163011
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
At the moment, duplicating a website is not possible in the sense of
duplicating content, pages, etc. It is still available as an action from
the form view, and it could make sense to start up a new website with a
few common values (social media? etc?)... but many of website fields are
technical fields that should not be copied and many are dubious to copy
and not even visible in the form view. Really, duplicating a website at
the moment is misleading. This commit disables the possibility from the
form view.
In the future, we want to focus on the ability to export / import a full
website, but that's not for now.
opw-3782830
closesodoo/odoo#160587
X-original-commit: 43971a22c56b197306060ac3be7903d36d2c4be9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this other commit], the style indicating the active nav item
stopped working if the user added record pages to the navbar. This was
due to the cache system not being invalidated when switching from one
record page to another.
This commit fixes the issue by disabling the cache for the navbar if
there is a record page in the menu.
Other potential solutions were considered but ultimately rejected:
1. Using the record as a t-cache key. However, this would mean that if
you have 60,000 visible forum posts, you would end up with 60,000
different caches.
2. Activate the correct element using JavaScript. This would lead to a
duplicate logic in the JavaScript and the Python code, and it would
introduces a slight lag to add the active class on the correct nav item
(due to the time it takes to load and execute the JavaScript).
The chosen solution is the best compromise, as it maintains the cache
for most cases (website menu without records page links in it), nothing
change with this commit. For problematic cases (record pages in the
website menu), this commit disables the cache, which is a reasonable
trade-off.
Steps to reproduce the bug fixed by this commit:
- Edit a website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This commit fixes the issue (a update of the website module is needed)
and adds a test to prevent regressions.
Notes:
- To see the issue locally, remove the --dev xml or --dev all arguments.
- The same issue was occurring with other record pages (blog posts, ..).
- We will introduce back the groups on menu and benefit from this new
method to also disable the menu cache if one of the menu is linked to
a group. See task-3800830
[this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159006
X-original-commit: 43576cd424b6d0fc7da01142b5e6550e371ad1ff
Related: odoo/enterprise#59321
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since [1] when the "Padding (Y, X)" option was added, form elements are
recognized as columns because they match the `.row > div` selector of
that new option.
This commit excludes those form elements from this option's selector.
Steps to reproduce:
- Drop a website form.
- Click on field's input.
=> An empty "Column" editor appeared in the side panel, and an error
occurred when trying to delete it.
[1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712
task-3748574
closesodoo/odoo#157572
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
The s_picture snippet's image was not using the img-fluid class; which
means that if you removed the default img-thumbnail, the image could
overflow its container, especially if you replaced it with a custom
image.
The user still had the possibility to apply width: 100% to solve the
issue. This commit solves the issues by just adding the img-fluid class
for future s_picture snippets. Existing ones are not worth worrying
about: setting a 100% fixed width is an easy fix and a good practice
anyway.
task-3266862
closesodoo/odoo#157808
X-original-commit: 79208821fb60abe8f34dc45c2f282cdbf52c0d4b
Related: odoo/design-themes#784
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: base_import, gamification, hr_skills, mass_mailing, portal,
portal_rating, survey, web, web_editor, website, website_sale,
website_slides
The goal of this commit is to improve the accessibility of the website
pages. This has been made by implementing and correcting ARIA
(Accessible Rich Internet Applications) roles and attributes. More
precisely:
- An `aria-label` attribute has been added on progressbar elements to
avoid a warning of type `ARIA progressbar elements do not have
accessible names`. It has also been added on iframes to avoid a warning
of type `<frame> or <iframe> elements do not have a title`. Furthermore,
`aria-label` has been incorporated on some anchors to avoid a warning of
type `Links do not have a discernible name`. Finally, it has been added
on elements that have the `dialog` role to avoid a warning of type
`Elements with role="dialog" or role="alertdialog" do not have
accessible names` and on elements that have the `listbox` role to avoid
a warning of type `ARIA input fields do not have accessible names`.
- To avoid a warning of type `Some ARIA parent roles must contain
specific child roles to perform their intended accessibility functions`,
`role="menuitem"` has been added on children of menu elements. As
explained in [the menuitem role documentation], "The `menuitem` role
indicates the element is an option in a set of choices contained by a
`menu` or `menubar`". To avoid this warning, `role="presentation"` has
also been added on elements located between `tablist` and `tab` and
between `menu` and `menuitem`. Indeed, as explained in
[the presentation role documentation]; "The `presentation` role removes
an element's implicit ARIA semantics from being exposed to the
accessibility tree". The goal is to inform the assistive technologies
that the default semantics of the element should be ignored. Finally, to
avoid this same warning, the `option` role has been added on elements to
identify selections a user can make in a `listbox`.
- The `aria-label` of some elements has been adapted in order to avoid a
warning of type `Elements with visible text labels do not have matching
accessible names`.
- The value of `aria-disabled` has been corrected to `true` (instead of
`disabled`) (see [the aria-disabled documentation]).
Still to improve the accessibility of the website pages, an alternative
text (`alt`) attribute has been provided for images.
[the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role
[the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role
[the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#valuesclosesodoo/odoo#140453
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_hr_recruitment
In order to improve the accessibility of the website pages, an
`aria-label` attribute has been added on some social media anchors to
avoid a warning of type `Links do not have a discernible name`. The
`options.js` file has also been adapted in order to correctly set the
`aria-label` attribute of added social media anchors.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
In order to improve the accessibility of the website pages, an
`aria-controls` attribute has been added on `tab` elements of the
"Accordion" snippet to avoid a warning of type `Elements with an ARIA
[role] that require children to contain a specific [role] are missing
some or all of those required children`. Indeed, as explained in
[the tab role documentation]; "An element with the `tab` role should
contain the `aria-controls` property identifying a corresponding
`tabpanel` (that has a `tabpanel` role) by that element's `id`". The
`_createIDs()` method has been adapted in order to handle the update of
the `aria-controls` attribute at the update of the `tabpanel` id.
[the tab role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role#description
Part-of: odoo/odoo#140453
The goal of this commit is to add an `aria-label` attribute on the
"extra item" anchor in order to improve the accessibility of the website
pages and avoid a warning of type `Links do not have a discernible
name`. However, as the logic responsible of the creation of this anchor
is in a non lazy loaded file, the translate function `_t()` (located in
a lazy loaded file) can not be used to translate the value of the
`aria-label` attribute. To solve the problem, this value has been put in
the `data-extra-items-toggle-aria-label` attribute on the header. The
translated value is then extracted and added in the `aria-label`
attribute at the extra items button creation.
Part-of: odoo/odoo#140453
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit resolves the accessibility issue where the search field
located within the header was not navigable (see [1]) via keyboard
tabbing, rendering it inaccessible to users relying on keyboard
navigation.
This fix ensures that users can seamlessly navigate to the search field
in the header using the keyboard, thereby enhancing the overall
accessibility and usability of the website.
[1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822
task-3607481
closesodoo/odoo#153197
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Since PR [1], which redesigned the headers, there are now two navbars:
one for the desktop view and one for the mobile view. This also means
that the different menus are in both navbars at the same time. However,
this causes some issues with the mega menus.
Indeed, since each mega menu is in both navbars, the changes made in one
are also made in the other (since it is a field in the database). This
causes issues when drag and dropping:
- Drag and drop a mega menu element.
- Re-drag it and drop it somewhere else.
=> We notice that the element was cloned and each drag and drop adds a
new clone. Moreover, when clicking on a link inside these elements, a
traceback appears.
This happens because since both mega menus are synced, the drag and drop
clones are also synced and so the dragged element is dropped multiple
times (after each clone).
This commit fixes these synchronization issues by adding the mega menus
only once in the DOM, in the desktop navbar. They are then moved from
one navbar to the other when we open them.
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
opw-3730165
closesodoo/odoo#146492
Related: odoo/design-themes#756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: test_website_modules
In PR [1], the headers have been redesigned. One of their major changes
is that now, they have two navbars: one for the desktop view and one for
the mobile view.
However, the `o_main_nav` and `top_menu` navbar ids are also duplicated,
meaning that there are multiple elements with the same id in the DOM,
which is not a good practice.
This commit fixes this by replacing the ids by classes in the navbar
templates, since their use does not really require for them to be ids
(e.g. `#o_main_nav` is mainly for styling). For the desktop view, the
ids are still kept (for stability purpose).
Note that the CSS rules and the selectors in the JS files (except for
the tests) now take into account both the ids and the classes (to be
safe).
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
Part-of: odoo/odoo#146492
Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.
This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.
Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.
Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>
<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.
[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d
opw-3513760
closesodoo/odoo#152502
X-original-commit: e6fe14dc90af6782693fd5e9dca6f18ecfe7c89a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Google has removed the feature that allowed sitemap submissions. Now,
it's standard practice for Google to crawl the /sitemap.xml. This commit
permits to show a notification message when the user clicks on the
button to submit a sitemap.
task-3323849
closesodoo/odoo#152700
X-original-commit: fb842f682bb8b2600d861a5e0bb92503857bd2de
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Appending strings within a `t-out` for a website template makes it so
that it can never be translated. Instead the string should be written
like normal text so that it is correctly seen as to be translated and
`t-out` only the next step so that it's also correctly matched as to be
translated.
opw-3700815
closesodoo/odoo#152312
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Commit [1] introduced a way to "hide" an ir.ui.view through a new
visibility field.
That field has multiple possible values to restrict the access. One of
those is "Restricted Groups", but when selected it's really hard to
figure what to do next because nothing happens on screen: there is no
"groups" field where to add the groups.
Those groups should actually be added a bit below, in the groups_id
field which is "hidden" inside the "Access Rights" second tab.
This is because the groups_id field already existed (in base module)
before introducing the website visibility feature which just relied on
that field when set to "Restricted Groups".
Note that another possible value for visibility is "Password", and in
this case a password field appear below the visibility field as one
would expect.
[1]: https://github.com/odoo/odoo/commit/e239934abe456257c9dc285d1ad9829c0353900cclosesodoo/odoo#151602
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the refactoring of base_automation, the 'website-publishing'
option of server actions was broken; it did get included in the view
but outside of a group node and without labels. The result was a
floating checkbox which would trigger a label-less char field upon
selection - not the clearest of UIs.
This commit properly insert these fields into a group node. Note that
since server actions can normally only be reached by going through
technical menus, the fact that this section of view is now in a
group_no_one-only section should not change anything functionally.
closesodoo/odoo#151498
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Note: This fw-port commit cherry-picked and squashed commit [2] directly
as it was fixing this original commit before it had the chance to
be forward ported.
Since commit [1], which adapted the website pages list view to OWL, the
records listed on screen are filtered according to the active website
filter. However, the full list of records is still used behind the
scenes for all potential actions.
Steps to reproduce:
1. Go to the pages list view.
2. Select a specific website (if it's not already the case).
=> The total of records in the upper right corner does not match the
number of pages on that specific website.
3. Click on the "Select all" checkbox.
=> All the pages are selected, including those that do not appear on
screen.
This is because the records were just visually hidden with a `t-if`.
[1]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
[2]: https://github.com/odoo/odoo/commit/db670f64f4c2190f1655f9077ea62885049a3c84
Courtesy of @robinlej and @detrouxdev
Related to task-3676124
opw-3554064
opw-3658648
closesodoo/odoo#149547
X-original-commit: 8d78a916dc8c0eca82e8a6a2c6f5541938709930
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit addresses an issue when the logo is in text mode and we
want to click on the `logo` check button under the `Header`/`Elements`
options.
The bug manifested itself in [this commit] during the redesign of the
website template headers. The logo button, initially assumed to have two
states, is, in fact, comprised of three: None, Text, and Logo. To
address this issue, a workaround has been implemented, treating None and
Text as a single state. Consequently, if the current state is Text or
None, toggling will transition to Logo, and conversely, if it is Logo,
the toggle will shift to None.
Steps to reproduce:
- Enter edit mode.
- Click on the header navbar.
- Click on the logo.
- Go to navbar brand options and choose "Text" in the dropdown Logo
selector.
- The website is now saved. click on the button `LOGO` under the
"Header" -> "Elements" option.
- An error occurs: the template is not well-formed or wrong.
[this commit]: https://github.com/odoo/odoo/commit/e5380a8e40be47cddf53aa24ff01e7c6802bbdb7
opw-3624285
closesodoo/odoo#146839
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
On website (with “developer” mode enabled), The “Model Pages” menu item
is accessible even when there are no created module page records, which
is not relevant in most use cases.
The code from [1] introduced a way to expose models (both manual and
existing models) publicly on the website by creating pages for them,
these records are accessible through the model pages' menu (which is
currently visible in debug mode only).
A first spec aimed to make this menu item visible only when module pages
are created for the current website, But since we need to perform async
calls for that (to check if some module page records exist), and after
further discussion, it was decided to remove it completely.
[1]: https://github.com/odoo/odoo/commit/198e226f5bd66dba6598d1ef85e5fa5fb82b38b2
task-3659626
closesodoo/odoo#148175
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Each date in the timeline snippet was displayed with the time line going
through them. The line is supposed to be cut around the date. This
occurs since [1] which made it so `<span>` elements are automatically
removed by the editor if they do not have any attributes. Unfortunately,
this snippet relied on such a span, since [2]. This commit solves the
issue by making the snippet better (and the XML structure will further
be improved in the master forward-ported version). Unfortunately, this
is not entirely stable, even though it leads to the exact same result
provided no custom code tweaks the snippet. It will also solve existing
timeline snippets in current databases.
Note: [1] was obviously a mistake to merge in stable, although it might
be kept seeing the delay since it was merged and nothing critical seems
to have happened.
[1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c
[2]: https://github.com/odoo/odoo/commit/fbe38fb41dfdb76878748a1149f93700b566d228
task-3657771
closesodoo/odoo#147598
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The header call to action button template was extended by other ones
based on classes that can be changed using the Odoo editor. So if you
changed them, saved then toggle those other template options... you
broke your header.
closesodoo/odoo#141694
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The text and links in the header configurations were always the root
elements that were editable. For them to be properly editable, we need
their container (at minimum) to be the root editable element. Indeed,
on root editable elements, only the class and style can be changed (if
not dynamic). But changing a link requires to change the href, the
target. Changing a text style requires to change the tag entirely, etc.
For this to work, the `_link_class` configuration was removed, it was in
fact mostly useless and actually even breaking some layouts. So doing
this fix actually improves the design as well. For the layout were it
made sense, it actually became useless by refactoring the templates.
This was necessary anyway for texts which did not use `_link_class` but
were root editable nodes anyway because of the `t-if` conditions laying
around.
closesodoo/odoo#140869
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The configurable text in the header templates has a `_link_class`
option which sometimes was set to add the "nav-link" class on the
links in the default header texts... but that class was already there
no matter the config.
This removes the double class addition.
Part-of: odoo/odoo#140869
Prior to this commit, on mobile, we couldn't see the entire offcanvas
menu because the browser's UI was hidding part of it.
To fix that, this commit adapts the height of the offcanvas menu using
`dvh` unit.
task-3582657
closesodoo/odoo#141032
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This PR refactor the "inputs design system" by reverting the correlation
'$input-bg == $light == color-3', initially introduced by #120302.
Beside ensuring color-consistency, the former system aimed to simplify
palette edition by clarifying how color-3 was used (simply all the UI
elements...).
While the former system was responsive to user customization and
color-presets, it didn't necessarily delight everyone's discerning
taste, at least not with default settings/palette.
This commit enforces a classic "white with borders" design that's
independent from the color palette and doesn't adapt to color-presets.
The rationale behind this decision is that the need for non-white inputs
is "nonexistent" and exceptional cases should be addressed using the
SCSS editor.
As a workaround to ease edition for users that still wants to challenge
themselves with the creation of "not standard" palettes/designs, this
commit introduce a colorPicker option assigned to $input-bg.
The hope is that this new controller help users finding a "compromise
color" that could work with any color-presets.
task-3568806
closesodoo/odoo#139642
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When introducing the templates for the "new page" feature in [1], on
some elements classes ended up being specified twice, or being added
without removing a contradicting class (e.g. different bottom paddings)
This commit adjusts the blocks of the new page templates so that:
- no class appears twice
- only the visually applied class of several conflicting classes is kept
For `pt*`, `pb*` and `o_cc*` the class with the highest number is the
visually applied one.
[1]: https://github.com/odoo/odoo/commit/b27d52c193a08fe6a4471c844afa3d01a33ccace
task-3562147
closesodoo/odoo#139572
Related: odoo/design-themes#731
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [this PR], some headers have some preselected options. For
instance, by default the header_sales_one displays social icons without
colors and a CTA button with rounded sides. However, if one modifies the
option in the panel, it appears to be working, but upon save it goes
back to no_icon_color / rounded sides.
This happens because the option is forced by the header template. That
behavior takes the precedence over the user's option choice.
As there is no proper way to make it work without modifying the model,
this commit removes the forced option on the templates for Odoo 17.
It should be properly reintroduced in master.
[this PR]: https://github.com/odoo/odoo/pull/119650
task-3576074
closesodoo/odoo#140669
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the layout of the theme options was reorganized, the
button's font-family option was not displayed anymore.
This commit restores the button's font-family inside the "Button"
section, before the button "Padding" options.
[1]: https://github.com/odoo/odoo/commit/388e4bb2bfcaebdd4ff30277fb49a034592d7086
task-3478355
closesodoo/odoo#140692
X-original-commit: 718ae15606fe452da26fe9c4fa9c90cc443fd8f1
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit sets `s_text_cover` default color preset to `o_cc4` to make
it look more like the header of "Anelusia theme" that was the initial
reference for the design of this snippet.
It also fixes a typo in `o_ccx` class introduced in commit [1] at the
same time actually.
[1]: https://github.com/odoo/odoo/commit/5ac340b1b27c9527463e2eed65fe2e7768b36702
task-3568868
closesodoo/odoo#140721
X-original-commit: 66f63ab23159fae86ba81369287e1cf8aac66d87
Signed-off-by: Quentin Smetz (qsm) <qsm@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>
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
qsm-odoo