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>
This commit is a follow-up of odoo/odoo@bb819f6a5c.
Even if the fix above worked around having the settinggs header's
content out of screen on smaller screen, the solution was ugly and was
meant to be improved later on.
This commit reworks the HeaderSetting's template and simplifies it to
properly fix this issue.
closesodoo/odoo#110530
X-original-commit: 0ab079664e380e5e77440e290ec604e3830108bb
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, this flow was broken:
- Install website
- Create a new website of your own (not using the one created
automatically from XML data)
- Choose another color palette for that website
- Uninstall the website app
- Reinstall the website app
- Try to choose another color palette for any website
=> It does not work
Indeed, after the uninstallation, the DB is left in an invalid state:
the SCSS customizations attachments of the website that was created by
the user are not removed, they just have their website_id field emptied.
Some code made at [1] was already there to remove those attachments. The
problem is that it only worked for websites which were created by XML
data (at website installation), not by the user. Indeed, the `unlink`
method is not called during uninstallation to remove records that were
created by the user, thus the `unlink` override was not called either.
See [2] for some details.
This fixes the issues by moving this attachment cleaning code in a
dedicated method, called in `unlink` but also in the `uninstall_hook` of
the website app.
This also takes the opportunity to refactor the code involved, in
particular to not even consider customized attachments which do not have
a website_id.
[1]: https://github.com/odoo/odoo/commit/2f361bec36dff09181b96d140d62c477cdf013a1
[2]: https://github.com/odoo/odoo/pull/97852#pullrequestreview-1067851656
opw-3127531
closesodoo/odoo#110338
X-original-commit: 988eafa03b57be3b3a7f110650c61ce8fda88e31
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When the QWeb `<template>` loading test was introduced at [1], the
`test_website` module did not exist yet, see [2].
This commit moves that test and its related data file to `test_website`
to remove the `fake data` noise from the `website` module.
That's one of the two purpose of this `test_website` module:
- Avoid noising the website module with test only data & code
- Encapsulate in a lighter module the module operations tests, but it's
not really the case anymore as those tests are now standalone tests.
See manifest for more details.
[1]: https://github.com/odoo/odoo/commit/9cd982bcc811cacb42f5c08db139043d2734b891
[2]: https://github.com/odoo/odoo/commit/ef03db9edd9472201cb2c08a32d20ff0f33a5fdfclosesodoo/odoo#109349
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit:
When entering edit mode on the website and discarding directly, the editor
considers that there are changes in the DOM and displays a confirmation modal.
After this commit:
When entering edit mode on the website and clicking directly on discard, the
confirmation modal is not displayed.
Task-3056463
closesodoo/odoo#110515
X-original-commit: 650a97d1bd59254cc2115d54d58940b6112a8d70
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: Dhaval Baraiya <dhba@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to avoid html entities in logged message by correctly
managing enclosures. For that purpose a new tool 'nl2br_enclose' is added that
eases Markup management on top of 'nl2br' simple tool.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
In website(_sale) messages are created from website forms. However those
are technical models, you should always use the MailThread API notably to
ensure values coherency. In our case using message_log seems to be what
original committers wanted to do (even creating a message as a comment
which has no effect as the notification process is not called that way).
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
* = digest, hw_posbox_homepage, im_livechat, mass_mailing, web_editor,
website, website_slides_forum
Since the migration of Bootstrap 5 [1], some CSS rules was automatically
converted (`border-left` and `border-right`) when it shouldn't be.
These conversions were made because the CSS rules was embedded in
HTML/XML code and the REGEX for the conversion had no protection for
these cases.
This commit restores the old correct value.
Ref:
[1] odoo/odoo@1fcd098af5closesodoo/odoo#110141
X-original-commit: 0cbf7c00ecc307fc725da345415647828e771bb4
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
When overriding an existing controller route, developers can
easily c/p the route definition and call super() in the overridden method
when the route attributes are automatically deducted by odoo from the parent route.
Removing those redefined attributes simplifies the routes definition,
clearly highlighting what's changed by the override.
Also reduces unexpected behavior when modifying the base route without
noticing/considering the redefined attributes in a overridden route,
which overrides the changes made to the base route when the sub-module is installed.
This commit adds a test to catch routes attributes redefinition, and clean existing routes.
closesodoo/odoo#108512
Related: odoo/enterprise#35176
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since it's first implementation at [1], a new cursor is created to then
build a new environment after the website's `authenticate` overide with
the new `uid` of the logged in user.
Since the new visitor SQL upsert refactoring done at [2], it seems to be
introducing a SQL deadlock sometimes.
It has been detected on odoo.com while monitoring the logs. Despite
being quite rare, it still happens too often due to our heavy trafic.
Step to reproduce (among others):
- Install website_livechat
- Login as admin on 127.0.0.1
- On 127.0.0.2, load the website
- Open the livechat
- Type something in the discussion
- Directly try to login as admin
- It will load for a certain time then crash on a 502 timeout due to the
SQL deadlock
- You may need to repeat the process to actually face the bug
[1]: https://github.com/odoo/odoo/commit/6bec0e4d29e6b33b74962b2893a7a405667ef58c
[2]: https://github.com/odoo/odoo/commit/d348bed1ad9d3d16b295f013f015706be6c07820closesodoo/odoo#109830
X-original-commit: b241cf7de9329af1410b9dd45b161aa41926effb
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This basically reverts [1].
After discussion with the related team, [1]'s purpose was to prevent
merging two links together if backspace was hit at the beginning of one
mega menu item. [1] however made mega menu creation impossible as it
prevented removing any mega menu item (well, you had one possibility if
you used Chrome which was to unlink the mega menu item and then remove
it via backspace but...).
After some more discussion, we decided that allowing to merge mega menu
items seems not bad (it is the same behavior as the rest of the editor
when two links are next to each other). In any case, being able to
remove default mega menu items is more important.
[1]: https://github.com/odoo/odoo/commit/9779145d9157e9687c36d2caa0ecea2862a2ac5a
opw-3109946
opw-3120070
closesodoo/odoo#109804
X-original-commit: 7de359470fb4d8eb81f018262a5e4c66a71c7043
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the title attribute on navbar items.
The title was only repeating the content so it was useless.
closesodoo/odoo#109230
Task: 3097276
Related: odoo/enterprise#35562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the behavior disabling the unused snippet assets
performed two checks:
1. It was looking for occurrences for its use in the snippet template
2. It was looking for occurrences for its use in the HTML fields
3. Checked on the occurrences of step 1 and 2 and return result.
In many cases there are already coincidences in the first step, making
the second step unnecessary since this second one is the slowest.
Matches are now checked between steps 1 and 2 to skip the second if
matches are already found.
closesodoo/odoo#109488
X-original-commit: 56100532dbcbdeb5487662d0cbf35ba6d62b15b5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Romain Derie