Previously, background size and position for snippets was configured in
a modal, the user could choose a "focus point", which is rather
unintuitive. They could also choose to use the "contain" background
mode, with or without repeat, or a third option, where they could
customize everything, from the background size in both directions to
whether to repeat the background in only one or in both directions.
This commit streamlines the background-sizing options, only the "cover"
and "repeat pattern" options have been kept, as they cover almost every
use case. Their configuration has been moved into the options menu for
consistency with the rest of the editor, and the background's position
is now chosen by clicking on the corresponding menu option, and dragging
the background to the desired place.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088304
* web_editor
This commit adds a slide counter in carousel snippets option menu, as
well as left and right buttons, this way the user can manage their
slides entirely from the options, instead of having to go to the block
itself to navigate to where they want before going back to the option
menu to add or remove a slide.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088291
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Currently we have:
- a colorpicker for background color of snippets
- a colorpicker for foreground and background text (topbar)
- a colorpicker for menu/footer/navbar/etc
These 3 are separate colorpickers with different options.
After this Commit
All 3 will use the same color palette wich allow you to select
theme color, common colors, custom color and transparent filter.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2087383
* web_editor
Previously, the user could choose their anchor names using a modal
window, anchor names also have weird rules, this was not a great user
experience.
This commit makes the anchor button generate anchors automatically based
on the first title in a section, or the snippet name if there are none.
If the anchor name is already taken, it is suffixed by a number. After
it has been generated, it is also copied to the clipboard and the user
is shown a toast to tell them the anchor has been generated and copied.
The anchor is displayed in the toast along with an edit button that will
open the same edition modal as previously, but it is now less
restrictive.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088270
This commit adds buttons to move sections up or down and to move columns
left or right, which is more user-friendly than drag-and-drop in some
cases.
Part of https://github.com/odoo/odoo/pull/38959
maintask-2066614
task-2088265
* website
Now snippet options can be defined as a button which can be placed next
to the clone and delete buttons, through a new "isTopOption" method.
This commit also review the buttons and title design and take advantage
of the feature to review the way snippets options are added in their
container (that code indeed contained useless part since 13.0).
Part of https://github.com/odoo/odoo/pull/38959
task-2066614
Changing the filter color and its intensity was not working anymore
because of failed JS refactoring when the logic was shared for both
blog posts and events in website.
closesodoo/odoo#40227
X-original-commit: 3296468beded14d4ef52d221ef8683941f12291c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In 4d5c3b9fc1c5 the arguments of the MenuEntryDialog widget were
altered, and one instantiation of this widget was not adapted, resulting
in the last parameter being undefined and causing a crash. This commit
adapts that call.
closesodoo/odoo#40187
X-original-commit: ab7f501ff401cc1a85a95dd3cc65d80ecfeec2cc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When the user changed the parallax option, it was only updated on save.
So, the user was not able to have a preview of what he chose.
Note: this commit is made in saas-12.3 but does not fully solve the
problem there... and unfortunately I don't know why. It fully solves
the problem in 13.0 though and this is more important.
closesodoo/odoo#39995
X-original-commit: 4b633949cd4fd1cae807b95d233879ac4adc01ce
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Adapt website for 13.0 9996d04fd2 change of LinkDialog constructor
arguments (to get back to same arguments as in 12.0).
opw-2086444
closes#39888closesodoo/odoo#39910
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Purpose
=======
This is the first huge step to improve the test suite in several ways:
- Make them demo data independent, allowing to modify the demo data without having to adapt the tests depending on it. It also allows to have a beautiful + convenient demo dataset to make a demonstration, and to configure complex data in the tests to manage the corner cases.
- Improve the test performances by converting them into SavepointCase. Each test will be rollbacked to it's initial state, after the setUpClass call. That way the different data are not re-created at each test for nothing.
- Introduce several test classes in base/tests/common.py to launch a TransactionCase, HttpCase or SavepointCase test with an available demo user, portal user or a large set of partners.
- This is the first step to tend to a rolling release process, allowing to execute the tests (or a subset of the tests) on a migrated base, for example.
closesodoo/odoo#39868
Taskid: 2075739
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, when an user clicked on a control button to go to
another carousel slide, the overlay ended at the wrong position and
multiple scrollbars appeared. This occured because bootstrap fires the
'slid.bs.carousel' event too soon, because it emulates the transition
end event with a setTimeout. So on a normal computer, this occured:
- User click on control button, transition starts.
- slid.bs.carousel is fired -> we retarget the edition to the new active
slide and reposition the overlay... but that slide is still moving
as the transition is not really finished.
- The transition finishes, the overlay is at the wrong position, outside
of the screen.
Actually, this is more complex than than because our own system checks
transition end events to reposition the overlay. Even if unperfect,
we now have:
- User click on control button, transition starts.
- slide.bs.carousel is fired -> we enable the parent carousel instead of
the current slide (this DOM element is not moving).
- slid.bs.carousel is fired -> we know it is fired too soon, so we wait
an extra 20% of the time between 'slide' and 'slid' before retargeting
edition.
- The transition finishes, the overlay is still over the carousel and
not the active slide.
- Our extra 20% duration ends, we retarget edition to the current slide
and reposition the overlay (should not move since normally at the same
position as the carousel itself).
Part of https://github.com/odoo/odoo/pull/38997
task-2090180
Previously, the carousel and quotes carousel snippets were the only ones
that were not enclosed in section blocks. This had a number of
undesirable side effects, such as editing the anchor on the carousel
breaking the carousel functionality, and the inability to separately
choose a background for the carousel itself and individual slides.
I also used this opportunity to move controls relative to the entire
carousel onto the carousel itself rather than the individual slides. The
sizing_y (vertical padding) will however keep targeting individual
slides, as the carousel uses the height of its tallest slide, and also
because padding on the carousel will not get covered by slide
backgrounds and saty blank, which is unwanted.
Lastly, most of the snippet options for the carousel were rewritten, as
they were quite broken. There was some compatibility code for saas-3
left, some useless events were bound to the controls, even though they
were already handled through event-delegation at the document level.
Finally, most of the edition features were broken on duplicated
carousels since the onClone method wasn't reassigning most of the things
it needed to.
Part of https://github.com/odoo/odoo/pull/38997
task-2090180
In the editor, the snippets from uninstalled module are shown with the
possibility to install the module to get snippet.
Before this commit:
When clicking on it, it will redirect to the module page, in the backend from
where you can install the module.
Now:
A popup will be shown to save current changes and install the module.
The installation will be done without changing page, in the editor. Once done,
the page will reload in editor enabled mode.
task-2089285
closesodoo/odoo#39138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, if you had a page_id set on a menu, and that you
fork this page, the page_id from the menu was always pointing to the
previous one, so you see old page, but edit new page.
> Reproduce:
> Fork Contactus (Page_id on menu become wrong)
> Refresh contact us (done on save btw)
> You see old content
> Edit with Html Editor, you sill see that forked view exists!
Bug was hidden before that we set page_id on menu, but it is needed if
we want to support the groups visibility on the menu item.
closesodoo/odoo#39472
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Now, you can define a Visibility mode between:
Public (All poeple)
Connected (Portal or Employee)
Restricted Group (Has this group or is Employee)
With Password (Know password or is Employee)
Internal Users (Is Employee)
It is a 'fair' feature, but without really warranty that the content is
really unreadable via others methods, ...
It is more for frontend display, that real secret. Dont use this like
a keychain ;)
We only catch the visibility on the main view and not the t-call inside.
Even if it should work on controller too, it is only display now on the
page property menu. (Or on the view directly in backend)
task-2091365
* web_editor
Commit https://github.com/odoo/odoo/commit/7e2b0ebe7996c9fa35f75949b7fc8cd5a58d7c36
broke the website JS loading as it added a dependency to a lazy loaded
JS module which was not even always lazy loaded.
A test so that this does not happens anymore will be made in another
commit.
Related to task-2092386
closesodoo/odoo#39391
X-original-commit: 5ac269d722f9ff8c206215dd1c07b8544cfd5382
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website
Inherited colorpicker were not used due to the context missing the
website_id and the method call being used instead of call_kw.
task-2092386
closesodoo/odoo#39357
X-original-commit: 7e2b0ebe7996c9fa35f75949b7fc8cd5a58d7c36
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since saas-12.3, deferred actions use native promises. This has the
annoying side-effect of force-deferring promises even if they are
resolved at once... and we relied on the opposite behavior for some
call made in _setActive or option methods.
In master, we should review the async logic of snippet options. Right
now we will rely on the fact those promises are resolved at once but
that we need to avoid for their "async part" anyway. The _setActive
method and the option methods are thus still working synchronously in
stable, despite the new force-deferring promises.
Also, with old promises, when we waited for the resolution of multiple
deferred, the resolve handler received the multiple results as
individual arguments. Now it receives all the results in an array as
a single argument. The resolution of action demands had to be adapted.
closesodoo/odoo#39171
X-original-commit: 30d15315a73c1fa34ada86371b06c02b6375db89
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Snippets with side margins look quite compressed between full width
snippets. This commit adds an option in the side-menu to control whether
a section is stretched or not. This option is available everywhere it
would have a reasonable visual impact (the cutoff was arbitrarily chosen
to be that the stretched section is at least 5% larger than the
unstretched version)
task-2080570
closesodoo/odoo#38852
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The snippet was using the posts of all websites and blog post creation
was suggesting all blogs. Now:
- On blog post creation only suggest the blogs of the current website
- In latest posts option, only suggest blogs of the current website
- In any case, latest posts only displays posts of the current website
Part of https://github.com/odoo/odoo/pull/38510
Related to task-2083198
closesodoo/odoo#38794
X-original-commit: 4be97b48861a6631fe465054c62baea65bfc1524
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Test case;
The user as edition rights on the website
Install quotation builder
Have a sale order with many lines
Click preview > you end up on the portal view
Before this commit, there was a blank space just before the
sale order lines per se
This was because the sale order's lines website description
were in the dom and took some fixed space, which is a feature
meant for the edit mode by using the class oe_no_empty
After this commit, we restrict the effect of that class concerning
the fixed height only to edit mode
There is no more gaps in the sale order preview
In master, one should check whether the class / rule is still relevant
OPW 2082267
closesodoo/odoo#38435
X-original-commit: 4b177412235cdf3e62f5ff30c18246c003c25cc2
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Follow up of commit a3845ae3f0
Issue
=====
Since the above commit there is a confirmation dialog when clicking on a button,
for which the only options are to Discard or Cancel.
The problem is that when discarding it will revert the selected website back to
the default value. Therefore before the current commit it is impossible to
install a theme on a website other than the first.
Solution
========
The solution is to avoid showing this dialog when clicking on buttons for which
the result depends on the currently selected website. This leads to the same
behavior as what existed before the mentioned commit: the settings are
implicitly discarded because they are not saved, but at the time of the click
the transient model still holds the non-discarded value that the user selected.
This restores the "select a theme" feature, but also restores the unfortunate
side effect that the user might unknowingly loose all of his pending changes
when clicking on the button, but only for those two specific buttons.
Other considerations
====================
Saving instead of Discarding was considered but it is impossible to do because
saving might do a lot of changes that might even lead to the installation of
modules, so the settings page has to be reloaded to apply them, and then the
website field will be reset to its default value again.
Instead of changing website specific settings from the main settings, it was
considered to update them through a form view, but it is apparently too
complicated for on-boarding.
The last consideration was that the settings view should actually mark the
corresponding fields as unchanged when changing the website, but it is too
complex to implement for a case that is not supported in the first place,
especially for a fix in a stable version.
task-2083198
closesodoo/odoo#38745
X-original-commit: 2298ef19bcd9e7a14958dce9a93cea69258064d8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
In the backend, when a mailing popup was being edited, it was not
centered in the edition area (and went under the editor UI) and was not
using the correct style.
task-2083465
closesodoo/odoo#38449
X-original-commit: 6ccf3b618b4b0774deccb4f75bf33f3ea4dc8b75
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a background video was used in a mega menu, it was only working in
edit mode. Indeed, the background video size is computed on page load
(and on window resize) but as the video is inside a hidden dropdown
menu in this case, the size cannot be properly computed.
This commit fixes the issue by recomputing the video size on dropdown
menu opening.
task-2080590
closesodoo/odoo#38314
X-original-commit: 66ec1c19b63fe26e559ed2d8d7359df974ade789
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* web_editor
The purpose is to force our dropdown style in our UI so that themes do
not break it anymore (same way all the other elements are forced (cards,
headings, etc)).
task-2059538
closesodoo/odoo#38321
X-original-commit: 4ef0eac5ba134f462f72f3e9c60e5c9fc95f3a8c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Since Odoo 9.0, the `return_label` in url was not working anymore.
What it did before 9.0 is add an item in the breadcrumb which once clicked
would redirect to the frontend.
This was handled in the `do_load_state` of the action manager in JS.
We don't need to reimplement that behavior as now we have the 'Go to website'
stat button. Thus we remove the code.
Closes#36325
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
After this commit, you will be able (in technical mode) to update the url for
the python controllers.
Eg.
You can now rename /shop in /garden and /shop/product/ in /garden/vegetable/
Most of urls will be replaced at fly in the renderd qweb, with the function
url_for but all old urls will keep available. So if you access url /shop you
will be automatically redirected to /garden (308 Permanent Redirect).
As for cdn and other post-process of att, the automatically replacement in the
rendered qweb is only done when you will be not website editor. But the new
dispatch of URL will be applied in all cases.
For developper, since it is Permanent Redirect, don't forget to clear cache or
open chrome debug tool (with option 'Disable cache while DevTools is Open) to
see your lasts changes.
closesodoo/odoo#36555
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit moves most of the logic of cover edition to website. This
will allow to define cover on other non-blog models, like events.
Note: this also "accidentally" fixes a crash during rendering of the
blog page when there is no blog or post.
Part of https://github.com/odoo/odoo/pull/37009
task-2043872
Before this commit, 'Go to website' in website module dashboard might not
redirect to the correct website.
It would just redirect to `/` (href) without forcing the website selected in
the dashboard.
task-2063252
Closes#36390closesodoo/odoo#37359
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, if one would introduce a scheme or a port in his website
domain, it would make the website selector to crash JS side.
Indeed, it would replace the current url hostname by the website domain.
If the website domain was introduced with `http://` it would lead to
`http://http://mysite.com`.
If port was introduced, `http://mysite:8069:8069`.
Also, by fixing those 2, it also make `localhost` and `127.0.0.1` to work.
(which would not work without `http://`.
Related to #36390
* web, theme_bootswatch
Improvement of https://github.com/odoo/odoo/commit/02a321cffb2da60a86b960e75c445e37094567b4
- Clarify the name of the support font (to distinguish it from standard
and google fonts and avoid confusion with Noto Sans and Noto Serif).
- Make sure the support font is added and can be added for all font
definitions in odoo scss files thanks to a scss function.
Could be backported in 12.0 if judged necessary.
Part of https://github.com/odoo/odoo/pull/37293
Before this commit, the default font for the website was the bootstrap
one, which is a series of many fonts which should at least contain one
which is present on every user system.
The problem is that commit https://github.com/odoo/odoo/commit/ed18095127b20da516fa5ada943b2dd6d5c84652
added the definition of a Roboto font, available in all assets... and
Roboto is part of the bootstrap font. This added a new font loading on
page load and that loading is not optimized at the moment. This thus
broke our work to improve google pagespeed ratings.
This commit replaces the bootstrap font with a forced Roboto font whose
loading is handled by an optimized loading of the related google font.
This also improves the very default font of the website by making it
more stable accross different browser (we will always use the loaded
Roboto font instead of relying on the user system fonts).
Part of https://github.com/odoo/odoo/pull/37293
Samuel Degueldre