When a new user is created from the website, the company id was always
set to the first company of the database even if the website was the one
of another company. This flow has been already fixed if there is the
"Specific User Account" setting activated (see [this other commit]).
This commit fixes the same issue but for every case.

Steps to reproduce the issue:
- Create 2 companies A & B
- For each company, create a website linked to a different URL
- Activate 'Free sign up' for company B
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account

=> If as an admin you check the company of the created user, it is
company A instead of company B.

[this other commit]: https://github.com/odoo/odoo/commit/77c708c516beb322df37220634e178ba82e894c9



task-3277317

closes odoo/odoo#120475

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Set an input "Placeholder"
value.
- Go to the page (in 'edit_translations' mode) > The translation of the
input "Placeholder" attribute doesn't mark the input as translated and
even after saving the translation, the input is still marked as
"to_translate".

The goal of this commit is to fix this issue by extending the same
behaviour on the translated `<select/>` options (using `.oe_translated`
class) and setting the right translation state on the input from the
linked attribute translation `<span/>`.

task-3323245

closes odoo/odoo#121128

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

This commit fixes a bug with the navbar links in the header of a website
on mobile. When the text of a link is long enough to be wider than the
screen, the text does not wrap to the next line as intended, but instead
overflows to the right outside of the screen, causing part of the text
to be hidden.

Steps to reproduce the bug:

- Edit the text of one of the menu links on a website to make it longer
than the width of the mobile screen.
- Bug: In mobile view, part of the link text is hidden.

This bug occurs with both the "default" hamburger type and the
"off-canvas" hamburger type.

opw-3233684

closes odoo/odoo#119998

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

There is a historical code to return an error/404 when someone disable
the website info view, see [1].
There is also a feature introduced to add an option to disable the
content of this controller, see [2].
Commit [2] should probably have gotten rid of the view check in [1]
which was probably the way people used to stop this page leaking their
DB information.

From there, regardless if you deleted or disabled the view, the page
would still be referenced in the sitemap.xml, which would lead to a
traceback page (case 1) or a blank page (case 2).

This commit is simply conditionning the presence of this page in the
sitemap so it's removed from it if you disable/remove the website info
view.
It will help SEO wise to not have error page in it.

Note that we probably don't want to keep indexing this page, as it is
a technical link which doesn't bring any value to our clients to be
included in their sitemap.
It might have been useful for Odoo to perform some google search / stats
or something like that.
But since this is a stable fix, the behavior is kept as is as much as
possible.

Also note that it has always been in sitemap, even if marked
excplicitely since [3].

[1]: https://github.com/odoo/odoo/commit/8aca457e34bdec6257b9bfa917aebe4de053e2aa#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119R146-R149
[2]: https://github.com/odoo/odoo/commit/f025d3e17cbb3b1fd05152ca46af091b6e11ee20
[3]: https://github.com/odoo/odoo/commit/e19227d3ba9c9296bfc0c221ac70a863a571b9a6#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119L200



opw-3255831

closes odoo/odoo#120336

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

The website info page was introduced with [1] where the code was
apparently checking for the existence of the view (to be rendered) to be
able to handle a proper error if it did not exists.
It seems like it was to support the case where someone would delete this
view to not leak any info on the public controller. But it's uncertain
as this code is 10 years old.

It was a year later improved with [2] to have an option on the page to
be able to sort of disable it: it would simply show a blank page but it
would still be served.

As of now, the `try/except` with the `get_template()` call is crashing
and rendering traceback whenever this view is deleted, making this code
useless and not doing anything.
It's probably not needed anyway since the option introduced with [2] but
as we are in stable, this commit is making the controller return a
proper 404 page instead of a traceback.
Arguably, that part of the code could be removed. We will do it in the
master forward port.

[1]: https://github.com/odoo/odoo/commit/8aca457e34bdec6257b9bfa917aebe4de053e2aa#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119R145
[2]: https://github.com/odoo/odoo/commit/f025d3e17cbb3b1fd05152ca46af091b6e11ee20

opw-3255831

