With the last realease of owl, .trim now implies .lazy. This means that
if t-model.trim is used, the value will be updated in the state only when
the change event is triggered. Here we adapt the helper editFavoriteName
which was supposed to update the state value.
X-original-commit: 7a16b75a35a5bd60190ee5b437b925a2fa99fb70
Part-of: odoo/odoo#149507
We update owl to 2.2.9. Our version was 2.2.7.
Release notes:
https://github.com/odoo/owl/releases/tag/v2.2.8https://github.com/odoo/owl/releases/tag/v2.2.9
These releases contain small improvements
2.2.8:
- [IMP] template set config: getTemplate function
- [IMP] parser: .trim modifier implies .lazy modifier
- [REF] parser, template_set: factor out parseXML function
2.2.9:
- [IMP] reactivity: replace sets with small arrays for performance
X-original-commit: 91a1f495b260ab23df80d74faeae25a5883deda0
Part-of: odoo/odoo#149507
Since https://github.com/odoo/odoo/pull/103510, the read_group parameter "groupby" can no longer contain
implicit duplicates. For example groupby=['date', 'date:month] doesn't work
anymore. Here we remove all duplicates from groupby before making a read_group.
closesodoo/odoo#143792
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Due a typo, sortedKeys were not always cleared when pruning the
new trees after an update. Consequently the method _getTableRows could be
called on a inexisting sub tree. Here we simply fix the typo and a test.
opw-3584675
closesodoo/odoo#143714
X-original-commit: 3fa2d6e418daa2b1fa0df3c8d1ca643fac4cbaa2
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The component ExpressionEditorFieldSelector used by the expression editor
to allow the selection of a field has several drawbacks:
- the fields are not alphabetically ordered
- there is no possibility to (fuzzy search) a field
- the field types are not indicated in debug mode.
- the style is different from the classical style to be found in the
domain selector.
Here we make the expression editor use a version of the ModelFieldSelector
component where the debug input is not shown. Indeed, this would require
some validation of the input value in order to prevent complex path like
user_id.company_id that are forbidden in studio for instance. Anyway,
there is not real need for such an input since it is easy to find/select
a simple path with the fuzzy search.
Task ID: 3599699
Part-of: odoo/odoo#142483
Have the model field selector popover open, modify the path in the
debug input (bottom input available when isDebugMode=true), then close
the popover by clicking away. The model field selector is correctly
updated but its parent does not receive the right path. This happens
because onClose is called before the function update passed to the
popover is called.
Here we make the popover communicate its current path on each input
event so that if the popover has to be closed, the model field selector
knows which path to communicate to its parent.
closesodoo/odoo#141362
X-original-commit: 6a4e4221a1daa474217070f6a78602a962bbcf65
Related: odoo/enterprise#50337
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Since the refactoring of the model selector [https://github.com/odoo/odoo/commit/ebf646b44f747567ff8788c884f7f18dffd453e0], it is now more possible
to clear a selected field name (i.e. reset the path to "").
This has lead to an unsatisfactory situation when creating filters in a
spreadsheed. Indeed, the proper functioning of the interface was heavily
relying on that possibility.
In this fix, we introduce a new prop "allowEmpty" that if set to true
allows to clear the selected path and improve the display of falsy paths:
for a falsy path, the model field selector is empty and does not have a
warning message.
X-original-commit: 0244b0a7092b4c68e9f5cd4926b3017ea32b91de
Part-of: odoo/odoo#141362
Before this fix, a condition of the form (field_name, "in", expr) would
be "stringified" in such a way that expr would be wrapped in a list, e.g.
we would get by expressionFromTree the expression
field_name in [expr]
Here we prefer to keep expr as it is since we have no information on its
type at evaluation. That is we transform the above condition into
field_name in expr
closesodoo/odoo#140966
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
If one edits an input value in a dialog and click on the dialog header,
the blur event is prevented because the dialog is draggable and the
pointer down native behaviour is prevented by the draggable hook builder.
This can cause data losses or the dialog content to not be render correctly.
For instance, this happens with the debug input of the domain selector
dialog.
We fix that by triggering the blur event programatically.
closesodoo/odoo#140436
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
When foo is not an x2many, a condition of the form
("foo", "in", [])
was transformed by the ExpressionEditor into
"set([foo]).intersection([])"
while it can be better expressed as
"foo in []"
In this commit, we improve the conversion of conditions of that kind and
similar other conditions.
Note that we also ideally want domains and their corresponding expressions
to be evaluated the same ways on records (at least on good examples).
For this we want for instance, the condition
("foo", "in", 1)
to be translated to
"foo in [1]"
and not
"foo in 1"
which is an invalid Python expression.
closesodoo/odoo#140140
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Now that some field attributes like invisible are given by Python expressions
and that those can involve some set operations, we have to ensure that
the views can be validated if they use such operations. We do that and
add a test.
closesodoo/odoo#139451
Signed-off-by: Géry Debongnie <ged@odoo.com>
Now that some field attributes like invisible are given by Python
expressions that can involve set operations, we want to be able to easily
edit those expressions in the expression editor. For this we have to
improve a bit the mapping expression <-> condition tree, in order to
have simple rewrittings like
"set(user_ids).intersection([1, 2])" <-> condition('user_ids', 'in', [1, 2]).
Part-of: odoo/odoo#139451
We define some helpers to easily create condition trees and use them
where it is possible.
closesodoo/odoo#139377
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
We improve various aspects of the domain selector:
- We make the domain selector be able to display all domains accepted by the class Domain (domain.js)
- We improve the edition/selection of values, e.g. for the operators in/not in
- We improve/simplify the style/dom
Task IDs: 3507123, 3508940
closesodoo/odoo#128680
Related: odoo/enterprise#48324
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Notté <mano@odoo.com>
The async methods of field service were not declared in its key async.
This would allow destroyed components to process the results of those
methods (despite an initial call to useService). We fix that.
closesodoo/odoo#135950
X-original-commit: 7955def19c7d4a8c49be472413423bbf3beec2e5
Signed-off-by: Géry Debongnie <ged@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>
When a domain field value is edited via the debug textarea, no
search_count is done for performance reasons. A single exception is done
when saving the record. Then we check the validity of the domain created
in the debug textarea in order to avoid to save an invalid domain in db
(and get tracebacks,..). The problem is that a search_count can take a
very long time to be executed if the domain is valid. Here we introduce
a route /web/domain/validate in order to quickly check the validity of a
domain and use it in domain field in order to fix the above mentionned
performance issue. Note that the search_count is still done if it useful
but does not have to be waited anymore.
X-original-commit: 40288221c39ff8fba41cd6ac231ab33600dc0cd4
Part-of: odoo/odoo#128913
Co-authored-by: Oliver Dony <odo@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
We make the elements of the path description be a bit above the bottom
line in the model field selector.
closesodoo/odoo#121688
Related: odoo/enterprise#41660
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
We add the class o_input to the root node of the DomainSelectorAutocomplete
component in order to get a line below the tags and the input value.
Part-of: odoo/odoo#121688
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 facet descriptions of the domain created via the domain
selector. We do this in several ways like it was done for the readonly
mode of the domain selector:
- 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
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>
On confirmation of a domain created in the domain selector dialog, a
validation check involving the server is done. That validation based on
a search_count can be rather/too costly (see PR message). Since the
search_count is done in silent mode and the confirmation button is not
disabled on click, if the validation takes too much time, the user is
lead to think that the first click did not work and clicks again, and so
on...
Here we disable the button on appropriate time to avoid that situation.
Part-of: odoo/odoo#127832
Before this fix, a condition like "Foo is not set" created via the domain
selector would be badly described in the facet as "Foo is set".
We fix that problem and add a test that covers that situation and similar
ones.
closesodoo/odoo#127447
X-original-commit: a6b7de5d62906e5508585e0b994bf95544d10476
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
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>
Some props like className were declared as optional in TagsList while
they are not used by the component. We remove them from the props
declaration.
Part-of: odoo/odoo#126350
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
The computation of the default value used by an editor used to assume
that the (default) operator is equal. We now pass the operator info to
getDefaultFieldValue in order to be able to have a different default
operator ("in" will become the default operator for relational fields).
Part-of: odoo/odoo#126350
The key negate is defined as mandatory in the definition of the type Tree.
We add them at some places (event if it did not pose a problem for now:
undefined and false are both falsy).
Part-of: odoo/odoo#126350
The label of a facet with type "comparison" did not have any
background color. We set it to be the same as for the label of a facet
of type "groupBy".
closesodoo/odoo#126496
X-original-commit: b0527528ee73b503ffbfef491b2389018c119376
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
The label of a facet of type "comparison" had the role "button" while
click on it has no effect. That role should be reserved for the label of
a facet that is associated with a domain (e.g. a facet of type "filter").
X-original-commit: 4c649abf491b32c218769b0bb1eba19881dedbb0
Part-of: odoo/odoo#126496
When the domain selector is in debug mode (props.isDebugMode = true),
the operator ! (not) is not distributed in the leaves in the domain
selector. That is a domain like ["!", "|", ("foo", "=", 1 ), ("id", "=", 2)]
will be visualized in the domain selector as
Match records with none of the following rules:
Foo = 1
ID = 2
The problem we fix is that when such a domain is added via "Add Custom
Filter" (for instance), the search bar facet produced has a representation
of the domain where ! has been distributed even if the debug mode is
active. With the previous example:
------------ -----------
| Foo != 1 | | ID != 2 |
------------ -----------
This makes the user think that the domain she sees is not the domain
she has created.
In the present commit, we make sure that the ! operator is distributed
or not uniformly within the scope of the search model.
closesodoo/odoo#125967
X-original-commit: d15d7e13be0ca6f7705c3bb6f992b45949bccef0
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Let us consider the search arch
<search>
<field name="foo"/>
<searchpanel>
<field name="bar"/>
</searchpanel>
</search>
The two tags "field" are supposed to generate different objects:
- the first one should generate an entry in the search bar autocompletion
- the second one should generate a search panel section.
It turns out that the second field did also generate an entry in the
search bar. This is of course wrong. We fix that problem and add a test.
closesodoo/odoo#125724
X-original-commit: 7e62e3cf569e59a676a834198854f415fa0ae590
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The values for the key "async" found in some services is used to declare
async methods that should be "protected". The hook "useService" makes sure
that no code used to process results of those protected methods is
executed by a destroyed component. The orm method "webSearchRead" was
not protected due to a "typo".
closesodoo/odoo#125688
X-original-commit: 2899888a2449b42b2c5d37846fc9411da6f7f9cc
Signed-off-by: Géry Debongnie <ged@odoo.com>
The values for the key "async" found in some services is used to declare
async methods that should be "protected". The hook "useService" makes sure
that no code used to process results of those protected methods is
executed by a destroyed component. The orm method "nameGet" was
not protected due to a "typo".
closesodoo/odoo#125683
X-original-commit: c2b9f14fa9fbf67063b8885b698ea17a63d79454
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
We make the class DisplayNameRepository use the name service instead of
BatchEndpoint. This makes the code simpler and allow to avoid a lot of
rpcs (in some occasions) when fetching display names.
closesodoo/odoo#124090
Related: odoo/enterprise#42124
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@odoo.com>
The method getDisplayNameAsync being no more called, DisplayNameRepository
has no need to manage deferreds. We simplify it.
Part-of: odoo/odoo#124090
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Lucas Lefevre <lul@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>
A domain of the form ["|", ("foo", "=", "a"), ("foo", "in", ["b", "c"])]
created via the domain selector will be presented in the search bar as
"Foo in ( a , b , c )". That is we make the fusion of some
conditions and use parenthesis and commas to separate the values in order
to get shorter facet descriptions.
closesodoo/odoo#123352
X-original-commit: 3d2580db3225382ab745250b28845f6cb95cbd27
Related: odoo/enterprise#41814
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
In edit mode, we add a 'New Rule' button at the bottom of the domain
selector to make easier to add a new condition.
X-original-commit: 2e761f8965909e4b11d3319c48bd5416c414961f
Part-of: odoo/odoo#123352
When a domain with a single condition is displayed in a domain selector,
the implicit connector "&" or "|" is not displayed. This makes the
operation 'Add node' less obvious in that case since it is not known how
the new condition will be combined with the others.
Here we always display the connector to solve that problem.
As a by-product, we get another problem solved: a domain of the form
["!", ("foo", "=", "abc")] was incorrectly displayed.
X-original-commit: bd57f20980734641ce405bd34d8b17dc780adb17
Part-of: odoo/odoo#123352
When a new search bar facet is created via the domain selector dialog,
quotes are sometimes put around some parts of its description, e.g.
Country = "Belgium". We make the facet description more readable by
removing those quotes.
X-original-commit: 2c12980e129acf9ffe5e1e474d3dee6abb7adfe4
Part-of: odoo/odoo#123352
There is no action that uses the search models/components available in
the legacy control panel. We remove those.
closesodoo/odoo#121433
Related: odoo/enterprise#41078
Signed-off-by: Géry Debongnie <ged@odoo.com>
The fact that callback recorders are put in the env by the action
service has a serious disadvantage. A view using itself some View component
can have easily its own local state and global state polluted by that
subview (views use useSetupView). This would lead to very subtle
problems hard to detect and understand. Moreover, we view the callback
recorders as rather technical stuff and we would like the developers not
to have to think about them. For that reason we pass the callback
recorders as (optional) props to the View component that make them
available in the env. Note that the situation remains unchanged for
client actions (we do not have a View analog component for the actions).
closesodoo/odoo#121050
Related: odoo/enterprise#40901
Signed-off-by: Géry Debongnie <ged@odoo.com>
With a slow network, make a new search in the search bar of a graph view
would lead the graph renderer to be rendered twice. This was due to the
fact that in the graph controller template an arrow function is passed
as a prop to the graph renderer. The reactivity system treats that prop
as changing at each graph controller rendering and ask unnecessarily (in
this case) the graph renderer to render.
closesodoo/odoo#121292
X-original-commit: dab0187e382e5f93dd5ccc78ecbd7e2f47f5c75e
Signed-off-by: Géry Debongnie <ged@odoo.com>
We allow edition/creation of domains with a domain selector via the
search bar facets or the menu "Add Custom Filter".
The domain selector has also been improved and now support expressions
and a new operator "between" for some field types (those for which <=
and >= are valid operators). We also improve the support of the connector
not.
Task ID: 3063564
closesodoo/odoo#112326
Related: odoo/enterprise#37715
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Before this commit, a domain of the form "[(.., .., -1)]" would be
incorrectly represented in the domain selector as .., .., undefined.
The root cause was that py_js view the sub expression -1 as the
application of the operation - to 1 and thus create an AST of type 6 for
it. The domain selector did not expect to get such an AST but did not
crash either. Here we make it extract the intended value from the AST
for -1. More complex expressions like 3-1 are still not supported.
closesodoo/odoo#119620
X-original-commit: f9604da60c6650ad46aafe08e9fad118654a149b
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The new SampleServer class was introduced in c67b9f9907
without dedicated tests. We fix this oversight.
closesodoo/odoo#119188
X-original-commit: 693f7bd74066fa9854db4ecef751f13ec5c7e7a6
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We refactor the ModelFieldSelector and ModelFieldSelectorPopover
components.
We also improve a bit ModelFieldSelectorPopover:
- on first page, the button to go back is no longer available
(so that it is now more difficult to produce an invalid path)
- we always start with a page presenting the model where the last
selected field name belongs to
- the keyboard navigation is improved
- click on model field selector opens the popover with the focus in
the search input (if any)
- for relational fields in popover: the user can either click on the
relational field (and select it) or a special button that make him
follow the relation to the field comodel
We also refactor the hook useDynamicPlaceholder to make it use a new
component DynamicPlaceholderPopover that uses ModelFieldSelectorPopover.
Task ID: 3272798
closesodoo/odoo#117951
Related: odoo/enterprise#39673
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
The objective of this commit is twofold:
- improve the style of the DomainSelector component, in particular, the
style of the control buttons "Add node", "Add branch", and "Delete node".
- add the possibility to reset the domain when the current domain is not
supported. The debug input is also always visible in that case
if the debug mode is active. It is displayed in readonly iff the
corresponding DomainSelector prop is set to true.
Task ID: 3269923
closesodoo/odoo#118057
Related: odoo/enterprise#39512
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
The old submenu "Add Custom Filter" of the menu "Filters" is now replaced
by a menu item "Advanced Search". Click on that item will open an
"Advanced Search" dialog in which the current search domain is displayed
in a domain selector. It is then possible to easily add/remove/edit some
parts of that domain before make a new search with the edited domain.
Task ID: 3269923
Part-of: odoo/odoo#118057
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Since the dashboard view has been removed, there was only one call to
computeVariation of utils/numbers. We move the definition of that
function where it is used (pivot_model.js).
Part-of: odoo/odoo#118057
Since the dashboard view has been removed, there was no more true usage
of setDomainParts. We thus remove the support of domain parts.
Part-of: odoo/odoo#118057
We move the function loadFields from the view service to a newly created
field service. That service can also be used to load model fields for a
given path (loadPath), i.e. load all model fields for the models
traversed by the given path.
We use loadPath in useModelField and DomainSelector.
closesodoo/odoo#117882
Related: odoo/enterprise#39418
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We introduce two new methods for Cache:
- a method "clear" that can be used to delete a specific path
- a method "invalidate" that can be used to delete all paths
Part-of: odoo/odoo#117882
The operator =? is recognized by expression.py as a valid operator but
was not recognized by the Domain class (see the method "contains") as
such.
closesodoo/odoo#116914
X-original-commit: b6495bd51295c513ab0d5c083560ac3a1236bd4f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We remove a useless import of GroupByMenu and refactor the processing
of data points in the model.
closesodoo/odoo#114172
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Revert partly https://github.com/odoo/odoo/commit/d55e6cca0648c78ab27e0107ab7d545e9fd4972b.
Rationale: if the field workcenter_id is not found in the group_bys, the
records in a given row can be associated with different workcenters with
different unavailabilities. So if for instance two records in the same
row are related to workcenters 1 and 2 with respective unavailabilities
from Monday to Wednesday, and Thursday to Sunday, that row would be
totally greyed. This leaves the user with no interesting information.
Moreover, we are about to refactor the GanttView and we want to simplify
the API of the method gantt_unavailability, in particular we do not want
to send row records anymore.
Part-of: odoo/odoo#112756
Co-authored-by: Mathieu Duckert-Antoine <dam@odoo.com>
The new MockServer has no _mockCallButton method. Due to an issue with
the patch function that does not reasign this._super correctly when
entering the _mockCallButton function, a crash did occur.
Part-of: odoo/odoo#112756
From a practical point of view, it seems better to also add the
dialog service in the service registry when calling
setupControlPanelServiceRegistry.
closesodoo/odoo#113610
Related: odoo/enterprise#37510
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The previous commit has as a side effect to change the value returned by
the create method of the orm service. Here we adapt the code that uses it
and make the test pass.
Part-of: odoo/odoo#111965
Let us have records with values 1, 0, 77, 3 for a float field 'foo'.
read_group allows to get those values in an array with the aggregate
function array_agg:
read_group([], ["foo:array_agg", ...], []) will return
[{ __count: 4, foo: [1, 0, 77, 3], ... }]
We now support the use of array_agg for integer and float fields in
the mock server.
closesodoo/odoo#112825
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
mockReadGroup should not count the value false for a many2one when
aggregating a many2one field with the aggregate function count_distinct
and should always return a number. We fix that.
Part-of: odoo/odoo#112825
Let us have records with values false, 1, 2, 1, 1 for a many2one 'm2o'.
read_group allows to get those ids in an array with the aggregate function
array_agg:
read_group([], ["m2o:array_agg", ...], []) will return
[{ __count: 5, m2o: [null, 1, 2, 1, 1], ... }]
We now support the use of array_agg for many2ones in the mock server.
Part-of: odoo/odoo#112825
This reverts commit 8d437bf.
Because of the above commit, the sample server did not correctly group
the records when a date/datetime field was used as a groupby.
We revert id and add a test.
closesodoo/odoo#110321
X-original-commit: 1a0c688aee7682919b66492636f46eff481abd29
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
When some true groups have been fetched, the sample server use them to
construct the value returned by _mockWebReadGroup, i.e. construct some
fake groups. It also populate those groups by assigning them some
previously created fake records. It turns out that those fake records did
not have the right type when the first group by is a date/datetime field.
The record values created (during the group assignation) for that field
were luxon.DateTime instances instead of strings like "2022-12-15".
This was the root cause of the following problem.
Have a kanban view in sample mode and grouped on a date field, then
switch to a pivot view grouped on the same date field. A crash occures.
That crash is linked to the above mentionned problem in the following
way:
- open the kanban view (with sample="1" in its arch)
- some existing groups are fetched by the relation model but no records
exist
- the kanban view switches to sample mode and some fake invalid records
are created in the sample server (the invalidity of records do not
cause visible problems at that time)
- switch to the pivot view
- the sample server is reused but existingGroups is set to be null, so
that _mockWebReadGroup uses the invalid records to create the groups
it needs. The crash occures at that step.
Forward-Port-Of:: cdd583f74f51086c8d5f243a2a761622229ccc26
closesodoo/odoo#109031
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When some true groups have been fetched, the sample server use them to
construct the value returned by _mockWebReadGroup. It turns out that
this construction was invalid: the value returned for the first group by
in each group had the wrong type in many cases. For instance, when the
first group by is a date field, the value returned could be an array
with a luxon.Datetime instance as first element and a description as
second element while it should be a description only (e.g. "December 2022).
We fix that problem.
Forward-port-of: 59c7c8c9adcad468ad9d985113a2b88e745b7414
Part-of: odoo/odoo#109031
The function used to group fake records in _mockReadGroup was
overcomplicated. We simplify it.
closesodoo/odoo#108921
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The keys from the action context were not available in the context of
a name_search done when a user expand a one2many field in the search
bar. We add them.
closesodoo/odoo#107660
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Currently the label of the lines is not limited to the number of characters. When the user gives a name that is too long, the graph will not be displayed.
- This commit limits the number of labels, if exceeded it will display as ...
closesodoo/odoo#106623
X-original-commit: 54657151957c5be5e885c245db9e1830709833c0
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When a one2many is used as a search default, its label has to be fetch
via a name_get in order to get a correct display of the facet
corresponding to that field in the search bar. It turns out that the
search model did not wait properly the return of the name_gets before to
start to compute the facets.
closesodoo/odoo#106624
X-original-commit: 50f58212410b321c1c4ad3d42a91cd1d23567308
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Take a (py.extras) datetime representing the moment "2022-10-17 00:00:00"
in the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or datetime, so that in
October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103579
X-original-commit: ee1a8d26f241f2f7bea6880afcc946119b0e6bd8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Take a PyDateTime representing the moment "2022-10-17 00:00:00" in
the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or PyDateTime, so that
in October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103561
X-original-commit: a11e1fb5f702400fe51938362fe3f24570977ba9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Now that the module web_dashboard has been removed https://github.com/odoo/enterprise/pull/31641,
some props of the reporting views graph and pivot have become unused.
We remove the code related to those props.
X-original-commit: 7d231d1d37707dab4b0ecdd4e2e7cc4535ba6196
Part-of: odoo/odoo#102761
When a x2many record is opened in a X2ManyFieldDialog, it can happen
that the form renderer displayed in the dialog also contains a x2many
that use a kanban or list renderer. In those cases, the View component
is not used. Consequently, the WithSearch component responsible for
making available a search model in the env is not used either so that
a crash occurs at the setup of the kanban renderer (and sometimes later
on for the list renderer). We fix that problem.
closesodoo/odoo#103349
X-original-commit: 2c284317b6dc3c0f0b4e9e376dcee755d81222da
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, click on the "Search More" option in a list many2one
and then selecting an option in the opened dialog would lead to a crash.
This used to happen because the record is updated with a value of the
form [integer, undefined] (that is with no defined label) and nothing was
done in the list model to fetch that label, making impossible to render
the many2one after the update.
Here we make sure that a label is available after the update.
closesodoo/odoo#103271
X-original-commit: 81abccf729ef5b56a8656961931b7489e4364a1f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Have a kanban view grouped on a many2one and displaying that many2one
with a widget in the record cards. Drag a record from one column to
another: a crash occurs. This happens because the record update is done
with a value of the form [id, undefined] (that is with no defined label)
and nothing is done in the kanban model to fetch that label,
making impossible to render the many2one after the update. We fix that
problem by using the known group display name as label for the dropped
record.
X-original-commit: 2a6fe373d48385485933429fbc1e6e3eabd877b4
Part-of: odoo/odoo#103271
Before this commit the attribute default_order was not taken into
consideration by the kanban view.
closesodoo/odoo#103127
X-original-commit: 0116b590a47c8c12354877498e576ad28e42c1f2
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Before this commit, a list header with no label and associated with a
first orderBy field would be highlighted (i.e. would have the class
table-active). Since this is visually weird, we remove that class from
such a header.
closesodoo/odoo#103108
X-original-commit: 36fb5a0d170d9f5692485d0b2fc374951794cd69
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
