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_editor dirty elements are saved by calling the ir.ui.view `save()` method.
As this method is called through call_kw _rpc on the ir.ui.view model, self
is binded to the view which has the `id` sent in the request.
In some cases, when editing a field for example, the id sent is the id of the
field's record (eg: product.template for price field).
In that case, the view binded on self will be the view with the id of the
field's record being edited.
If there is no ir.ui.view with the same ID as the field's record, self won't
exists.
This misbehavior resulted in no error luckily since we only use self to call
ir.ui.view methods without ever using self properties.
Since multi-website 47b00c5d53 overrided the `save()` method and used self.key
it was crashing when the self record did not exists.
This commit will fix that by doing the multi-website check only when it is a
view and not a field that is being edited. (We know that if xpath is set)
opw-1904637
Step to reproduce:
- Go to a product on ecommerce, eg product.template 13013
- Edit the product price field, the oe-id attribut is 13013
- Delete the ir.ui.view that has the same ID than the product (13013)
- Save -> It will crash since self is binded to "ir.ui.view(13013,)" but it
does not exists and we try to access key
closesodoo/odoo#28469
* 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
Some code is in charge of setting the same min-height for all items of
a carousel to the natural height of the tallest item, once the page is
loaded. This code was not working correctly in the case the natural
height of this tallest item depends on the height of one of its inner
image, as we have to wait for the image to be loaded in that case.
closesodoo/odoo#28159
This commit fixes a bug introduced with https://github.com/odoo/odoo/pull/28251:
When opening the ace editor on page load thanks to the #ace-view-editor
URL hash, a JS error occurred preventing the editor to open.
This was due to the way actions were executed on page loading:
- Menu elements are initialized and can handle actions
- On initialization, the ace menu tried to launch the editor
- First, it asked that all widgets are closed (see mentioned PR)
- The website handled that action demand by asking everyone to close
their widget
- The 'new content' menu tried... and failed as referenced a variable
which would only have been created in the start method.
Conclusion: before handling actions, all action-capable widgets should
be started. This is what this commit does: when receiving an action
demand, we first wait for the action handler to be fully started. This
implied another change: before, many menus were waiting for the result
of an action to notify that their start method is finished... this
would cause a deadlock in the new system so those were removed, this did
not make much sense anyway (if the result of that starting action has to
be known, a dedicated event/method should handle that).
closesodoo/odoo#28364
Some of our new snippets for 12.0 uses parallax. Those were not using
the exact structure required by parallax which *may* lead to unexpected
results when playing with the related options.
closesodoo/odoo#28299
- The affix navbar went over the ace editor, preventing to save/close
- The ace editor went always under the new content menu
Now:
- The affix navbar is always under the ace editor
- The ace editor closes when the new content menu opens
- The new content menu closes when the ace editor opens
closesodoo/odoo#28251
On res.config.settings for website, when removing a language from language_ids, if this language is defined as default_lang_id, the default language will be updated by an onchange to prevent any inconsistency.
The same should happen when doing this directly on the form view of a website record.
closesodoo/odoo#27727
When updating to BS4, the datetimepicker library was updated to
tempusdominus.js.
It expects the DOM to be slightly different to apply correctly.
opw 1896103
closesodoo/odoo#28073
If multi-website is disabled, we still show all the websites on the website
analytics dashboard.
This commit will only show one website if multi-website is disabled
closesodoo/odoo#27737
Before this commit
When user was in company A and try to create a second website for company B an
error was raised, because the search from user in company A don't find a public
user in company B and the same default user (public-user@company-B.com) was
created again before to be catched and raised by the sql contraint login_key.
Now we use '-' instead of '_' to avoid parser of email to detect it as invalid
After this commit, we don't have anymore the error:
- 'You can not have two users with the same login!'
or - 'Login must be a valid email address'
opw-1891315
closesodoo/odoo#27873
Commit 850e1675eb improved the website.menu creation on module install
(eg: /shop for website_sale).
This commit aims to do the same on module uninstall.
Before this commit:
Uninstalling a website module would uninstall its website.menu (/shop) stored
on the default menu tree.
But the copies of that default menu, on websites, would remains.
Indeed, there is no direct link between the default menus and its copies.
More annoyingly, installing that website module again after uninstalling it
would create a new copy of the default menu, resulting in multiple same menus
on website.
Now, if the menu to be uninstalled is in the default tree menu, we remove all
its copies (the website.menu having that same URL).
Closes#27488, closes#27721
* website
Default web_editor/website colors and other bootstrap related variables
took precedence over some bootswatch overriddes. While we have the
control with Odoo themes, theme bootswatch is a library we do not want
to modify. This commit removes the web_editor and website customizations
when bootswatch is installed.
Closes https://github.com/odoo/odoo/issues/27821closesodoo/odoo#27855
The animation that made all the carousel items have the same height
automatically was broken. This commit fixes it and improves its behavior
during edition.
closesodoo/odoo#27801
In website dashboard, 'DateRangeButtons' are pushed into control panel's
SearchView and breaks the UI in small devices.
This commit fixes the issue by hiding them in small devices.
task-1884038
closesodoo/odoo#27082
on the webiste sale, have a category with a subcategory
Then in the customize menu, enable "ecommerce categories"
Before this commit, the option to have collapsible categories wasn't there
This was because, due to multi_website, the children views of the "categories"
that were inactive weren't written upon when copying their parent
After this commit, the functionality is back
OPW 1893169
closesodoo/odoo#27796
What was designed as a new feature appeared as a regression: users were
not able to choose a bootstrap gray as a background color anymore but
instead got the possibiility to choose a hardcoded gray. This commit
restores the use of the custom gray palette that themes can customize
and which automatically uses the correct text color when used as a
background. This also allows to remove ugly inline style from snippet
definitions and allows to solve bugs like the described below one:
---------------------------------------
Also add bg-* classes on snippet cards:
---------------------------------------
Snippet cards are often put (or may be put by the user) in an element
which have a bg-* class on it. This means that the card will still have
a white background (as chosen by BS4 by default) but the text color will
be adapted to that ancestor bg-* classed element.
This commit forces the card background color (as suggested by BS4) with
bg-* classes.
closesodoo/odoo#27637
* base, website
An image URL may be like "/web/image/<xml_id>" where <xml_id> is the
xml id of an ir.attachment. In fact, the route does not use the xml_id
but the 'key' field, which is normally equal to the xml_id for standard
attachment. In the context of themes + multi-website, the value used as
an xml_id may refer to a theme.ir.attachment instead of an ir.attachment
and this led to a bug as those must not be used the same way.
The crop route which gets image information is adapted by this commit to
always look for the *current website* *ir.attachment* related to the
given xml_id/key.
Thanks to @kig-odoo for spotting the issue.
Closes https://github.com/odoo/odoo/pull/27588closesodoo/odoo#27611
Using `request.env` should be reserved for code that lies outside of
model methods (typically: controllers). Model methods have to use the
appropriate `self.env`.
This particular case caused frequent Python-PostgreSQL undetected
deadlocks during installations of website-related modules in 12.0.
One way to reproduce it was to trigger the installation of both
`website` and `website_form` in a single transaction, with neither
pre-installed.
Installing Apps that depend on both would do the job, such as
`website_sale`, provided that GEOIP is available on the system.
In details:
During installation of `website`, new attachments creation would call
get_current_website (see 602807acdf and
4f6ec1cd2a), using the wrong database
cursor: the one from the request instead of the one for the
installation, as provided by `ir.module.module._button_immediate_function`.
This would acquire database locks on `res.country` and `ir.model` in
the wrong transaction, later blocking alterations to `ir.model` in
the installation transaction, e.g. for website_form's
'website_form_access' column.
This combination of events was possible before 12.0, but more difficult
to reproduce as module installations used to happen with a super-user
account, ignoring ACL checks and therefore not locking `ir.model`.
qsm-odoo