A lot of tests in different QUnit modules need this delay to be
patched to 0. Some of them (e.g. the 'ActionManager > Misc' module)
didn't patch it correctly. It worked before because a patch was
done in a previous test, and wasn't unpatch. The previous commit
ensures the patch is removed, so now we have at least 2 tests of
the above mentionned module that fail. This commit ensures that
the delay is patched in every tests, and allows to specify a
custom delay if necessary.
For testing purpose, the multi-click timeout delay of the quick
edit is patched. However, in this specific test, it is patched
twice (once to set it to 0 in beforeEach, and once to set it to 50
in the test itself). A single call to unpatch removes the second
patch (50) but keeps the first one, for the remaining of the test
suite. This could lead to weird situations where the whole suite
passes, but a single test executed on its own fails.
Issue spotted in the assets revamp PR, as it alters the test order.
Before this commit, quick edit tests could crash in an undetermined way.
It was due to the setTimeout for the quick edit event in FormController
which waits at least 1 tick even if timeout = 0 like in those tests.
Now, if this timeout is 0 then we bypass the setTimeout.
* sale_product_matrix
Before this commit, if we created a new row in an editable list view,
do not "touched" it and clicked out of the list then the record tried
to be saved and threw error notifications.
Now, that flow will discard the record to make it consistent with the
form view which discards the record when we leave the form.
task-2431691
closesodoo/odoo#68382
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a module wasn't correctly defined (e.g.
wrong format for dependencies, wrong format for module name, name
already defined...), an error was thrown but only in debug mode.
In non debug mode, the problem was simply ignored, which is wrong.
An example of harmful consequence would be the following: if
someone defines a new test file and uses an already used module
name, he won't be notified of his mistake unless he runs the suite
in debug mode. If he doesn't, the runbot won't detect it either as
it runs tests in non debug mode. It would then lead to one of the
two test suites not being executed.
Fun fact: a lazy loaded file was actually loaded twice, but we were
only notified in debug mode. With this change, it made the test
suite fail all the time, no matter the mode. We simply removed the
file from the page source, and let the first test needing it lazy
load it.
closesodoo/odoo#66918
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Commit [1] tweaked the empty (unset) fields css rules s.t. they
have a non null height in readonly, to reduce the shift between
readonly and editable form view. This only concerns form view,
but the changed rule also applied in list view. As a consequence,
empty fields increased the rows height in list views.
https://github.com/odoo/odoo/commit/288b24cbdf54ac0dbee7e012f074fac9a0c68238closesodoo/odoo#68482
X-original-commit: 020b814b3be055c6bf795153dce6079810d34b1c
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The range date lib would open the selector on focus.
This is a behavior we don't want in lists, but want to keep in quickedit
forms.
Task id: 2492914
closesodoo/odoo#68390
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Do not trigger quick edit when we are selection text with mouse:
- click and holding to select text
- multiple clicks selecting text
Since click on an editable field now change the edit mode, we could no
longer select the text.
With this change, quick edit is delayed by a given delay and if the edit
mode is not enabled if:
- there is a subsequent click within the delay
- there is a text selection when the click event is handled
closes#68023
X-original-commit: 2939ea4dd4736e659cc3e4df2226a3b08ac8ec48
With this commit we support adding FieldDependencies on custom widget, consider
FieldDependencies given on custom widget and add it to fieldInfo so that when
modal does calls to server to fetch data it consider those fields while reading
this will let us to design custom widget which may have some other fields in
dependency, say for example weekly recurrence widget which uses sun, mon etc.
fields, so with this we can fetch data of those dependent fields without adding
it to view.
task-2335399
closesodoo/odoo#60277
Related: odoo/upgrade#2021
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
with this commit we adding weekly recurrent widget, currently proeject and
calendar shows boolean for each day vertically but with this widget we displays
week days and its boolean horizontally.
Here widget will display first day as per language's week_start field, also we
adds FieldDependencies on custom widget and consider those FieldDependencies
while processing view node in basic_view.js
We add support of registry to contain owl custom widgets and add support
of rendering owl custom widgets.
Also with this commit we removes fields like sun, mon, tue etc. from view and
instead use "web_weekly_recurrence" custom widget to display boolean for each
week day.
Co-authored-by: Mohammed Shekha <msh@odoo.com>
add support of <widget> tag for owl, In order to prepare the future,
we want to convert everything in Owl, in future widgets generated by
<widget> tag will also be converted to owl.
with this commit we support widget to instantiate using ComponentWrapper.
task-2337692
Co-authored-by: Aaron Bohy <aab@odoo.com>
The confirmUpdate method in list_editable_renderer would destroy all
rows' widgets and recreate them *except* the currently modified one
(this one gets updated).
The problem was that the widgets of the current row were recreated
anyway. It created a memory leak.
This memory leak isn't such a big deal, as anything is garbage
collected as soon as the view is left anyway (so it's a small leak
during the lifetime of the x2many list)
The fix consists in keeping the reference of the widgets on the
currently modified row, and when all rows' widgets are recreated, we
delete a replace by our reference for the current row.
closesodoo/odoo#68386
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a list editable used as a one2many representation, inside the
confirmUpdate method, the on_attach_callback method on the field widgets
wasn't called.
It wasn't detected earlier because most of the legacy widgets didn't
implement this callback (all owl components do however).
It was problematic as the confirmUpdate function destroys and recreates
all the field widgets (with exception for the currently modified row).
Not calling the on_attach_callback would result in missing / unexpected
behavior such as _applyDecoration not being called.
The fix is simple: call the method if it exists on all the widgets after
they have been created.
Purpose of the commit is to display the default label next to the icon
for state_selection widget in list view.
also that widget support the hide_label option to hide the label in
state_selection widget of the list view.
Related Ent PR: odoo/enterprise#16559closesodoo/odoo#66589
Taskid: 2451287
Related: odoo/upgrade#2195
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Let's assume an x2many list with an onchange. When a sub-record is
modified, an onchange is performed, and it may update other records
in the relation (e.g. the debit/credit case in accounting). This
commit ensures that modifiers are correctly re-evaluated in that
situation, so that they are up-to-date with the new x2many values.
task-2373929
closesodoo/odoo#61911
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
One might design a custom field widget to display/interact with a
one2many field. Before this commit, if this field widget triggered
a field_changed event to update a related record, it crashed,
because the code assumed that there was a view associated with the
field.
Closes#68276
opw~2468238
closesodoo/odoo#68309
X-original-commit: 3826a2645b94e0f62c719814c4dbe4cc6502e1f2
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, hr_skills module defined a few css rules
but weren't enclosed in a custom class to make them only
for hr skills so these rules leaked everywhere in odoo.
This commit encloses these css rules to not leak them and move
a rule which changes the color of list's remove button into web
module to keep the color.
closesodoo/odoo#67921
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Open Calendar weekly view
Scroll the weeks
The 'Responsible' filter will accumulate entries from the events and not
deleting them.
This create issue with the view in db with heavy calendar use and a lot
of responsibles
This reverts commit 64d0fe4118, coming from
task 2146842, addressing the following issue in calendar view (i.e. in planning
app) not reproducible anymore
"
In calendar view, when you unselect all filters of a category, all
events disappear (it's expected), but all filters also disappear.
So you can't selectd anything, you must reload the view to unlock
the situation.
"
opw-2479920
closesodoo/odoo#68118
X-original-commit: 0ae22aa773f9343fc79937cceb5bf60c5fb3ba3c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
This commit fix a bug introduced in #66551 where a mismatch has been done between
session.user_context.allowed_company_ids and session.user_companies.allowed_companies.
This commit also adds the following tests:
- a JS test in order to prevent future unwanted issues regarding multi company
in BasicModel.
- a Python test in order to ensure that session_info['user_companies'] is not
involuntarily changed.
closesodoo/odoo#68025
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit aims to allow ones to customize the condition whether the
optional column dropdown should be rendered or not.
PR enterprise : odoo/enterprise#15205
task-2392303
closesodoo/odoo#66979
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Valuation
- Click on export all (little button next to "Inventory at date")
The field "Total value" have too many decimals: 60739.2000000004
This occur because of the multiplication: it yield the correct value
(60739.2), but every rounding attempt done, even in the ORM, will
mess up the representation
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
opw-2438384
closesodoo/odoo#67558
X-original-commit: 67cf82962688360cfe25c6b2118a7dbd17a6ee95
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Issue
- Install "Accounting"
- Change user language to arabic
- Go to Customer Invoices list view
- Try to filter on field "Created On"
Traceback is raised from the DatePicker Component
Cause
The cause is two fold:
There is an issue in moment that behaves abnormally when its internals
are not able to extract the month in a locale, and, instead of returning an
invalid moment, it returns a valid moment with the month set to January
which just happens to be the first month of moment's default locale
ref: https://github.com/moment/moment/issues/5600
Secondly, the defaultProps "locale" of the DatePicker was set to moment.locale()
at the file's initial loading, that is, before any user locale parameters were loaded
The bootstrap datepicker was then set with the wrong locale, and the case fell under moment's issue
After this commit, the locale of the DatePicker is always the one of the user, and there is no traceback
opw-2460156
closesodoo/odoo#68059
X-original-commit: e2c46bb80e1e312dd34ac554d79813ef35282e62
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Before this commit, calling unpatch on an object that hasn't been
patched before crashed (before reaching the code that handles the
case by throwing an Error). This scenario is now properly handled.
This commit also defines specific Error classes for the patch and
unpatch faulty cases, so that they can be elegantly catched (in
tests for example).
closesodoo/odoo#68057
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
In tests, we might want to disable a specific patch for a specific
test (e.g. to remove a monkey patch done when another addon is
installed, to test the behavior of the current addon).
Before this commit, it was possible to unpatch at the beginning of
the test, but we couldn't re-patch when the test was over.
Feature required by task~2392303
To find the main element which scrolls in the page, we rely on its
height being as tall as the body one. The code which checks that was
making a comparison between a rounded value and floating value without
care of the rounding errors that might induce, especially on zoomed
pages.
Fixes https://github.com/odoo/odoo/issues/63306closesodoo/odoo#67986
X-original-commit: 71b6fc7341dfec5e8fc2352c3143b1e324a880f8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Sales"
- Switch to "German" language
- Go to Sales -> Products -> Products
- Try to filter on "Public Price" is equal to "2,3"
Not possible to add decimal point at the end (only in middle of number).
Cause
In case the 'decimal point' in DB params is not a dot '.',
the filter input will be considered as 'text' instead of
'number'.
In case of the 'number' type; HTML do already a pre and post
processing, including managing decimal point (who, for example,
is not included in ev.target.value if last char is a '.').
Unfortunalty, the library is not well working with other
language and not supported on every browser, therefore,
must use own logic.
In case of a 'text' type, the value will be send to 'parseFloat'
,then `parseNumber` will replace decimal_point by dot (also one the
issues since needed to display decimal_point according user language),
and `Number` will remove the decimal_point in case of '123,' -> '123',
and therefore we will not be able to write decimals ( apart of adding
the decimal point after writing the whole number...)
Solution
If user input is well parsed, store parsed value in condition.value and
set condition.displayedValue to the input value (an so without updating
input value). Else, replace input value with previous value (who should
be the condition.DisplayedValue).
opw-2463441
closesodoo/odoo#67978
X-original-commit: e795ce5bff14b6b748c1f4a2651946aafdc299f4
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before this commit, clicking on the "add a line" button on a
many2many list field directly opened the dialog without
switching the form into edit mode.
This is incorrect, the form needs to switch into edit mode otherwise
the selected records are saved and cannot be discarded.
closesodoo/odoo#67919
X-original-commit: 3608e724c6099f0eff5f14cbd844e0d7507d0d1d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the quick edit behaviour has added, embedded lists
can be edited and display the "add a line" buttons in a
readonly form but not display the remove buttons
This commit fixes that inconsistency.
X-original-commit: 7cc17a345bc9cbe165d061300d91d1ac0e583fc1
Without this commit, all tests executed after that one would use
the patched version of the FormViewDialog.
Issue spotted in the assets revamp branch, by moving form_tests.js
after calendar_tests.js
closesodoo/odoo#67887
X-original-commit: ff19ee8d8b39a719a09dd9f6060faa3afa474da3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The left css property computation wasn't usefull for ltr mode and
even worse, it introduced a bug when a horizontal bar was present
(as often on mobile).
The entire width of the table was used to compute the offset even
though we only saw part of it (scroll bar). It's why this left css
property was too high.
We can simply remove this logic as "right: 0" on .o_optional_columns
already do the job for the ltr mode.
Note that we still need to compute the left property for the rtl mode
to put the dropdown menu above the table. Otherwise it will be on his left!
Steps to reproduce:
- Go to Subscription
- Open an existing record
- Try to open subscription lines column dropdown
=> You need to scroll on the right to see it.
Related PR: https://github.com/odoo/odoo/pull/62472
Related Task ID: 1929043
closesodoo/odoo#67755
X-original-commit: 87c6f6338d267acaab90705f9d5ca8ad27ae30fd
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
These are throttled/debounced so the handlers are sometimes called after the
component has been destroyed.
opw-2451752
closesodoo/odoo#67754
X-original-commit: 852781cf64ad6bb10c552e106e93e2bb6035e34b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.
In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).
Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.
The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.
That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.
Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.
[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648
Issue reported in task~2352524
Model: account.move
One2Many (A): account.move.lines
Nested computed One2Many (B): tax_detail_ids
Field triggering the onchange (C): tax_ids
closesodoo/odoo#67739
X-original-commit: a3732031d38d7c7e93565cdd3cd4fdf838ae54ec
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Before this commit, on mobile in the Accounting app, the link in a
kanban card was not well placed.
After this commit, in mobile we consider a link as a block so he is
moved below.
Steps to reproduce:
* Open Odoo on Mobile
* Go to Accounting => Bug ("Create Manually" is in a strange position)
Task ID : 2200168 (4.a)
closesodoo/odoo#67692
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, when a calendar view was resized the full view was
rendered again to recalculate the resize.
After this commit, we now set manually the new size.
This avoid to lose the current position-y in the calendar.
Steps to reproduce:
* Open a window (not maximized)
* Go to calendar (day/week view)
* Scroll to the end of the calendar
* Resize the window => the calendar returns to the begging.
Note:
By the same way it also fixes a performance issue in TimeOff's render as
it makes an RPC to calculate the popover for the year view.
Task ID: 2200168 (5.a)
closesodoo/odoo#66387
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Description of the task :
Make the website ui as consistent as possible by making some layout
quick wins.
Behaviour before the PR is merged :
The user has to double click to select the hex color on the color
picker after clicking on it a first time.
Desired behaviour after PR is merged :
The hex color value is selected when the user clicks on it.
Part of https://github.com/odoo/odoo/pull/65255
task-2438556
Commit [1] altered the way the FieldMany2Many behaves with respect
to 'create' and 'delete' options. Indeed, for many2many fields,
adding or removing records doesn't mean "creating" or "deleting"
records, as it is only about adding/removing records to/from a
relation. This is completely fine and correct.
Unfortunately, a feature has been lost in the process: it is no
longer possible to state that a many2many field should be editable
but should not allow to add (or remove) record to the relation.
This commit fixes the issue by adding two new options: 'link' and
'unlink' for that purpose.
[1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096
opw~2466213
closesodoo/odoo#67495
X-original-commit: df44e65bbbba55a7ee2224ad5b4f13248a39423a
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The Many2ManyCheckboxes widget displays all values that could be
in the many2many relation, with a checkbox indicating whether each
value is in the relation or not. It is designed to be set on fields
where the comodel contains a few records (typically, we don't want
to see dozens of checkboxes in the form view). This widget shouldn't
be used on many2manys with a large comodel, as we have better tools
to handle them (like a tree view).
We deal with extreme cases (when the widget is, by mistake, set on
a field where the comodel is huge) by using the name_search limit
of 100: at most 100 checkboxes are displayed.
Before this commit, this extreme situation wasn't correctly handled.
If there were in the relation records that weren't displayed
(because they weren't inside the 100 limit), then, editing the value
by (un)selecting a checkbox would automatically remove all non
displayed values from the relation.
This commit ensures that we keep in the relation all values that
aren't displayed.
Issue spotted when working on opw~2439041
closesodoo/odoo#67400
X-original-commit: 9e9d3aa78c42ad4ffca3b56a28382ed84078cde3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if the widget "many2many_checkboxes" was set on
a field with more than 40 values in the comodel (i.e. more than 40
checkboxes displayed), (un)selecting a checkbox that wasn't in the
first 40 checkboxes crashed. This was due to the default x2many
limit of 40: we only created a datapoint for the first 40 values,
whereas we could have up to 100 values to process (name_search
server-side limit). Note that this limit of 40 had no other impact
than limitating the number of records processed by the BasicModel,
the maximum number of checkboxes displayed being ruled by the
name_search server-side limit.
This commit ensures that all values returned by the server (at most
100 when this message is written) are processed and can be edited
as expected.
opw~2439041
X-original-commit: d037d12753179d890459b23319b0d769fce62771
Styles for the hex and rgba inputs from the color picker were modified
on directly from the web module, which means that for a specification
concerning only the frontend colorpicker, the backend colorpicker was
also changed.
This commit reverts the changes that were made and only applies the new
style for the website editor.
Related to https://github.com/odoo/odoo/pull/65249closesodoo/odoo#67396
X-original-commit: 9529e29615699942aac89099cd37144e052b9004
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A previous commit (8dbd1efef899fb637acca3c318ae99cb23838b8f) fixed a
part of the basicmodel that used _.each to iterate on an object with
field names as keys, which does not work when a field is named "length".
To fix it, I simply used a native for ... in statement. However, I
missed the fact that there was a second 'return' statement in the body
of the closure given to _.each, so the onchange method returned
prematurely.
The fix is to simply use the continue statement in that case.
closesodoo/odoo#67267
X-original-commit: d9834e65ee57511f4850fa2d74287eb0b67087b9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
# Purpose
This PR's primary objective is to ensure that the timesheet uom is working in accordance with the company settings in a multi company environment.
Prior to this PR:
- The timesheet preferences sent to the front end were always those of the default
company of the user.
- The timesheet related widgets initialisation process (adding the correct ones in
the fieldRegistry) was performed before the front end treatment of cids and coockies
which prevented applying the front end selected company settings.
After this PR:
- A dictionnary is used in the session in order to structure the companies info.
- The company timesheet preferences are sent to the front end through the company dict.
- The uom info is sent to the front end through the session.
- The timesheet uom is now managed from the frontend and is now in sync with the settings.
- Timesheet widgets are initialised during the AbstractWebClient init and are in sync with
the multicompany front end settings
task-2168337
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#66551
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit's primary objective is to ensure that the timesheet uom is working in accordance
with the company settings in a multi company environment.
Prior to this commit:
- The timesheet preferences sent to the front end were always those of the default
company of the user.
- The timesheet related widgets initialisation process (adding the correct ones in
the fieldRegistry) was performed before the front end treatment of cids and coockies
which prevented applying the front end selected company settings.
After this commit:
- A dictionnary is used in the session in order to structure the companies info.
- The company timesheet preferences are sent to the front end through the company dict.
- The uom info is sent to the front end through the session.
- The timesheet uom is now managed from the frontend and is now in sync with the settings.
- Timesheet widgets are initialised during the AbstractWebClient init and are in sync with
the multicompany front end settings
task-2168337
Closes: #66551
Before this commit:
- Some semicolon where missing
- There was a typo in the variable name
After this commit:
- The above problems are solved
task-2168337
Closes: #66551
The underscore (_) library has a bug in which the _.each method does not
work with object which contains a "length" property. This is because it
does look for that key and if it is a number, it will assume that it is
an array with that length value. Nicely done...
If that length value is set to 0, then it will just do nothing, since it
thinks that it is dealing with an empty array.
Note that if the value is set to an object, _.each is smart enough to
notice that it cannot be an array, and will do the correct thing in this
case.
Usually, our _.each calls are safe, since we usually iterate on arrays,
or on object with safe keys, or on object with values that cannot be a
number.
But there was 2 unsafe calls in basic_model, which leads to strange
bugs: some code is skipped, and the form view is then confused. The
motivation for this fix is the fact that onchanges are not applied at
all, if there is a length field set to 0.
To fix this, we can just avoid using _.each. Note to every Odoo JS
developers reading this: new Odoo code should avoid using the _ and $
libraries, because we do not really need them, and we want to keep our
dependencies to the strict mininum.
OPW: #2465808closesodoo/odoo#66126closesodoo/odoo#67172
X-original-commit: 8dbd1efef899fb637acca3c318ae99cb23838b8f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
* This feature will be useful when the user needs to "reschedule" an event.
It is more convenient to open the CalendarView around the original start date of the
event instead of "Today"
* Add a test to ensure that the context key is correctly passed to the view as the initialDate
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
Aaron Bohy