*: website_mass_mailing (tests)
- Web Editor facts:
Since the refactoring of the editor done at [1], the cookies bar popup
is receiving a `contenteditable=true` attribute, making it receive the
chrome default `height` style for such elements.
The problem is that if this cookies bar's modal is hidden, the bar will
be shown as a thin empty white bar.
- Website Builder / Popup Snippet / Cookies bar facts:
A popup element is composed of a `.s_popup` parent containing the actual
`.modal` BS modal. Our internal logic and events are hiding and showing
this inner `.modal` modal element without considering its `.s_popup`
parent. It means that when the `.modal` is hidden, its `.s_popup` parent
is not touched and kept visible.
It might looks like it's not an issue as it would just be an empty
element (its only child is hidden) but it leads to some issues as
explained just above: an ugly white bar is shown.
Note that the cookies bar is nothing more than a `.s_popup` snippet.
- Web Editor facts 2:
During the mentioned refactoring [1], they actually added some code to
hide this bug once you were playing with the edit mode (mainly for when
you clicked on the invisible panel element or before saving).
But this code was actually not fixing the case when you just entered
edit mode.
This commit simply remove that "edit only" web editor logic and add a
new one in charge of simply synchronizing the `.s_popup` snippet
visibility with its `.modal` BS modal in a public widget (which is
obviously also executed in edit mode).
Finally:
- note that if there is no way through regular flow to arrive to the
same result with a normal popup snippet, it is still concerned by this
issue and you can reproduce it by moving it somewhere else in the DOM
and/or simply adding it the `contenteditable=true` attribute.
- we already fixed that issue a few months/years ago, I couldn't find
a commit related to that so I don't know if it was due to the same
root cause
- in case one is wondering why we simply couldn't do that in the already
existing `_onHideModal` of the `PopupWidget`, it is because that
`hide.bs.modal` is not called when entering edit mode, because the
`destroy` is destroying it before hiding the modal. The event is thus
not fired. And we can't move the hide part before the destroy's super
because otherwise, it would go through the normal hidden process which
is creating a "seen" cookie for the popup as if it was closed
manually.
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
task-2754108
closesodoo/odoo#105553
X-original-commit: 21a5e7000f08fbd1936173937c7d90b152a5414f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Currently entering custom urls will be missing characters if they
contain unicode.
Steps to reproduce:
1. Open Promote dialog
2. Enter a custom url that contains unicode (e.g. `Nội dung có Dấu`)
3. Output: `n-i-dung-c-d-u`
Expected output after this commit: `noi-dung-co-dau`
closesodoo/odoo#105195
X-original-commit: 3c1cd65e2eb44c5d2cb695afad19c58f24bde8b1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Part of [1] was lost during the frontend>backend merge [2].
The SEO name field was not "slugified" anymore in JS, it led to 2
issues:
- Bad UX, one could type something and it would end up after save with
something completely different
- 404/crash: as the generated URL in js (based on the seo name value)
would not be slugified, it would redirect to that URL, which would not
be found as the record URL in python would be slugified. There would
be an URL mismatch between the python route and the JS redirect value.
This could still somehow happen as the JS and PY slug are not doing
the exact same things but at least this will restore what we had
before and mitigate the issue.
Step to reproduce:
- Go to a blog post and open the SEO dialog
- In the custom URL input, type "créé"
- You will be redirected to `/@/blog/travel-1/créé-1`
This will be a 404 page, as the correct URL is now
`/@/blog/travel-1/cree-1`.
[1]: https://github.com/odoo/odoo/commit/c387ec19b4648ae52bf3210253febd7825745627
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
X-original-commit: 3c266751c41ab0a96494ccd6cd1a1fff3a6a7058
Part-of: odoo/odoo#105195
Before this commit, following these steps:
- Go to /blog
- Activate the option Customize > Top banner - Name / Latest Post
- Disable the option Customize > Full Width Cover
The URL to which we are redirected when we click on the category of the
post presented at the top of the page leads to an error. In order to fix
the wrong url we had to patch QueryURL so that the url prefix is added
only if the url does not already start with the prefix.
opw-2882492
X-original-commit: https://github.com/odoo/odoo/commit/2b326de107b9b7a2013ee9ff174d81b645d6a623
Part-of: odoo/odoo#104639
*: test_website, website, website_blog, website_event, website_forum,
website_sale, website_slides
Reverts this refactoring because it breaks multi-tenancy: if several
databases run on the same server and different modules are installed
in each database, the global variable becomes wrongly populated.
Steps to reproduce:
On runbot:
- Go to the `-base` URL or simply select the `base` DB
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model
On Odoo.com saas DB:
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model (unless you installed
each and every module related to the search snippet)
Locally:
- odoo-bin -d first -i website --stop-after-init
- odoo-bin -d second -i website_blog --stop-after-init
- odoo-bin -d first,second
- Try to use a search bar on "first" database (using "Search in
Everything") => it tries to access the blog models.
Revert of PR: #98423
opw-3045092
closesodoo/odoo#105077
X-original-commit: 5806f71af1b6f44aac063f7e504be736300f699d
Related: odoo/enterprise#33669
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Introduce the '@mail/model' module that gathers all the stuff involved
in model definitions. This allows us to reduce the number of imports.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website, website_livechat, website_slides
Task-3056971
Part-of: odoo/odoo#105096
In commit [1], a check was added to see if a media is editable in order
to prevent its edition if it is not the case. However, this also had as
effect to block the edition of some grid images. Indeed, as the columns
in grid mode containing only an image have their `contenteditable`
property set to `false`, the images don't pass the check because their
parent is therefore not editable.
This commit removes the `contenteditable` property from these columns
in order to make their images pass the check and therefore allow their
edition.
Tests are also added, ensuring that these grid images can be correctly
replaced.
[1]: https://github.com/odoo/odoo/commit/ddade4346347266b7f699d05865578dc96e2bf98
opw-3028116
Fixes#103234closesodoo/odoo#104899
X-original-commit: d8c374e3e6b31bf88aa42952aadf3379936f7600
Related: odoo/design-themes#617
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_sale
Since [1], it was not possible to edit a company team snippet image
anymore as soon as the page was saved once. Indeed that commit added
o_not_editable/contenteditable="false" on the parent column to make sure
no text can be added in that column and contenteditable="true" on the
images so that they are still editable (even though HTML-specs-wise
adding contenteditable="true" on images probably does not mean much as
images are self-closing tags, our editor understand that as the ability
to edit the image anyway). That contenteditable="true" part is however
removed when leaving edit mode... and was not restored upon entering
edit mode again.
This fixes the problems with a specific JS patch, we'll review to see if
better can be done in master.
Funny enough, that bug was actually gone in 15.0... by mistake. A recent
bug fix actually reintroduced that isolated bug at [2] (by reintroducing
the fact that images in a non-editable environment are not possible to
edit). The 3 opened tickets this commit mentions were actually reported
for 15.0 immediately after that, while the 14.0 being broken about this
since the beginning apparently did not bother anyone.
Note: as a forward-ported fix, this also takes the opportunity to clean
a bit what was done at [3]. (calling `_super`, no duplicated code,
adding comments, ...).
[1]: https://github.com/odoo/odoo/commit/656cac1bf21c7c5a56aa569008aac58436c747fb
[2]: https://github.com/odoo/odoo/commit/e113bae04a64a8bd341a80736086ab7c25079dd3
[3]: https://github.com/odoo/odoo/commit/e2f7b8fad76dc816b2f6864340d3740446117cdb
opw-3031217
opw-3032482
opw-3035289
closesodoo/odoo#104521
X-original-commit: 1636ba5ed2f8a284bef0930313a85cc3dc7cf072
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The tour snippet_cache_across_websites is at some point switching
between websites. The selector would be taking the second option in the
website list, which may not be correct if a module is adding a website
in its demo data.
This change aim to always switch from website 1 to website 2, without
caring about any other potentially existing website.
closesodoo/odoo#104596
X-original-commit: 7f756cfd5abc740e1a93a3225481c36279f094ed
Related: odoo/enterprise#33444
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this commit if a Table of Content entry was a too long word
without spaces, it span beyond the width of the menu part of the Table
of Content block.
Note that in Chrome, during Edit mode the words are already split
across several lines because the `contenteditable="true"` of the
`#wrap` node applies some built-in extra styles (not from user agent
stylesheet) among which `overflow-wrap: break-word;`.
After this commit long words are split across several lines.
task-2965279
closesodoo/odoo#104559
X-original-commit: ef7174e16663036d3598122d4abdcd5eab0189a0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This fix allows generating the sitemap (via `website.search_pages`) via
RPC. The changes are necessary as since #99667 the `request` object is
no more available to RPC-executed functions.
See also: the `test_search` test case of `website.tests.test_page`.
closesodoo/odoo#104567
X-original-commit: 8f4e214417cfb1aed7e595b8d6ab71f33a347b29
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before this commit, opening the Page Manager in debug mode would throw
an error, stating that the website.RecordFilter has a t-foreach with
duplicated keys.
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."
This commit fixes the keys to be the website id instead of the website
object.
[owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loopsclosesodoo/odoo#104540
X-original-commit: 0d1c263298ca6724a6fe6c31e2a2d3221c5e8c75
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_blog, website_event, website_forum, website_slides
With [1] it has been made easier for partners to extend search options.
This task introduces similar inheritable functions for blog posts,
events, forum posts, slides, pages and hybrid results.
[1]: https://github.com/odoo/odoo/commit/d29f2f3ac5f8c3e8109287e0933609bdbe0cadb1
task-2897924
closesodoo/odoo#97908
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
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