Part-of: odoo/odoo#120336

Since this commit [1], the option to set the background color for
snippets in the footer has been removed. However, this should not affect
the snippets in the "All pages" popup, which is also located in the
footer.

This commit fixes that by showing the background color option for popup
snippets in the footer.

Steps to reproduce the bug:

- Drop a popup.
- Set the "Show On" option to "All pages".
- Drop a text block in the popup.
=> The text color is white over a white BG (because it is in the footer
and the footer text is white).

[1]: https://github.com/odoo/odoo/commit/00f70f7936d37ec1c7c26065b2126045337e2825



task-3102275

closes odoo/odoo#111681

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Add a new 'Selection'
field.
- Go to the page (in 'edit_translations' mode) > The selection field
options are not translatable.

The goal of this commit is to make the select options translatable
by adding an intermediate `.o_translation_select` element.

This element will handle option's text translations from the linked
`<select/>`. The final values are copied to the original element
right before save.

opw-3233360

closes odoo/odoo#117519

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, links scrolling to an anchor with a special
character did not work and displayed a traceback. The issue was that to
check that the anchor is valid, we don't need to check that the anchor
is a valid url as we have been doing since these commits [1], [2]. But
we only need to check if the jQuery selector is valid to correctly
target the element to which the page must scroll.

Indeed, the anchor widget returns stuff like 'ok%C3%A9%25' when typing
'oké%' wich is not valid jQuery selector. It has to be encoded to
'#ok\\%C3\\%A9\\%25' to be valid and that's what this commit does.

We also changed the way to display a new anchor to the user in this
commit. Before, we showed the anchor unencoded in a notification and now
we show it encoded. That way, if the user copies the anchor from the
notification, it's the real anchor.

Also, this commit detect if the success URL of the redirect of a from is
the current page to perform a scroll to the anchor instead of a
redirect. To make this comparison, we needed to add the url code of the
language of the current page to the session info.

Also, before this commit, the page froze when we clicked on the "submit"
button of a form that redirected to an anchor that did not exist.

[1]: https://github.com/odoo/odoo/commit/0abfaeda96c2eaa868cc7fc5fa1926dfa90fc420
[2]: https://github.com/odoo/odoo/commit/b492bde6a121be1c15ed90ce0827fcfd72a12f5c



task-2172312

closes odoo/odoo#82059

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

There was an issue before this commit where some flags (basically all
the ones which are not tribands) would appear "broken".
This is the case for the China one where the symbol on the flag would be
squashed.
Using `object-fit` css property will keep the original flag ratio.

task-2929438

closes odoo/odoo#118903

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When the navbar hamburger type option is set to 'off-canvas', the 'call
to action' button of the 'boxed' header is located "next to" the navbar
instead of "in" the navbar as it should be.

This commit puts the 'call to action' button in the navbar when the
'off-canvas' menu is opened.

task-3063878

closes odoo/odoo#105768

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.

Note that we leave the old clickOnEdit util as it could be used in
custom codes and we don't want to break them.

task-3203820

closes odoo/odoo#116490

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When a mega menu "Sub Menus" are configured as "On Hover", it becomes
very difficult to edit its content.

This commit changes the behavior of the "On Hover" while the page is
being edited:
- it disables the hide on exit (`mouseleave`)
- it prevents the show on hover if another dropdown is already opened
- it hides the menu when the page is clicked outside of the opened menu

This commit also disables the preview of the "Show Sign In" option
which is not previewed anyway, so that it does not deselect the mega
menu when hovering the options.

task-2825376

Part-of: odoo/odoo#110258

When assigned the role of restricted editor, there are many ways to
break the web_editor when trying to do actions that should be
unavailable. There is a traceback for the following scenarios under
some circumstances (mainly because of pages without editable areas or
features without the proper access rights):

- Drag and dropping snippet when Restricted Editor.
- Clicking on product when Restricted Editor in /shop.
- Clicking on product image on specific product page.
- Clicking on user name (e.g. Marc Demo).
- Clicking on menu items or logo.
- Clicking on a blog's image in /blog.
- Clicking on a blog's image on specific blog page.
- Clicking on calendar's image in /calendar.

