The BS3 'show' class cannot be supported as BS4 still defines a 'show'
class for other purposes which conflict with its former use (tab-pane,
fade effects, ...). Adding more complex rules won't solve the problem as
they would change css rules priorities.
closesodoo/odoo#34139
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Commit https://github.com/odoo/odoo/commit/4f9a0cb4fcdfa9fee66c042593f4d411dd0e192f
introduced a way for users to enable a compatibility template to provide
support for some old BS3 classes.
Some of these classes are the bg-gray-* classes. The problem is that
enabling the compatibility file forces them to the new BS4 gray values
while the user may have done a custo to generate them automatically
from other gray values. This commit allows to keep the compatibility
file enabled, without overriding compatibility grays the user may have
provided on its own.
closesodoo/odoo#34134
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
If destroy is called before start, there will be a crash before this commit.
At the time of this commit, this can be reproduced in master by dropping the
image gallery snippet, clicking on add images (double click, which opens the
media dialog twice for some reason), selecting 2 images to add on the
media dialog, and clicking on add. The error will be in the JS console.
closesodoo/odoo#33440
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The rte_translator tour that test translation on the frontend could not
be started from the "[debug menu]" > "Start Tour" for two reasons:
- the start URL is not specified, so the test was started on current
backend page wich is wrong (in python the start url is "/")
- the backend original state (params after #) does not work with ?k=v
inside argument value, so `#return_url=/?debug=true`.
To solve this issue, we encode the return_url value and add a start url
when rte_translator is started manually.
opw-1998623
closes#33443
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Since https://github.com/odoo/odoo/commit/5a030db3eb77b6d80187f8ae1a64303b2f50391d
the HTML editor displayed the translated versions of the templates it
allows to customize. So if the user edited and saved such a template,
the non-translated version was saved with translated-version content.
The behavior before the mentioned commit was:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, re-make a RPC to load the view again
The mentioned commit made this simpler by making:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, simply show the previously loaded view
... the problem was that the step (2) of the old behavior was
explicitly saying (client-side) to load the view's untranslated content.
This commit makes step (1) always load the untranslated versions of the
views (server-side).
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes#30567
* web_editor
When an user saves its website, all the animations are destroyed so that
a clean DOM is saved. This is particularly important for snippets like
the latest post one that would crash the page if not cleaned before
saving.
Two cases were found where animations were not cleaned before saving and
this is what this commit fixes:
- When an user used the undo/redo system, all animations were lost as
the DOM is recreated.
- When an user duplicated a snippet, animations were not restarted on
the cloned element.
closesodoo/odoo#29159
The UTM graph data in Website > Dasboard > Analytics is not getting
properly filtered on the basis of values of date_from and date_to on
website_sale dashboard.
The field confirmation date which is of type datetime while date_from
and date_to are of date string in local browser timezone.
Hence date_domain is not perfect as shown below on local date 29th april
2019, we would send:
('confirmation_date', '>=', '2019-04-22'),
('confirmation_date', '<=', '2019-04-29')
But in reality we could want a from midnight of week before the current
UTC day, and to current UTC now or 23:59:59 of current UTC day.
This way, the data sent back matches more what is expected, instead of
the preceding domain, we would then have the following:
- if UTC now corresponding to local now is on '2019-04-29'
('confirmation_date', '>=', '2019-04-22 00:00:00'),
('confirmation_date', '<=', '2019-04-29 23:59:59')
- if UTC now corresponding to local now is on '2019-04-28':
('confirmation_date', '>=', '2019-04-21 00:00:00'),
('confirmation_date', '<=', '2019-04-28 23:59:59')
- if UTC now corresponding to local now is on '2019-04-30':
('confirmation_date', '>=', '2019-04-23 00:00:00'),
('confirmation_date', '<=', '2019-04-30 23:59:59')
And each one will be displayed as days 22 up to 29 in line chart (with
local today 29 being the last day of the chart and contening orders of
the current UTC day).
With these change in the UTM pie chart:
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to before yesterday UTC
- a local date that is the same as an UTC date => we see the sale from
up to today UTC instead of yesterday UTC
And in the line chart (that already had half of the fix in f6fc7c2319):
- a local date that is before a UTC date => we see the sales from up to
today UTC instead of from up to yesterday UTC
- a local date that is after a UTC date => we see the sales of current
UTC day + range of days (eg. for a week 7) instead of current UTC day +
range of days minus 1 (eg. for a week 6).
opw-1971539
closes#33041
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
Facebook API does not accept float values for height and width
parameters anymore.
closesodoo/odoo#32970
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The basic font-family offered on Odoo do not support a large set of characters
and rely on the system fonts for non-latin languages
On a system without specific fonts installed, the characters were replaced by �
For Hebrew, the system sans-serif font (at least on Windows pc) was too small.
Rely on the unicode-range range CSS descriptor to load a font only for a
specific range of unicode code.
https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-face/unicode-range
This way, the fonts are ignored for English text (and you don't have to load
the fonts of every possible language).
Add Noto fonts that covers many charsets.
There is an heavy version for many charset and lighter ones for Arabic and Hebrew
More ranges can be added later
Serve the fonts on our CDN to avoid shipping several MB of fonts for everyone
but lazyload it when needed.
Fixesodoo/odoo#32228Fixesodoo/odoo#21781
Example where the issue occurs:
- Publish an event
- Go to the website, register for that event
- At confirmation, when the email address is requested, click quickly
several times on the 'Continue' button
Several registrations are created since nothing prevents multi-clicks.
The stateful button feature of the `button.js` jQuery plugin has been
dropped in Bootstrap 4 (see [1]).
[1] https://getbootstrap.com/docs/4.1/migration/#buttons
opw-1958580
closesodoo/odoo#32571
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On the line chart of google analytics account, we have a tooltip with
lines ({date}
sessions: {number of session}) overlapping and going
outside of the modal width.
This does not happen on google examples, the only fix found is to
display the tooltip in HTML instead of SVG.
opw-1961605
closes#32285
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The current style on "Active users: {number}" placed it 60 pixels over
were it should be, so this was:
- overlapping "Visits" title
- not sparing vertical size (since we use "position:relative")
opw-1961605
closes#32245
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Some valid facebook pages appear as broken by the preview although
they load perfectly fine afterward.
At facebook, an id is required to perform requests to their graphql
endpoints. The ID is part of the URL of the page, sometime (like Odoo)
the ID is the name of the page and sometime (like LACME France) it is
a generated 9-digits id shown in the URL after the name of the page.
Example of two valid page URL and their page ID:
https://www.facebook.com/Odoo
^^^^
----
https://www.facebook.com/LACME-France-910072559192969
^^^^^^^^^^^^^^^
----------------------------
`^` denotes the page id and what odoo uses as page id after the commit
`-` denotes what odoo used as page id before the commit
opw-19494444
closesodoo/odoo#31922
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
* web_editor
BS conflicts with our UI again: btn sizes and form controls are
more difficult to force with BS4, this commit adapts the controls to
use less problematic sizes, and adds/adapts some more forcing rules.
Part of https://github.com/odoo/odoo/pull/31117
task-1941156
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
When the edit mode is entered, some elements receive
data-editor-message attributes. These were not removed on save which
could in some cases make the attributes be saved in the database. For
this to happen it would require an `.oe_structure.oe_empty` element to
be put *inside* an editable element (instead of being the one which is
editable). In that case the `.oe_structure` content would be saved in an
inheriting view but the parent view would also be COW'd for no reason
because of that attribute.
Difficult to say if such a case exist in the current views but as it
technically possible and that some of our tests use that configuration,
it is worth fixing.
Note: this fix was in fact done in the new editor in master and allowed
to detect that one of our test was not testing a feature correctly
because of that. This will be adapted in a different commit of this PR.
closesodoo/odoo#30834
Commit https://github.com/odoo/odoo/commit/29075a8e2c734624cec4f6009185616634f70dea
was written while there was an incorrect behavior related to
multi-website, oe_structure_ID and edit mode in a rare specific case
(see the second commit from this PR for detailed explanation
https://github.com/odoo/odoo/pull/30834).
That rare case was detected in 12.0 since the tour did not work on
master with the new editor (that fixed the incorrect behavior).
Basically, it was COWing the edited view even if only an oe_structure_ID
was touched.
Indeed, when saving a specific view in the HTML editor, we should also
search for its possible new ID as it could change if we also edited its
generic parent. In that case, the view will be copied and then unlinked
to preserve inherit order on the new specific tree.
Before this commit:
1. If we were editing a template with no xml_id, typically the case when
editing a specific view (COW'd), the 'Template ID' label would be left empty
as the view does not have an xml_id but only a key.
2. If we were editing a generic view, the template would be COW'd and replaced
by the specific one created during the save.
After the save, the page would be reload and will try to reopen the edited
template (stored in url `res=123`). But as this template would be replaced
by the COW'd view, the JS would crash trying to access an inexisting view.
The HTML editor would then open in a very thin modal, barely editable.
Now:
1. Display the template's key instead of its xml_id. The key is basically a
duplicate of the xml_id, mainly used in website.
2. If we are saving a generic view, we search for its newly created specific
view to upload the URL hash before reloading.
task-1934279
Fix#30447
With the following view hierarchy:
A
|
B' (oe_structure_ID view)
Before this fix, when saving multiple templates at once from the same hierarchy
the COW views (website) would not be saved correctly as the first call to
`write` would COW the parent view, then the second concurent call to `write`
would create the child specific view under the generic parent view.
Instead, the generic parent should have been cloned to a specific parent view
and then the child view should be COW under the specific parent.
A A'
| |
B' B*' (This one is the old B', without B' changes in the html editor)
Instead of
A A'
|
B'
Calling the `write` one after another will do the trick. Indeed, when the
second call is fired, the first call has already triggered the COW behavior.
Thus, the second call correctly retrieves the COW view.
Another issue might still appear, if the parent view write is sent first.
Indeed, the parent view will be COW, thus the specific child view (second write
waiting to be fired) will be deleted to be added on the new specific hierarchy.
Thus, that write will then raise an error since the view does not exist anymore.
task-1934279
Fix#30447
On mobile the frontend menu navbar is an hamburger menu that open on
click.
If the option "Customize > Main layout | Affix Top Menu" is
enabled, there is two menu:
- one at the full top of the page
- one affixed to the top of the viewport (only shown if we are at least
scrolling 300px away from the top of the page)
But there is a side effect: when scrolling if the menu at the top of the
page is opened, it will be automatically closed => this makes sense to
avoid having two menu shown on the same page but is an odd behavior.
With this commit, the behavior is changed and when the menu is opened in
the top, the affixed menu is not shown (it only works if the top page
menu has no opened dropdown).
opw-1920310
closes#30564
- Fix the position of 'Add to menu' toggle button in new page dialog
- Properly align tip icon in the welcome message
task-1895287
closesodoo/odoo#29403
In the 'banner' snippet, there is a column using a white jumbotron
component. Those comes with a default background color so when using the
website builder to remove the white background, it did not go away;
it was replaced with the default background color (some gray).
This commit sets the default background color of jumbotron components to
'transparent'.
task-1889341
closesodoo/odoo#30099
Since 12.0, some modal footer button order were changed. The primary button
would not be the one in the modal footer corner.
This is against bootstrap but more annoyingly, users are intuitively clicking
on the secondary button, ending up closing the modal and losing form
information they entered.
This commit simply fix the regression from 12.0 as before 12.0 these buttons
were positionned correctly.
Note that a commit in master (saas-12.2) will fix all the other ones that were
wrongly positionned before 12.0.
Step to reproduce:
- Go to an event having the possibility to register.
- Click on 'Register Now', a modal is shown to write details (name, email..)
- You intuitively click on 'Cancel' as it is the bottom right button
|________________________________ CONFIRM _ CANCEL _|
- The modal is closed, if you try to open it again your infos are lost
Closes#29884
task-1922120
When there is a website with traduction (for exemple, Spanish and
French). In the Spanish website, at the SEO menu, you can add keywords
using any of the languages (Spanish or French), but these keywords are
only added to the Spanish website.
To avoid misunderstanding between the website language and the keyword
language a tooltip is added.
closesodoo/odoo#29683
Lang / Context is implicitely added in the query using this._rpc
Before this commit if you set the title 'Title 1' for your website in the main
langage and after edit the title as "Title 2" in another language, it was the
main title that was replaced instead of the translation.
Now we use this._rpc that bind automatically the context and so the current lang
that we are editing.
closesodoo/odoo#29596
* web
This commit introduces helpers for async handlers, especially for button
clicks. Those helpers are now used automatically for website widgets
(animations) if the 'async' word is placed in front of a handler name
in the `events` key definition.
Completes https://github.com/odoo/odoo/pull/27981
- Correct `col-*-offset-*` support.
- Compatibility for BS3-deprecated `visible-*` classes (only not taking
care of table/table-row/table-cell cases as difficult with sass and
those classes were already BS3 deprecated anyway).
- Correct order for BS3 `visible-*-*` and `hidden-*` classes (otherwise
their combination are not correctly working). Also, the 'inline'
version was forgotten by previous PR.
- Compatibility for BS3 `btn-xs` class.
closesodoo/odoo#28842
On save, the editor will ask to parent widgets if something needs to be
done first. The website navbar will receive that demand and asks to its
action-capable components to do something. For example, the content menu
handles page-related options saving. However, some users with limited
access rights do not have the content menu... but the website navbar
expects that the save action is performed. So, this empty action is
defined here so that all users have an 'on_save' related action.
This was only happening since 12.0 as 'on_save' actions were introduced
there to save page-related options.
closesodoo/odoo#28810
The previous code made sure we wait for images to be fully loaded before
initializing the auto more menu. But in some cases, it is not enough, we
also have to wait for fonts or even extra scripts. Those will have no
impact on the feature in most cases though, so we will only update the
auto more menu at that time, not wait for it to initialize the feature.
closesodoo/odoo#28684
* web_editor
- Restore the preservation of Odoo text-muted color (the rule became
!important with BS4 and had thus to become !important in the
preservation mixin).
- Preserve base design in the "new content" menu (which now uses
text-muted). Indeed, in some themes, the "new content" links were not
even visible anymore.
closesodoo/odoo#28666
Steps to reproduce the bug:
- Go to Website > Dashboard > Analytics and click on "Link my analytics account"
- Enter some data and save
Bug:
A traceback was raised: TypeError: website_set_ga_data() missing 1 required
positional argument: 'website_id'
opw:1905874
closesodoo/odoo#28636
This commit adds a compatibility file which can be added on demand by
enabling its associated view. This will basically map old BS3 classes
and structures to the related style with BS4.
closesodoo/odoo#27981
When opening the customize menu as soon as the page became visible, an
RPC crashed and the toggable options did not appear anymore. This
happened:
1) DOM is ready.
2) The user click on the menu.
3) At the same time, the customize menu is initialized (`attachTo`),
its event handlers are bound and the async `willStart` method is
called.
4) The event handler for the user click is called... and crashes as
requires a variable which would have been set in the `start` method.
The bug did not appear in previous versions as the handler was not using
the standard system and bound the event handler "by hand" in the `start`
method.
Maybe `attachTo` should not bind event handlers before the `willStart`
method is completed; this would be a subject for the master branch. This
commit solves the problem by setting the required variable in the
`willStart` method instead of the `start` method.
closesodoo/odoo#28578
Before this commit, RTL on frontend was only enabled for connected user.
To have RTL, we add the direction on the element, and the RTL version of
the stylesheet for the applicable languages are generated thanks to rtlcss.
opw-1892757
closes#28434
* web, web_editor
The logic which chose if the user text color was supposed to be used as
bootstrap "dark" text color or bootstrap "light" text color
(https://github.com/odoo/odoo/commit/8b2dbd1441d6713d9072db03e8d3cb6c2246410f)
was fine when using the default theme with default bootstrap but was not
working as intended in some themes.
This commit also introduces a more accurate and complex method to
determine the correct contrasted color in most cases.
closesodoo/odoo#28468
qsm-odoo