This commit adds a new SelectMenu component. This component makes it
possible to search for options for a select element. It can be used to
replace the jquery select2 element for most cases.
Changes have been made to the Dropdown component as well as the position
hook, to allow the menu to be placed with the same width than the toggler,
using the 'fit' variant. Tests have been added to assert this position
feature.
Tests have been added to make sure the behavior of this component is
working as expected, and let the core element's usage being asserted.
Part-of: odoo/odoo#106265
Co-authored-by: luvi <luvi@odoo.com>
Previously, when restoring service metadata after clearing it, we would
use the patch function instead of an Object.assign. This is probably a
relic of a previous version of the code that used patchWithCleanup, but
in this context it is completely wrong, as we are giving something other
than a string as the patch name and no object at all as the patch value.
closesodoo/odoo#108390
X-original-commit: b83ab5061fe15e69f6c0703baf6f1eec61332f0e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
There are several customizations of the list and form view that consist
in modifying the behavior of a static menu action (archive, unarchive,
export, delete, duplicate). We have seen that this one is very complex.
So we decided to simplify it.
Solution:
Add the getStaticActionMenuItems API point. This allows us to easily
modify the behaviour of static actions.
We also took advantage of this commit to simplify the ActionMenu api.
We have removed the other actions because it was not clear enough.
They are directly added in the action category.
closesodoo/odoo#107086
Taskid: 3089039
Related: odoo/enterprise#34598
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since odoo/odoo@69c3d5aa25
the readonly and required modifiers were no longer passed
for non-editable views. Which means:
- kanban: never passed,
- tree: passed only when `editable="1"` or `multi_edit="1"`,
- form: always passed.
The rationale behind that is that a view which is considered
as readonly doesn't need to know if its field are readonly or required,
as by definition, if the view is readonly, the user shouldn't
be able to modify anything in the view.
This was to make the views sent to the web client more light-weight,
not sending unused information, and save KB of transfers.
However, some widgets, used in the kanban and non-editable tree,
allow to modify fields, even in readonly considered views,
and therefore need to know these readonly/required modifiers
from the field definition in the Python model.
e.g. the `widget="color"`, odoo/odoo#103478
Ideally, these readonly/required modifiers should be transferred
only when the widget requires it, to avoid transferring the
readonly/required modifiers
when they are not useful in kanban/tree views
(which is 99% of the time).
However, this would require a bigger refactoring,
which is considered too risky compared to the added value
for a stable release.
task-3013110
closesodoo/odoo#106838
X-original-commit: 5a68d254949f1d0ff545023cfd14890efff10f5f
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.
Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.
Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.
How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
the right values)
Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.
After this commit:
The ui will not block.
closesodoo/odoo#105269
X-original-commit: 9917d841fa38ccc1e6d67875a665494dc22ef92f
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
This commit adapts the codebase to match its enterprise counterpart
where calls to legacy cookie api (cf. web.utils.cookies) are replaced by
cookie_service ones.
closesodoo/odoo#104080
X-original-commit: 724469e19ff83e91a41c6721e334df1ad8d1c02c
Related: odoo/enterprise#33189
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
**Before**
A traceback is raised when pressing shift-tab on the first column of
the first row in a focused list field as shown in the vid:
https://youtu.be/g97ZTp1QdBE
**After**
shift-tab on the first column of first row will now unselect the list field
and immediately focuses on the previous field.
**Additional change**
We now allow skipping focus on the dropdown toggler by introducing new
props.
closesodoo/odoo#103485
X-original-commit: 9ba9977e42d201035b5299bc13ba03211cddbc1f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Only kanban, tree and form implements onchanges.
Therefore, on calendar, graph, pivot, ..., putting `on_change="1"`
is useless and is a waste of resources and KB.
e.g. CRM lead pivot view
Before:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" modifiers="{"invisible": true}"/>
</pivot>
```
I would have like something smarter, like using the `editable` concept
for instance, but it's not that easy.
e.g. kanban is not considered as editable, while it does support
onchanges when grouping record by a field and drag and dropping
record from one column to another.
However, if we change the kanban view to make it editable,
the view validation will start validating the fields domain:
https://github.com/odoo/odoo/blob/45d4ac14f65c53dcde56592715d50169bde116ad/odoo/addons/base/models/ir_ui_view.py#L1439-L1442
causing issues:
- If a field used in the domain is not in the view, it will need to be
added in the view,
- while it will not be used, as you cannot do a search in related fields
in kanban views anyway.
e.g.
```
odoo.tools.convert.ParseError: while parsing /data/build/odoo/addons/analytic/views/analytic_line_views.xml:120
Error while validating view near:
<kanban class="o_kanban_mobile" __validate__="1">
<field name="date"/>
<field name="name"/>
Field 'company_id' used in domain of field 'account_id' ([('company_id', 'in', [company_id, False])]) must be present in view but is missing.
```
In addition, the kanban doesn't need the readonly and required
attributes on the field nodes, as other editable views (tree and forms)
do.
In addition, the tree list is currently considered as "editable" only
when it has `editable="bottom" or `editable="top"`, while
a tree without this editable attribute can still trigger onchange,
for instance when using `widget="handle"` or `widget="boolean_toggle"`.
We should therefore making the tree list editable whatever the case,
leading to the same issues than listed for the kanban above,
or make an exception for field in non-editable tree views using a
widget..
So, as the smarter way seems difficult and risky, for a limited gain
I choose the easy way by separating the concept "editable" and
"onchange-able" and to not set `on_change="1"` on views not considered
as "onchange-able".
closesodoo/odoo#102788
X-original-commit: aeb65ee536b1611c1cb829c91906f327f8e331c7
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit removes legacy views that are not used anymore as they
have been converted to owl. They could actually have been removed
in the commit that converted them, as we never needed to have a
double implementation of views, unlike we need to (field) widgets.
The LazyColumnList is a special case. This view hasn't been
converted. Instead, it has been decided not to use it anymore.
So it was dead code, and this commit removes it.
The form/list/kanban views are no longer necessary in the view
registry, since their owl version exists. However, we kept them
in the test asset, as they are massively used in legacy tests
(in field tests for instance).
closesodoo/odoo#102634
X-original-commit: 186a8b31161fc8c75b346ff97f9403dca1ae677e
Related: odoo/enterprise#32501
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When converting the list view to owl, the support for view widgets was
overlooked as this feature is not used very extensively and was not
tested.
This commit adds support for them and adds a test for it.
closesodoo/odoo#102193
X-original-commit: 9098c1d3cd4af8f324b5b09668e92822575f932d
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
pivot, graph, cohort views do not care to know whether a field
is readonly or required, as you cannot edit records in these views.
Even kanban is readonly in most cases:
- you can drag and drop records from one column to another,
which is prevented if the group by field is readonly
but this shouldn't rely on the fact the field is
within the architecture, as you can group by on any fields
from the search views / control panel.
Hence, this shouldn't rely entirely on the modifiers passed on the field
nodes in the view architecture alone.
- you can create new record inside the kanban,
with a simplified form, thanks to the `quick_create`,
but this uses an independant form view, in which the readonly and
required modifiers are correctly passed.
So, `modifiers="{'readonly': true, 'required': true}"` can be dropped
for kanban views as well.
This allow to spare some KB by not setting useless modifiers in views.
e.g. CRM > My pipeline pivot
Before
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row" modifiers="{"readonly": true}"/>
<field name="stage_id" type="col" on_change="1" can_create="true" can_write="true"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true, "readonly": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
Regarding the change of behavior shown in `addons/web/static/tests/views/kanban_view_tests.js`.
It was introduced very recently, by myself, in
odoo/odoo#100806
I revert this possibility to set readonly="0" on a field node in a
kanban view, because:
- First, this is not used anywhere in both odoo/odoo and
odoo/enterprise.
- Second, this really makes things harder if we want to do so:
- as readonly="0" is passed, the "readonly" gets removed from the node
modifiers, as they are simplified by removing falsy value:
modifiers="{'invisible: True, 'readonly': False}" becomes modifiers="{'invisible': True}"
- as readonly in not amongst the modifiers, it fallbacks on the model
field property, in the javascript code, which is readonly: True.
- the thing to do would be to still transfer "readonly"
from the field attributes to the node modifiers.
- which either mean to consider a kanban view as editable
- this will cause issues because the validation mechanism
will suddenly check the domain attribute property
https://github.com/odoo/odoo/blob/d4a92b112d0554a2624f7768feb7d54e0484469f/odoo/addons/base/models/ir_ui_view.py#L1443
and there will be plenty of views where some field used in the
domains will be missing. Besides it is pointless to validate these
domains as they are completely unused in kanban views
- either mean to find another mechanism than "editable" to decide
wheter to transfer the modifiers "readonly"/"required" or not,
which over-complicates things.
- besides only "readonly" would need to be passed, not "required.
So, to keep the code stupid simple, I remove this possibility added only
a few days ago, which is actually not used anywhere in standard for the
moment.
closesodoo/odoo#102221
X-original-commit: 69c3d5aa25655173ed66a52570559322c650c7df
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Setting the attributes `can_create` and `can_write` in views
which are not editable is useless as you cannot edit the record
in these views.
This allow to gain some KB when serving the view to the web client,
as well as making the view cleaner.
e.g. the graph view in the CRM > My Pipeline menu
Before:
```xml
<graph string="Opportunities" sample="1">
<field name="stage_id" can_create="true" can_write="true"/>
<field name="user_id" on_change="1" can_create="true" can_write="true"/>
<field name="color" modifiers="{"invisible": true}"/>
</graph>
```
After:
```xml
<graph string="Opportunities" sample="1">
<field name="stage_id"/>
<field name="user_id" on_change="1"/>
<field name="color" modifiers="{"invisible": true}"/>
</graph>
```
This revision takes the opportunity to port the `editable` concept
from the server to the web client MockServer,
in order to be able to test the removal of these attributes from the views
in the QUnit tests.
The `_editableNode` JS function added here is the translation of the
existing `def _editable_node` method in `addons/base/models/ir_ui_view.py`
https://github.com/odoo/odoo/blob/f5edde3624f4fe40f87cc7fed7dcfc4bbce1f19f/odoo/addons/base/models/ir_ui_view.py#L1282-L1301closesodoo/odoo#101902
X-original-commit: f0beddf534a57e972ac3a7bef6afa1caae1dcff3
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit does multiple things:
- The readonly mode of form view is removed but not for the fields.
it means that the fields in the view are always in edit mode except
if we force them to be readonly.
- The control panel is revamped to take less vertical space and shows now
the record editing (dirtiness)/validity status after editing the record.
- The record is saved only when leaving the view or by clicking the save
button when hovering the record status in the control panel.
- The record can still be discarded by clicking the discard button when
hovering the status text in control panel.
task id: 2822553
X-original-commit: 77824ad44b6945a9811120380747f87ef6362ae2
Part-of: odoo/odoo#101118
Co-authored-by: luvi <luvi@odoo.com>
This commit introduces the new calendar view written in owl.
closesodoo/odoo#101185
X-original-commit: e88988f58582d5b49a32d7102a74a176f40c4c69
Related: odoo/enterprise#31808
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Before this commit, in a Kanban view, the group representing
a new column did not contain a domain. Its domain should have combined
the view domain and the groupBy domain ([groupByField.name, "=", id]).
How to reproduce:
- Go to a grouped kanban view with a progress bar
- Create a new column
- Create a record in this new column
- Click on the progress bar to filter the records on a state
Before this commit:
All records corresponding to the selected state are displayed in the
column. (even the records that are not part of the column)
After this commit:
Only the new record is displayed in the column.
closesodoo/odoo#101096
X-original-commit: 1022262c6fcd51c8d4fc8024217542bb1f536d2c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
"phone" isn't a valid input type, so it had no effect, except
breaking the tour system when a PhoneField input was the target
of a step, since the "consume event" was then "click" instead of
"input"..
closesodoo/odoo#100388
Related: odoo/enterprise#31437
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Following odoo/odoo@4636620004
`get_views` only pass the model fields included in the view architecture,
except for the main model when the search views is requested.
Because the search views requires all fields for the user to be able
to make advanced filters and advanced group by using any fields of the
model.
However, other views requires more field descriptions as well than
just the fields included in their architecture:
- the graph view requires all integer and float fields,
to automatically add suggestions of measures in the measures dropdown
menu. It's a bit like the search view, the user should be able
to choose any measure available in the model
(as long as this is integer or float fields)
- the pivot view requires all groupable fields,
so the user can group by any groupable fields of the model.
The JS MockServer `getViews` is adapted to include the changes added by the above
revision as well as the current revision,
for the qunit tests suite to be able to reflect these API changes
from the server side.
closesodoo/odoo#100376
Related: odoo/enterprise#31427
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit aims to make the behavior of the mocked 'read_progress_bar'
requests closer to their server implementation.
Namely, the returned dictionnary is supposed to contains the display
names of the current groups in its keys. This was not the case and has
been fixed.
Part-of: odoo/odoo#100149
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
PR [1] removes some `<field/>` node attributes from view archs that
were transfered into the `modifiers` attribute (e.g. `invisible`).
However, the `invisible` attribute was still used in some views
(e.g. graph, pivot, search and cohort). This issue hasn't been
spotted by the tests as the MockServer was still sending archs
with both `invisible` and `modifiers` attributes.
This commit adapts the MockServer to make it behave like the real
server, which makes some tests fail, and adapts the impacted
views to make them look into the `modifiers` attribute, which fixes
the failing tests.
Closesodoo/odoo#99920
[1] odoo/odoo#99619closesodoo/odoo#99948
Related: odoo/enterprise#31220
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit allows the 'editInput' test handler to also handle inputs of
type "file". To do so, the value must be a file (or a list of files),
and the handler has been refactored to accept a certain given value only
if its type allows it.
Part-of: odoo/odoo#98251
The goal is to improve the dates utility functions (parse/format) by removing the timezone option, which is difficult to understand and has proven to be error prone.
- Rationale
When manipulating DateTime objects on the JS side, associated timezones
must be always coherent.
Until now, there were several code parts that had to check the DateTime
timezone and handle things differently in a case or another.
This sometimes lead to wrong code.
E.g. there was a bug in the DatePicker component because the DateTime
object it receives in props is in local timezone, but once it updates it
through the parse utility, the new object is in UTC.
- After this commit
The DateTime objects you'll get through deserialization or parsing are
always set in the user's local timezone.
The formatted strings you'll get through formatDate and formatDateTime
utils will always be expressed in the user's local timezone.
The formatted strings you'll get through serialization utils will always
be expressed in UTC.
- serializeDate and serializeDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the server expressed in UTC
- formatDate and formatDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the user, expressed in the user's TZ
- deserializeDate and deserializeDateTime
- expected input: a date(time) string provided by the server, in UTC
- outputs: a DateTime object in user's TZ
- parseDate and parseDateTime
- expected input: a date(time) string provided by the user, in its TZ
- outputs: a DateTime object in user's TZ
- Other changes in this commit
As the timezone option has been removed from parsing/formatting utils,
all their usage had been adapted in the codebase.
The large diff in dates_tests.js is because some tests were reorganized,
others were removed/adapted/joined.
A test has been removed from daterange_field_tests.js, because it has
no sense: it displays a date field as a datetime, but a date field does
not have any time information.
Part-of: odoo/odoo#98980
Co-authored-by: Julien Mougenot <jum@odoo.com>
Before, it was possible to drag&drop an element from a point to another.
However it can be useful for tests to drag, make actions/tests
and then drop.
Now, the user can use the `drag` function and drop after with the
returned function.
Part-of: odoo/odoo#98897
*: mail, web.
The pyEnv used during tests is based on the mock server to provide
server like api. This issue is that when creating multiple environments
during tests, a new mock server is created each time. This is not realistic
since in a real world scenario, multiple tabs would share a single server.
In order to make pyEnv work with multiple tabs tests (e.g. multiple env tests),
let's create a single mock server shared between js environment during a test.
task-2053917
Part-of: odoo/odoo#97975
Before this commit, the isVisible helper would most of the time work as
expected, except if an element has display: contents. In that case, it
has no bounding box, but it may still be visible if one of its child
is visible.
This is particularly important since we want to set the display property
of all field components to "contents".
Part-of: odoo/odoo#96865
Have an editable list view, displaying a many2many tags field. The m2m field
has a context, mentioning `active_id`. (`context="{'default_field': active_id}"`)
"basic context keys" is to be understood as the usual suspects: active_id, active_ids, current_company_id, active_model
Type something in the m2m input, and selet create and edit, in order to create a new record in a dialog form view.
Before this commit, there was a crash because active_id was not present in the evaluation context.
After this commit, the new record opens in its form view, with the right value for the field that must have a default.
closesodoo/odoo#96910
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The wrapping promise synchronously resolved to the rpc promise.
Hence it could not be aborted since the promise was actually already
resolved.
Part-of: odoo/odoo#97036
The mock server's mockReadGroup function would not properly compute the
value, range and domain of the returned groups for date/datetime fields.
The value should be expressed in the local timezone,
and the range/domain shoulb be expressed in UTC timezone.
Consider the following:
- a record with a datetime field of value "2016-12-14 12:34:56" (expressed in UTC)
- a user with an UTC+2 timezone offset
- a read_group with groupby "['datetime:hour']"
The corresponding group would have had the following metadata:
- value: `"12:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 11:00:00"], ["datetime", "<", "2022-12-14 12:00:00"]]`
- range: `{ from: "2022-12-14 11:00:00", to: "2022-12-14 12:00:00" }`
It now has the following valid metadata:
- value: `"13:00 14 Dec"`
- domain: `[["datetime", ">=", "2022-12-14 12:00:00"], ["datetime", "<", "2022-12-14 13:00:00"]]`
- range: `{ from: "2022-12-14 12:00:00", to: "2022-12-14 13:00:00" }`
closesodoo/odoo#96946
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, an error was raised when an invisible button was
found on a list view (for example, if it has a group).
Now, the invisible buttons are correctly managed.
closesodoo/odoo#96963
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a ListView, a field containing an invisible
attribute using an expression to be evaluated was never displayed.
Example:
<tree>
<field name="foo" invisible="context.get('notInvisible')"/>
</tree>
The foo column is never displayed.
The solution is to use the column_invisible modifier to know if the
column should be displayed or not. column_invisible contains the
evaluated expression of the invisible attribute by the server.
closesodoo/odoo#97066
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit in tests, when creating a view with makeView, the same env was shared for services, view and
main_components_container. This is rather wrong as bugs in prod could not be reproduced in tests.
For example: env.config was present in the env for every services and components, this is wrong as
only View must receive it in its env.
After this commit, makeView separates the env for services and top-level components from the one dedicated for View.
Part-of: odoo/odoo#96618
This commit will trap the focus on the dialog, this will avoid modifying
a background record when a dialog is open. Trapping the focus on the
dialog is a well-known technique for modals (dialog).
closesodoo/odoo#96361
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Doing a `search_count` on millions of records could be very slow. On
large databases, the pager counter "1-80 / 8000000" could take several
seconds just to get the total number of records.
This commit limits the counter in list and kanban views to 10k records,
and shows "1-80 / 10000+" if the limit is reached. If you click on
10000+, it updates with the real count (or if you go up to 10000 with
pager or input value).
The search_count on res.partner of odoo.com takes 4s. With this patch,
it will take ~20ms.
Task 2761165
closesodoo/odoo#95642
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
There was an issue with the computed `read_group` `__range` when grouping on
the same date/datetime field on multiple granularities (i.e. month, week).
Since the range was stored with the field_name as a key, the last evaluated
range would override the previous ones.
Impacted Versions:
- master
(- exists since 15.0 but it does not impact the user directly so it has been
decided to fix this only in master, since the API is modified)
Steps to reproduce:
1. Open a list view and group by a date field with at least 2 granularities
2. Open the chrome debugger (network) and check a web_read_group rpc preview
3. Find the web_read_group for groups related to one of the largest
granularities and check the `__range`
Current behavior:
- `__range = {field_name: false}`
Expected behavior:
- `__range = {field_name: {from: range_start, to: range_end}`
Explanation
Since the smaller granularities are evaluated last, and the condition to update
`__range` is related to the field_name and not the granularity, the range is
always overriden by the smaller granularities (even if their value is False)
when grouping on the same field with multiple granularities.
Furthermore, there is a conceptual problem with the current solution: it does
not allow to store multiple ranges when the read_group is not lazy and when
grouping on the same field with multiple granularities.
Therefore, the proposed solution is to use the full groupby keys in the
`__range` to allow storing multiple ranges depending on granularity. The keys
in `__range` would thus match the group value keys and allow more flexibility
if a domain must be forged from the group(s) range(s).
Task-2894519
closesodoo/odoo#95193
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, in the HomeMenu, typing several characters very
quickly could result in some not being present in the command palette
when it was opened.
Exemple:
In the HomeMenu,if I type "a" "b" "c" quickly the command palette will
open with the search value "/a" or "/ac". So we have lost the second
and/or third character.
Why:
All characters typed between the first and the moment the command pallet
is not yet mounted are lost because the search bar of the command pallet
is not yet available.
Solution:
If you use openPalette and the command palette is already open.
The configuration of the command pallet will be overwritten by the one
given to openPalette.
In our case, we can pass new configurations with the correct searchValue
until the command palette is returned.
closesodoo/odoo#95492
Task-id: 2906623
Related: odoo/enterprise#29230
Signed-off-by: Géry Debongnie <ged@odoo.com>
The call to web_read_group done in _loadGroups was incorrect when the first groupby
was of the form date_field:granularity (e.g. "create_date:day"). The groupby was
sent as a mesure and interpreded as such, leading to an error of the form
"Invalid aggregation function ...".
This was not detected before by lack of manual testing: the mock server used in tests
checks the read group parameters in a different way from what is done server side.
So the error was not visible in the testing environment.
In this commit, we remove the error in web_read_group and improve the mock server
(a bit) so as to make such errors be detected.
Part-of: odoo/odoo#92475
This commit introduces the new kanban, list and form views written
in owl. Even though it contains the implementation of those 3 views,
only the kanban view is activated for now (the list and form views
aren't 100% ready yet, so they aren't added to the view registry).
Alongside the views, the fields (<field name="..."/> in archs) and
widgets (<widget name="..." in archs) of web/ have been implemented
in owl as well. Legacy ones remaining in other addons are supported
in our new views, thanks to a compatibility layer. The goal is to convert
them asap though.
Legacy views, fields and widgets are kept for now, which explains the
number of added lines in this PR (around half of them concern tests).
They are still extended by custom code in other addons, that still need
to be converted (a lot of them are already on the way). Moreover,
they are still used in Studio as well. The plan is to lazy load them in
the Studio bundle when all custom code extending them will be
converted. Studio will be converted for v17.
Part-of: odoo/odoo#92475
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
This commit mocks the website service for all the QUnit tests.
As the website module now defines a patch on the WebClient and NavBar
components, adding the website service, this service needs to be mocked
for all the tests. This is done by patching the QUnit.testStart hook.
Also, after the addition of the new media dialog, this component is
mocked at the field html unit test.
See merge commit for more information.
task-2687506
The mock implementation of search_count returns `false` instead of 0 when the
domain doesn't match any records.
Also, writing some tests revealed the `active_test` context key was not taken
into account.
closesodoo/odoo#93746
Related: odoo/enterprise#28449
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, the test utils that trigger an event (e.g.
click) didn't check whether the target of the event was visible.
As a consequence, when writing a test, one might trigger an event
on an invisible and undesirable target, and don't understand why
it doesn't work due to the absence of feedback. This commit
improves that situation by throwing an error in those sitations.
Obviously, some tests relying on the former behavior needed to
be slightly adapted.
closesodoo/odoo#93549
Related: odoo/enterprise#28360
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