There is now no longer a traceback which makes the editor crash or
freeze. This mimics the behavior in other cases where the editor does
not show a traceback, but there is no message indicating that the action
is unauthorized.

When accessing a menu that cannot be edited, the "Edit the menu" button
is not shown to the restricted editor.

task-2747895
opw-3164176

closes odoo/odoo#76900

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

Since [1] when a `/` was added as default text when no option is
selected in dropdown options, the selected font name is not displayed
anymore inside font options because they both rely on specifying a
`content` on the `::before` pseudo-element inside the `we-toggler`.
Because the empty value text also includes a `:empty` inside its
selector, that rule wins over the font name.

This commit makes the font name rule `!important` so that it gets
applied instead of the empty selection rule.

[1]: https://github.com/odoo/odoo/commit/dc6ff20386567abbabcb2d35388a3dc8995cab28



task-3256509

closes odoo/odoo#117448

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Since [1] the font family parameter was encoded twice when adding a new
google font. This causes an issue for fonts that contain spaces in their
name.

This commit removes that additional encoding and highlights the fact
that it already is an encoded parameter.

Steps to reproduce:
- Go to the Options tab while editing a website page.
- Open the Font Family dropdown.
- Select "Add a Google Font".
- In the "Google Font address" enter
`https://fonts.google.com/specimen/Open+Sans`.
- Click on "Save & Reload".

=> Field was highlighted as being wrong.

[1]: https://github.com/odoo/odoo/commit/d8cff9a37ba51c64628085b48d071ecb24e70f07

task-3256509

Part-of: odoo/odoo#117448

*: google_recaptcha, web_editor, website_blog, website_forum,
   website_sale_comparison, website_slides, website_twitter

This commit fixes improperly escaped query parameters across javascripts
of website-related modules.

See https://github.com/odoo/enterprise/pull/31711



closes odoo/odoo#100868

Related: odoo/enterprise#31711
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

This commit fixes several bugs with the navbar and the header templates:

- The "right" alignment options didn't work with most headers. This was
due to a missing CSS rule.

- The "right/left" alignment option was reversed with the "vertical"
header template.

- The navbar collapse style was broken with the "Hamburger Full" header
template.

- This commit hides the alignment options in cases where they have no
effect ("Hamburger Full" or "Magazine" header template + not
"off-canvas"). It also changes the options label to "Mobile Alignment"
when the alignment only impacts the mobile view (since this commit =>
[1], the "alignment" option no longer only impacts the mobile view,
depending on the templates, it can also impact the "desktop" view).

- The text section of the "Magazine" header template had no background
color (It was transparent after scrolling the page).

- The "off-canvas" navbar was not positioned correctly with several
header templates (e.g. "Boxed" header template).

[1]: https://github.com/odoo/odoo/commit/2a1aa808e939eeaa3caec6a1a82e19f023f1d010



opw-2951315

closes odoo/odoo#106764

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, the sub-menus that appear when the mouse hovers them
were not displayed correctly. The public widget which is in charge of
positioning the sub-menu (`menuDirection`) could not work because the
dropdowns were opened manually (which is not recommended) and so, the
`show.bs.dropdown` event was never triggered which prevented the public
widget from aligning the sub-menu items correctly.

Steps to reproduce the bug:
- Have a long sub-menu in the last position of the navbar.
- In edit mode align the navbar elements to the right.
- Enable the option to have the sub-menus displayed at hover.
- Save the page.

=> When hovering the sub-menu, it opens on the right and overflows the
page while there is enough space on the left.

task-2904507

closes odoo/odoo#115153

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

Since [this commit], some JS code tries to open the sub-menus in the
right direction so that the page overflow is limited. Unfortunately,
languages that read from right to left (RTL) were not supported by this
code, which left some sub-menus of the navbar overflowing when there was
room to open them without overflowing (on the other side).
Steps to reproduce the bug:
- Have a sub-menu in the last but one position of the navbar with long
strings of characters.
- Align navbar items to the right.
- Have an RTL language installed on your website.

