This commit refactors the patch function in order to simplify its code
but also and most of all remove the `this._super` bound on each patched
method call.
The patch function now supports the javascript keyword `super` to
get the parent's property.
This removes constraints we had with `this._super`. We had to create a
rather complicated intermediate function to bind `this._super` and this
function was called each time before we called a patched method.
It was annoying for debugging but necessary. Because of this
intermediate function `this._super` was also had to re-bind each time
we entered a patched method which was annoying with async method, we
had to save the parent method in the patch before awaiting its
execution. Finally, not a big issue but still, objects could not have a
`_super` property as it would be hidden in the patch.
task 3410198
Part-of: odoo/odoo#125716
Now that most of the webclient codebase (fields, views, client
actions...) has been converted to owl, the legacy extra next tick
used in a lot of tests is no longer necessary. This commit removes
the helper and its usage. At some places, a real tick was needed,
but we didn't see it because of the use of the legacy extra next
tick.
Part of task~3439226
closesodoo/odoo#130236
Related: odoo/enterprise#44869
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Before this commit, when using the ace field widget with a html field,
the markup value of the field was sent to the code editor. The issue
with this is that the ace library only accept strings (it will extract
the string from the markup), and when ask for the current value, it will
respond in string. Because of this, the ace field will always be
considered as dirty, even if not modified, because it will compare the
initially sent value (a markup) with the value given by the library (a
string).
Now, the formatText used on the ace field will always send a string
(remove the markup). And the code editor will check the props to only
accept strings.
X-original-commit: 1778672e9b0076bf385d46e68efb4914d6bf790c
Part-of: odoo/odoo#129995
Have a form view with an x2many field, and a context on that field,
depending on other fields of the view. For instance:
```xml
<form>
<field name="a"/>
<field name="b_ids" context="{'key1': a, 'key2': 4}"/>
</form>
```
As we read records in a single rpc (unity read), we need to be able
to (at least partially) evaluate the context set on b_ids to build
the field specification for the web_read call. The problem is that
the evaluation context is incomplete when we want to evalute it, as
we don't know the value of `a`.
Before this commit, we evaluated that context by adding "sentinel"
values in the evaluation context (a sentinel being a Symbol), and
we removed all keys whose values had been evaluated to the sentinel
afterwards. This worked for the example above (we were able to
generate the context `{ key2: 4 }`).
However, this wasn't flawless. For instance, with
```xml
<field name="b_ids" context="{'key1': a + b}"/>
```
our sentinel strategy didn't work, because you can't perform such
operations on a Symbol.
This commit comes with another strategy, which is actually easier,
and which handles the above case. We now parse the context, and
evaluate each value individually (if it needs to be evaluated). If
the evaluation crashes, we swallow the error and do not add that
particular key to the evaluated context.
Part of task~3179751
closesodoo/odoo#129925
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce
==================
- Enable debug mode
- Go to Settings / Technical / Automation / Automated Actions
- Set "Action To Do" to "Execute Python Code"
- In the code editor, type really quickly
The code is briefly focused and when the next input is processed,
everything is erased.
Cause of the issue
==================
The AceField makes a debounced commit with the current editor value.
This triggers an onChange event, and upon receiving the results,
we update the editor value with the resolved value.
Although the editor value may have changed in the meantime,
we still revert it to the previous value.
Solution
========
There is no need to update the record every 10ms. We can simply to that
on blur. This is also what was done in 16.2.
opw-3379740
closesodoo/odoo#129694
X-original-commit: 4047ed03117fbcd5634843e29dc82e7ffb71b910
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This commit adds a shortcut in the orm service to call the new
"web_read" python method and adapts the few calls to use it.
closesodoo/odoo#129502
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, there was a hook, named useModel, which eases
the use of a model in views. The main (and almost only) role of the
hook was to deal with sample data (determine whether or not they
can be enabled, fallback on the sample orm when necessary, leave
sample mode at reload...). This hook is used by all views except
form and activity as they do not implement sample data.
This commit renames that hook into "useModelWithSampleData" and
introduces a new hook "useModel", which is a lot simpler that the
other one, as it's only goal is to do the plumbing between the
component using the hook and the model (i.e. spawning required
services and loading the data on willStart and willUpdateProps).
This new hook is used in form and activity views.
Note that useModel doesn't trigger deep renderings, as it is only
used on the RelationalModel which is based on fine-grained
reactivity.
Part-of: odoo/odoo#114024
Before this commit, we had several implementations of a relational
model. The form view used the BasicRelationalModel, which was a
wrapper around the BasicModel. The list view used the
RelationalModel (a simpler version that didn't support complex
usecases of x2many fields). The kanban view used the KanbanModel,
an extension of RelationalModel.
This commit removes all these, and replaces them by a single model.
It is called RelationalModel, and as a similar structure as its
predecessor (with datapoints). It now handles tricky x2many usecases
of the form view though.
This commit also comes with several important changes:
1) The new model is based on unity reads [1]. This means that all
data required by the view is fetched at once, and datapoints are
created with their data (whereas before, they were responsible to
fetch their data). There's an exception for special data: they are
no longer handler by the model. A hook "useSpecialData" has been
created, and it allows fields (components) to fetch additional
data they require.
2) The new model uses onchange2 [2]. With onchange2, we send and
receive a diff, instead of the whole state of the record. Morever,
onchange2 uses unity, which means that returned commands for x2manys
(e.g. command 4, LINK) contain the values of the corresponding
records, so we don't need to fetch them in a separate call
afterwards.
3) The new model no longer triggers deep renderings (render(true)).
It is instead based on fine-grained reactivity (i.e. only what
depends on what has changed is re-rendered). We introduced a hook
"observeRecord" which allows a component to subscribe itself to
some keys in a record datapoint, and register a callback to
execute when those keys change (e.g. to fetch data).
[1] odoo/odoo@7d2baaa0c7
[2] odoo/odoo@f5e6494da3
Task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
This commit adapts the NameAndSignature component to allow usage in the sign
module by enabling customization of behavior when "auto" and "load" buttons are
clicked. It also replaces the top buttons for fa icons for a cleaner UI and
adds autofocus to the name input field.
task-3286974
Part-of: odoo/odoo#126296
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
With ab4f45b, the domain validation done
on confirmation in the domain selector dialog was removed. Now that we
have a new route /web/domain/validate (see previous commit) that allows
us to quickly check the validity of a domain, we can reintroduce the
validation.
closesodoo/odoo#128913
X-original-commit: fa7788fac3c48e95dcbe78abb66ac5c284d27c56
Related: odoo/enterprise#44291
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
For the relational fields and the operators =,!=,in,not in, we allow
the user to use autocompletion as in a many2one or a x2many field.
Task ID: 3291990
Part-of: odoo/odoo#121688
We improve the readonly mode in several ways:
- instead of displaying ids for relational fields, we display the
associated names.
- instead of displaying values for selection fields, we display the
associated labels.
- quotes around strings are not displayed by default. They are if
there is some ambiguity: the presence of a value of another type
like 0, false or an expression makes necessary to put them.
Task ID: 3291990
Part-of: odoo/odoo#121688
Before that commit, we could get two operators with the same key to
display at the same time. In that case, an error would be thrown by OWL:
Got duplicate key in t-foreach... . We fix that problem.
Part-of: odoo/odoo#121688
Even with a limit of 1, the domain validation done in the domain selector
dialog at confirmation can be too costly (see PR message). Since we do
not have (yet) the tools to validate quickly domains server side, we
simply drop the validation server side.
closesodoo/odoo#127832
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Before this commit, the way focus was handled by the DateTime feature
hook was inconsistent. This caused the date/datetime/daterange fields to
not be able to open the picker when clicking on the "Add start/end date"
button, and effectively lose the value set on the field on save.
This commit introduces a more consistent focus handling as well as a
helper returned by the hook to open the picker on command.
Part-of: odoo/odoo#127734
The new CodeEditor dismissed the notion of ace EditSession.
This serves to split the ace internals (history, values etc...) according
to the logical unit of a session.
After this commit, from the CodeEditor point of view for each edited resource (a view mostly)
corresponds one session.
Part-of: odoo/odoo#126963
This commit fixes the filtering of choices when the choices or the groups
props values are updated. Before this commit, the filter was only triggered
when the length of choices or groups differ.
Instead, it is prefered to apply the filter of choices whenever those props
are updated (in a dedicated useEffect).
A test has been added, updating the choices props, while having an object with
the same number of choices, while having different values. Before this fix, the
filtering wouldn't be applied correctly, since the filter wouldn't be triggered
because the object has the same number of values in it.
closesodoo/odoo#127733
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Currently, the domain editor dialog doesn't handle domains like
[('foo', '=', uid)] if you don't provide the (user) context in the
component props.
Since this kind of domain is expected to work everywhere, the component
now uses the user context by default to evaluate the domain.
There's no need to provide the context everytime the component is used.
closesodoo/odoo#127565
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The domain component in readonly mode doesn't display dynamic/contextual
values.
For a domain `[('foo', '=', uid)]` the component displays "foo =" instead
of "foo = uid"
Part-of: odoo/odoo#127565
The commit [1] removed two async module and caused a reorganisation
on the module loading.
Since that commit, the patches could be applied in a different order
and be applied after a save of one these patches.
This commit fixes a case where we save the reference of a patched
function that we call it later with missing patches.
[1]: 96687f29496ab4cf16ae2ab1584ef1a6a3fb4a11
Part-of: odoo/odoo#121185
The commit [1] removed two async module and caused a reorganisation
on the module loading.
Since that commit, `uniqueId` did not begin with the id 1 in its test
and so the test failed.
Now, the variable containing the last id of `uniqueId` is set on the
function itself. This allows us to reset the id in the test.
[1]: 96687f29496ab4cf16ae2ab1584ef1a6a3fb4a11
Part-of: odoo/odoo#121185
We make the domain selector accept any expressions in the first and
second components of a domain condition. Along the way, we have found
necessary to refactor the Tree type (see domain_tree.js) and use it
directly in the domain selector instead of having yet another auxiliary
structure. Another simplification brought by this commit is that the
virtual operators is, is_not, set, and not_set are introduced earlier
and make possible to simplify the way operators are managed.
closesodoo/odoo#126350
Related: odoo/enterprise#43161
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
We make TagInput use the generic component TagsList. This gives a better
looking/working to the editors used for the operators "in"/"not in" for
char fields.
Part-of: odoo/odoo#126350
A string representation of a domain like "[('bar', '=', false)]" is
evaluated by py.js the same way as "[('bar', '=', False)]".So both domains
are recognized as correct while false is not a valid python expression.
We do the same in domain selector, the expression "false" ("true")
will be understood as "False" (resp. "True").
Part-of: odoo/odoo#126350
This commit makes the datetime hook independant from the props update
mechanism it previously relied on (onWillStart & onWillUpdateProps) to
update its internal props.
This was an incoming issue as the future relational model will rely on
fine-grained reactivity to update the fields rather than updating the
model and re-rendering all child components (effectively calling
'onWillUpdateProps').
Now, the hook relies on an internal state that tracks whether the props
given by its caller changed from one render to another, which is checked
at render time (i.e. in 'setup' and 'onWillRender').
closesodoo/odoo#125039
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, 2 implementations of a "shallowEqual" function
coexisted, one in 'web/core/utils/objects.js' and another in
'web/core/utils/arrays.js'.
This commit only keeps the one in objects.js and makes the other simply
import and export it as well (easier to maintain while also easier to
find for those who want to work with arrays), while also taking an
optional comparison function argument in case the comparison needs to be
more specific (e.g. compare DateTime objects).
Part-of: odoo/odoo#125039
Since [1], a test introduced in [2] was failing undeterministically.
**Explanation**
Commit [1] introduced a positioning recomputation when a load event
occur in the target's document.
The failing test in [2] loads an inline stylesheet inside of an iframe
without waiting for it to be loaded.
When the test failed it was because of the "load" event of the
aforementioned stylesheet that occured at an inappropriate moment.
Now the test awaits for this event.
Note that within the same conditions in the real world, we want to
make sure the popper is repositioned.
So this current fix is a bit cheating but the test is about testing
an unrelated behavior, so this is acceptable IMO.
Runbot error id: 22544
[1]: 532c4cfa4e60bc9531
[2]: 208a1277750d63eef3
closesodoo/odoo#126938
X-original-commit: 3ca170bf31ca6e6f12293f0dabe106d385773333
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
=== ISSUE ===
With Milk, we introduced a change related to the active state color
meaning that the `active` state should use the following SCSS variables:
- $o-component-active-bg for the background ;
- $o-component-active-color for the text ;
- $o-component-active-border for the border.
The datetime_picker component was currently using the primary variable
which is not the expected color. This change also affects the different
states of the datetime picker (hover, click, ...)
=== AFTER ===
We apply the right variables on the component for consistency purpose,
and make some little design adjustments using `:before` and `:after`
pseudo elements to stylize the different states.
task-3329797
part of task-3326263
closesodoo/odoo#126728
X-original-commit: df0e75d36bfe85bdbe0a9823003e0849c17a9405
Signed-off-by: Pierre Paridans (app) <app@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
The goal is to provide a better feedback to the user, especially in
mobile mode. With this commit, when switching menus, we clear the screen
and display an empty control panel (only for act_window actions though)
so we have some initial content that get filled as soon as the
view/action is ready.
Task 2900847
closesodoo/odoo#124068
Related: odoo/enterprise#43038
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the ctrl+enter shortcut to dialogs which will trigger
a click on the first visible button in the dialog's footer.
Task-3369676
closesodoo/odoo#125330
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
This commit:
- adds a "delay" parameter to the `draggable_hook_builder`, waiting for
that delay on pointer down events before triggering the drag sequence
(making it possible to use "long mousedown" events);
- changes the event detection in `draggable_hook_builder` to listen
for pointer events instead of mouse events, effectively supporting the
drag and drop feature on touch devices;
- adapts the test helpers (with some refactors to `triggerEvent` and
other utility functions) to make them use pointer events instead for
drags and drops;
- adapts the tour utils to use a tone-downed version of the refactored
test utils `dragAndDrop` function;
- also changes events in list view which does not yet uses the draggable
hook, but should still work with the same helpers in tests.
Part-of: odoo/odoo#116005
When hovering over an employee's photo (without edit rights) and the
image hasn't been loaded in the cache, the popover is positioned to the
right of the image. With a big image, the popover can be outside of the
page.
Steps to reproduce:
1. Install Employees and set a 4k image to any employee
2. Remove all the rights of Marc Demo on Employees
3. Connect as Marc Demo
4. Open the form of the employee with the 4k image
5. Hover on the employee photo
6. The image position is off
Solution:
Update the position of the popover when the image is loaded and restrict
the image width in the popover to the popover width
Problem:
When we try to find the best position to display the popover and the
image is not loaded, we will find that there is some room for the
popover on the right because the image has no height or width
opw-3281649
closesodoo/odoo#125951
X-original-commit: 532c4cfa4e60bc95319b774794680eabc80b1219
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
This commit adapt several components and utility-classes in order to
increase visual contrast.
In the case of `o-mail-ActivityGroup` and `o-mail-NotificationItem`
templates, these has been reworked in order to use default BS components
and consequently automatically inheriting the improved design.
task-3338419
closesodoo/odoo#124903
Part-of: task-3326263
X-original-commit: 190ec1c947e17b2b4aa8614e9e0a04d00cb38d90
Related: odoo/enterprise#42507
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The reactivity utils were initially an ad-hoc solution to some problems
that came up when using the reactivity in places that are not
components. As it turned out that these needs are actually quite common,
the utils that were originally duplicated in many modules were moved to
the core utils in web, but there were no tests for these utils, and the
Reactive class was not documented.
This commit adds some tests for the reactivity utils and a docstring
motivating the existence of the Reactive class.
closesodoo/odoo#125549
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit will have nested components making use of
the usePosition hook to synchronize their repositioning.
**Before this commit**
Each component handles its own repositioning logic.
If it is mounted somehow inside another component using that
same logic, conflicts occur in some circumstances.
**After this commit**
It is now ensured that, in case of nested positioned components,
the whole chain of repositioning computations is called in the
proper order: from the parent to the children.
**Example**
- Before
![before]
- After
![after]
[before]: https://github.com/odoo/odoo/assets/1159815/3c9cfae7-db68-4707-a73c-ad7e2e71d4bf
[after]: https://github.com/odoo/odoo/assets/1159815/a21f56e0-d8e3-48c1-9509-8e6ee5040d4bclosesodoo/odoo#125531
X-original-commit: 9f947ba3fd3a00a0c80efc40186c36e0de78de16
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, the CodeEditor made Ace display infinity lines in height.
This prevented Ace to be scrollable in some contexts.
Specifically, when Ace was in a flex context, the scroll did not work.
After this commit, the CodeEditor takes an optional maxLines props to pass to Ace.
If not set, Ace will just adapt the number of lines to the size it gets.
closesodoo/odoo#124656
X-original-commit: eb81a4c857a249e4cd2f28b455d87b64a8e93c9a
Related: odoo/enterprise#42367
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when inputting latin numbers (i.e. 0-9) with a
locale using a numbering system different than "latn" (e.g. "arab"),
the parsing failed resulting in an error.
The issue is that these locales often support both their numbering
system as well as the "latn" one. This commit makes the parsing fall
back to the "latn" system in case latin numbers are found in the input.
OPW-3316325
closesodoo/odoo#124635
X-original-commit: 12970754fc915eb181e040d3e45fc566fe310167
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
We define a new service "name". That service makes possible to load in
batch display names and maintains a cache. Some known display names
(fetched otherwise) can be added to the cache. The cache is cleared at
least each time the UI is updated via _updateUI (action service).
Part-of: odoo/odoo#124090
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@odoo.com>
* = project,website
On the small screen, the sub dropdown is a bit weird to positioning, so
we use an accordion instead.
We apply this change also on desktop to avoid split behavior between
small screen and bigger screen and also to avoid duplicating code.
Also, we have made some DOM/CSS change:
* avoid reflow of the search bar menu by adding a min-width on the
columns and a max-width on the input for custom groupbys and favorite
filters
* re-align caret vertically for accordion indicators
* reword favorite edition items and add a tooltip
* all menu items have the class `o_menu_item`
closesodoo/odoo#122635
Note: DOM and some tests were adapted to reflect the change
Task-id: 3276542 (Part of)
Related: odoo/enterprise#41563
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit adds the onInput props, allowing to run code from the parent
of the SelectMenu depending on the search value. This can be used in
situations where the list of choices must be dynamic. Also, whenever the
list of choices or groups is edited in length, the menu is filtered using
the newer values.
For example, choices can be generated from a fetch of items. Now, instead
of loading all items before instanciating a SelectMenu, a limit could be
set during the fetch, and another fetch can happen as the user type.
A test has been added to verify that the onInput props is called correctly,
and executes its code. In this test, the list of choices is edited, and we
assert that the newer elements are present in the menu.
closesodoo/odoo#124224
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Michael (mcm)