When the `s_nb_column_fixed` class is present on the row, it should not
be possible to change the number of columns in the "Columns" option (the
option is supposed to be hidden).
However, since commit [1], this behavior is broken. It happened because
the "Columns" option needs to always be displayed in order to display
correctly the "Grid" option and this class was therefore ignored.
This commit restores this class behavior by hiding only the widget
changing the number of columns and not the complete "Columns" option, in
order to still be able to toggle between the grid and the normal modes.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
task-3369847
closesodoo/odoo#127144
X-original-commit: 8148521f052268877f36947e0533843a25d17b83
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
We have a public widget that disables automatic slides on carousels when
the user is in edit mode (see `registry.slider`). Unfortunately, since
[this commit], the automatic slide of the carousel in the "Products"
block was not disabled in edit mode. This was because a
`widget_start_request` was made without specifying whether the user is
in edit mode. When it's not specify, we consider that we are not in edit
mode. As a result, the public widget no longer stopped the carousel
because it considered that it was not in edit mode. This commit fixes
this problem by correcting `widget_start_request`.
Steps to reproduce the bug fixed by this commit:
- Have an ecommerce
- Edit a page
- Drop the "Products" block
=> If you wait a few seconds, the carousel moves, even though it
shouldn't as long as you're editing your site.
[this commit]: https://github.com/odoo/odoo/commit/7af099ccf1e5892513c1b0827553fe93614f2f07
task-3356629
closesodoo/odoo#127185
X-original-commit: 4231aca9665829673e29a027469471743dab16c4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
The `PageDependencies` obtains the page dependencies from the server
during its `onWillStart`. If the parent component state changes before
the component is mounted, Owl destroys and creates a new one.
This is the case if the server response is not obtained before the
value of the URL field is modified again.
Because of this, if the user types quickly in the URL field, an RPC
is sent for each key press.
This commit obtains the dependencies in a `useEffect` that is run only
once (instead of inside the `onWillStart`), and only after the
component is mounted. It stores them in the `state` so that they are
rendered once they are obtained.
Steps to reproduce:
- Open Website > Site > This page > Properties.
- Type quickly in the URL field.
=> One RPC was sent per key press.
task-3169376
closesodoo/odoo#127125
X-original-commit: a65d8811119f4d1a044be3e140fd0c27ad1cf823
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
The issue occurred after the merge of this PR [1]. In that, we removed
the dependency on underscore.js and introduced new functions to the
qweb engine: `range` and `uniqueId`.
The variable named `uniqueId` was clashing with the qweb function
`uniqueId()` that's why variable were getting compiled as a function
instead of the actual value, which led to unexpected behaviour.
This commit renames the uniqueId variable to avoid conflicts with the
qweb function `uniqueId()`.
[1]: https://github.com/odoo/odoo/pull/123018
task-3357115
closesodoo/odoo#124659
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce the bug:
- Drag and drop several snippets onto a web page in edit mode to make
the vertical scrollbar appear.
- Drag and drop a popup onto the page.
- Drag and drop snippets into the popup so that the height of the popup
exceeds the height of the viewport.
- Try to scroll the popup downwards by clicking and dragging on the
scrollbar (not using the mouse wheel).
- Bug: the page is scrolled instead of the popup.
Note: This bug occurs in Chrome (not in Firefox).
This issue occurs because two scrollbars are present at the same
location (one for the page and one for the popup) and they overlap each
other. Normally, Bootstrap removes the scrollbar from the body when a
modal is opened, and this behavior was adapted for the #wrapwrap element
with this commit [1]. However, when transitioning to Bootstrap 5, the
code that overrides Bootstrap was removed instead of being adapted (this
was done in this commit [2]).
In later commits [3] and [4], we continued to remove code that updated
the scrollbar based on the opening of a modal because this code was
causing errors due to the fact that it was incomplete without the part
removed by commit [2].
This commit restores the original behavior (before the deletions made by
the aforementioned commits) by restoring the missing code and properly
adapting it to Bootstrap 5.
[1]: https://github.com/odoo/odoo/commit/9cf8b97fe40444b44ebb6e6fb992bc658a087d32
[2]: https://github.com/odoo/odoo/commit/0b94da214b7017e8580e671cbaa68ade6de2fbc7
[3]: https://github.com/odoo/odoo/commit/cb7cf77ed080e86f800af61c9a3dc4ad36ad6cfb
[4]: https://github.com/odoo/odoo/commit/51939d09f84579f61f1ff77aacd754beba036dc2
task-3102275
closesodoo/odoo#126709
X-original-commit: 0e75f1c01ca4fcc3eb483a7256bcf72b2bca39c3
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
1. Introduce primary variable to simplified overridden value of
`$min-contrast-ratio` and document its need.
2. Reduce `$min-contrast-ratio` to 2.9 to solve the inconsistency with
the previous version 15.0 of text color over some background color.
Of course it won't restore everything to the way it was: we still
want the version 16.0 to be an evolution over version 15.0 using what
bootstrap recommended to compare contrasts. But as going from 3.0 to
2.9 should not impact existing websites too much and solve use cases
we feel need solving, we feel it is an ok change.
3. Restore override of the `color-contrast` method that will now
handle the transparent colors. Before this commit, a color-contrast
function was just considering RGB value only, after this commit it
will consider RGBA value, relying (by default) on the fact the body
background is the background behind the colors we are comparing.
task-3241031
closesodoo/odoo#126759
X-original-commit: 313220ed4a0ff4ae26eb113a3a88b0dc44b649fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
Steps to reproduce the bug:
- Drop the image-text snippet on the homepage.
- Double click on the button inside the snippet.
- Choose the homepage as the URL ("/").
- Open the "Page Anchor" selector and click on "#top".
- Bug: the select does not close itself after selection.
This bug occurred because there are two instances of Bootstrap on the
same element (the link anchor dropdown): the "bs.dropdown" instance and
the "bs.tooltip" instance. The tooltip instance was added by this commit
[1], probably unintentionally during a copy-paste operation.
Additionally, the text of the Tooltip was not correct ("Link size").
Having these two instances on the same element caused an error because,
since this commit [2], we check that an element doesn't have only one
instance. If multiple instances are found, the others are disabled. This
check was the reason why the "bs.dropdown" instance stopped working.
Note that we could have kept the Tooltip by moving it to the
"we-toggler" element. However, we removed it because it didn't provide
any additional value, the text of the label itself is sufficient.
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
[2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3378864
closesodoo/odoo#126715
X-original-commit: 6367129caf2c5d4e59ba7db0fe47047be0cb6caf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Form fields can be prefilled since [1] and their visibility
conditionally linked to other fields since [2].
1. This commit ensures prepopulated fields trigger the conditional
visibility mechanism (A), including when said field is first hidden,
then conditionally displayed (B).
2. Until [3], with a chain of visibility conditions, when one of them
was "contains", "does not contain" or a date-related condition, a
traceback was raised (C). This commit corrects the fix from [3] to
prevent this behavior now that the reason has been identified.
3. Tests are also set up to enforce these fixes.
Steps to reproduce (A):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated from user mail
- Save and check the form: A won't be shown despite B being set
- Removing one letter or typing anything in the input B will trigger
the visibility of A.
- Expected result: B should immediately appear.
Steps to reproduce (B):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated and depend on field C being set
- Field C is empty by default
- Save: only field C is shown. Type a letter: field B appears, but not
field A.
- Expected result: both should appear.
Note: this bug only occurs when field A is before field B.
Steps to reproduce (C) (until [3]):
- Drop a form
- Field A depends on B containing "abc"
- Field B depends on C being set
- Save and type something in C: there is a traceback.
task-3335536
[1]: https://github.com/odoo/odoo/commit/54873d2
[2]: https://github.com/odoo/odoo/commit/2dcbfec
[3]: https://github.com/odoo/odoo/commit/2714469closesodoo/odoo#126634
X-original-commit: 074dbb6842de1092af2abe51e6da0433ff38a96e
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
For each form action, existing fields can be defined. These existing
fields are references to objects in the ORM. It is possible to put a
domain on the field in order to filter the elements you want. For
example, the "Create an opportunity" action has a "Salesperson" field
that refers to users. This field filters the external users of the
company in order to have only the internal users. Unfortunately,
although this domain is present, it was not taken into account when
displaying the values for the field. This commit fixes this problem and
takes into account the defined domain.
Steps to reproduce the bug fixed by this commit:
- Have the website_crm module installed
- Put a form on a page of the website
- Set the form action to "Create an Opportunity"
- Add a new field
- Set the field type to "Salesperson"
=> The list of users displayed contains external users of the company.
task-3095745
closesodoo/odoo#121903
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit ensures that the unsplash beacon calls home when an unsplash
image appears on a page.
To achieve this it patches the RPC call when the test URL contains the
test name as parameter. The patch cancels the actual beacon call to
avoid polluting data during the test, but marks the image as having had
its beacon message sent. The test then simply checks if this marker
appears on the image.
task-3360109
closesodoo/odoo#126522
X-original-commit: 1b0f25130b461e7b531548363c680200c7363e7f
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Website configurator 'website/configurator/4', Pages and Features description
takes up more than one line owing to the larger 'font-size' of the h4 class.
With this PR, use heading size `small` instead of `h4` so that description
remains in a single line.
task-3326543
closesodoo/odoo#121743
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Reproduction:
1. Install Event, Sales, Webiste
2. Login as Admin, go to Website -> Go to website -> Events
3. Click the Open wood event, Register, buy one VIP ticket
4. In Address step, Edit the billing address, change the name to “Test
Name”, click next
5. The user name “Mitchell Admin” is changed to “Test Name”, we
shouldn’t be able to change the info
Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
we use the can_edit_vat to check if we have existing invoice(s) or
SO(s). However, we should block the route that an employee changes the
billing address when placing an order. If they are placing an order for
external people, it should be done from the back end.
Fix: add an extra error case when it's an employee trying to change the
name or email address when editing billing address. This is the case
when an employee tries to order for external people. They should do it
from the back end. They can still buy for themselves without changing
the billing address. Also added translation in pot. Edited the test for
editing address of log in user, added tests for portal user. Reformat
the invoice exsits check for name change to have better readability
The adding of can_edit_vat:
https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085
Related fix to block the name change:
https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
A patch to not block the checkout process when name is not set:
https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394
opw-3126325
closesodoo/odoo#126261
X-original-commit: 972c55bf76f4c5f1b1bedec4a77ddaeac8be1483
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds a margin top on the we-alert to make it prettier.
Otherwise, the alerts are too close to the elements above them.
task-3302433
closesodoo/odoo#120874
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Users are not supposed to be able to change the field type for fields
that are required by the model. This commit removes the option to change
the field type for fields required by the model.
Steps to reproduce the bug fixed by this commit:
- Put a form on the page of a website
- Set the form action to "Send an E-mail".
- Click on the "Your Email" field
=> The user can change the type for this field. We don't want this
because this field is linked to the `email_from` field in the
`mail.mail` model. This commit fixes this issues for every model
required fields.
task-3302433
Part-of: odoo/odoo#120874
When a user puts a form on his site, depending on the action of it, some
fields of the form become necessary. These fields cannot be deleted.
Unfortunately, some users do not understand this. This commit helps
users understand that these fields are required for the action by adding
an alert in the required fields options and by improving the tooltip
displayed when the delete button is hovered.
task-3302433
Part-of: odoo/odoo#120874
*: web_editor, website
The goal of this commit is to add the reorder option on the carousel
slides. Because the option is now shared between the "Carousel", the
"Image Gallery" and the "Images Wall" snippets, a common super option
(`GalleryHandler`) has been created to handle this reordering.
task-2930786
closesodoo/odoo#117369
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Steps to reproduce:
- Add a form.
- Setup a conditional visibility on one field, using the "contains" or
"does not contain" operator.
- Save.
- Open the HTML editor and voluntarily break the form by changing the
"data-visibility-dependency" attribute to a random text (non existing
field used as a dependency).
- Save => Crash on page load.
One customer apparently reached that case of receiving a `null` value
(actually possible when retrieving a form data which is an unchecked
checkbox for example) but combined with an operator which really
requires the received value to be a string... but not sure how this is
possible. In any case, it should not make the form crash: it's just a
problematic *visibility* dependency, it should not prevent using the
form. For now, let's prevent this case to crash and add an error in the
console so we may investigate the issue if it ever shows up in a test.
opw-3243345
closesodoo/odoo#125981
X-original-commit: 27144695ff4cd5fc026332c324cfdf8498d5ef14
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Previously, any call to `IapAccount.get` during testing would lead to
the creation of a new `iap.account` record as this was done in a
separate transaction which is commited.
As we don't want any database modification resulting from a test
execution, we will now check if we're in test mode or not.
During testing, a new account will be created in the current transaction
so that it can be properly rollbacked at the end of the tests.
This commit also modifies how the `iap_jsonrpc` function is disabled
during testing as the old implementation used some pretty obscure
manipulations of the `BaseCase` class.
The tests of the `website` module needed to be updated to take those
changes into account.
closesodoo/odoo#122663
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Since [1] an error is raised when switching the Mode of an Images Wall
from Float to Grid or Masonry while an image is selected.
The display of the size of the image is being updated while its option
panel is not there anymore.
This commit prevents this error from happening by setting up the grid
layout with clones of the images instead of the images themselves.
This leads to the construction of a new editor for the new image.
Steps to reproduce:
- Drop an Images Wall snippet.
- Switch Mode to Float.
- Select an image.
- Switch Mode to Grid.
=> Traceback.
[1]: https://github.com/odoo/odoo/commit/2cbb691a84ce186ddd34a2a4c76d95671ed6e834
task-2990053
closesodoo/odoo#125436
X-original-commit: c532bc6c3b861a68e8381f39efaa22201ae253cb
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Prior to this commit, when using the "Slide Hover" reveal effect on the
footer, Safari would glitch it scrolls and could result in unreadable
content.
This commit fixes this by a weird hack that seems to work. Adding an
element with a background-image and a background-attachment set to
fixed seems to resolve the issue.
task-3302302
closesodoo/odoo#125346
X-original-commit: 5766aefcd354e89094c8e650b29529301e39d49d
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
`_lt` must be used instead of `_t` for `gettext`s that are called when
the file is loaded.
closesodoo/odoo#125695
X-original-commit: 1cde6dc66c3337fa8e6c18156340f18fdab1dd84
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Due to a change between Chrome 101 and 114, the CSS Custom Property
containing custom string are now always serialized using the type of
quotes used in their declaration (ie. single quotes will be kept ;
double quotes also) which wasn't the case in previous versions of Chrome
(and still not the case in WebKitGTK 2.40.0 at least).
This doesn't impact the value itself but only comparison between the
computed value and an arbitrary one (like we do in the design-themes
test).
This commit fixes it by removing the single/double quotes in the
`assertCssVariable` test helper.
The impacted precondition was introduced in odoo/odoo@b29e17765f and
odoo/design-themes@8b377af3a7 .
closesodoo/odoo#125500
X-original-commit: 82074846c429dd6abad5734680ca3e7923668bb9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
*: account, crm, crm_iap_mine, event, hr_expense, hr_holidays,
hr_recruitment, lunch, mail, mass_mailing, point_of_sale, project,
purchase, purchase_stock, sale, survey, web, website, website_blog,
website_event, website_forum, website_sale, website_slides,
test_main_flows
In odoo/odoo#111103 the tour system was rewritten. The previous tour
system used to depend on the `root.widget` js module, and this module
was an async module that indirectly depended on `session_bind` which
would load the translations, meaning that the js module definition code
of the tours would only run after the translations were loaded. This is
no longer the case with the new tour system, this means that the module
definition code is executed as soon as the dependencies of that module
are fulfilled, which is generally befoe the translations are loaded,
causing most tour tips to not be translated.
This commit adds a hacky workaround for this problem: it creates a new
module that has a default export which is a promise, and has a legacy
alias, this creates an async module that waits for the translations to
be loaded. This module is then imported for its side-effect in all
onboarding tours, causing them to be translated correctly once again.
This commit also needs to convert the steps key in the tours internal
registry to a getter. In previous versions, the steps were directly
added as is to the internal state of the tour service, but since
odoo/odoo#122834 the steps are now mapped, and without a getter, any
edits to the steps occurring after registration will not be taken into
account. This causes issues in some modules that change original
behaviour of other modules (eg accounting makes invoices into a menu in
the accounting app instead of a top-level app in the home menu) as they
need to edit the steps of existing tours to make them work.
In a separate PR, we will implement a more proper fix by changing the
API of the tour manager so that we no longer need this workaround.
closesodoo/odoo#125284
X-original-commit: d130699ba82dc9919c9116f4b64a5e461ebb6319
Related: odoo/enterprise#42655
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
*: web_editor, website
Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".
When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.
Upgrade PR: https://github.com/odoo/upgrade/pull/4767
task-3287330
closesodoo/odoo#123873
X-original-commit: c82d01f7532b5b120bedfbc40bf8f2f07d750ed6
Related: odoo/upgrade#4767
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
*: website
Commit [1] (and [2]) from the "website in backend" refactoring adapted
the colorpalette to read color information on the right document (as
the right document could now be the one of an iframe which is inside the
editor environment). Unfortunately, it did not do that correctly, making
an inconsistent API relying on the fact the colorpalette should receive
an "editable" param... while a jQuery version "$editable" param of the
same thing already existed. Doing so, it forgot to give that important
"editable" param in two cases:
- For editor toolbar colorpickers (text foreground/background edition)
- For colorpickers inside another UserValueWidget (like we-multi).
This commit solves the inconsistency by removing the need of that
"editable" params and relying on the previously existing "$editable". In
the future, this should be refactored anyway.
Steps to see the issue (A):
- Enter edit mode of one of your website page
- Select some text
- Hit the "reset" (trash button) of the text background colorpicker
=> The text becomes black for no apparent reason.
Steps to see the issue (B):
- Enter edit mode of one of your website page
- Choose a new main color for your website via the theme tab
- Select some text
- Open the colorpicker for the foreground color
- Go to the solid tab and input explicitly the main color of the website
=> The color is hardcoded on the selected text instead of using the
text-o-color-1 class.
=> A test has been added to check this usecase. Making a test for (A)
is less robust as it also requires the backend color names not being
the same as the frontend ones to have the bug (otherwise it works by
chance)... and that will be solved by the next commit of this PR
(another test will be added by that commit too) **.
Note:
- After this commit, following (A), a bug remains: the text receives a
strange padding (as a "inherit" background is actually applied).
Another PR will be made to solve that (see task for more info).
- ** After this commit, (A) done in backend HTML fields instead of a
website page leads to the same bug still. This is because of another
problem that the following commit of this PR will solve.
[1]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
[2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
task-3237693
X-original-commit: a30206606423af9e6c8e0313c74fd6200247437e
Part-of: odoo/odoo#125131
Steps to reproduce the bug (in 16.0):
- Create a hoverable mega menu
- Drop inline Search snippet inside the menu
- Search for something.
- Hover on the search result and move the cursor outside of the search result.
=> Result Error.
Since [1], is having a fix to the overflows of the page. In that fix
we are triggering hide(), and show() events on a 'dropdown-toggle' element
without checking whether the element is exist in the target or not.
this commit will make sure that element should be present in the target
before triggering the event.
[1]: odoo@5846a05
closesodoo/odoo#125083
Closes: odoo#118803
X-original-commit: 4fba98dbe9a82cf0fec9080bea147f5d4d088b53
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds arabic in the list of iap languages so that we can test
that the industries are correctly translated in arabic.
related to task-3343616
closesodoo/odoo#125005
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit ensure the expected tables are accessed when a page (not
only) is requested.
This is needed because without that, we can only check the query count
number which might be broken without being noticed:
- Commit 1 reduce queries by 2 (no need to access table X anymore)
- Commit 2 later reduce queries by 2 (less access on a table) but
without noticing it, it also now introduce back the access of table X.
At the end the query count is still fine, but the code is not: it broke
a previous improvement while it was not necessary.
Worst, it could even lower the query count despite still breaking a
previous improvement (-3 queries +2 queries back).
Also, since the query count of a page is not exactly the same inside a
test and in real use cases, an `EXTRA_REQUEST` param is used in those
tests to abstract that change and still use the "real use case" query
count in the test to fit the reality, be human readable and easier to
write/debug.
Indeed, in test mode there is more queries due to the test cursor
rollback and savepoint, but there is one less query (the cache one).
Some commit wrongly reduced that `EXTRA_REQUEST` param making it looks
like there was an improvement while there wasn't.
This commit will help preventing all of that, ensuring the correct
tables are accessed and only those, on top of checking the query count
number (we still need to check the query count in case there is a query
not catched in the SQL table logs).
Some of the PRs/commits where it happened:
- https://github.com/odoo/odoo/commit/aa1c1b0bcb5327894c7b00d0454eebae06eaa005
- https://github.com/odoo/odoo/pull/112000/files#r1160851862closesodoo/odoo#124939
X-original-commit: 26e1fc3abd54a1baa16cf1c99d75d501a8dc6906
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit changes the way the we-many2one and we-many2many fields work
so that they check if the model they are attached to has a website_id
field, if so, the data loaded from the model will be that related to the
current website.
After this commit, developers can get rid of the website_id field when
they add a many2X field. The domain will be automatically computed.
task-3316278
closesodoo/odoo#124985
X-original-commit: 78cfcf3b2b3a44ee8e19084639e37277991b969a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Steps to reproduce the bug:
- Install the Website Slides module.
- Got to the /slides page.
- Click on a course.
- Click on the "Add Content" button.
- Choose "Web Page" in the modal.
- Once in edit mode, drag and drop a "Table of Content" snippet onto the
page.
- Save the page.
- Scroll the page and observe that the navbar items are updated as you
scroll.
- Click on the "Fullscreen" button.
- Bug: When scrolling the page, the navbar items are no longer updated
as you scroll.
This commit fixes the issue by detecting the scrolling element by
traversing up the ancestors from the 'table of content' snippet, instead
of using the 'getScrollingElement' function, which always returned the
'#wrapwrap' when a Website Slides page is in fullscreen.
opw-3302118
closesodoo/odoo#124935
X-original-commit: 1ac274c3cdddca3e6caf76d9b30b9efaa38bc09f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Steps to reproduce:
- Go to a website page > Add a 'Form' block.
- Go to the page (in 'edit_translations' mode) > Reload the page > The
form won't be pre-filled with default values. [1]
The page reloading with `?edit_translations=1` leads to a misleading
situation where the form block is handled as on 'edit_translations'
mode (see: `data-edit_translations="1"` on the DOM) hence the behaviour
in [1].
The goal of this commit is to prevent this inconsistency by simply
adapting the browser URL once "edit_translations" mode is activated.
closesodoo/odoo#124889
X-original-commit: 8c7d096a09fe23ac7ef9b7bf54123592c52122dd
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Since [1], navigating from the website application to another one
raises an error when using Firefox.
This commit avoids looking at the URL if the iframe is not available.
It seems that in Firefox the `pagehide` event is triggered after the
iframe is released.
Steps to reproduce:
- Use Firefox.
- Go to the Website app.
- Go to Discuss.
=> An error popup was displayed.
[1]: https://github.com/odoo/odoo/commit/eacfab230b8b6d676f378ad74a402849af83dcbb
task-3302981
opw-3349388
opw-3357461
opw-3357511
closesodoo/odoo#124940
X-original-commit: 57c3ab3058d4e2eee581f5c35a7a9e1b9ac83593
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit adds a test to check that the IAP languages work as
expected for the website configurator. The test checks that the
industries are translated (different than other languages).
task-3343616
closesodoo/odoo#123722
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] where the CSS / classes of the TourPointer was completely
redone, the pointer doesn't show up anymore in the default tip on the
configurator waiting screen.
This commit redisplays it as it appeared before.
Since [2], the classes `o_theme_install_loader` and derivatives have
been replaced. The commit thus also removes the file
`website.theme_install.scss` which is not needed anymore.
task-3358028
[1]: https://github.com/odoo/odoo/commit/3a79803
[2]: https://github.com/odoo/odoo/commit/1ff7f1eclosesodoo/odoo#124634
X-original-commit: 1569edb57e2e5adb242945557d9a64fac46fda96
Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>
Without this commit, the words in this template (below the images) won't
be colored as translated (green) / not translated (yellow).
This is because there is a block element inside an inline element and
the color is applied on the inline element which has no impact on
children blocks since inline elements don't take up available space.
See https://stackoverflow.com/a/7439861
Note that:
- `display: inline-block` is not an option either as it would be messing
with the `t-field` which receive this `data-oe-translation-state`
property too. Applying the `inline-block` style on those will break
the layout, typically on a product page.
- same for `display: contents`, it's not working as such elements don't
generate any box, properties like border / bg color etc are thus
ignored.
opw-3305117
closesodoo/odoo#124560
X-original-commit: ed89b0ffd7f4d6a04f71f474720ff4d82c9ecf9a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
TypeError: expected string or bytes-like object
This error occurs when the 'url_from' field is left empty during website rewrite
To reproduce this issue, follow these steps:
1. go to website -> configuration -> redirects
2. create a new record -> select 308 redirect / rewrite in action
3. keep 'url from' empty and put any value in 'url to' such as '/'
4. Click on the save button, and this error message will be displayed.
After applying this commit will fix this issue.
task-3346588
sentry-4229658026
closesodoo/odoo#124558
X-original-commit: 26fa923f6ab01298bf1a1e9f6a615c9aa9e2e5ed
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit modifies the label of the alignment option for the
"magazine" and "hamburger-full" header. It changes the label from
"Mobile Alignment" to "Alignment" when the "hamburger type" option is
set to "off-canvas." This is because in this case, the alignment also
affects desktops.
The bug was introduced by this commit [1].
This commit also changes, for the same reason, the label of the
alignment option for the slogan header.
[1]: https://github.com/odoo/odoo/commit/3eaab4e81ea2598788c9d6757ef38bbbd6454f65
task-3254619
closesodoo/odoo#124277
X-original-commit: 5b854cb332d1cd65769427750bb2bef758176c2d
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Signed-off-by: Vray Benjamin (bvr) <bvr@odoo.com>
Since commit [1], the text selection must be kept if there was one when
using a snippet option. However, it is not the case when toggling the
grid mode for snippets that have None columns (e.g. Text) or have some
content outside of their row element (e.g. Picture). Indeed, when these
contents are wrapped inside a new column and then in the row, the
selection is lost.
This commit, as done in commit [2], restores the selection after the
content wrapping. It also adds a test checking if the selection is well
kept when toggling the grid mode and going back to normal mode.
[1]: https://github.com/odoo/odoo/commit/e8112e2865ca449c4df9cd6147e9e24c4c6dcd41
[2]: https://github.com/odoo/odoo/commit/e4d7fbfca85c869d3a04dc517a8ad522cb533a90
task-3324775
closesodoo/odoo#124513
X-original-commit: bcb0e9b83fcb7e3f8a66131a089b88b39f58a2e4
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
This is a proposal to try to find a similar asset before generating one.
If get_attachments fails, the next step will be to generate the
attachments from scratch, a slow operations.
When creating a new website, all assetsbundle would actually be
similar to their version without website, but the url is different.
This can be visible because the first loading of /web is slow after
creating a new website: the website_id is forced in the session
and the assets_backend are regnerated, identical to the original ones.
This commit proposes to try to find an attachments with differents extra
but the same uniquifier when possible and copy it's content.
Note that just returning the other attachement url may work, but it
would be confusing to randomly have links to assets comming from another
website_id. This would also be a problem if the original attachment is
unlinked, forcing to recompute it for other websites.
Good to know, since the content is the same, no duplication of the
content should appear in the filestore, just an entry in the database.
Part-of: odoo/odoo#121376
1. move cache to _get_asset_paths
The `_get_asset_content` cache has many cache key that are related to a
posprocessing of the `_get_asset_paths` result, the heavy part of this
method. Moving the cache to _get_asset_content will have the benefit
to create less duplicates entries in the ormcache as well as less cache
miss.
To simplify even further, the css and js parameters are removed since
they only filter the output of get_paths, the heavy part of globing the
file will be done before that. Anyway, they are both true when called
from _get_asset_content, and the only other call, in
`_get_related_bundle` don't really need to filter them since it is not
a critical part regarding performance, and the funtional result will
stay the same.
The initial orm cache key was using `_get_template_cache_keys`, a little
overkill and possibly creating duplicates entries again. The only
context key needed is website_id for `_get_related_assets`.
Note that it is not really enough, the orm cache key should actually
contain `request.session.get('force_website_id')` as well has
`request.httprequest.host`. This will be addressed latter since a nicer
solution would be to have website_id as a unique parameter computed
earlier.
2. better _get_asset_paths cache key
The orm cache key was simplified in previous point but there is still
one concern, the website_id depends on more parameters than that:
- request.session.get('force_website_id')
- request.httprequest.host
- existing websites
The idea here is to call `get_current_website` instead of using all
parameters that could define the webiste.
In the same spirit of `_get_template_cache_keys` `_assets_path_params`
can be overriden to give extra params that are usefull to list assets
path. Those params are computed before entering the method
`_get_asset_paths`. This may latter put at a higher level latter, in
get_asset_node, to simplify the _generate_asset_nodes_cache key.
3. better assets_node caches key
The main purpose of this part is to improve ormcache containing assets
nodes. The ormcache key contains
- to much context key
- missing session/host/env info
- unwanted boolean options.
- keys leading to the same cache value
The main goal being to reduce the size of the cache keys, decrease the
number of cache entries and improve the cache hit.
This will also make the behaviour more coherent and hopefully less bug
prone because of mismatch in parameters.
The main reason of the orm cache is the slowness of the validation of
the assets. This includes:
- listing files (dedicated orm cache)
- computing version
The cache key was depending on
- `debug`
The only relevant value for debug is "contains assets"
We dont need to differ between debug='', debug='1', debug='test',
and 'debug=assets', 'debug=tests,assets', ...
- `defer_load`, `lazy_load`, `media`
Those values are only useful to generate html node, a leightweight
operations that does not really needs to be in cache. `media` was also
used in the generation but it looks useless if we have the media on the
node. THIS NEEDS TO BE VALIDATED but in any case, since media is not
used to generate the url, it doesn't make sence to use it in the
generation.
The main idea to remove them from the ormcache key is simply to generate
the nodes outide the ormcached values.
-`async_load`
This one is similar to `defer_load` and `lazy_load` but it looks like
it wasn't used anymore. This was simply removed
- context.get('lang')
The only information needed is the direction, rtl or ltr. This means
en and fr languages, despite sharing the same css assets, will duplicate
the ormcache entries.
-`_get_template_cache_keys`
Only the lang and webiste where really relevant in this flow. Other
keys are actually useless in this flow.
Some information used in the generation where not in the orm cache key
- `self.env.user.lang` if there is no lang in the context
- `request.session.get('force_website_id')`
- `request.httprequest.host`
- ...
The proposed solution is to:
- extract any informùation needed from thecontext, request, environment
before entering the ormcache, reduce it to the minimal possible set of
values needed
```
rtl = self.env['res.lang']._lang_get_direction(self.env.context.get('lang') or self.env.user.lang) == 'rtl'
assets_params = self.env['ir.asset']._get_assets_params() # website_id
debug_assets = debug and 'assets' in debug
```
and remove a leightweight part of the logic
```
def _get_asset_nodes(self, bundle, css=True, js=True, debug=False, defer_load=False, lazy_load=False, media=None):
links = self._get_asset_links(bundle, css=css, js=js, debug=debug)
return self._links_to_nodes(links, defer_load=defer_load, lazy_load=lazy_load, media=media)
```
Where _get_asset_links is the cached part, and _links_to_nodes is the
lightweight part generating the nodes based on the `defer_load`, ....
Additionnal notes:
- data-asset-version and data-asset-bundle are removed from the node
since they don't seem to be used anymore since 65d70acdbf
- async_load is removed since there is no occurence of this in the code.
- a small hack is still needed to pass javascript content instead of
links, this is only to manage css compile error and will hopefully be
removed in the future.
- a context key is still in use to generate the bundle, the
`commit_assetsbundle` but it has no impact on content and will hopefully
be removed in the future.
4. Add test for ormcache hit/miss
In this context, hit/miss is about having the same cache key for the
same result. This test demonstrates the current state, were entries are
create in the ormcache only if the key is really different and will lead
to a different result.
5. remove cache invalidation
This cache invalidation is quite agressive since everytime an
assetbundle is updated, all workers will clear their cache.
The concerned cache by this clear_cache is `_generate_asset_nodes_cache`
throug `_get_asset_nodes`.
The cache is ignored, both in dev=xml and debug=assets.
This clear cache was made conditionnal in 553ea82f81 but this does
not solve an issue we can have in production.
Lets imagine a clean solution
- all sources are updated
- all workers are restarted.
The orm caches are all empty, but since the sources
changed, all bundles will be recomputed. This means that every bundle
updated in database with save_attachement will invalidate the cache of
all workers. Rendering a pdf report of any kind using a specific bundle
will invalidate all cache. Starting a debug=assets for the first time
will invalidate all cache, even if the cache is not used in this case.
But for a regenerated bundle we would expect the ormcache to be:
- empty (did not generate the same bundle yet)
- have the same value (concurrent generation of the same bundle)
Having a different value would mean that the bundle was generated with
another version of the sources. In this case it is maybe even better not
to invalidate the cache since it could lead to an invalidation war
between two workers.
The only case where invalidating this cache is useful is when a bundle
changes, Usually if an ir_asset is created, modified, ...
There is still another rare but possible possibility to have a 404 if
the transaction is rollbacked after populating the assets node cache.
In this case, we only need to clear the cache locally in case of
rollback.
Part-of: odoo/odoo#121376
*: account, base_import, board, website
This PR enhances the "cog menu" by fixing several UX flaws.
Notable improvements include:
- Reordering entries in a more logical manner, enhancing user intuitiveness.
- Assigning icons to common actions for quick comprehension.
- Grouping both print actions and module-specific actions for better organization.
Enterprise:
- https://github.com/odoo/enterprise/pull/41851
task-3337951
task-3355224 (milk post-merge fixes)
part of task-3326263
closesodoo/odoo#124413
X-original-commit: 596772885a87016d29f002cd4e41b5a973965e40
Related: odoo/enterprise#42212
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
Co-authored-by: stefanorigano (SRI) <sri@odoo.com>
Before this commit, the Product (backend link) is not readable to the community
and in the enterprise, it's not matching with the rest other backend links
(blueish) (e.g. New) due to the default text color. Same way TRANSLATE button
have visual glitch for community and enterprise.
After this commit, the backend link is readable for the community and matches
with others in the enterprise version by using `$o-navbar-entry-color`
task-3346020
closesodoo/odoo#124455
X-original-commit: 154be2e2f673c039e62e148e7b2c05304af6b568
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit allows users to choose any color for their navbar when it is
over the content. With this commit, the user can choose the color he
wants for his navbar when it is scrolled and when it is not scrolled
without worrying about color mixing.
To simplify the explanation below, note that "Colors" option means the
Colors option of the header (just below the Template option) and the
"Background" option means the option below Header Position.
By following these steps:
- Drop some blocks in a the page (to be able to scroll)
- Set a light transparent red for the Colors option.
- Set the navbar position to "Over the content"
- With the Background option, set the background color to a dark color.
=> When you are at the top of the page, the color is the one of the
Background option. So far so good. Now when we scroll, the color of the
navbar is dark red. This is not what the user expects. The user should
be able to have any color he wants for the scrolled navbar. It's not the
case before this commit. He cannot have a dark transparent header on the
top of his page and a light transparent red when he scrolls. In this
configuration, the Colors option should set the color of the navbar once
the user has scrolled. The colors should not be mixed.
Technical explanation of the problem:
Background option applies the color on the header element and Colors
option sets the color on the nav element. The nav element is a child of
the header element.
So when the header has a color set by the Background option and nav has
a color set by the Colors option which has transparency, the color of
the header influences the color of the navbar when scrolling. This
commit allows to correct this.
This commit also fixes the same problem for the gradient option.
task-2904507
closesodoo/odoo#106281
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Jquery find return an object instead of an array of element.
When you map on this object, the first callback element is
so the index and not the element. This commit fix wrong usages of
.map() used with Jquery.
closesodoo/odoo#124359
X-original-commit: b87dac213dcc8a197dc7c00245a392d1e4d86925
Signed-off-by: Géry Debongnie <ged@odoo.com>
Soukéina Bojabza