To reproduce the issue:
- Website > Edit mode > Add "Share" block.
- Cannot edit the link by clicking a social share item ("Edit link"
on link popover doesn't work).
Since 15.x, "Share" snippet items are not meant to be user links but
buttons to share the page on the related social media. It is also
useless to update those links after the update on [1], since they will
be replaced by the right values "on social item click" (the shared URL
may be updated during the page use as on product pages).
The goal of this commit is to fix this behavior and prevent the link
popover from appearing on items (by setting the `o_no_link_popover`
class right after the snippet is dropped into a drop zone).
[1]: https://github.com/odoo/odoo/commit/ddb2c06be4196c86ff6a2fd74874487d75b31c94
opw-3084367
closesodoo/odoo#108724
X-original-commit: f4a602ca4d423056fa3f760fc8a3fc222e2a5e51
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
To reproduce the issue:
- Website > Edit mode > Add "Share" block > Save.
- Click WhatsApp > Missing space between page title and its URL.
Starting from [1], the `$('title').text()` value was replaced on "Share"
snippet by `document.title` (which will trim and collapse whitespaces
in the page title). This leads to a missing space between page title
and the shared URL.
After this commit, the correct spacing is restored.
[1]: https://github.com/odoo/odoo/commit/ddb2c06be4196c86ff6a2fd74874487d75b31c94
opw-3084367
X-original-commit: e7e9eb4f806680b19f3ec61fb080316a3160e7fb
Part-of: odoo/odoo#108724
The last two parent of this commit introduced fixes towards the Snippet
Cache, more specifically, the snippet cache according to the snippet
language.
Commit [1] introduced a Snippet template "Cache" that keeps the snippet
templates in memory throughout multiple instantiation of the
SnippetsMenu. Unfortunately, while this improved performance, it also
introduced bugs where the cache was not properly cleared. Starting
the edition in translate mode, then switching back to master edit mode
would sometimes lead to the Snippets being loaded in the wrong language.
The parent commits fix that but this one introduces a test to make the
snippet cache and translation more robust.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af#diff-52a4f9d2c217548e69e6b7fd097f286f1754a6389734eea254b87255e501cbefR18closesodoo/odoo#108643
X-original-commit: a066dc8319cc9c204656a25af16fc78ae618cd71
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: mass_mailing
When images are dropped from outside the browser into a website page
text paragraph, they are stored as an inline base64-encoded source.
This commit marks those images to be saved as attachments when it
happens in website. The save happens upon page save similarly to what is
done when images are transformed.
This commit also applies this behavior for pasted images.
task-2928495
closesodoo/odoo#98801
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, adding an anchor using auto-complete would not
properly prefix the url with the URL of the current page.
Steps to reproduce:
- Create a page (e.g. /test), add blocks and create an anchor (e.g.
- Save the page
- Click on "Edit Menu" in "Pages"
- Add a new menu entry
- Type '#' in the URL field and select the anchor
- Save
=> The menu entry is wrongly set as it does not contain the original
page's URL inside the `href` attribute. This means that clicking on the
menu from any other place will not properly redirect to the anchor on
the /test page
On top of that, editing a menu entry that was previously linked to a
page would change the URL of the page with an anchor, making it
impossible to access the page anymore until you change the URL back in
the page manager.
Steps to reproduce:
- Create a new page (e.g. test)
- Add a new menu entry that has this page as its URL
- Save the new menu entry (close the dialogs)
- Re-open the Menu dialog and edit the newly created menu entry
- In the URL field, replace it with the page + an anchor
(e.g. /test#anchor)
- Save
=> The page's URL is now /test#anchor and is no longer accessible
The is due to the `save` method of the `website.menu` model not
containing code to properly manage adding an anchor to the menu.
This commit fixes that.
opw-3067750
closesodoo/odoo#108502
X-original-commit: 192bf08da191e6fad27dd2913be0801817256a3a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To reproduce the issue:
- Go to website > Add language > Add blocks to your homepage and
translate it.
- Make translations on the "Contact us" page (or a new custom page).
- Install a new app > The translation of the homepage is lost (only on
homepage).
Explanation:
After [1], The `_load_module_terms()` method was updated on website
module to copy translations from base to specific views when module
translation is loaded. And since [2], the translated field's column is
either NULL or a JSON dict mapping language codes to text (the field's
value in the corresponding language).
To explain what happens exactly when new app is installed, let's suppose
we want to load module translation for the config {'en_US', 'fr_BE'} in
the following situations:
S1 (e.g. "Contact us" page):
-=-=-=-=-=-=--=-=-=-=-=-=-=-
```
generic_arch_db = {
'en_US': '<div>Generic (EN)</div>',
'fr_BE': '<div>Generic (FR)</div>'
}
- specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Specific (FR)</div>'
}
```
`_load_module_terms()` will copy translations for 'fr_BE' from generic
to specific `arch_db` (using generic translation dictionary).
result:
```
new_specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Updated Specific (FR)</div>'
}
```
S2 (new custom page):
-=-=-=-=-=-=--=-=-=-=
```
generic_arch_db = NULL
specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Specific (FR)</div>'
}
```
result:
Nothing to do here (only specific version), the specific translation
will not be updated.
S3 (e.g. website homepage):
-=-=-=-=-=-=--=-=-=-=-=-=-=
The generic view has no translated `arch_db` (only the 'en_US' version):
```
generic_arch_db = {'en_US': '<div>Generic (EN)</div>'}
specific_arch_db = {
'en_US': '<div>Specific (EN)</div>',
'fr_BE': '<div>Specific (FR)</div>'
}
```
`_load_module_terms()` will copy generic translations only for languages
available on "generic_arch_db" and the 'fr_BE' version will be lost.
result:
`new_specific_arch_db = {'en_US': '<div>Specific (EN)</div>'}`
The goal of this commit is to prevent this behaviour by keeping the
specific translated `arch_db` even when the generic value has no content
for the translation language.
Remark: This behaviour occurred while loading module translations,
as a consequence, the specific translations are also lost when the
website module is updated.
[1]: https://github.com/odoo/odoo/commit/94db81d8d28c4cbc7b51ae1688c9362042ee3619
[2]: https://github.com/odoo/odoo/commit/ef00294e7189359c47638c4a71626f1937395edb
opw-3083480
closesodoo/odoo#108477
X-original-commit: 91a9c870eede96040ac49d2375fe0e18342342e1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Note: this bug is not possible to reproduce in 16.0 anymore, since the
Bootstrap 5 update. This commit is however kept as it makes the behavior
more efficient keeping the original fix's diff + it also cleans things
that were not necessary anymore since the "website-in-backend" update
that was made at [1].
Steps to reproduce the bugs (in older versions):
- In edit mode, choose the "contact" header template.
- Drag and drop a table of content snippet on the page.
- Save the page.
- Click on the table of content links.
- Bug => the links are not activated correctly.
The reason of the bug was that the scrollspy offset (calculated against
the header height) was not updating when the header height changed.
We did make a new call to scrollspy at the right time but that had no
effect because we first had to destroy the existing scrollSpy to be able
to make a new call that works.
opw-2951315
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#108223
X-original-commit: edd9d2b3df597786b2db416aed382dc5666623e2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Prior to this commit, the steps block options could not support a column
that was more than nine out of twelve (bootstrap columns) wide.
Steps to reproduce the bug:
- Drop a block step on a page
- Set a width of 10 columns on the first step
- Set a width <= 2 columns on the second step
=> the connector is not well displayed.
task-3033126
closesodoo/odoo#108362
X-original-commit: 9c4e0eaa60ad89140661e3c297ea1b4e22d6faae
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website
The fields of a form that are mandatory because of the model they need
to be used in cannot be removed. When such a field is selected, the
remove button displays a tooltip giving this information.
Disabling the overlay button is done by removing the specific class -
which makes the event selector not linked to the button, but also
impacts the applied CSS rules.
This commit adds an `o_disabled` CSS class upon disabling the button.
The tooltip is put on a `span` that wraps the disabled button because
tooltips cannot be shown on disabled elements.
Steps to reproduce:
- Drop a "Form" block.
- Select the "Phone Number" field.
- The overlay's delete icon has a reddish background.
- Select the "Your Email" field.
=> The overlay's delete icon had a dark gray background instead of a
reddish one.
task-2950433
closesodoo/odoo#107864
X-original-commit: ed3acbae6a6b2fe91c948ceeb16a5bdb3fa8f060
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, following this flow:
- Add a form
- Add a selection field
- Add an option starting with a number
- Save
=> The created form's option value is only the number
From the website_form options, the options HTMLElement of a form field
are generated using the field's records ids for their html element value
attribute (see FormEditor._renderField).
When [1] refactored the website_form options to use a generic
ListUserValueWidget, the list records id computation changed to use
parseInt instead of strings.
This commit changes the detection of parsable int to match only strings
that are made only of digits, and less than 16 of them so that their
value is not lost.
[1]: https://github.com/odoo/odoo/commit/9304f8fa7bb94f21dd4caa83f9679ffd1642691b
opw-2980760
closesodoo/odoo#108248
X-original-commit: 166f4aa4d23a01901585b60d69fac47fe70b7ebe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
This commit mitigates an issue with shape elements sometimes having tiny
spacing on their top or bottom edge.
This issue is mainly on Chrome when the user has changed the page zoom.
When the page is zoomed the elements can have a width value with a
decimal part. Because of it, the size of the SVG background images are
not correctly rounded compared to their container and therefore leaves a
visible space.
Steps to reproduce the bug:
- On Chrome, add several shapes on a website page.
- Change the zoom of the page and change the window width.
- At some points, the gap will appear.
The least bad solution we found to fix this is to ensure that the width
of the shape elements is always as close to an integer as possible.
Reminder: several commits had attempted to fix this before ([1], [2],
[3], [4]). But that wasn't enough to stop it happening. Some shapes
still need to be fixed although that will likely be done in future
versions.
[1]: https://github.com/odoo/odoo/commit/c0f62593a4da37e8404dddc0a5762879a5ebbf7f
[2]: https://github.com/odoo/odoo/commit/ac82407b259eab929486bf0a333a48bc507efa60
[3]: https://github.com/odoo/odoo/commit/42b3ad10e0b32b7fc72f801e2c67d6baf938c566
[4]: https://github.com/odoo/odoo/commit/e386f318f5cff50901dba3db8a2587911ba02a6e
task-2824607
opw-3069213
opw-3057533
X-original-commit: 623db525e18931a4dd5794da78be840afc34991a
Part-of: odoo/odoo#108228
It was reported the following error:
```
psycopg2.errors.DatatypeMismatch: column "country_id" is of type integer
but expression is of type boolean
LINE 9: false, 1, NULL, 4, 4,
```
The root cause is unknown, it's not yet sure how this is happening
exactly.
This commit is then fixing naively the consequence.
Somehow, GEOIP is returning a country code which does not exists in Odoo
for this error to appear. It's normally not possible.
There is multiple possible cases that would lead to this error:
- The user modified the `code` field of a country in his DB (unlikely)
- The user deleted a country in his DB (unlikely)
- The GEOIP database is returning a country which does not exists in
Odoo. This is the most probably case, even if the latest up to date
`GeoLite 2 City` seems to have the exact same country code list as in
Odoo 16.0 (250 exact same ones).
Moving the country_id search directly in the query will prevent the
issue and is better anyway to avoid an useless query everytime when
GEOIP is enabled.
Perf wise, it doesn't seems to alter at all the query speed.
closesodoo/odoo#108232
X-original-commit: 42fe2540620b7529d9a848c4570290cbf64a4f48
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Add a "Table of Content" on the website.
- Try to save a "Block" of the table.
- 14.0: you get an error message.
- 15.0: it keeps loading forever.
- 16.0: you get a white page.
Users should not have the possibility to save part of a snippet. The
goal of this commit is to ensure that the save option applies on a
snippet. If it is the case, the user has the possibility to save it. If
not, the user does not have the opportunity to save it.
opw-3056913
closesodoo/odoo#108002
X-original-commit: 5f28c7d9a04c46d570b13766eaaa90e755008623
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, following this flow:
- From the documents app, click on the "share" icon of a document,
- In the website builder, in edit mode, paste the link in the link
tools,
- Save and click on the link,
=> There is a traceback coming from cross-origins errors with the iframe.
These documents should be opened in the top window, as it does not make
sense to open the pdf viewer inside the iframe. This is defined in the
website module, to avoid creating a website_documents module just to
patch the WebsitePreview._isTopWindowURL method.
[1]: 44da4bf
task-2687506
closesodoo/odoo#107860
X-original-commit: 2e8fce06cbe4e2d24dd80eca1c59a9d44d181d30
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit, following this flow on the website builder:
- Add a new .xml page,
- From the page manager, click on the record to open it,
=> There is a traceback as the website service parses the html document
as an editable one.
This commit fixes the test introduced in [1] to hide edit options on non
editable documents. The test is updated to check:
1/ If there is a dataset (the document of an XML file opened on Firefox
will not have a dataset),
2/ If the dataset has a websiteId key. It is the case only for website
pages, rendered using the 'website.layout' template, and not for other
files (js, css, scss, less, xml, csv).
[1]: https://github.com/odoo/odoo/commit/44da4bfcc30ca4fe78a1e0c5cb2f9f498ba6e72e
task-2687506
X-original-commit: bf2c6abdded1509ae22ed299abaa39fa066efb7d
Part-of: odoo/odoo#107860
This commit removes unnecessary spaces from the XML of the table of
content block.
Related to opw-3047375
Related to opw-3035502
task-2948895
closesodoo/odoo#107732
X-original-commit: 7ee4cc7d02158c63e6e2bd5eacc94371040872a8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since the Bootstrap 5 merge, when there were several TOCs on the same
page the scrollSpy only worked for one of them. This commit fixes that.
Steps to reproduce the bug:
- Drop two TOC blocks on the same page
- Save the page
=> The second TOC is not working properly, it does not highlight the
current section.
Related to opw-3047375
Related to opw-3035502
task-2948895
X-original-commit: c182691bbfd6be8cc9aed26162635f5fdb117991
Part-of: odoo/odoo#107732
The table of content (TOC) has two mechanisms that interest us here:
The first one is scrollSpy (from Bootstrap) which allows (among other
things) to bold the menu elements according to the scroll. The second
one is a mutation observer which is implemented to regenerate the menu
when the content of the TOC changes.
This being said, when we edit the TOC and scroll at the same time, there
is a race condition that makes scrollSpy want to add a class to a menu
element while this menu has just been regenerated by the observer. The
error is only visible since the migration from Bootstrap 4 to Bootstrap
5 because to add the class, Bootstrap 4 did it with the jQuery
`addClass()` function which does not cause an error if the element on
which it is called does not exist. Now, Bootstrap 5 does the same thing
in pure JS with `classList.add()` which causes an error if the element
on which it is called is not defined. This commit fixes this error by
disposing the scrollSpy when the menu is regenerated.
Steps to reproduce the error:
- drop a table of content block
- drag a snippet around and go over the drop zones
=> traceback. It can appear directly or after some tries.
opw-3047375
opw-3035502
task-2948895
X-original-commit: a05f782871c61b2d58ca2fd4277cb7aed65a301d
Part-of: odoo/odoo#107732
Since [this commit], when dropping several "table of content" blocks on
the same page, it was impossible to save. This commit solves this
problem.
Steps to reproduce the resolved bug:
- In edit mode, drop two TOC blocks
- Click on Save
=> the UI is blocked
[this commit]: https://github.com/odoo/odoo/commit/06b03ba5ef8375b1236f6ecb52ac468124e910ba
Related to opw-3047375
Related to opw-3035502
task-2948895
X-original-commit: a6de596017cdbd0da10b4050da132d46dc82a491
Part-of: odoo/odoo#107732
When the url redirects to an anchor on a website page, the page must
scroll correctly to the section. This commit allows to do that by taking
into account the size of the navbar. The bug is visible by following
those steps:
- Drop a text - image block on a page
- Drop a picture block under text - image block
- Create a link to target the picture block
- Put link to block picture in the "Learn more" button
- Save
- Right click on the "Learn more" button and open link in a new tab
=> The page is not scrolled correctly to the picture block.
Note that the bug is not present if the header has scroll, disappear or
fade out as scroll effect.
task-2818629
closesodoo/odoo#92777
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
One can very well select a "auth=user route" as homepage for his
website, like /my.
There would then be an issue with such an URL being set as homepage:
- As the user landed in the homepage controller which is auth=public,
the system will add the public user as env user (see
`_auth_method_public()`).
```
@http.route('/', type='http', auth="public", website=True, sitemap=True)
def index(self, **kw):
```
- Then, that controller will reroute to the homepage url (/my). The
request.httprequest.path will now be /my
- Then, that controller will recall the dispatcher stack:
`request._serve_ir_http()`
- From there, this call won't fail as it should because the user is
considered as logged in as it went already through the
`_auth_method_public()`, adding the public user as env.user.
`_auth_method_user()` won't raise its error.
- The /my page will be rendered despite not being logged in.
Once the user land on that page, the system will actually detect him as
logged out on a page supposed to be accessed when logged in.
It will then:
1. Show a toaster to inform the user
2. Auto reload the page
As the current URL is still `/` (due to the reroute and not a redirect),
the same flow will happen again, and again, looping forever.
--------
Note that accessing /my directly won't be an issue, as it won't go
through the homepage controller (which is auth=public), so there won't
be a user_id set on the env (the public user), meaning that the dispatch
layer will reject the access and raise an access error (through
`_auth_method_user()`.
Also note that the same behavior will occur when going through the first
menu fallback mechanism:
- if the user didn't setup any homepage_url
- and deleted his / website.page
- and his first website menu is /my
In that case, it will go through the first menu redirect fallback, which
will be working fine (as it's a redirect and not a reroute).
With both those 2 flows (going through redirect), the user will
correctly land on the login page (which will redirect to /my once logged
in).
------
Finally, the other solution would be to prevent such a configuration
(/my as homepage_url) but it was not easily doable (if doable at all),
see https://github.com/odoo/odoo/pull/99100#discussion_r963055251
------
A test is also added and over the more complexe case (which should cover
everything):
- With /my as homepage_url
- With the / website.page deleted
- With /my as first menu URL
-> Accessing / as public user should:
1. Reroute to /my (because of the homepage_url set to it) which
should fail now thanks to this commit
2. Since the reroute / re-serve failed, it should reach the
"first menu fallback" mechanism, which is also /my
3. That fallback should be a redirect, not a reroute, so the user
should actually land on the login page
4. Once logged in on that page, it should properly redirect to /my
opw-3077339
X-original-commit: 4f5899f769266edc27a0b2d812df092b95f43c71
Part-of: odoo/odoo#107759
Commit [1] improved the "sanitation" of this field for special
character. For instance, when copy pasting the following terms:
| Input | Before | After |
|-----------------|------------------|-----------------|
| fée d'été à 40€ | f-e-d-t-40- | fee-dete-a-40 |
| Nội dung có Dấu | n-i-dung-c-d-u | noi-dung-co-dau |
But it actually came with a bad behavior which was not noticed: it
prevents to type `-` at the end of the input, which sounds good but is
not.
Indeed, when typing `a-word`, you will type `a` then try to type `-`
which won't work as considering a (forbidden) trailing slash, even if
you actually want to type something after.
This commit allows trailing slashes again, it's not a big deal and one
can remove it if he wants to.
[1]: https://github.com/odoo/odoo/commit/bb43d4dbb5745be84f0f9462e768989e50607bea
opw-3075419
closesodoo/odoo#107746
X-original-commit: bb43e343c0ec823dad8b102a81945b4a05a7af85
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
For some reason, safari on mac is not showing the sidebar menu content
at all. It remains a white div without content.
Seems like a bad implementation of that browser for this case, or at
least an implementation which is not shared by all other browsers.
Note that removing `z-index`, `position:absolute` or `overflow` css
property from the `wrapwrap` will make the menu appear.
!!! Also note that having a non scrollable page (not enough content),
like an empty homepage, will make the menu appear too. !!!
As this issue is quite critical:
- All mac/safari users are not seeing your website menu..
- And the admin don't event know it most of the time (as not on mac)
And since:
- It's been going for months without someone finding a proper fix
- It's hard to investigate as devs generally don't have mac to
investigate and have to use browserstack which is really bad for such
work
Step to reproduce:
- Select the sidebar header template
- Visit the website on safari
-> The menu will be invisible, like if the navbar was empty
opw-2984536
opw-2896939
closesodoo/odoo#107616
X-original-commit: ffa34d840a07efbbec3b180839d7cbf64787e4ef
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Prior to this commit, when using a background video on the cover of the
website_slides homepage (/slides), after saving, a traceback would
occur and the video would not be displayed.
Steps to reproduce:
- Install website_slide
- Go to /slides
- Enter edit mode
- Change the cover of the page by a video
- Save
- Traceback
The reason for that is that the cover snippet used on the homepage of
elearning is the root of an XPath instead of its own oe_structure. (This
was changed in 16.0)
[1] made it so that the style and class attributes are saved but did not
save any data attributes needed for the background-video widget to work.
This commit adds those data attributes.
[1]: https://github.com/odoo/odoo/commit/5b252215dc375526af87c31a32256dd1a9582f02
opw-3063043
closesodoo/odoo#107577
X-original-commit: 86dc4d4349d033c95c0e04e8c173f63e5e2044ed
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [this commit], a new option is available on the steps block to
change the style of the connectors. Unfortunately this was causing
errors in the console. This commit makes sure that we don't have these
errors in the console anymore.
Steps to reproduce the issue:
- Drop a steps block on a page
- Change the type of the connectors
=> Errors are displayed in the developer console.
[this commit]: https://github.com/odoo/odoo/commit/aba31e9f2d8a44ce1586403f2a621a6caeed57b4
task-3069766
closesodoo/odoo#107511
X-original-commit: c1805fc5d3c3eeaa5c2edca69a6b9375f4ea1a39
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
If the website domain is wrongly configured (set to a URL that will
actually be redirected through DNS/proxy/cloudflare etc), the website
preview iframe will loop forever.
The wrong configuration this commit is about are:
- Having set the website domain to naked URL while you configured your
naked URL to redirect to your `www` URL.
- The other way around (`www` to naked URL).
- Having set the website domain to `http` while you configured your
`http` domain to redirect to your `https` domain.
- The other way around (`https` to `http`) if it's even possible/done by
someone
While this could just be considered as a misconfiguration, it's a low
effort to support it. Also, the bug it implies is quite critical as the
user can't access his website app anymore (if he is smart enough and
somehow figure it's because of the website domain, he will think about
going to the General Settings to remove the domain).
All in all, it's a low effort to fix a (rare) critical issue.
Step to reproduce (`https`):
- Go to runbot (in `https`, normal way)
eg: https://21544921-16-0-all.runbot172.odoo.com/
- Edit the website domain and set it to the `http` version
eg: http://21544921-16-0-all.runbot172.odoo.com/
- Try to access the website app, it will loop forever, indeed:
1. You are on the `https` URL in your browser tab
2. The website app will try to load the iframe with the website domain
as URL, which is the `http` version.
3. The code in charge of loading the iframe URL (website_preview.js)
will detect that `http` URL as originating from a different domain
than the one of the current tab URL (parent window).
4. In this case, that code will reject that URL and instead load it in
the parent window URL -> It will basically redirect your whole
browser tab to that URL.
This is done as if you are loading the URL of a different website,
we want you to be completely redirect to this other website domain.
5. As `https` to `http` redirection (and naked -> www or www -> naked)
is done at a lower level (through nginx, dns, cloudflare etc), the
browser will not load the `http` requested URL but redirect and
load the `https` one.
6. Now, you are basically back to step 1. and entering an infinite
loop.
The same issue can be reproduced with naked domain and `www` domain but
not on runbot and difficult in local.
You can also reproduce it in local, but it will just do the useless
redirect once and won't loop as nothing is redirecting the naked to www
in local:
- Edit your `/etc/hosts` file and write
```
127.0.0.1 rde.com
127.0.0.1 www.rde.com
```
- Edit your website domain to `http://www.rde.com`
- Now go to `rde.com:8069`
- It will wrongly redirect to `www` version
-------------
On top of that, the domain misconfiguration would also lead to useless
reload when using the website switcher (it would reload the whole page
instead of just the iframe).
Step to reproduce on local (on runbot it will be replicable but it will
then enter the infinite loop described above):
- (Still with the `/etc/hosts` tweak described above)
- Edit the website_1 domain and set it to the `www` version
eg: `http://www.rde.com:8069/`
- Edit the website_2 domain and set it to the `naked` version
eg: `http://rde.com:8069/`
- Open the website app, land on one of the website (and its URL)
- From there, select the other one, it will redirect the whole page to
the other domain (naked vs www) instead of just reloading the iframe.
-------------
opw-3079168
closesodoo/odoo#107394
X-original-commit: 0808659dd29db938bb6f8386ee2027eafecb2f0f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Some commands from the powerBox command bar were not working
properly in the e-shop product "terms and conditions" section.
This was due to the isolation of Odoo fields
inside the odoo editor as a all.
Those fields do not always have an editable block element
to apply the command on.
We disable some commands that should not be apear in this context.
We also remove a redundant command (separator) in website pages.
task-2962067
closesodoo/odoo#107174
X-original-commit: 3776faa178314c4df889f4c04cc3931f8bef225c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit enables the use of the option "All pages" when using a popup
snippet.
Steps to reproduce the bug:
- Drag & drop a popup snippet.
- On its option in the right panel, there is "Show On" set by default
to "This page".
- Try to modify this option and select "All pages".
Bug observed: The "All pages" option can not be selected and the "Show
On" stays on "This page".
This commit has been done because since the version 16.0, the footer is
on an iframe [1]. Because of that, the program does not have a direct
access to the footer. This is why it is needed to first access the
top-level document before using the querySelector.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2983822
closesodoo/odoo#107236
X-original-commit: f469385dcfcbd9290c3522422f9e10600bb60b76
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As a fix, this introduces a new option for images in grid mode. When an
image is alone in a column which later becomes a grid item, or when an
image is directly added as a grid item via the dedicated option, the
image used `object-fit: cover` so that when the image is resized as a
grid item, it fits the dimensions of the selected grid area.
This confused some users as the image did not appear the same depending
on the screen size. Indeed, if an image is set to take 5 columns as
width and 3 rows as height, it does not ensure the ratio in pixels to
stay the same depending on the screen size: the grid is always made of
12 columns (so the width of each column depends on the screen width),
while the rows are always 50px tall. We could enforce the ratio of grid
items to stay the same or limit the ratio loss by reducing the 50px
height on smaller breakpoints but that would actually increase another
problem: for colored text grid items, their text would more easily
overflow their fixed area.
In the end, using the grid mode is about compromises, even if it allows
to achieve nice things and to have more freedom. This commit although
adds a new option to mitigate the issue for images: users now have the
possibility to switch the default "cover" mode of grid images to
"contain": in that mode, the whole image will always be visible (and
thus keeps the same ratio) and is just "contained" in the grid area
which is selected as dimension.
opw-3069234
closesodoo/odoo#107172
X-original-commit: faf19ef7f87fc043fb9a814516e01b8eeafd9b61
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: website
Commit [1] introduced the possibility to configure "website filters"
used in the website to display some records dynamically via the "dynamic
snippet" and its variants. One of their field is `limit` which is a max
number of records the filter allows to show (so that the client side
cannot ask for thousands of records). Users can configure the limit used
by a snippet via the editor: they are allowed to choose up to 16, still
safe-guarded by the internal limit configured on the website filter on
the python side.
The problem here was that [2] introduced website filters for the blog
posts but set up a max limit of 6. Thus breaking the editor option if
the user choose a limit between 7 and 16. This commit fixes the issue,
for newly configured snippets (as a stable fix) or for users who would
-u their blog application. EDIT: as the master version of this fix, all
blocks will now use their set limit. We consider that is an acceptable
change after migration that the user can change by himself if he wants
to.
Steps to reproduce:
- Install blog application
- Add a "Blog Posts" snippet
- Set "Fetched Elements" to 10 (there are 7 records in demo data)
=> Only 6 are still shown
[1]: https://github.com/odoo/odoo/commit/0e7640b5f22d2bea04bbe22d3189cff7e03af545
[2]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
opw-2885948
closesodoo/odoo#107179
X-original-commit: 3a3dc8729aa2beec49602fe4c141043f60effdf1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit ensures that when searching on a `inherits` field of
a model (like `name` of `website.page`), it works properly when
`pg_trgm` is activated.
Indeed, `name` is a field of `website.page` record but only at the ORM
level, not in SQL, due to how `inherits` works.
So, when the `pg_trgm` extension is enabled, it will switch from ORM
queries to raw SQL query (to use the native SQL similarity feature and
not our custom python/orm one, as obviously the SQL one is better, more
powerfull/accurate and faster).
But this will actually make the code fail when searching on fields from
a model which has `inherits` and that you search on that `inherits`
model fields.
Note that in 15.2, the `pg_trgm` extension is auto installed when
possible thanks to [1] and [2].
[1]: https://github.com/odoo/odoo/commit/eedf37d6e286b995c47b946be1a6b66817094eff
[2]: https://github.com/odoo/odoo/commit/75e6b645acdc95aece506ce0249fd0760838281c
opw-3063592
closesodoo/odoo#107178
X-original-commit: 3d978caad9de2010603581687ee39a5240b74074
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
When breaking a page from a Carousel or other slider snippet (eg by
hitting the backspace key at the beginning of a page), the editor's
history gets reverted but ends up applying the `active` class to all
pages. This is due is some way to the `_computeHeights` method of the
slider snippet, which applied the class to all pages to observe their
heights, then put them back in place. It seems in the labyrinth of ticks
the history step somehow started from a place where every page was
active, so we reverted back to that. The point where these classes were
applied should have never been observed in the first place since it's
purely technical. Not observing it fixes the bug.
task-3081259
closesodoo/odoo#106986
X-original-commit: be1d93edcfbd496c22a7c988b4570858a3d06c2c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since [1] when the search bar was refactored, images can be displayed in
the autocomplete results, and fallback icons are displayed instead of
images for records that have no images.
However, if no module that participates in the results provides actual
images, then the fallback icons are not displayed at all.
This commit makes the fallback icons displayed only based on the "Image"
toggle option of the search bar.
It also disables the hidden display options and enables the visible
ones.
Steps to reproduce:
- Do NOT install website_sale (which is currently the only module that
provides autocomplete results with images).
- Drop a "Search" block.
- Save.
- Type a single letter in the search box. (e.g. "a")
=> Autocomplete results were displayed without their icons.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2951026
closesodoo/odoo#106953
X-original-commit: 4eecba4c8f5327fd1a137a8d88574c2b6a5eda05
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The comment became outdated:
- For 14.0 and above: mentioned the "Customize dialog" which does not
exist anymore.
- For 16.0 and above: mentioned "Bootstrap 4" instead of "Bootstrap 5".
Related to opw-3056683
closesodoo/odoo#106916
X-original-commit: fe90329ee32f9608c143a9fd658fe2a00712f9e4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit [1] introduced a website tour util to assert the value of a CSS
variable. This was used at the start of theme tours to check we are in
fact on the right theme before starting the tour.
While it's great for those tours when they are started as a test, it was
not meant to be shown to users following that tour. This commit fixes
that. Notice that theme tours are currently broken so the issue was
probably hidden. Those will be fixed at [2].
[1]: https://github.com/odoo/odoo/commit/b29e17765f4e912b2dd472493b5be500b3a32c87
[2]: https://github.com/odoo/odoo/pull/106703
Related to task-3084175
closesodoo/odoo#106756
X-original-commit: 696c45b4e5917d086f60fd960590328b878014f0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the website homepage tour was starting with an
unresolvable "Wait for the editor to be started", useful only for tests.
This commit removes that technical step for user tours.
task-3035156
X-original-commit: d45ce39b2904bcb4335f74fab3c42f3eebf477d5
Part-of: odoo/odoo#106746
Co-authored-by: qsm-odoo <qsm@odoo.com>
When entering edit mode, the navbar is hidden. The problem is that since
the merge of the website-in-backend feature at [1], it is only not shown
via an animation (height 0 + out of screen) but not `display: none`. The
tour system thus thinks it is still shown and keeps showing the related
tour tips.
E.g. with website_sale installed (and no demo data, to have the tours),
go on the shop page, there is a tooltip pointing at "+ New", enter edit
mode => the tooltip is still there and it even prevents to click on
"Discard" to leave the edit mode.
This commit fixes the issue by making the navbar `display: none` once
the closing animations are finished.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3082439
closesodoo/odoo#106735
X-original-commit: cdc8d4c889b316664323afad0d848403960150d5
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
While showcasing your website inside the website application, there is
the possibility to hit the escape key to enter fullscreen (hiding the
backend navbar outside edit mode and the editor panel during edit mode).
There was a problem following this flow:
- Go to your website inside your website app
- Hit escape to enter fullscreen
- Press CTRL-K to switch to another part of the backend
=> You are now somewhere in the backend, without the navbar (fullscreen)
and you cannot exit it.
As it was a one-line fix (except for the re-indentation), this commit
now allows to exit fullscreen mode wherever we are.
Discovered during task-3082439
X-original-commit: bd225ec782e26c87301e9e786ffd7250ad62ebfc
Part-of: odoo/odoo#106735
Quick feedback from client, this is following [1] that added a button
next to the URL input of `we-urlpicket` to be able to preview the link.
The wording was not great, it gives the impression it's an option to
chose to have that URL opened in new tab (eg when form is submitted).
Also, giving it the style of a conventional we-button was also giving
the same impression that it was actually an option that you could click
on to enable something.
Changing the wording and the style of those special we-button should
reduce the confusion.
Arguably, one might think about the usefulness of this button but it
acts as the counterpart of the regular links which have a "Open in new
tab" possibility when hovering the link in their preview tooltip.
[1]: https://github.com/odoo/odoo/commit/acdf3cf7f5aebd803ffa1507e81ed8801727a03a
opw-3060966
closesodoo/odoo#106538
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In this commit [1] (merged in 16.0) a bugfix has been made in the
`removeSlide` function but this one should have been applied on all
supported versions because the bug it fixes is present on all versions.
The bug it fixes is the following:
- Drop a carousel block on a page
- Remove the *first* slide
=> There is no active indicator.
Moreover, the bugfix made in 16.0 [1] introduces another error: when a
slide is removed from the carousel the indicators are not in a correct
state anymore.
Following the same steps with the changes of [1]:
- Drop a carousel block on a page
- Remove a slide
=> Indicators are no longer consistent with the slides so tracebacks
appear during the carousel slides. The list of indicators must have on
each element a `data-slide-to` attribute which must reflect the
position of the slide (starting with 0).
So this commit is to backport the fix from 16.0 [1] to 14.0 and to fix
the new bug that [1] introduces.
[1]: https://github.com/odoo/odoo/commit/f7055d3dbabfbe471f490bd65c2032f5251f3f37
task-3040931
opw-3051615
closesodoo/odoo#106639
X-original-commit: 212e8ce620f6eb95aeff6426e06cb29b2c06d0c1
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:
(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)
- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button
=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.
opw-2967706
closesodoo/odoo#106477
X-original-commit: 076d7ac7795f86d48b532b6c2a1ff76e4503604e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
