In an edge case the content of the field has already been
prefetched as sudo during the read of another field as sudo,
therefore it doesn't try to read the field as the normal user
closesodoo/odoo#88134
Signed-off-by: Julien Castiaux <juc@odoo.com>
Steps to reproduce the bug:
- On the website application, add an image gallery snippet.
- Change the "Speed" parameter.
- Save.
-> Nothing happens: The displayed image is always the first one and
there is no cycle between the images of the snippet.
Since Bootstrap 5, the amount of time to delay between automatically
cycling to the next item is defined by `data-bs-interval`. The bug
comes from the fact that some parts of the code still used the old
parameter name (`data-interval`).
opw-3165570
closesodoo/odoo#113423
X-original-commit: 8368fa1f5e45a14ed8938017b2da90a810dbf0c8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [this commit], it is possible to have a block only displayed on
mobile screens. This feature can break the steps snippet by following
these steps:
- Drop a steps snippet in a page
- Set the third step to be visible only on mobile
=> The connectors are broken.
This commit fixes this issue by only considering steps that are visible
in desktop view for connectors drawing.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
closesodoo/odoo#113184
X-original-commit: d8521d197518e90d63443d1095b2df84487ad4ae
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
From [this commit], it is possible to define the visibility of blocks
according to the device on which the page is displayed (either hide on
mobile, or hide on desktop). This change has brought two problems on the
table of content block:
1. The sub-component s_table_of_content_main (the right part) can be
invisible, which does not make sense.
2. The sub-component of s_table_of_content_main can be invisible but it
did not change the navbar of the TOC.
This commit prevents hiding the main part of the TOC and rebuilds the
navbar of the TOC according to the device visibility of its
sub-components.
[this commit]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2
task-3116227
Related to opw-3135927
X-original-commit: b7f9c26a93e58f2ace964ab6b05132cc9f8f3366
Part-of: odoo/odoo#113184
By following these steps:
- Drop a block table of content on a page
- Disable the visibility of the block in desktop view
=> A traceback is displayed.
This is because for scrollspy to work properly, the elements that it
handles must be visible (no display: none). Unfortunately, we put a
display none when the block must be invisible for a certain device and
the width of the screen is the one of this device. Since it is quite
complex to prevent all the cases where the block could become invisible,
we patch the scrollspy component of bootstrap so that it has a similar
behavior as in version 4.X. (not cause an error if the navigation
element is no longer in the DOM or is no longer visible).
The error is only visible since [the migration from bootstrap 4 to
bootstrap 5] because to add the class, bootstrap 4 did it with the
JQuery addClass() function which does not cause an error if the element
on which it is called does not exist. Now, bootstrap 5 does the same
thing in pure JS with classList.add() on elements that meet the
requirements (visible) which causes an error if the element on which it
is called is not defined (this is the case before this commit because
the TOC was not visible).
[the migration from bootstrap 4 to bootstrap 5]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3116227
opw-3135927
X-original-commit: f2b86dda77133ed9c4f02394693e771758d18bad
Part-of: odoo/odoo#113184
The first objective of this commit is to polish the website
configurator:
1) On page 1 of it: - The size of the text is increased.
2) On page 2 of it: - The font size inside dropdown is reduced.
- 30 results are displayed inside dropdown instead
of 15.
3) On page 3 of it: - The size of the text is increased.
3) On page 4: - The cards are refactored.
- The end line is removed.
- The "Build my website" button is moved to the left.
4) On page 5 : - It is now impossible for the user to click on a theme
preview before it is completely loaded.
5) On all pages, the size of the "Skip and start from scratch" button
has been increased.
On the second page of the website configurator, the user has to choose
an industry type. Sometimes, it happens that the user is searching for
an industry that is not known by the server. Before this commit, a
message of type "No result found" appeared and the user had to choose
an other industry among the existing ones. From this commit, the
"No result found" message is replaced by the name of the industry that
the user is writing. To choose its industry type, the user can click on
the displayed industry name or outside of the input area. This last
option calls the `_blurIndustrySelection` function and the written
industry is kept as the final industry choice. If the user chooses an
industry name that is not known by the server then the remaining of the
website configuration is done with the "abbey" industry. Moreover, this
unknown industry name as well as the language used by the user is sent
and stored to the IAP database. The goal of it is to regularly update
the industry list so that it becomes as most complete as possible.
IAP PR : https://github.com/odoo/iap-apps/pull/549
task-3062171
closesodoo/odoo#110187
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Facebook" snippet inside the "Table of Content".
-> The page is blocked.
This may happen with other snippets than the facebook one (e.g. the
image gallery or the countdown).
A mechanism that interests us here is the mutation observer. Up to this
commit its goal was to regenerate the navbar of the TOC when its DOM
content changed. In practice, since [1], a "widgets_start_request"
message was triggered up each time there was a change of the TOC
content. In the case of the Facebook snippet, this behavior led to an
infinite loop. Indeed, when the Facebook snippet was dropped inside a
TOC, its content changed so a "widgets_start_request" was triggered up.
This message led to the execution of the start function of the TOC but
also of the start function of the Facebook snippet. Because there is a
change of the DOM in this last function, the mutation observer
triggered up a "widgets_start_request" message again that caused the
program to loop forever.
The goal of this commit is to regenerate the content of the navbar only
when its content changes. To do so, the content of the navbar before
the change of the DOM is compared with its content after the change of
the DOM. If those two contents are different, it means that the navbar
should be updated. Thanks to this commit, it is now possible to add
dynamic snippets such as "Facebook" or "Countdown" inside the TOC.
With this in hands, another bug appeared:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Text-Image" snippet on the page but not inside the TOC.
- Drop a "Countdown" snippet inside the "Text-Image".
- Drag the entire "Text-Image" snippet with "Countdown" and drop it
inside the TOC.
-> The page is blocked.
This bug comes from the fact that the drop of a snippet that stands on
the page inside an other snippet leads to the destroy and the restart
of the option of the outer snippet. However, in our case, the mutation
observer was still listening to DOM changes even after the destroy of
the snippet option. This led to parasite function call. This bug is
fixed by disconnecting the mutation observer when the option is
destroyed. Note that this is done in [2] as this was a problem in older
versions as well.
[1]: https://github.com/odoo/odoo/commit/a05f782871c61b2d58ca2fd4277cb7aed65a301d
[2]: https://github.com/odoo/odoo/pull/112960
task-3122249
opw-3164969
opw-3173006
closesodoo/odoo#113070
X-original-commit: 9139b27ee9216f4b6111d0596f101d4927b493b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A DOM observer is initialized at the start of the table of content
(TOC) snippet options but is never disconnected. This could lead to
memory leak. The goal of this commit is to disconnect this observer and
stop intercepting the changes of the DOM at the destroy of the snippet
option.
Related PR: https://github.com/odoo/odoo/pull/110860closesodoo/odoo#113075
X-original-commit: 3787599479d2f1e951bca6622c7049b62d631795
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Changing numeric values using the keyboard arrows did not work on some
fields. This commit solves this problem by adding the necessary
attributes to the numeric (we-)inputs.
task-2601533
Part-of: odoo/odoo#81241
This commit improves the handling of events on the editor's we-matrix.
The fields that make up the list trigger a preview at each input and the
user can navigate through the matrix with the keyboard.
task-2601533
Part-of: odoo/odoo#81241
This commit improves the handling of events on the editor's lists. The
fields that make up the list can trigger a preview and it is possible to
switch from one field to another using the keyboard. Note that the
social media we-list must render at each blur of one of its inputs, so
this we-list does not allow to switch from one input to another with the
keyboard.
As the we-list events changed, the social media block tests had to be
slightly modified to take these changes into account.
task-2601533
Part-of: odoo/odoo#81241
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The redirect function in the router exists only for the wait option.
This option is only used in one case (client action home). We have
therefore decided to remove the redirect function and to call
browser.location.assign(...) directly.
We will also remove the "wait" param for the "reload" and "home"
client actions. Because no call to "reload" needs it (1) and all calls to
"home" want it wait=True. So we will move the code that was executed
if wait=true to the "home" action client.
(1) In the POS, wait=true is used for a "reload" but this has no impact.
Wait=true was intended to wait for the server to restart before reloading
the page. In the case of the POS, there is no restart of the server, so
wait=True is useless.
closesodoo/odoo#112621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when obtaining link URL suggestions, both the
specific and the matching generic page were suggested.
After this commit, only the most specific ones are kept in the suggested
list.
This commit also adapts the sitemap in the same way.
In stable, a condition on a dedicated context key is used in case those
methods were called with the goal of obtaining both generic and specific
pages.
In 16.0, those methods will always filter duplicates pages as it was
supposed at first.
Steps to reproduce:
- Edit Contact Us page (to create a specific view)
- Edit the Contact Us menu
- Type "/" in the URL
=> "/contactus" appeared twice.
task-2968292
closesodoo/odoo#112746
X-original-commit: c5a50362ef55ced373c53c7af069fd5534043ae2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since website was moved from frontend to backend in 16.0 with [1], there
was an issue with the page list view which would not show the homepage
record when multi website group was not enabled.
Indeed, we have our own `recordFilter` method which is based on the
`website_id` field.
But the framework ignore this field (it doesn't read the property at all
and so don't have access to its value) if it's hidden by a `groups`
property. In such cases, the field should be duplicated and hidden with
`invisible`, as those fields will have their value retrieved depsite
being hidden.
Step to reproduce:
- Install website with no demo data (to have only one website)
Or go to runbot / install website with demo data and disable the multi
website group
- Go to Website > Site > Pages
- You don't see the homepage in the list, because there is 2 homepage
(one specific and one generic) but since the website_id is not fetch,
both are considered generic (which is not supposed to be possible)
and the filter is then considering those to be shadowed by the other,
ultimately filtering out both.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#112461
X-original-commit: 5ff5daee518d23c3b6958133eb1f99bc5fc1063f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since Werkzeug 2.1.0, the Response.autocorrect_location_header is
disabled by default.
As it's RFC compliant and supported by browsers, the base_url is simply
removed from the assertions.
Part-of: odoo/odoo#112298
Adds basic support to filter possible m2x values based on another
record. This is necessary for the website_appointment snippet
introduced within this bundle (see related ENT PR).
An important need implemented here is to not store a list of valid IDs
in the DOM but fetch them based on data stored by a different widget.
Use case covered:
Model A has a Many2Many relationship with Model B via a `model_b_ids`
field.
A first widget (Wa) on a snippet's options allows to select a record of
Model A. A second widget (Wb) allows to select records of Model B.
```xml
<!--Widget A-->
<we-many2many data-model="model.a" data-m2o-field="name"
data-fakem2m="true".../>
<!--Widget B-->
<we-many2many data-model="model.a" data-m2o-field="model_b_ids"
data-filter-in="true" .../>
```
Before this commit, the second widget would only be able to show
all records of Model B linked to any Model A record and matching a
static domain provided as attribute, which is still supported.
This commit allows, after having selected `record_a` in the first
widget, to only populate the second widget with the records of
Model B that are in `record_a.model_b_ids`.
Implementing this is done by
* Adding `data-filter-in` to Wb's xml attributes (as above)
* Calling `Wb.setFilterInDomainIds()` when another record is selected
in Wa.
Task-2574175
odoo/odoo#90748
See odoo/enterprise#23750
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
See previous commit, it fixes a bug introduced by a recent change in the
javascript framework that broke the website kanban override.
This commit is ensuring that the kanban can be accessed and used.
Ideally, it should have been a QUnit test but since this has to be
merged ASAP (critical bug) and a test is more than welcome as it's not
the first time our custom kanban is broken, a hook in an existing tourµ
is used to easily and quickly test it in the meantime.
closesodoo/odoo#112369
X-original-commit: aca72bcdae98e1304c934f67efa65273d636863a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Since [1], an error was raise because the xpath to add an if attribute
: "//div/t/t[2]/KanbanRecord" wasn't precise anymore and was applied to
the wrong KanbanRecord, removing the correct attribute.
Now a more precise xpath is used.
[1]: https://github.com/odoo/odoo/commit/fa20b8de642fc57e5c6a49ca77c28d4aab150df9
X-original-commit: bc4776d8f532f2c5882bdac1c72ac95c5ade6be9
Part-of: odoo/odoo#112369
*: website_slides
In some cases, components had dark text over dark background (or light
text over light background) by mistake.
Example:
- Enter edit mode.
- In the theme tab, choose "boxed" as page layout.
- A color picker appears below to control the color behind the box.
- Set it to a dark color (if your box main color is light)
- Go to a course page (install website_slides)
- Check the mobile version
=> The bootstrap tab and its section uses the dark color you set up as
body color instead of the expected boxed layout color.
Another example:
- Do the same thing (set up a dark color behind a boxed layout).
- Go to a shop / product page.
=> The inputs are dark with dark text.
This is because of bootstrap which uses `$body-bg` as default value for
other variables, such as `$nav-tabs-link-active-bg` in the first case
described above. It also uses the variable in the creation of CSS rules
not controlled by explicit variables.
In 16.0, bootstrap was updated to 5.1.3 with [1] and this actually
increased the problem: input backgrounds now default to `$body-bg`,
amongst other things. Since [2], `$body-bg` is also used as the default
color for range thumbs.
In previous versions, this fix focused on fixing a critical component:
nav-tabs, for which the fix was straightforward.
Starting from 16.0, this commit will fix everything at the small risk of
changing the `$body-bg` variable meaning in the case of boxed layouts.
Before this commit, its meaning was "the color used for the background
behind the boxed layout (the <body> background color)", so equal to the
Odoo value `o-color('body')`. After this commit, its meaning will be
"the color used for the background of the box itself", so equal to
`o-color('o-cc1-bg')`. The `<body>` background color will be forced by
using `o-color('body')` as the value for the related *CSS* variable
defined by bootstrap. This allows to have a correct CSS generation for
all components in case of boxed layouts: indeed, the components mix
their own color with `$body-bg` (or use it as it is) relying on the fact
this is the color which appears behind them... which was not right in
case of boxed layouts.
This commit actually fixes another bug that was found during adaptation.
It is 2-fold, and unfortunately, it does not make sense to fix one part
without the other as it would increase the problem without the other
part. The website_slides pages customize their default background color
to not be the one chosen by the user, but a mix of it with some
lightgray. Odoo default for the body being white, this makes it a
lightgray for website_slides pages. This is totally ok... but only in
"full" layout. In boxed layout, we have the 2-fold problem:
A. The mixed color is not applied to the boxed layout but on the
background behind the box. So if you have a white box above a black
background, in website_slides pages you won't have the black
background you expected to keep but a lighter version of it and the
website_slides box will not use the lightgray but stay white
(creating other inconsistencies as the lightgray would also be used
by other components like tabs, for that app only).
B. The mixed color is actually not mixing the right colors: it mixes
the hardcoded lightgray with the color of the background behind the
box, while it was intended to be the one of the content (the one of
the box), like in "full" layout.
The changes explained above about `$body-bg` naturally fixes (B). Not
fixing (A) at the same time would result in a big change for the color
which is behind the box. This commit fixes it at the same time by now
applying the color to the right element. In previous version, this could
be fixed as well but would require a different fix (not relying on
`$body-bg`). So it makes sense to merge this first and backport+adapt.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/46e53879749be7ba3d30338d0f25c0a68a88eb3c
opw-3151962
closesodoo/odoo#112254
X-original-commit: 14c985af526602a88666714e716283650521e537
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
For some reason the `website_id` field was added in the form view of the
`ir.asset` model in a website module overide but it was not done for the
list view where it matters equally (if not most regarding the flow).
Indeed, those views / this model is mainly accessed for debugging
purpose in which case you are most likely looking for a specific asset.
In the website case, it's most of the time to find the custom asset
that was created following a scss customization in the right panel of
the website builder.
In such a case, it will have a website_id and will be easy to find in
the list view.
It's also the case for all the records having a `website_id`, we show
that field in both form and list view, it's always important when
managing / debugging DBs in multi-website environment.
See [1] for introduction of `ir.asset`.
[1]: https://github.com/odoo/odoo/commit/8cc066173dfb61bd95b8e1f0716f71f4e251810aclosesodoo/odoo#112156
X-original-commit: 1e6ea1a1e38f9769b91b80c3fd1e2ecabae35bb6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The editor offers bootstrap tooltips, but these were not all initialized
and therefore appeared as standard HTML tooltips. This commit fixes that
by initializing all the tooltips so that they all have the same style.
Details:
- The bootstrap tooltips are now available in translate mode.
- With bootstrap 5, only one bootstrap component can be initialized on a
HTML element. This is why the tooltips are now initialized on the
first child when there is another bootstrap component.
- Some tests have been adapted.
task-2777738
closesodoo/odoo#85666
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The website now being displayed in the backend of Odoo (since [1])
within an iframe. To be able to send events inside this iframe, the
`PublicRoot` widget from within the iframe is "captured" (using the
`OdooFrameContentLoaded` event). This is used to send events to Public
Widgets such as notifying them that the edition is about to start, so
they need to reload in edit mode.
Prior to this commit, the WebsiteRootInstance would be set to
`undefined` when the page was about to be unloaded (`beforeunload`
event). This is useful as this prevents the editor to start in an
inconsistent state if a user clicks on a link or changes page and clicks
edit too soon.
Unfortunately, the beforeunload event can be canceled.
Two ways this can be noticed:
- On firefox, enter edit mode and edit the page
- Try to close the tab
- A browser dialog is displayed asking the user to confirm if they want
to leave the page
- This is done using the beforeunload event
- It is triggered in both the iframe and the top window on firefox when
trying to close a tab
- Clicking on cancel won't allow you to resume the edition as the
`websiteRootInstance` was set to `undefined`
- On any browser, enter edit mode
- Upload a document using the media dialog
- Save
- Click to download the document
- Try to enter edit mode
Clicking on the link triggers a `beforeunload` as the browser is about
to leave the page. The browser somehow detects a download and cancels
the beforeunload. But the `websiteRootInstance` was already set to
undefined.
This commit fixes that by only setting the websiteRootInstance to
undefined in some context:
- When clicking on a link that will result in navigating inside the
iframe
- When changing website
- When the `WebsitePreview` component is asked to reload the iframe
- Doing it again when a `pagehide` event is triggered.
This last one is only for safety (e.g. if a widget within the iframe
triggers navigation which leads to a pagehide). Though using this event
is often too late, as the editor has time to start but often not fully,
and destroying it so early can lead to tracebacks.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3046473
closesodoo/odoo#112048
X-original-commit: e47a9900e4a7842774d33a332b325e1f08c3ca45
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Commit [1] improved the url dependencies search behavior to include more
models to search in but also the multi record capability (needed for
multi delete in list view now that website is in the backend).
But a line of code was badly designed, making the perfs horrible.
That line code shouldn't have been part of the loop as it doesn't
depend of the loop.
This was drastically more impactful on the `/` page.
Benchmark: for the `/` page, searching in 1000 product template website
description will go from 29.74 seconds to 0.29 seconds.
See the speedscope result on the PR description.
For ~10.000 products, it will go from ~7 minutes to 1.35s.
[1]: https://github.com/odoo/odoo/commit/6ac17b93437868cbefbe13448a6fcbb29953f221
task-3169378
closesodoo/odoo#111933
X-original-commit: 9816b2ba6ee85dcba7b2f85e70c617994b7748c4
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit conditions based on `_handle_visibility` and
`_get_cached_visibility` did work only by relying on the cache of the
`menu.page_id` being populated when accessing `is_visible` in sudo.
This does not work if the cache is cleared between the calls.
This commit makes sure all 3 conditions have access the record.
The actual issue has not been reproduced locally yet.
The various workers, crons, websocket work on distinct envs - even
through code they cannot impact the cache of another local env outside
the `check_signaling` system which is only used between requests.
For the problem to occur, some intra-request multithreading is needed
but it could not be located so far.
task-3149270
closesodoo/odoo#111882
X-original-commit: a864192ecd270848fede23d3eb053318d07ae8e8
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, if a link to a page was not correct because of a
case mismatch, it would simply land on a 404 page.
While it's correct, as URL are case sensitive, it leads to a few bad UX
flow at the admin/editor level:
- Create a link in your page (on a text or a button eg), type an URL
which does not exists (to create it after) like /Page
- Click on the link/button you just made, you are redirected to /Page
which display a 404 with the "Create page" option (correct)
- When you click on that button, it will actually create a page with
/page URL, leading to a mismatch between the URL you created and the
page URL.
Your link/button will still lead to a 404 URL as it points to /Page.
Since it's just a fallback when an exact URL match is not found, it
should not break anything and should not have bad impact at any level
(seo/speed etc).
Indeed:
- It's done through a 302 redirect
- `_serve_page()` is already a fallback case, so it will only make
the `website.redirect` and 404 cases a bit slower due to the extra
search query.
The only possible scenario seems to be if the user (mind the uppercase):
- Created a /Page page
- Created a redirect from /page to /another-page
In this case, /page won't land on /another-page but on /Page.
This flow seems unlikely and is not actually wrong either way.
At least, it certainly is less important than ensuring a case
insensitive fallback.
Finally, note that another solution would have been to either:
- Force page URL to lower case.
-> This is not stable friendly, people might be relying on this to
create pages with different casing:
`/Batman-VII-The-Dark-Knight-Whatevers`, while not recommended,
doesn't sounds idiot.
On top of not being stable friendly, we probably want to keep
offering this possibility
- Redirect all URLs to lowercase endpoints.
-> This is obviously not stable and not Odoo's jobs. It should be
something decided by the sysadmin and done at nginx (etc) level.
task-3110294
opw-3104030
closesodoo/odoo#111736
X-original-commit: f05491105f93939490cbeb078cb7653c38685644
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_event
Since [1], it was not possible to customize the SEO values of an event
sub-page because a condition was inverted by mistake. Opening the SEO
dialog on those sub-pages actually displayed (and allowed to save) SEO
values related to the event main page.
[1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1
Related to task-3129034
closesodoo/odoo#111289
X-original-commit: 2072a7739eb9a9ee87c8b3c7b0d43a82a7e2375f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_sale
During the big "website-in-backend" refactoring, [1] and [2] were made
to add the "edit-in-backend" and publish buttons in the systray. At the
same time, the information about if the main object of the iframe is
available to "edit-in-backend" / is published was added on the loaded
iframe's html element (as was already the information about what the
main object is).
The problem is that [1] + [2] were merged around the same time as [3]
which decided to put the existing data addition on the html element...
in a t-if. [1] and [2] ended up adding the new information only if the
user is a designer, while it is actually needed as restricted editor
users. As a result: the publish and "edit-in-backend" buttons did not
appear anymore for restricted editor users.
At the same time, [3] seems wrong on its own, as it moved some
information in the conditional block although we wanted that information
to be available even for visitors (especially, the main object which is
for example used by the product snippet*). This is fixed by this
commit too.
* Steps to reproduce:
- As a restricted editor, go to /shop in the backend iframe
- Click on a category at the top
- Edit
- Add a "Products" snippet in the category-related area
- Click on it and choose "Current" as the value for the category
=> Crash. That crash actually also occurs as a visitor on page load if
such a snippet was saved by an admin first (but the crash in that case
is silent).
Note that the "seo-object" info is not needed by public users but was
restored as a public data as it was the case in 15.0. It might make
sense to some custo. However, the "oe-company-name" info, which was
public in 15.0, is kept shown for designers only as it seems to be dead
code in 16.0 (will be removed later on in master).
Unfortunately, no stable fix can really be made to solve this issue:
this commit had to modify the existing `website.layout` XML. So to solve
this issue in existing databases, you either have to patch the view
accordingly or update the website app. That should be ok, considering
that the only real problem is that some options cannot be used as a
restricted editor user.
[1]: https://github.com/odoo/odoo/commit/f260e3c1441b380d0c9f5294d7cadcaad9c90662
[2]: https://github.com/odoo/odoo/commit/028efcbffe1cbaa00fe6a262151c75fda922008d
[3]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
task-3129034
X-original-commit: bfb6d7820c35f3eba3bb760810866350092a16d9
Part-of: odoo/odoo#111289
The page properties and optimize seo menu items were not explicitly
marked as not shown for non-designers. An unrelated bug currently hides
those items by chance... but as that bug will be solved in a further
commit of this same PR, it had now to be explicitly hidden in that case.
Note that after this a related bug remains: the "This page" title on
top of those sub menus is left visible if no sub menu is shown and
clicking on it actually crashes. That bug will be solved in another PR.
Also note that it might make sense to show the optimize seo dialog for
restricted editor users when they have the correct rights... but this
would be an improvement to consider in master.
Related to task-3129034
X-original-commit: 26c46ba70bac227c2b6a28a941e5c4f13bfe9029
Part-of: odoo/odoo#111289
Before 16.0 and the website-in-backend refactoring made at [1], the
publish button of the frontend had this behavior:
- The record is unpublished
- Click on the publish button -> a rpc to publish is sent but the
switch visual state is not updated (the internal checkbox is still
unchecked)
- The rpc comes back with the response -> the switch visual state is
updated (red -> green)
This is actually the behavior since the bug fix made at [2]. The main
point of this commit was to prevent toggling the checkbox while its
javascript behavior was not initialized yet.
From 16.0, that loading problem is not an issue anymore, as the publish
button is instantiated client side and thus only appears when it is
possible to use. We can thus update the visual switch state as soon as
the user click on it for a better UX. However, that was flawed:
1. If the publish action actually failed, the switch was kept
checked/unchecked while it should be reverted to unchecked/checked.
2. If you clicked very fast multiple times on the button, many RPC were
sent and their result order was not guaranteed.
3. There is no possibility for tours to wait for the actual publish
action to be done... and that will be needed in a further commit of
this PR.
This commit fixes all those flaws:
1. If the RPC fails, we now revert to the status before the user clicked
on it. Inspired by [2], the internal checkbox is now disabled, which
leaves its status entirely up to OWL instead of browser behaviors.
2. The switch now stops listening to clicks while a RPC is being
performed.
3. While a RPC is being performed a "data-processing" attribute is added
to the whole switch area.
Note: in master, the whole switch system should be reviewed. The publish
button one's structure actually makes no sense: a <div> which contains a
<a> which contains a <label> (already invalid DOM), with the <div> being
the event handler of the switch status changes...
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/2e751d80dd4b23abf374d5aa488827faaa593e62
Related to task-3129034
X-original-commit: 36a8fe44d6ec609a9bad8d960768766a44d4074e
Part-of: odoo/odoo#111289
This commit adds a new feature to the web editor of a website. A "text"
input field has been added to the link editor panel, allowing users to
edit the label of a link.
The label will only be updated when the input is changed, to prevent
loss of formatting (e.g. if one letter is bold).
However, only formatting applied to the entire selection will be kept
(e.g. if you have a "link <b>like</b> this", nothing will be in bold if
you update the label in the editor panel).
Additionally, if there is a media element (such as an image or icon)
included in the selection, the "text" input will be hidden.
task-2900529
closesodoo/odoo#99239
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
*: website
When changing the padding of the grid items with the `Padding (Y, X)`
option (when the grid mode is toggled), depending on these items
content, the effects are not always visible.
This commit adds a highlight effect on the grid items when the padding
is changed, to better show the changes being made.
task-3058630
closesodoo/odoo#111584
X-original-commit: f3f2c4c73ce08d3898b8c88e1ef045f7bbd1f624
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
Before this commit "parallax" animation was not working in modals.
This commit adds a parameter to the animation effects to enable
animations (triggered by the scroll) in the modals.
Note that for the "Newsletter" popup we have hidden the "parallax"
options. To make them work, it would be necessary to review the
structure of the "Newsletter" popup so that the vertical scrollbar is in
the same location as the "s_popup" snippet (on the ".modal" element).
task-2971402
closesodoo/odoo#111424
X-original-commit: f369686c1b74219968746a0f0a164dd6b3c5cfc6
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Since [1], a race condition would be faced as the dict order is not
guaranteed, sometimes failing because:
```
AssertionError: Lists differ: ['/demo', '/admin'] != ['/admin', '/demo']
```
[1]: https://github.com/odoo/odoo/commit/a87b4142dd4a2c05e3e1885b2c54f5e0d3c7ac47
runbot-15727
closesodoo/odoo#111417
X-original-commit: 3e9a1dd76ce5172c4797bc92f0351e107589c3a5
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since [1] when the translations becames stored as JSONB, the
translations of website-specific views were lost when adding a new
language.
[2] did fix a similar problem when installing an App, but did not
solve this.
This commit makes sure to only change the requested translations
without impacting the existing ones when a language is added.
Steps to reproduce:
- Add French language to the website
- Add the number snippet on the homepage
- Translate "Useful options" -> "Options utiles"
- Go to setting -> Languages -> Activate any language (not even on a
website)
=> French translation disappeared.
[1]: https://github.com/odoo/odoo/commit/ef00294e7189359c47638c4a71626f1937395edb
[2]: https://github.com/odoo/odoo/commit/91a9c870eede96040ac49d2375fe0e18342342e1
opw-3120079
closesodoo/odoo#111378
X-original-commit: 52fd577de8e270f84e8ca23c9350f2fb3ab5a7d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Ignore anchors, those are not sent to the server anyway, no way to
compare even if we wanted to
- Ensure query string (qs) are the same to be considered equals
On top of that, it also fixes the case when the user inserted an
absolute URL instead of a relative one, it will now match.
task-3096367
opw-3091427
closesodoo/odoo#107782
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- `clean_url` method was wrongly flag as `api.model`
- the `unslug_url` was not called for the URL comparison in the dropdown
case, meaning that `/shop/prod-1` would not match `/shop/product-1` as
it should (and as it does for regular non dropdown menu)
- the `active` class was actually never working for the dropdown case,
as the class was added on the wrong element (`li` instead of `a`)
The code was hard to read (mainly because huge python conditions in XML)
and kinda redundant, going through an util method should be clearer and
help reading the template XML.
task-3096367
opw-3091427
Part-of: odoo/odoo#107782
Due to the end part of the regex `(?=$|/)`, it will not find and thus
not unslug string if they end up with a query string or and anchor
except if there is a trailing slash before.
First, it's unlikely that there will be a trailing slash as it's not
common and on top of that, Odoo try to enforce non trailing slash in
URL.
Second, it's not that hard to makes those cases work.
Before this commit, the following string would "match" and be unslug:
- /blog-1
- /blog-1/
- /blog-1/register
- /blog-1/?qs=2
- /blog-1/#anchor
But those would not:
- /blog-1?qs=2
- /blog-1#anchor
Part-of: odoo/odoo#107782
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since the refactoring of website.visitor with [1] (upsert), the
`access_token` is supposed to be holding the same value as the
`partner_id` when the visitor is linked to a partner:
- Anonymous visitor: no `partner_id`, `access_token` is a hash value
- Partner visitor: `partner_id` set, `access_token` should be sync with
`partner_id`.
`partner_id` is just a stored computed field holding the `access_token`
value if it is an integer value.
There should never be a case where there is a `partner_id` set and the
`access_token` is not equal to the `partner_id`.
For instance, having a visitor with `partner_id` = 4 and `access_token`
= `e4r3ejkj4` is supposed to be impossible.
It would lead to crash, because the visitor is only searched based on
his `access_token`, meaning that when searching for the visitor of
partner 4, none would be found and a new one would try to be created,
raising the `uniq_access_token_id` SQL constraint.
While the `partner_id`/`access_token` sync might seems weird, it is done
to allow the `upsert` use in SQL to improve perfs of this low level
behavior.
It's actually not as weak as it seems as there is only a single entry
point to update the `partner_id` and `access_token`: the authenticate
override of website.
Those fields are not supposed to be changed elsewhere.
Note that modifying the `access_token` would not be an issue as the
`partner_id` is just a stored compute based on the `access_token`.
But it's only true when modifying through the ORM as if you do that in
raw SQL, it won't go through the `api.depends` which is supposed to
recompute the stored computed `partner_id` field.
But something was forgotten during the initial dev: the partner merge
behavior: it does (on top of other thing) auto discover the m2o field
relations that points to a `res.partner` and modify those values in raw
SQL to the new value.
This is obviously wrong regarding the `website.visitor`'s `partner_id`
field, the `access_token` should also be updated, or when possible
visitors should be merged too.
Note that for DB upgrated from previous version to Odoo 16, this is
ensured through the following upgrade script [2]:
```sql
UPDATE website_visitor
SET access_token = partner_id::text
WHERE partner_id IS NOT NULL
```
[1]: https://github.com/odoo/odoo/commit/d348bed1ad9d3d16b295f013f015706be6c07820
[2]: https://github.com/odoo/upgrade/commit/0cedcbf70494dfeddeb5a97c13bf875cb6a86886
task-3148111
closesodoo/odoo#111002
X-original-commit: a87b4142dd4a2c05e3e1885b2c54f5e0d3c7ac47
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
- Install website and set in French
- in the robot wizard you see:
Exemple de règle :
Refuser : /web/login
Autoriser : *
closesodoo/odoo#110911
X-original-commit: 10e50eeeb4c3c83da2c671bd600561679fdacd44
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The "All Websites" list of views is confusing for users with its
combination of default and specific views.
This commit makes the "All Websites" filter only available in debug
mode, and defaults the selected website on either the current website
(if one is selected) or the first website of the list.
The test is adapted because only the current website's pages are
displayed now.
task-3092786
closesodoo/odoo#110898
X-original-commit: 01cb743f1c0c22621bcfa92005a7d10dfa92e746
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website_crm, website_form_project, website_hr_recruitment,
website_mass_mailing, website_sale
Prior to this commit, modules that add elements (fields, references,
etc.) to the website_form registry, would do so inside the
`website.assets_editor` bundle.
It creates a module dependency error since [1] + [2]:
The form options (`s_website_form/options.js`) defined in
`website.assets_wysiwyg` requires the registry defined in
`website.assets_editor`. But since [1] and [2], the
`website.assets_wysiwyg` bundle is loaded inside the iframe without
`website.assets_editor`, as only `website.assets_wysiwyg` is needed to
properly display and interact with the editor. (Although, most of the
bundle is not necessary and a later IMP will either only load the CSS
needed or split the bundle).
This commit moves the modules that creates the registry as well as
modules that extend it to the `website.assets_wysiwyg` bundle, fixing
the dependency error. Though they are not required inside the iframe,
the bundle can now be loaded without the need of assets_editor,
removing the missing dependencies. But mainly, this should have been the
case since the introduction of website.assets_wysiwyg at [3] anyway: we
want to lazy load everything that is editor related. Although it was [4]
which mixed the form editor files between the `website.assets_editor`
and `website.assets_wysiwyg` bundles.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[2]: https://github.com/odoo/odoo/commit/a154ee7ad6fd3ebdd38943e1439badae11c3151d
[3]: https://github.com/odoo/enterprise/commit/19a144d6af2974e964c6487170e6bca1b14d3898
[4]: https://github.com/odoo/odoo/commit/f8882698e8f4d1a3ad081522778344e2bd7aa0declosesodoo/odoo#110811
Related: odoo/enterprise#36195
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Currently, the character `/` appears at the end of the url of the
language dropdown on the home page e.g. /en/, /fr/. This will cause one
more redirect when performing the language change.
Indeed, this error is only encountered with path = /
Please try the following `url_lang('/', 'en_US')` => /en/
After this fix, the trailing `/` will be removed when using the func
`url_lang` e.g. `url_lang('', 'en_US')` => /en, this means that the
language switching links on the homepage no longer redirect redundantly
again.
closesodoo/odoo#106109
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Julien Castiaux