This basically reverts [1].
After discussion with the related team, [1]'s purpose was to prevent
merging two links together if backspace was hit at the beginning of one
mega menu item. [1] however made mega menu creation impossible as it
prevented removing any mega menu item (well, you had one possibility if
you used Chrome which was to unlink the mega menu item and then remove
it via backspace but...).
After some more discussion, we decided that allowing to merge mega menu
items seems not bad (it is the same behavior as the rest of the editor
when two links are next to each other). In any case, being able to
remove default mega menu items is more important.
[1]: https://github.com/odoo/odoo/commit/9779145d9157e9687c36d2caa0ecea2862a2ac5a
opw-3109946
opw-3120070
closesodoo/odoo#109804
X-original-commit: 7de359470fb4d8eb81f018262a5e4c66a71c7043
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the title attribute on navbar items.
The title was only repeating the content so it was useless.
closesodoo/odoo#109230
Task: 3097276
Related: odoo/enterprise#35562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When editing a website form, a `search_read` request is fired on
`ir.model` model to get the list of possible form actions (create
ticket, create opportunity, etc.).
But since commit [1] in Odoo 15, non-admin users don't have read access
anymore on this model, leading to a traceback when clicking on a form in
edit mode.
Steps to reproduce (as designer):
- Install only website and login as admin
- Make "portal" user an internal user and give him "Editor and Designer"
rights
- Login as "portal" user
- Enter edit mode on any page and drag & drop the form snippet, or
simply go to /contactus page which already has one
- Click on the form -> Traceback
Steps to reproduce (as publisher/restricted editor):
- Install website_hr_recruitment
- Make "portal" user an internal user and give him the following rights:
- Website: Restricted Editor
- Recruitment: Administrator
- Login as "portal" user
- Go to a job page like /jobs/detail/experienced-developer-4
- Enter edit mode and drag & drop the form snippet
- It will crash
[1]: https://github.com/odoo/odoo/commit/5dc4cff60a557e14b08440c227423291c407899b
opw-3098097
opw-3101884
closesodoo/odoo#109339
X-original-commit: 054c216e93b818794316bfd4b8ce56d6853a61d3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Cannot be used in v16 since some mixin don't exist anymore.
After 4 odoo versions, and now that we use bootstrap 5, we drop the
support of bs3.
closesodoo/odoo#109359
X-original-commit: 2c34fd4f031b006451305c46b99a790540c5e902
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, trying to delete a page from the page manager in
debug mode would throw an error of type "Got duplicate key in
t-foreach".
As explained in this commit [1] and as per the [owl documentation]:
"Owl requires the presence of a t-key directive, to be able to properly
reconcile renderings." and "A key should be a unique number or string."
In our case, "dependency_value" is an array. Due to that, the current
item of the "t-foreach" iteration is the current value. The bug is
fixed by ensuring that the value of "t-key" is the current value index
and not the value itself.
[1]: https://github.com/odoo/odoo/commit/0d1c263298ca6724a6fe6c31e2a2d3221c5e8c75
[owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loops
task-3082345
opw-3100483
opw-3111671
closesodoo/odoo#109329
X-original-commit: f56d5906f845cb45f88d9729b73aa2ed08c551f3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Install the "Surveys" application.
- Go to the "Website" application.
- Go in the page manager ("Site" > "Pages").
- Select a page (typically "Home").
- Try to delete it.
- Error of type "'survey.survey' object has no attributes 'name'".
The error comes from the fact that records do not necessarily have the
attribute called "name". To fix this error, this commit uses
"display_name" that is defined in all models.
task-3082345
opw-3100483
opw-3111671
X-original-commit: d5aa5d7ebf9cd17a6df054252a1313ec8b85e83e
Part-of: odoo/odoo#109329
This commit allows to debounce the events of the RangeUserValueWidget so
that the user can use this widget with the left and right arrows without
having a lag effect (especially on the image quality option).
In addition, steps were added in the website_gray_color_palette tour to
let the time for the debounce to trigger the changes.
task-2601533
closesodoo/odoo#109165
X-original-commit: dddec7489f5cb4e48368684a8783015517c394ee
Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>
Before this commit, the popup snippets were configuring the modal option
for bootstrap 4 rather than 5.
The `data-focus` in bootstrap 4 becomes `data-bs-focus` in bootstap 5.
Without `data-bs-focus` option, the Newsletter popup snippet became
uneditable because any click inside popup changed the selection to be
inside the first focusable element within the modal.
The reason of the input being focused is: upon click inside the modal,
the target of the focusin event is the parent of the modal because that
parent is contenteditable="true". Because that target is outside the
modal, `_handleFocusin` correct the selection by focusing the text
input.
task-3102155
closesodoo/odoo#109148
X-original-commit: bc99f3cdb5c2fca59a24dc4970c9ca6e69721838
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since 2013 we have a kind of a URL hack that allows to redirect to the
initial URL after installing a lang through the website, see [1].
It was even tested in python unit test with [2] but sadly it was still
broken by a combination of [3] and [4] which actually broke it at the
javascript level: the python view was correctly still outputting the
correct URL and the python part was correctly handling that return URL
when passed, but the javascript was not actually passing the URL from
the view/href to the python side as the lang install wizard was now
called through JS instead of a normal backend URL redirect (since the
website frontend > backend imp at [4]).
Step to reproduce:
- Go to any page other than the homepage
- Click on footer > add a language
- Add a language
- You are redirected to the homepage always instead of the URL you came
from
Note that this is only true if done through the backend / iframe preview
as clicking on the "Add a language" from the frontend will work as it
should. Indeed, when clicking on it from the frontend, it's a simple
link redirect but when click in the iframe preview, the click is
preventend to let the JS open the action in the top window instead.
[1]: https://github.com/odoo/odoo/commit/5cfbcc3aff5a28022b397ec7a28ebaca6db43673
[2]: https://github.com/odoo/odoo/commit/269aa594111a152ad4b7714856ea745bfef57155
[3]: https://github.com/odoo/odoo/commit/11429329b8dea2dd0b2496dc8c1c8627751cccff
[4]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#108869
X-original-commit: 05caf6e697461176326ee61beeccb1193472267c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
After [1], most snippet options should use something like
`this.$target[0].ownerDocument` to access the document properties
instead of the global object `document`. This is because the editable is
now inside an iframe.
Commit [2] tried to adapt most occurrences but missed some.
This commit adapts the leftover code and fixes 2 bugs:
1. The SCSS Variable `font` wasn't properly reset when deleting a Google
font that was currently being used, resulting in a `/` being displayed
and the variable having an inconsistent state.
2. In the Chart snippet, the color being used to represent data is
displayed inside the option as a border on the input widgets. It was
currently using Odoo's colors instead of the ones defined in website.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2978623
X-original-commit: 6e0bd78e59b8352d15c9f21bf5f891924d6c3c9f
Part-of: odoo/odoo#108819
When `link_tools` was introduced at [1], `_onURLInput` did only update
the configuration form and did not touch the edited DOM. Even though its
name would be misleading for that purpose, it was therefore used without
issue as an event handler responding to the configuration form input
events and as a private method called in the `start` method of the
widget lifecycle.
At a later stage, with [2], DOM modifications were introduced in
`_onURLInput` (using the misleading `_adaptPreview` method whose
refactoring at [3] made it update the configuration form only in the
case of the "Link Dialog" but update the actual link DOM for the "Link
tools" (website / mass mailing)).
This commit fixes that behavior by touching what is strictly necessary
in stable to keep the original intend of `_onURLInput` (updating the
configuration UI) but at the same time update the DOM following
configuration form input events (as intended by [2]).
In master, all of this should be reviewed.
Here are steps which revealed the problem. Although, meanwhile, [4] and
its parents were merged which fixed other parts of this issue but
keeping the potentially problematic DOM update on selection as described
above. Notice that [4] and its parents may be reviewed further in a
future update.
- Edit Home page
- Drop a "Banner" block
- Select the "Contact Us" button
- Select "Custom" style in the link tool
- Select a fill color
- Deselect the button by clicking on the Banner's text
- Select the button again
=> Button is redrawn without its color
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
[2]: https://github.com/odoo/odoo/commit/226c4c4032c26d3d8f622b29fb151fa8e78ba70a
[3]: https://github.com/odoo/odoo/commit/4a1d776243b059d423152bd026bb8bc758477224
[4]: https://github.com/odoo/odoo/commit/eb4edac560227b46efdcfe958e3b93e0b88def64
opw-3086198
task-3096806
X-original-commit: da25eadde299b81b78d84678978b7e1f703530cc
Part-of: odoo/odoo#108812
Co-authored-by: qsm-odoo <qsm@odoo.com>
The "website_gray_color_palette" tour recently failed 4 times during
staging build on runbot, out of those 4 caught times, it seems that:
A) 3 were because the last step was marked as failed too soon
(screenshots and logs seem to indicate the editor was still loading).
B) 1 was because of a "random" asset error (traceback when lazy loading
the editor JS).
The cause of (B) was not found and should be later investigated if seen
again. This commit tries to avoid (A) which is probably related to a
known issue: when the website iframe has to reload it may sometimes take
more time than is allowed by the default timeout of tour steps. Some
improvements regarding that will be made at [1] and probably by further
PR after that (improving the editor loading speed in general).
Meanwhile, this commit reviews the tour to not save the editor as it was
actually not needed in this tour (nothing has to be saved).
[1]: https://github.com/odoo/odoo/pull/100122
runbot-14112
closesodoo/odoo#108747
X-original-commit: fa1819f09948c64ff7acf634eed075515f6a01d2
Signed-off-by: Quentin Smetz (qsm) <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>
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
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
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>
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>
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>
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>
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>
qsm-odoo