The current implementation of the many2one file upload in website form
will lead to a traceback in case of m2o fields.
It is currently only working with x2many fields. Note that it was
introduced as such with [1].
Step to reproduce:
- install website_sale
- drag & drop form snippet and click on it
- select "create customer" as action option
- add new existing field
- select "Main attachment" and save
- try to submit the form with a file uploaded in that new field
-> Traceback `ValueError: Wrong value for..`
This commit makes it work for all type of relational field.
[1]: https://github.com/odoo/odoo/commit/a77f5cf42faa75a2dd3931d83ad8ea86648248c0closesodoo/odoo#104241
X-original-commit: addea33a8cb6c47bacdbfad0f3082f88763b59ef
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: mass_mailing, website
Commit [1] introduced data-option-name allowing to name snippet options
without data-js so that their automatic snippet-option-XXX class was
not snippet-option-undefined. This was indeed useful to target specific
options in tours.
The attribute is however a complete duplicate of data-js (if you use
one or the other, it does exactly the same thing). Indeed, you can
define a data-js without a linked JS class (as it is already done). And
if you define both expecting the class using data-option-name but the JS
used from data-js that won't be the case, data-option-name is simply
ignored.
This removes data-option-name. This prepares refactorings that will be
done in the future:
- The way to define option in XML will be reviewed (probably client
side definitions, probably OWL templates).
- Adding data-js will probably require a JS class to exist, but all
option definitions of Odoo will declare one to ease extensions and
stable fixes.
Those are theoretical at this point though. This commit main focus is
simplifying the code.
[1]: https://github.com/odoo/odoo/commit/7b0a147cd43e8e890ebe5a882292a69a5c8c90acclosesodoo/odoo#103988
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.
This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.
Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:
- Current height is 700px
- There is some code that forces a min-height on all carousel items so
that they are the same height. As the gallery image dimensions depend
on the block forced height (this is how the snippet work), the forced
min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
is already set)... it ends up removing it as it thinks that setting
that height is not needed as the snippet is now "naturally" 800px tall
thanks to the carousel items' min-heights.
opw-2838774
closesodoo/odoo#104068
X-original-commit: d4d0da320d42093e720c7d440cf6611249c0295a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Both dynamic snippets and visible on mobile use the `d-none` class:
- dynamic snippets activate it by default and only remove it when the
content is ready to be displayed
- visible on mobile makes the section `d-none` when it must be hidden on
mobile and the class is contradicted by another class which is only
taken into account non-mobile
This commit introduces a dedicated class to temporarily hide the dynamic
snippets.
task-2930503
closesodoo/odoo#103637
X-original-commit: 7b3be2f183f53bfcb5f365a2c26127da0702dc15
Related: odoo/upgrade#3980
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit there was an issue with the header effects (except
the 'Scroll') if the page did not have much scroll height when the
header decreases in height when scrolling down. When this issue appeared
it was impossible to reach the bottom of the page.
This was due to the fact that when the header size is smaller when
scrolled (e.g. height scrolled logo option), the padding-top of the
`main` is decreased and therefore the scroll height of the page too..
Which meant that, during the transition that changes the height of the
header, this decrease in scroll height immediately increase the height
of the header, then decrease, etc. in an endless loop.
This commit fixes that by no longer triggering an animation that changes
the height of the header if the scroll height is too short.
This commit also fixes an issue with the standard effect which was not
properly destroyed and left a 'translate transform -100%' on the header
when changing the "standard" effect to a "scroll" effect and the page
was scrolled.
opw-2812482
closesodoo/odoo#103804
X-original-commit: 46993910eb31e9cbaf60a7d4e4c3014d60e7bb2b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This `s_social_media` snippet option uses a variable defined in the
module's scope to store social media values. This
reduces the amount of RPCs needed to fetch the data as they will only be
done once per edition.
Prior to commit [1], this cache would only exist as long as the page
lived. Which means that switching website, switching page or going in
the backend would reset its value. Commit [1] moved the edition in the
backend which means that the cache would persist between pages but more
importantly, between websites, only resetting if the backend was
refreshed or left.
Steps to reproduce:
- Go on website 1
- Modify the URL for facebook in the footer
- Go on website 2
- The value is the same when it should still be facebook.com/Odoo
This commit fixes that by resetting the cache when the editor is
destroyed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#103689
X-original-commit: 3efb726575679f62f9ee2894193323bfe45d7938
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1], there would be a traceback due to a wrong DOM selector in the
`configurator_tour`.
Indeed, completing the configurator will activate the configurator_tour
asset which is calling a broken clickOnSnippet tour util to generate an
appropriate homepage tour.
It would end up with the following selector:
`o_website_preview[data-view-xmlid='website.homepage'] iframe #wrapwrap .#wrap > section:nth-child(2)`
See the `.#wrap` which is incorrect and make jQuery crash.
This is because [1] adapted the tour utils to the new WebsitePreview
client action, but the clickOnSnippet function was wrongly changed and
could now be generating wrong triggers selector.
It was creating invalid selectors as it was concatenating a `.` with the
provided string parameter which was basically a class without the `.`,
like `s_popup`, but not in all cases. A whole valid selector could also
be provided, meaning that concatenating it with a leading `.` would
result in incorrect selector.
Basically, this commit revert the change made on [1] in `clickOnSnippet`
to restore the code of [2] that was preventing the wrong selector
creation.
[1]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35
[2]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
opw-3026167
closesodoo/odoo#103651
X-original-commit: 26c4e4a13b642e2856495a8c1f5a36afe3996c02
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website, test_website
Before this commit, the LinkPopoverWidget element was not positioned
correctly in mobile edition.
With [1] that introduced the website edition using an iframe, the
element was appended on the global document, outside of the iframe, so
that it was not overlapped by the snippets manipulators (that were also
in the global document).
But Bootstrap popovers are not meant to be used "on top" of iframes.
Bootstrap uses the container's ownerDocument to compute placements, and
does not take into account whether or not the target is located inside
an iframe (therefore, skipping the iframe's offset and dimensions in the
placements computations).
This was leading to a visual bug in mobile edition: the iframe top, left
values were not computed by the popover, and it was not positioned
correctly.
Since [2] moved the manipulators inside the iframe, the popover can be
initialised using its target ownerDocument body, without being
overlapped by the manipulators.
Styles are adapted so that the popover stays consistent in the frontend
and the backend, and a container option is added to the widget so that
the element can be placed with other snippets manipulators from the
website builder.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a
task-2687506
closesodoo/odoo#103562
X-original-commit: 931d488af0d4dce529e4ea4ab3c8b827bda0d699
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Younn Olivier (yol) <yol@odoo.com>
When the dark mode feature was merged with [1], it adapted the
EditWebsiteSystray item with the 'text-reset' class.
But this class was not removed if the website was translatable, and it
was not added on the TranslateWebsiteSystray item, which was leading to
wrongly colored systray items on a translatable website.
[1]: https://github.com/odoo/odoo/commit/ee3aa3054cdd715720466863239d5aa56186946c
X-original-commit: 9bc4987d8a4a3d1e5ff31d6e2fd3ea4b453fe21c
Part-of: odoo/odoo#103562
Before this commit, the "page anchor" option of the link editor did not
work in Website. Choosing an anchor did not update the link in the DOM.
task-2900529
closesodoo/odoo#103366
X-original-commit: b24b87a688bafac459bdc6ea698378189a1bf071
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This commit removes the path part of the reloaded page after a module is
installed from the website editor so that it lands on the root page of
the website, when the current page is a 404.
Steps to reproduce:
- Access `/@/a`, an undefined page.
- Edit.
- Discard.
- +New.
- Install Blog.
=> Reloaded `/@/a` but without its assets generated.
closesodoo/odoo#103345
X-original-commit: 886900c33d18f647016e596ba41c193f5fcf8a43
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website_blog, website_crm_partner_assign, website_customer,
website_event, website_event_exhibitor, website_event_meet,
website_event_track, website_forum, website_hr_recruitment,
website_membership, website_sale, website_sale_loyalty,
website_sale_slides, website_slides, website_slides_forum
With commit [1], the "customize_show" options were moved in edit mode.
They were wrongly displayed for non-designer users. Trying to use those
would throw a warning at the user.
[1]: https://github.com/odoo/odoo/commit/17a8a37e9bfc5b787d9666597d43e63f0064919fclosesodoo/odoo#103142
X-original-commit: f2ca62a4a9ccb6713a39c100fc87c112619eac41
Related: odoo/enterprise#32768
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
`is_view_active` relies on the `website` specified in the context.
This commit turns `is_view_active` to a model method, to avoid that its
callers think the `website` on which it is called is the one used.
closesodoo/odoo#103126
X-original-commit: 52d436706bf650bb14f2bc2a398d107ff99f81ea
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Previous commit adapted the URL dependencies screen following the
website frontend > backend merge done at [1] and [2].
It allowed to pass other records than website.page and also added the
multi record capability.
This commit is going a step further, by searching for the URL in all
HTML fields and not only views + pages + menu + blog.
It also let the XML take care of the wording instead of the python.
closesodoo/odoo#103136
X-original-commit: 6ac17b93437868cbefbe13448a6fcbb29953f221
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This is following the website frontend > backend merge done at [1] and
[2].
Before that improvement, the old page manager had a button to delete a
page which was behaving as the one in the page properties dialog: it was
showing the list of (possible) dependencies as a confirm step.
But since [2], that delete button was removed as the action menu of the
list view already has a delete button, which is better as:
- It is hidden and take no space, deleting a page is rare
- It is known by odoo users as all list views have that button
- It handles multi delete
So this commit basically just restore that delete warning step for that
list view delete button, and also make it possible to use that
dependencies warning dialog for multiple pages, not only one.
It also now handles records in a generic way, not only website pages.
It's needed because now, all the main Odoo frontend records are sharing
a list view mixin (see `js_class="PageListController"`).
It also fixes the fact that the text of the collapse were inside a font
awesome class, basically using a weird font.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/940f4ee875332dafa1f379970a7683be6b3ee606
X-original-commit: 11db2f6ed81419ac724ff27ac95a4438d670cbd5
Part-of: odoo/odoo#103136
This is basically reverting commit [1] which was done a few years ago
as improvement to [2], but it was a bit overkill IMHO.
Indeed, there is a sort of hack when creating a page with special
extension like "my-page.js" that will actually create a special page
with special arch. The goal is for such pages to be `t-call`ed later.
That's commit [2].
On top of that, when deleting such a special page, we introduced a
mechanism to show the views and pages that would possibly `t-call` the
that page which is requested to be deleted.
That's commit [1].
It basically is mimicking what was already done when you change the URL
of a normal page, we tell the user where that url is actually possibly
used.
But since the recent improvement in Odoo 16 done at [3], the page
manager is now a backend list view. It means that multi delete is now a
thing.
Thus, the page dependencies behaviors (key and url) need to be
refactored to handle multiple given URL/Key and not just one.
We choose to remove the key dependencies part (only used for those
special pages) instead of adapting it:
- That 'hack' is probably almost never used
- It's some code to maintain, eg now we need to refactor it
- We would need some extra code to make it only triggered for website
pages and not all records, unlike the url dependencies screen which
concerns all records
- That's an advanced feature (special pages), if you are using it, you
probably knows how to handle a website and you don't need us to remind
you where this special page's view is used.
[1]: https://github.com/odoo/odoo/commit/a91a3a563338e746d6d23cd57551af30e322e367
[2]: https://github.com/odoo/odoo/commit/727d461e1d2bcec4571665b90b6d1630f671a0a3
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 77f03abc56b147171eeba66bc55df5ee92c8af1a
Part-of: odoo/odoo#103136
Some snippets have a "hard coded" background color which doesn't change
when we want to put a preset color (theme). We have to delete the back-
ground first before being able to choose a preset color.
This commit fixes this behaviour by putting a preset color by default
on the concerned snippets (instead of a fixed color). These snippets
are searchbar and text highlight.
task-2824393
closesodoo/odoo#103123
X-original-commit: 4a1442679bb1058d08428e08bec3433e968fb64b
Related: odoo/design-themes#604
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The Masonry and Big Boxes snippets don't have a background option
because their blocks are supposed to take the whole space, so a
background is not really necessary. But since the addition of the grid
mode, these blocks can be placed more freely and a background may
therefore be necessary.
This commit adds the background option to these snippets.
task-3014939
closesodoo/odoo#103109
X-original-commit: 019f6824caafdf2cdc79babcbe45af3db0df1550
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_event
The 'website_event.menu_edit_menu' menuitem was added on 'website_event'
module to the 'custom menus' registry so it can be displayed by the
'website_custom_menus' service if the event page has menus to edit.
The goal of this commit is to move this code to 'website' by using a
generic 'custom_menu_edit_menu' menuitem that will be cloned to edit
every content menu on the current page with the corresponding
'EditMenuDialog'. This is needed as a fix as it would be a regression
to not have this in 16.0 since it was possible to edit any menu on a
page in previous versions.
task-2973149
closesodoo/odoo#102997
X-original-commit: 6af5ad67c9657c7dcaf4afa1ecb4561e9c72270a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
make searching translated field language dependent
add an extra filter using trigram index to speed up '=' and 'like' search
X-original-commit: 5b6f0a9e5f9d60735e306709a3e7d7ac46a586be
Part-of: odoo/odoo#103031
Before this commit, there was a conflict between 2 of the ways to open
the WebsitePreview iframe.
First, introduced with [1], when a user click on the 'edit in backend'
systray button, the URL he was on is stored to be used later if the user
click on the "Website Preview" breadcrumb. When he will click on that
breadcrumb entry, we want him to go back to where he was, not on the
homepage.
Second, some records in form views have a "Go to website" stat button
that will go to the website preview action, loading the iframe with the
URL of the record from the form view.
Before this commit, the second flow was not working if the user
previously click on "Edit in backend" on a record (first flow
described).
Indeed, if that "last url" was set, it would always be used, ignoring
the requested one from the second flow.
Step to reproduce:
- Go to a record in the website preview, like a product
- Click on edit in backend
- You land on the product form view, and that url was saved in JS
- From there, navigate to another record through the form view, like a
m2o relation or a stat button, or by whatever other mean, but don't
hard reload the page (F5)
- For the example, let's say you landed on a blog post record
- Click on "Go to website" on that blog post form view
-> You land on the product page you were initially, not on the requested
blog post page.
Courtesy of @rdeodoo
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#103010
X-original-commit: 7cd55e8a1d9516a6f457320064160328a49210f9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Instead of having a dedicated module for all-things dark mode related,
this commit moves the (S)CSS files into their respecting modules and
uses `web` and `web_enterprise` to provide the base infrastructure for
the dark mode (cf. dedicated assets bundle).
Note:
Don't forget that you have to handle 2 cases:
1: SCSS variables must be placed BEFORE bright ones
2: CSS variables must be placed AFTER
task-2710677
Part-of: odoo/odoo#102868
Move the file in a more convenient place to be shared and customized to
match different color schemes.
Commit preparatory to the introduction of dark-mode.
task-2710677
Part-of: odoo/odoo#102868
Before this commit, some functions overrode the save function of the
form controller. The issue is that this function is only called when the
button save is clicked, and not when we save differently (for example,
when clicking on the breadcrumb).
To avoid this mistake the save function on the form controller was
renamed to: `saveButtonClicked`, and the code that overrode the function
now override the save function of the Record, that it's called at each
time a save is perform.
X-original-commit: b6e3d833e6131562084eb13b2955c22f50ad1e79
Part-of: odoo/odoo#102992
*: website_forum, website_hr_recruitment, website_sale
Before this commit, most of the backend redirections to the
WebsitePreview, introduced in [1], were using ir.actions.url with the
get_client_action_url util, which was not optimal.
This commit changes that to use a new get_client_action method, which
returns the ir.actions.client record. It will execute the action
directly, avoid to redirect the router before, and improve performances.
Also, it allows to solve bugs, as:
- The back navigation from the WebsitePreview to the ListViews.
Going through the /web controller would add an entry in the history, and
going back on it would reload the client action.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102991
X-original-commit: 30fb11e479fb7b3db3649e55fcbdb06bfcdb398c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit at [1] factorized some code and in the process used a service
that was not declared. This prevented to use the "add page" dialog
(which allows to create pages via the "+ New" button) to create special
pages ".js", ".css". That feature will likely be removed or reworked
in a future update though.
[1]: https://github.com/odoo/odoo/commit/58698f848703395ff680bc7586ecc8eec4fb61ae
X-original-commit: 21b90ff8bdad22b6beea1b6b5a6d70276817c00e
Part-of: odoo/odoo#102991
Since [1], the Masonry snippet is in grid mode only and its templates
have been modified to allow this mode. However, some of them don't look
good and have to be improved.
This is what this commit does:
- some text blocks were too small so their height has been increased
- the Masonry second default image has been replaced by another one
that looks better.
[1]: https://github.com/odoo/odoo/commit/85b352af319edec84407f2046cf795b4e5503460
task-3013055
closesodoo/odoo#102984
X-original-commit: ad8926eafd34c2743e1a5247f6171fd183e6e506
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes the behavior of the website app when creating content.
Since commit (1), once a new record was created, it was no longer
redirected to the correct page. Now, this behavior is reintroduced and
works as expected.
(1): https://github.com/odoo/odoo/commit/916a5bebb3e74047a66503ddc59299540c252831closesodoo/odoo#102959
X-original-commit: 7cfe4523d18989b0273a026000109617bbfb2d13
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In PR https://github.com/odoo/odoo/pull/101763 the page_kanban template
in website has been changed because it was thought that the xpath was
meant to be inserted in the default slot.
However this wasn't the case (we want it applied to the Layout) so it
crashed the view.
This commit restores the proper xpath.
closesodoo/odoo#102942
X-original-commit: 631d552fc6d6279fd2564fffeb30d099abd767c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The goal of this commit is to add some fixes on page properties dialog
after the Owl REF [1].
- XML: use default form view style (remove </group>).
- Move the '/' back into the non editable part of the URL.
- Prevent python code from creating a different URL (and optionally
setting "website.rewrite" record for it) when the new URL is the same
as the initial one after slugify.
- 'useAutofocus()' on the first page properties field.
[1]: https://github.com/odoo/odoo/commit/61a9d7bd2abc6081b321a51d329f9e85209215e5
task-2687506
closesodoo/odoo#102869
X-original-commit: 1165dfcd4fd5677d14f3d3329ad7c62be847b31a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the Plausible dashboard height was hard-coded to avoid the
display of a scrollbar on the iframe.
In case the Plausible dashboard height grows in the future, it will not
be possible to scroll to the bottom elements.
This commit virtually restores the scrollbar, so that in case the
Plausible dashboard grows in the future, the scrollbar will appear and
still give access to the whole dashboard.
[1]: https://github.com/odoo/odoo/commit/b8c1976e933628182496929d348dda11b5051a0c
task-2993773
closesodoo/odoo#102852
X-original-commit: 616eb5384df085fdc94cb18ab8e14336f9b68702
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The website edition system is based on a main mutex to guarantee the
order of user manipulations. Meaning that if an user follows any flow
really quickly, each part of the flow should be guaranteed to be done
in the order the user asked for, independently from the duration of each
part. The mutex system to ensure that is not robust yet though, or at
least it is not easy to use and should probably be replaced by something
more easier to use in the future. Indeed, some operations are badly
implemented around this mutex.
This is the case of the drag and drop of a snippet into the page. Drag
and dropping a snippet is a long series of operations, to name a few:
1. The user mousedown on a snippet thumbnail
2. The user drags the snippet around
3. The user drops the snippet in a dropzone
4. We scroll the page to the position of the snippet
5. The snippet is built (options' `onBuilt` methods)
6. The snippet public widgets are started
That whole series of operation has to be reduced to an atomic work to
be added to the mutex queue. Meaning that for example, if the user
manages to click on the save button while he is dragging a snippet
around... the editor should only save the page after the whole series
of operations of the drag and drop has completed. This is not the case
right now: the mutex lock is released between (4) and (5) because we
have too: (5) and (6) use the mutex themselves and would thus induce
a deadlock if we only release the mutex after (6) as it should be. This
means that during the scroll to the snippet (4), if the user manages to
click on the save button, the save operation will be scheduled to be
done before (5) and (6). It is thus technically possible to save a
snippet which is not built** (even if it would not be critical most of
the time). Worse, before building a snippet, its options have to be
instantiated... and that operation is not mutex protected so this is
probably (not 100% sure) possible that this happens:
a. Drag and drop a snippet. During the scrolling, click on save.
b. End of scrolling, the mutex lock is released, we create the first
option and its widgets as part of the onBuilt process. Creating each
widget is async, once the first one is created, the saving process
starts as it was scheduled in (a).
c. Saving the content, destroying all snippet options and their widgets.
d. Continuing building snippet options widgets started at (b)... but
previously-made ones were destroyed at (c)... possible crashes***.
Fixing all of this probably requires a change in the system, maybe the
use of multiple mutexes, maybe the saving operation can always be
delayed at the end of the queue somehow, ... but this requires some more
thinking and probably not possible in stable. In stable, it could be
enough to disable the saving entirely during drag and drop (like drag
and drop of another snippet is currently disabled during another drag
and drop). This will be done in another commit if this is decided.
Meanwhile, this commit just changes the behavior in tours for now:
waiting for drag&drop to fully complete before clicking on save, like
an human would.
** It is possible to reproduce by using the ALT + S shortcut: start
dragging a snippet which has a onBuilt method in its options, hover
the dropzone where you will drop, ALT + S to save (the editor waits
you drop your snippet), drop your snippet -> the snippet is saved and
the edit mode is left... but the onBuilt was not executed.
*** a crash was indeed found during a specific theme tour (out of ~30
Odoo themes because of this after the other commit of this current
PR). After those other commits especially, it is also possible to
reproduce with the ALT + S trick, although not consistently. It may
be linked to the specific last snippet added by that theme tour
instantiating specific options. But as explained saving just after
drop is an issue independently from this potential crash problem
(snippet not built, etc).
X-original-commit: e96167ae20d2a143d7def4347166b37e158003b0
Part-of: odoo/odoo#102800
Prior to this commit, the language of the snippet menu would be the same
as the snippet content. This would cause issues if the user's language
was not the same as the website they were editing.
This commit fixes that by displaying the snippet menu in the user's
selected language but getting snippet content in the website's language.
This commit also fixes SEO data not being saved according to the
website's displayed language. Prior, it was saved according to the
user's current display language.
This commit also introduces a test for a fix made at [1] that
targets a previous version of odoo.
[1]: https://github.com/odoo/odoo/commit/db5d1eae2086ff338d8211af70c2f88240393c36
task-2687506
closesodoo/odoo#102799
X-original-commit: 55a978aa86967581956f855a1c5db33b7425bd15
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit [1] keeps the snippet cache alive through different
instance of the website snippet menu.
This allows for the user to switch pages, even apps, while
keeping the snippets in cache, decreasing the startup time of the
snippet menu.
However, the cache is not invalidated when switching website or
installing a new theme.
This commit adds a `invalidateSnippetCache` property to the
websiteService. If this property is set to `true`, the cache will be
invalidated next time the menus loads its snippet.
This property is currently set to `true` when changing website and
switching theme.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-2687506
X-original-commit: bb503962a36f3798c50049f2844e7b288b632955
Part-of: odoo/odoo#102799
This commit allows to regenerate the connectors of the step block when
one of the columns of the block is duplicated or deleted.
Steps to reproduce the fixed bug:
- Drop a steps block
- Duplicate one of the columns
=> The last column of the first row has a connector to the right of the
page.
closesodoo/odoo#102797
X-original-commit: 56522f4a26c95878bb726f54eb02c8c948576875
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
For the "+New" button, a `get_modules_info` route was added because the
information cannot be built-in the page by a server-side QWeb template
anymore.
This commit removes this route and replaces it by a call to the default
`search_read`.
task-2687506
closesodoo/odoo#102791
X-original-commit: 7f83e398b68d7c7544753e2b8bb1b334fb5f7036
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit includes several changes in the Plausible dashboard:
- Remove the "Analytics" title.
- Add margins (container-fluid => container).
This also fixes the country map overflow and the flickering.
- Remove the duplicated scrollbars.
- Use the background colors from within the iframe.
- Hide the date range buttons by default, but show them if website_sale
is installed.
It also reorders the Reporting menu as follows:
- Analytics
- eCommerce
- Online Sales
- Visitors
- Page Views
task-2993773
X-original-commit: b8c1976e933628182496929d348dda11b5051a0c
Part-of: odoo/odoo#102782
While working in the current state of the website configuration, the
overlay computation was not working anymore in case the scrollbar is
moved out of the wrapwrap. Indeed, in that case, the position was wrong
by the amount of the page scrolling.
While we could include that scrolling value in the equation, this commit
chooses to restore the way it worked before the "website-in-backend"
merge at [1]: making the overlay be naturally positioned according to
the page scrolling wherever the scrollbar is. To do that, the overlay
had to be moved inside the content (the website iframe) which has the
disadvantage of risking the overlay design being broken by a theme. This
solution was chosen as it simplifies the code, and potentially allows
for performance improvements in the future: not forcing a position
recompute after each scroll (the animation should already be smoother /
more performant this way). This will actually be needed for another fix
/ improvement: the background image overlay has to be in the iframe too.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#102785
X-original-commit: 872bb20b3ac08cf82613e15e6634a2e7593ccf7a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
An option to edit tables via a specialized overlay was made with [1] for
the backend edition of HTML fields. It was indirectly added for the
website builder where an UI to do that already exists (in the editor
panel). It is actually a problem because of the way it was implemented:
- Rely on the fact this is not the `<html>` which scrolls (which cannot
be considered necessarily true and won't be true by default in a
future update).
- Use 'visibility' property instead of 'display' to hide the UI making
the UI participate in the rendering of the page at all times (and when
the `<html>` scrolls actually shows a white bar at the bottom of the
website page).
It was decided we do not want this UI on the website side. This commit
takes the easy road: just force the fact it is hidden. Indeed, not
instantiating it comes with a bunch of problems as the related code is
spread throughout the editor code. A better implementation will follow.
Note: a further commit will move back the scrollbar behavior out of the
`#wrapwrap`, this is thus especially needed.
[1]: https://github.com/odoo/odoo/commit/7a64a04421171469c58bb94bbe8c55b1e2fdf3f2
X-original-commit: 8c1a719674315eadb6d8f6c925cc4303227fad67
Part-of: odoo/odoo#102785
Reproduce:
Go on a kanban view, with enough columns so it goes off the screens.
Scroll on the right, try to drag anything beyond the original (before
scrolling) limit of the screen. The cards are stuck floating at that
limit. Note it didn't prevent the drop to work properly where the mouse
was.
Issue:
The useSortable hook gets an owl ref, which is used as a limit to where
things can be dragged and dropped. Originaly and logically, it was the
current component ref, the renderer. But for some unknown reason, this
space was not getting wider than the initial screen size. It may be a
problem with the flexbox layout.
Tried solutions:
- A first solution was to add the overflow-x-scroll css property to the
renderer. It works, but now the horizontal scroll bar is no longer
always visible. You have to scroll all the way down to see it. UX wise
this is not acceptable.
- We could remove the clamp mecanism inside useSortable to let the drag
and drop motion go anywhere. This works, but decrease the quality of the
interaction. It looks cheap and not polished.
Final Solution
Finally, we decided to pass a ref to the o_content div from the layout
component down to the kanban renderer. If the useSortable is given this
ref, it works as intended. While it may seem too much, it is not
unreasonable to propose a reference to the most parent element of the
view contents to the renderer.
X-original-commit: a569305acaa1c812ede739c267e2e9530945f65f
Part-of: odoo/odoo#102756
Before this commit, the autocomplete dropdown no longer had a maximum
height, which meant that when it contained a lot of elements, it hid the
entire editor panel.
Indeed, since the CSS of the menu snippet is no longer that of the
"frontend", the 'max-height' CSS rule defined for the autocomplete
dropdown in the frontend (introduced by this commit: [1]) was no longer
applied on the autocomplete dropdown of the backend.
In this commit, we therefore moved this css code of the
'ui-autocomplete' defined for the frontend into the common css file
(backend + frontend) in order to return to a situation where this code
was applied to all autocomplete dropdowns in Website. And thanks to
that, we were able to remove the css file "edit_menu.scss" which
copied/pasted the frontend 'ui-autocomplete' code for only one of the
backend 'ui-autocomplete'.
[1]: https://github.com/odoo/odoo/commit/032dd007157de00b683a9d753aa929741c107c01
task-2900529
closesodoo/odoo#102719
X-original-commit: cce26d7697c73326e0a6f2ec81e01b56b4156ad4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The /web loading was slow during test when some themes are installed.
This is because without any context and request, the assets are
generated for website 1 before this fix.
With this default website:
_get_active_addons_list returns only addons that are not themes
_get_asset_paths will return less assets
When loading /web, no website is found because the domain is not empty.
This means that the web.assets_backend will have less assets when
generated outside of a request than in a request not matching any
website.
There is normaly no assets for the backend in theme BUT a tour is added
in each theme
('/theme_anelusia/static/src/js/tour.js', 'theme_anelusia', 'website.assets_editor')
('/theme_artists/static/src/js/tour.js', 'theme_artists', 'website.assets_editor')
('/theme_avantgarde/static/src/js/tour.js', 'theme_avantgarde', 'website.assets_editor')
('/theme_aviato/static/src/js/tour.js', 'theme_aviato', 'website.assets_editor')
('/theme_beauty/static/src/js/tour.js', 'theme_beauty', 'website.assets_editor')
('/theme_bewise/static/src/js/tour.js', 'theme_bewise', 'website.assets_editor')
('/theme_bistro/static/src/js/tour.js', 'theme_bistro', 'website.assets_editor')
('/theme_bookstore/static/src/js/tour.js', 'theme_bookstore', 'website.assets_editor')
('/theme_buzzy/static/src/js/tour.js', 'theme_buzzy', 'website.assets_editor')
('/theme_clean/static/src/js/tour.js', 'theme_clean', 'website.assets_editor')
('/theme_cobalt/static/src/js/tour.js', 'theme_cobalt', 'website.assets_editor')
('/theme_enark/static/src/js/tour.js', 'theme_enark', 'website.assets_editor')
('/theme_graphene/static/src/js/tour.js', 'theme_graphene', 'website.assets_editor')
('/theme_kea/static/src/js/tour.js', 'theme_kea', 'website.assets_editor')
('/theme_kiddo/static/src/js/tour.js', 'theme_kiddo', 'website.assets_editor')
('/theme_loftspace/static/src/js/tour.js', 'theme_loftspace', 'website.assets_editor')
('/theme_monglia/static/src/js/tour.js', 'theme_monglia', 'website.assets_editor')
('/theme_nano/static/src/js/tour.js', 'theme_nano', 'website.assets_editor')
('/theme_notes/static/src/js/tour.js', 'theme_notes', 'website.assets_editor')
('/theme_odoo_experts/static/src/js/tour.js', 'theme_odoo_experts', 'website.assets_editor')
('/theme_orchid/static/src/js/tour.js', 'theme_orchid', 'website.assets_editor')
('/theme_paptic/static/src/js/tour.js', 'theme_paptic', 'website.assets_editor')
('/theme_real_estate/static/src/js/tour.js', 'theme_real_estate', 'website.assets_editor')
('/theme_treehouse/static/src/js/tour.js', 'theme_treehouse', 'website.assets_editor')
('/theme_vehicle/static/src/js/tour.js', 'theme_vehicle', 'website.assets_editor')
('/theme_yes/static/src/js/tour.js', 'theme_yes', 'website.assets_editor')
('/theme_zap/static/src/js/tour.js', 'theme_zap', 'website.assets_editor')
Making the bundles for /web different with or without theme, and with or
without website id.
The proposed fix wont return a website if not specified in context and
if not during a request and if not forced to fallback.
The side effect is that the frontend assets where generated with a
website id 1 before that and it won't be the case anymore. This may be
a problem that could slow down frontend call on website 1 when design
theme is installed.
closesodoo/odoo#102690
X-original-commit: a5ed957b37b966bc50ed1219b6af65ed818f04a0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The tour contains this part:
1. Change the font-size
2. Click on save
3. Check that edit mode was left
4. Check the font-size is ok
The problem is that step 1 induces a series of RPC and processing
(rebuilding assets, reloading them in the client, etc) but those are
not awaited before going into step 2 which also induces a RPC (the save)
which is only done once the other RPC are finished.
While we will try to optimize the duration of those RPC in the future.
Meanwhile we could simply increase to the timeout of step 3 but it seems
better to change the tour to divide the multiple things to await:
1. Change the font-size
2. Check the font-size is ok
3. Click on save
4. Check that edit mode was left
5. Check the font-size is still ok
runbot-4706
closesodoo/odoo#102609
X-original-commit: c2bc6c2f8446e98c8a4089daf048e67457be277f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
In [1], the resizing and the drag and drop of a grid item both put
it in front of all the other items and in front of the background grid
(thanks to the `z-index` property).
This commit changes that behavior: now, the grid item stays at the same
z-index if we are resizing it or if we are dragging it over the grid
from which it is coming. In the case of a drag over an other grid, it
is placed in front of all its grid items. In all these cases, the grid
item is placed behind the background grid.
[1]: https://github.com/odoo/odoo/pull/93144
task-2973198
closesodoo/odoo#102525
X-original-commit: 67d1b078329600efce414974307d74e9fa9ba9fe
Related: odoo/design-themes#601
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Wolfgang Taferner