added test case for text paste in autocomplete in the searchbar using mouse,
it should populate the autocomplete dropdown.
task-2204174
closesodoo/odoo#48251
X-original-commit: 010961ee3eac55a1e885ce918b597943078324f6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, coming back on a view when in 'debug=assets' would erase the
previously loaded favorites with an 'undefined' value. This was due to an incorrect
cache invalidation mechanism in the DataManager's load_views' method.
Now the views and filters caches are properly loaded if any of them has been invalidated.
closesodoo/odoo#48085
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit, email widget was not trimming value and due to which
space aroung email value remain as it is added by user.
after this commit, email widget will trim the value and remove leading/trailing
space.
task-2197432
closesodoo/odoo#47470
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit:
when manually adding field in export wizard, string has extra space in
begining.
after this commit:
manually added field in export field list doesn't contain any extra
spaces.
task-2065433
closesodoo/odoo#36759
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose Of the task is, we need a visual cue on those fields to let
the user know that their value is company-specific.
So, in this commit On company depedent field we added a building
icon with title 'Values set here are company-specific' next to the
label in the form view.
closes odoo/odoo#47178
Taskid: 2001748
Closes: #47178
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Let's assume a form view with an x2many list, containing itself
an x2many field (no widget, so simply displaying the number of
records). When a record of the list is clicked, a form view
opens and displays the same sub x2many field, with widget
many2many_tags. Both list and form views of the x2many aren't
inline (thus have to be fetched on demand).
Before this commit, it crashed when the user clicked on a row
of the x2many list.
The bug has been introduced by a9cebd5a, which wrongly removed the
code handling this specific situation. At least, now we have a
test attesting that this code isn't useless.
Note that the diff isn't as scary as it looks like (we just added
an if/else, and thus indented the former code inside the else
clause).
closesodoo/odoo#48116
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, if an action context would contain a key/value pair
like
search_default_foo : 0
the filter foo would be activated, while it should be not considered
as default.
The present commit fixes that situation.
closesodoo/odoo#47958
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We have an editable list with 4 fields:
- fieldA (say boolean)
- fieldB with readonly modifier, readonly iff fieldA is true
- fieldC with readonly modifier, readonly iff fieldA is false
- fieldD
Add a new row to the list: fieldA being false by default, fieldC
is readonly whereas fieldB isn't.
Change the value of fieldA: fieldB becomes readonly, and fieldC is
now editable.
From that point, before this commit, clicking on fieldC activated
fieldD (instead of fieldC).
The bug occurred since 3fd7b20, which added a delay between
the moment fields are re-rendered (and inserted at the end of
allFieldWidgets) and the moment there previous instances are
destroyed (and the new ones take their place in the list). So when
several fields were re-rendered at the same time, the order in
allFieldWidgets could not match the actual column order anymore,
and cause issues like the one described above.
Part of task 2210323
closesodoo/odoo#48039
X-original-commit: 89b9717c08e148ad94db17d8746faa2312b6a07a
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When passing a default field chain to ModelFieldSelector, the page data is
not set correctly for the relational field. To understand the issue :
- login to master enterprise all db branch in runbot (debug mode recommended)
- create a mass mailing, add subject, select 'Contact' in `Recipients` field
- click on domain selector and select 'Company' from ModelFieldSelector popover
- click somewhere else to close the popover
- again open domain selector and observe the popover
Current behavior : fields of `Contact` are visible in the page even thogh
`Company` is selected in the ModelFieldSelector
Expected behavior : fields of `Company` should be visible in the dropdown page
This commit fixes the issue by correctly pushing the page data
in ModelFieldSelector.
task - 2058702
closesodoo/odoo#39548
Related: odoo/enterprise#5370
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
When using a mock environment, some services are started and need to be loaded
for some tests to work as intended. Before this commit, we waited for the result
of the `start` method of each service to be resolved. This was flawed because these
methods are all synchronous, so the awaiting period was actually a single microtask
tick.
To clarify this and still make sure that the asynchronous services have enough time
to load properly, the `Promise.all` has been replaced by an Owl next tick method
(with animation frame request).
Consistently waiting for services to be fully ready does not make sense anyway as
we may want to mock a delay during the starting mechanism.
closesodoo/odoo#47865
Related: odoo/enterprise#9328
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the 'mounted' hook of the control panel in the
report client action was never called, because of a missing call
to '_super'. As a consequence, the 'Print' button wasn't displayed.
closesodoo/odoo#47940
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the context sent by an action performed by the action menu
could hold an 'undefined' select_all key, which would cause the context evaluation
to crash.
Now, the select_all key is defaulted to 'false' and does not crash in actions that
do not provide it.
closesodoo/odoo#47745
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In JavaScript, the following computation introduces numerical errors:
```
Math.pow(10, -4) = 0.00009999999999999999
Math.pow(10, -5) = 0.000009999999999999999
```
In the context of `round_decimals`, such errors propagate to
`round_precision`, ultimately leading to inconsistencies between Python
and JS (see #47300 for detailed use case).
Instead of computing `Math.pow(10, decimals)`, we parse the scientific
notation to prevent such inaccuracies.
We also introduce tests in line with the Python tests.
opw-2205092
closesodoo/odoo#47694
X-original-commit: cb471897bfa08d1fee6a9f49e90d9c120e1733fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Use of the new control panel helpers to increase consistency and change the assertions
according to the new DOM/behaviour (e.g. components removed instead of turning invisible).
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Use of the new helpers in control panel (and subcomponents) tests and addition
of new tests.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
1. Test utils helpers adapted to properly instantiate the new Owl control panel
2. New file 'test_utils_control_panel' to create a control panel and use helpers
3. New helper: createComponent (creates a generic component, see jsdoc)
4. Use of the new helpers in the current tests (more in sibling commits)
5. Helper 'addMockEnvironment' is now asynchronous
6. Owl config mode set to 'dev' in test suite (props validation)
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Now that mobile is not supported anymore in community, the mobile layout of the
control panel has been entirely moved to enterprise. This caused some conflicts
with the community mobile test suite (which does not make sense anyway). The failing
tests and related style sheets have been moved as well.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
General cleaning of some helpers and generic files. The idea is that they are
less likely to be entirely re-written in the near future so this is a way to
keep the code clean, readable and compliant to the current standards. Changes include:
- Use of async/await when possible
- Use of const/let instead of var
- Removal of underscore.js
- Use of native JS instead of jQuery when possible
The logic of the affected code remains the same.
This reverts commit d6b854306c.
The reverted commit introduced issues in patching class methods.
Introducing getters in the patch function is not actually compatible
with the original method patching.
Test for patch method is also introduced to guard patch from future
invalid modification that happened.
A more robust way of patching classes is now being developed.
closesodoo/odoo#47557
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The FieldMany2One allows to quick create record (name_create).
However, sometimes, required fields on the co-model make the
name_create crash. In this case, the FieldMany2one opens a form
view in a dialog to let the user specify those fields, and create
a new record with the 'create' method. This was working fine.
The FieldMany2ManyTags embeds a FieldMany2One to let the user
search for and select or (quick) create tags. In this case, failing
quick creation didn't fallback on the dialog form view, but
displayed a server error instead. This commit fixes this issue.
Bug introduced by 50bf8309f8
Task 2192754
closesodoo/odoo#47183
X-original-commit: 63ab065f3298c13bb19ae1245d7fd2652581b254
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit allows to pass a bin_size context to False.
Before this commit it wasn't possible because it was
always overriden.
OPW-2208232
closesodoo/odoo#47491
X-original-commit: 17d53cea1043054dfa9c39b16b430539c4082a9d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit ca4eaf4 introduced the data-mobile attribute, used
to specify options to pass when executing an action, only in
mobile (like using a fullscreen modal).
However, we forgot to add the 'isMobile' check, so the option
was passed in desktop as well.
This commit fixes the issue and adds some tests.
Task ID: 2155601
closesodoo/odoo#47333
X-original-commit: 6cb68a53106fa7326a7f818461418437d5a0df77
Signed-off-by: res-odoo <res-odoo@users.noreply.github.com>
Let's assume a form view with a boolean field and a one2many field,
displayed for instance with widget many2many_tags. There is an
onchange on the boolean field, which populates the one2many, e.g.
[[5], [0, 0, {display_name: 'name', other_field: 'value'}]]
Before this commit, only the display_name was sent to the server on
save, because 'other_field' is unknown by the webclient.
Similar situations occurred with one2manys displayed as lists, and
onchanges returning values for fields that aren't in the list.
These situations probably didn't exist in Odoo yet, but a pending
task on website event adds one.
This commit ensures that all values returned by the onchange for
the x2many subrecords are sent back to the server when the user
saves.
closesodoo/odoo#46807
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit fixes two issues that occurred in the following
situation: in a form view, have a one2many field F1 displayed as a
list, that contains another one2many field F2, displayed with
widget many2many_tags (in the list), and with a list in the form
(in the dialog). In the dialog, the list of F2 displays a
field, say 'name', which has an onchange that sets 'display_name'.
Moreover, there is an onchange in the (main) form view, that
populates F1 and F2, for instance, it returns something like: {
F1: [[5], [0, 0, {
F2: [[5], [0, 0, {
display_name: 'xxx',
name: 'xxx',
}]]
}]]
}
1) If the user opens a related record in F1, and adds (in the
dialog) a related record in F2, then validates the dialog, the
newly created record in F2 isn't correctly displayed in the
many2many_tags (the display_name is `false`), i.e. the onchange
hasn't been applied.
2) If field 'name' in F2 in the list is required, the new record
can't be saved, even if the user enters a correct value.
In both cases, the reason is that we use the incorrect viewType in
datapoints: as we don't specify that we specifically want 'list',
the 'default' one is taken, and we thus use the fieldsInfo of the
many2many_tags, which only knows field 'display_name'. As a
consequence, onchanges aren't correctly applied (issue 1), and
fields aren't correctly reset (issue 2).
Issue reported on task 2189529
When x2many fields are displayed with widgets like many2many_tags,
there is no limit on the number of related records to fetch and
display. In this case, the 'limit' attribute on the datapoints is
undefined. This could lead to weird issues when the limit is used
in computation, e.g.
var index = list.offset + list.limit; // = NaN
There are several occurrences of the above examples in the code,
which can be observed in specific scenarios, e.g. the one encoded
in the test. In this scenario, when the bug occurs, new records
added to editable list views are inserted on top (even if the list
is editable="bottom"), but the edited row is the last one.
Issue reported on task 2189529
Let's assume the following scenario in a form view:
- have a one2many field, say fieldA, displayed as a list,
containing another one2many, fieldB, (no widget, thus
displaying 'n record(s)')
- the one2many list is not editable, so there is a sub form view,
displaying fieldB as a list, and in this list some random field,
say fieldC, is displayed
- have a random field on the main form view, with an onchange to
populate the one2many
- set that random field s.t. the onchange returns something like
fieldA: [[5], [0, 0, {fieldB: [[0, 0, {fieldC: 'value'}]]}]]
- there is now a record in fieldA's list, displaying '1 record'
as value for fieldB
- click on that record to open it in a form view (dialog)
- in the dialog, in fieldB's list, we expect to have a single row
displaying 'value' as value for fieldC
Before this rev., it crashed when opening the record in the dialog,
whether the form view was inline or not.
The crash occured because fieldB was already in the list view, so
datapoints already existed for it (a list datapoint, and record
datapoints for records in the relation, in our example one record
datapoint). However, those datapoints didn't have the fieldsInfo of
the form view. When opening the form view, we added the fieldsInfo
of the form to the datapoint of the record we opened, but we didn't
recursively apply the fieldsInfo to its children. As a consequence,
when rendering the list view for fieldB in the dialog, we haven't
the information about fieldC, and it crashed.
Note that if fieldB wasn't present in fieldA's list view, it worked
fine because datapoints didn't exist before we opened the record in
the dialog.
Task 2120235
How to reproduce
================
You must have
- a form view with a one2many list
- in this one2many list add a column of a reference field
How to reproduce
1. open the record associated to the reference field
2. edit this record in the form modal view
3. click on save
-> Traceback
Bug
===
In `basic_model` the attribute `localData` become inconsistent
because of the method `_fetchReferenceData`.
We want to store the ID of the parent and not the all dict.
closesodoo/odoo#47171
X-original-commit: af411b866aa2052c01168342f8f05ae3dabad83e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit trims leading and trailing spaces in search terms of
many2one.
task-2187414
closesodoo/odoo#45282
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when creating the first record in an editable
list (displaying no content helper), the width of the handle widget
cell was correct while the row was in edition, but it was reset to
0 as soon as the record was saved.
There are two places where this issue occurred: Journal Groups
(Accounting) and Ticket Type (Helpdesk).
After this commit, proper width will be set for the handle widget
in the editable listview on the first record creation.
task-2166338
closesodoo/odoo#46846
X-original-commit: 28b06e78b4940d3b6feb23c77c7de3441a50c0dc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, the method `on_attach_callback` is never called on any Widget in the
systray.
Calling `on_attach_callback` is required if any systray widget uses an OWL
component via the ComponentWrapper. Without the callback, the component is never
considered mounted to the DOM and no event handler is triggered.
closesodoo/odoo#46566
Related: odoo/enterprise#8887
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since formatBoolean returns a jQuery object, boolean fields were
displayed as [Object object] in pivot view.
so fix the issue of checkbox in the pivot view by not calling
fromatValue for boolean instead just set the checkbox element in
in template itself and added test case for checkbox in pivot view.
closes odoo/odoo#46445
Taskid: 2172258
Closes: #44299
X-original-commit: d7d0caf6f599f313687c958c5aff5764c0d23ffd
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
A previous commit makes the graph view render only the finer interval
option for each date/datetime field.
The fact is that in the control panel, different options can be selected
in any order along with other groupbys. This can lead to situations like
'Foo > Date: Day > Bar > Date: Month'
and becomes unreadable.
For that reason we choose to regroup and order options. For the previous
situation, this leads to the following global groupby
'Foo > Date: Month > Date: Day > Bar'.
Our choice also make more sense in a list view for instance.
Task ID: 2198846
closesodoo/odoo#46269
X-original-commit: 59afc869233165e21ef94f485b91d33ac4543b24
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Rendering a graph view with several options selected for a given
date groupby can take too much time and block the page.
Since grouping on the same date/datetime field several times
barely makes sense in a graph view, we choose to use only the finer
option, e.g. 'week' is prefered to 'quarter'.
Task ID: 2198846
X-original-commit: 7e36bee14e18ca17e15de1bacb7ff26010d0b372
Have a grouped list view with enough groups to have several pages.
Go to the second page, and toggle a filter s.t. it only remains a
single page of groups.
Before this commit, no group is displayed (like if there was no
record matching the domain), whereas it should display groups of
page 1. The issue occurs because we didn't reset the group offset
to 0, like we do for the regular offset.
Bug reported in the v13 migration pad.
closesodoo/odoo#46257
X-original-commit: c6a4123b25e884495c5c44287d4d9fed061eeaa4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If you have a currency with 3 decimals, when you show a list view
grouped, you might have result like:
[group partner 1 : amount : 4.4€]
- amount : 1.11€
- amount : 3.33€
which is a little odd, it is not that odd since the groupings are an
approximation (eg. you could have a line in EUR and a line in USD and
the grouping value would be the sum of both line).
But there is no way to specify another precision, and since this is a
grouping it could be of line of different currencies so we can't use the
lines currency to decide.
With this changeset, having for example:
<field name="amount" digits="[69,3]"/>
with `digits` attribute is taken into account for the aggregate value
and it would be displayed with 3 decimals.
Without the fix, the added test fails with:
aggregates monetary use digits attribute if available
Expected: "2000.000", Result: "2000.00"
opw-2195042
closes#45545closesodoo/odoo#46094
X-original-commit: 4dd293c71851d0c6e9ffe09402cf54cfe889f402
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
PURPOSE
In various views, the min width of some columns is too short for the label of
the field. This task aims at fixing this by increasing some minimal widths
and relabeling some fields.
SPECIFICATIONS
crm
* in view_crm_lead2opportunity_partner_mass, view_crm_lead2opportunity_partner
add date widget on create_date and remove the phone field in the inline
treeview of opportunity_ids;
event
* in view_event_form set width of boolean field 'done' to 70px and in
view_event_mail_tree set string of field 'mail_sent' to 'Sent'
* in view_event_form_inherit_ticket set string of fields seats_max to
'Maximum', seats_reserved to 'Reserved', seats_unconfirmed to 'Unconfirmed'
and set width '100px' in the inline treeview of event_ticket_ids;
gamification
* in challenge_line_list_view and challenge_form_view set string of field
'target_goal' to 'Target' in the tree view and inline treeview of line_ids
LINKS
Task ID 2166865
PR #43401
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently when the company is created or updated the whole
web-client is reloaded
so write a qunit test case when a company is created or when
the data is written to the company for the web-client reload.
closes odoo/odoo#44714
Taskid: 2188789
Closes: #44714
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
addEventListener supports an `options` argument, which can
be useful to listen on events during the capture phase
This commit allows to pass these options to the hook useListener
closesodoo/odoo#45478
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this commit, the behavior of the phone widget was tested in web
as if it was always altered with module SMS
Giving wrong test results when sms module was not installed
After this commit, the separation is clearer, and the phone widget's
behavior is tested according to the modules it is altered by
closesodoo/odoo#45271
X-original-commit: 2e337516468797dd898c79c9669b5a90c83b56a7
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
* modify client-side domain normalisation to error if the domain is
invalid (not enough terms / segments for the number of operators)
* add better error reporting to attrs / modifiers parsing
* add a few layered error augmentation to provide clearer context
e.g. "error: invalid domain <thing>" is helpful but "error while
parsing modifiers for field foo: modifier invisible: invalid domain
<thing>" is much more helpful
* rework _evalModifiers to deduplicate it in order to more easily
implement this contextual augmentation
* test that improper domains are properly found improper
* fix a bunch of incorrect attrs domains
* also removed an apparently undefined (& unused) "options" argument
to a _applyModifiers call
closesodoo/odoo#44642
Related: odoo/enterprise#8175
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The translation alert dialog was attached to the entire view in case no
status bar was found. This resulted in the following layout on large
screens:
chrome
--------------------------------------
| alert dialog | form view | chatter |
| | | |
--------------------------------------
Whereas when a status bar was set on the form view, the rendering was as
follow:
chrome
--------------------------------------
| status bar | chatter |
| alert dialog | |
| form view | |
--------------------------------------
The fix make sure the alert dialog is always placed just above the form
view just like when there is a status bar.
closesodoo/odoo#44878
Task: 2075172
X-original-commit: dacdc30681510e9c2db23610c5be5285a72a8949
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
When grouping records in kanban view, if a quick create widget was
already opened, clicking on the "+" to launch another quick creation
would crash.
Fixes https://github.com/odoo/odoo/issues/44680closesodoo/odoo#44949
X-original-commit: b482df17058e6f2117b616e6b152a7f2c90dc121
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the % symbol was part of the input. We could write a
value with the % symbol to divide the value by 100 (50% = 0.5, 50 = 50)
This commit removes the % symbol from the input and adds it in a span
after the input so we do not need to write the % symbol anymore.
The value from the input will be saved as $value / 100 in database.
task-2065078
closesodoo/odoo#43995
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, there was a discrepancy between
many2many_tags widget and regular many2many list
That is, in tag mode, when someone had read access alone on the comodel
he could modify the members of the m2m relation on the current model
Which couldn't be done in m2m list
After this commit, it is possible in a m2m list to add
records to a relation, even if we don't have CRUD access on the comodel
Task 44074
closesodoo/odoo#40194
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: web
Before this commit, when a widget declared assets to lazy load through
the assetLibs key, the asset was loaded through a context-less call to
the server through the base `rpc` function. This caused problems in
website: the website ID was not given to the called route and the loaded
assets were then stripped of their specific-website parts.
This commit solves the problem by allowing the `loadLibs` and
`loadAsset` functions to receive an extra argument: an extra `context`
to use for the actual call to the server. The method is now available
in the ajax service, so that website can add its custom context
automatically, the same way it does it for normal `_rpc` calls.
Part of https://github.com/odoo/odoo/pull/44596closesodoo/odoo#44596
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
If month - 1 or month - 2 are in the previous year, the filter is
incorrect.
ex: Date = Jan. 2020, Filter = Dec. 2019
=> last_year__last_month = 2018-12 instead 2019-12
Cause
If date is 2020-01-20
Selecting December => adding param "last_month"
Selecting 2019 => adding param "last_year"
Applying "last_month" => date become 2019-12-01
Applying "last_year" => date become 2018-12-01
Solution
Detect the right year to activate by default
when a month is selected and no year is selected.
With that solution it is not possible to get records in Jan. 2020
or in Dec. 2019 only for instance but the global functioning
of date filters stays the same as before.
OPW-2169528
closesodoo/odoo#44208
X-original-commit: 096fdc7d3fe0799aa761c6ad3597569a002c698e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Jason Van Malder <jvm@odoo.com>
This commit's intention is to bring class inheritance of event handlers
to components.
Use case:
A component class may want to set generic event handlers for all classes
inheriting from it, in order to set shared event behavior from the start
It is the case in many parts of Odoo, in particular in the cases of fields
which need at least to react on some keyboard event for navigation
The way to implement such a behavior is to make use of the
`useListener` OWL hook, by passing as arguments
event name and the handler function
Dhruv Patel