=> When you open the sub-menu in RTL, it opens on the wrong side and
causes an overflow of the page.

[this commit]: https://github.com/odoo/odoo/commit/392c91cda3133b921e9aca9a7b1c511231027438

task-2904507

Part-of: odoo/odoo#115153

Issue:

- Go to website > edit mode > add a form
- On one of the form fields, add a placeholder > save
- Change language > translate > impossible to translate the placeholder.

The fix on [1] was added to prevent interacting with inputs in editable
zones. This prevents translating attributes on those inputs too (using
the AttributeTranslateDialog) so the goal of this commit is to add
an exception to the restriction in [1], when input attributes are
translated.

[1]: https://github.com/odoo/odoo/commit/3e598a8014966e1a07a08d53bf85050b458e05a6



task-3042522

closes odoo/odoo#106198

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Steps to reproduce the bug:
- Add an Image Gallery (IG) snippet on the page.
- Add 2 new images in the IG.
- Click on the first image of the IG to load its data.
- Click on the trash button to remove the snippet.
- Bug => The snippet is not removed (an image is removed instead).

When a snippet is removed, the `removeSnippet` function is called. The
problem is that the `call_for_each_child_snippet` will never resolve.
Two mechanisms are of interest to understand why: the first one is the
`updateCurrentSnippetEditorOverlay` function. Its goal is to destroy a
snippet each time its target is not in the DOM anymore. The second
mechanism is specific to the IG snippet: when an image of this snippet
is destroyed, the `slideshow` function goes through the remaining
images to update parameters. To do it, the function uses the
`_replaceContent` function that empties the content of the carousel and
then fills it with new data.

When a snippet is removed, a `SnippetEditor` is created for each
element of it. In the case of the IG, a `SnippetEditor` is created for
each image of the the snippet. Because the first image already has a
`SnippetEditor` (because it has been clicked), the callback of
`call_for_each_child_snippet` is called to remove this image from the
IG snippet. The second mechanism explained before will then be called.
Meanwhile, a `SnippetEditor` will be created for the second image.
However, because the `_replaceContent` function emptied the content of
the carousel, the `updateCurrentSnippetEditorOverlay` function will
destroy the `SnippetEditor` of the second image as its target is not
considered present in the DOM anymore. Unfortunately, the
`call_for_each_child_snippet` still needed this `SnippetEditor` and
will never entirely resolve.

To solve this problem, the `removeSnippet` function is executed inside
a mutex. Because the mutex is also used by
`updateCurrentSnippetEditorOverlay`, we are sure that this function
will not destroy the snippetEditor while the `removeSnippet` is still
running.

task-3147271

closes odoo/odoo#111719

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

Steps to reproduce:

- Add a "Table Of Content" snippet from the website editor.
- Save > The effect on the active page item (in top menu) is removed.

Starting from [1], a `.scrollspy('dispose')` call was added to destroy
the existing ScrollSpy, and to be able to make a new call that works
correctly when the header height changed.

Since this call has no specific target as option, it will trigger the
`scrollspy._clear()` process on all `'.nav-link'` elements including
navbar items which removes the `'active'` class from current page link.

The goal of this commit is to fix this behaviour by calling the
'dispose' only when an instance of `Scrollspy` exists.

[1]: https://github.com/odoo/odoo/commit/476995ba5a1d33aa0590214609346557d1d471c0



task-3223277

closes odoo/odoo#114937

Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>

*: web_editor, website_sale

Since [1] when the Dynamic Snippet was first introduced, it also
introduced a concept of "inherited" snippets. Specific snippets would
all `t-call` the same template for their rendering.
A mechanism was introduced to deduce the `data-snippet` from the caller
template, but it stored the obtained value in the `t-called` template
itself. Because of this if several "specific snippets" that used that
template had to be rendered, they would all have the `data-snippet`
value of the first one that got compiled.

We could compile the snippet template into something having a
dynamically obtained `data-snippet` value, but then that would be
equivalent to just using a `t-attf-data-snippet`.
All specific snippets already do set a `snippet_name` in the context
because it needs to be added in the classes.

This commit therefore adds a `t-att-data-snippet` attribute on the
base template, and populates with that same value in `onBuilt` for
stable versions.

During forward ports across stable versions, each new caller must be
patched as well - and all patches must be removed in master.

[1]: https://github.com/odoo/odoo/pull/53175



task-2922635

closes odoo/odoo#98924

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

When using the 'Show on mobile' option, we can see that there is a
mismatch between the screen breakpoint at which the elements are
displayed like in mobile view (=> under 992px or `lg`) and the one that
is impacted by the 'Hide/Show' option (=> under 768px or `md`). This is
a problem because between these two breakpoints, the display is like in
mobile view but is not considered as such and so, hiding an element in
the mobile view (for example, if it does not look good in it) has no
effect until the screen reaches 768px.

This commit increases the screen breakpoint at which the 'Show on
mobile' option is applied, that is, up to 992px instead of 768px, in
order to be consistent with the display.

task-3110770

closes odoo/odoo#109053

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

This commit fixes two bugs with the table of content snippet:

- Before this commit, the scrollspy position for the table of content
navbar was incorrect in fullscreen or edit mode due to the calculation
being based on the presence of the main navbar, which is not present in
those modes.

- Before this commit, when the table of content navbar contained enough
elements to exceed the height of the page, the bottom elements were not
accessible without first scrolling through the entire table of content.
This commit addresses this issue by adding a scrollbar to the navbar,
allowing for easier access to these links.

opw-3115597

closes odoo/odoo#109927

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.

The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.

Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.

opw-3133464

closes odoo/odoo#113117

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Prior to this commit, the height of the Image Gallery snippet was set to
auto on screens smaller than 400px.

This ensures that the snippet looks the best on phones.

However, when using Bootstrap, what defines a smaller screen is not
any screen below 400px, but any screen below 768px.
This meant that the Image Gallery snippet did not look the same on an
iPhone 11 Pro max as it would on an iPhone 11 for example.

This commit fixes that by using the built-in mixin that relies on
Bootstrap's breakpoints (in this case SM).

Steps to reproduce:
- Go in edit mode and drop an "Image Gallery" snippet
- Open the dev tools and choose "iPhone 11" or 375x812
- The image gallery does not have white bands
- Change the resolution to "iPhone 11 Pro Max" or 414x896
- The image gallery has white bands / has a different layout

opw-2995100
task-2997119

closes odoo/odoo#109761

Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>

Before this commit, we-matrix could create a horizontal scroll bar in
the editor. This was because the inputs had a minimum width size.

Steps to reproduce the bug:
- Drop a chart block on a page
- Add some series

=> The matrix overflows from the editor.

There is no perfect solution to this problem... We have the choice
between:
1) Leave the existing overflow on the editor.
2) Put a horizontal scroll on the we-matrix.
3) Distribute the available space between the columns.

As we don't want a horizontal scrollbar, the best solution is to
distribute the available space between the columns. This solution has a
drawback which is that the cells can become really small if there are a
lot of columns but this solution seems to be the least bad from a UX
point of view.

task-3094162

closes odoo/odoo#107400

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

To reproduce the issue:

- Website > Edit mode > Click on header
- Change the shadow color of the header to a suggested gray > it only
  works with normal colors but not grays.
- Change the header to "Header full" (it has no shadow by default)
- Add a shadow > It works
- Change the shadow color to a gray > it is reverted to no shadow.

To explain what happens exactly, let's suppose we want to set the gray
color from the custom property "--900":

When this color selected on colorpicker, the `customizeWebsiteVariable`
method will update assets to set a new user value:

`'menu-box-shadow': var(--900) ...`

But when the SCSS is compiled, the property name (here "--900") is
computed as a number which generates a wrong CSS value: `var(900) ...`

The goal of this commit is to prevent this behaviour by protecting
colorpicker variable names so they cannot be used for any further math.

task-3069518

closes odoo/odoo#105916

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>