| Age | Commit message (Collapse) | Author |
|---|
|
closes odoo/odoo#70936
Taskid: 2412172
Related: odoo/enterprise#18366
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Infinite number of records cannot be exported, so after some limit we will get a
timeout error. If you need to export more records than that limit, you should be
able to filter records into batches. The easiest way to do it is making a
filter by ID:
```
[Y| ID Greater than 100000] [Y| ID less than or equal to 200000]
```
---
opw-2517946
closes odoo/odoo#71345
X-original-commit: 2e0127af0d283d1d9bdb033de356e2ddf0973cce
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
|
|
This is a forward-port of commit https://github.com/odoo/odoo/commit/970387f91fea0cb47404612f7d519ffba2c9ad3b
In editable list view, moving to next cell using TAB key crash when the
following field is becoming read-only (i.e non-focusable) and an onchange()
event is triggered.
Consider an editable tree view like this:
<form>
<field name="o2m" onchange="1">
<tree>
<field name="description"/>
<field name="date" attrs="{'readonly': [('description', '!=', False)]}"/>
<field name="type"/>
</tree>
</field>
</form>
1. Edit 'description'
2. Issue a TAB keypress before 'date' becomes read-only
It will crash while calling getSelectionRange() on an empty element.
opw-2523630
closes odoo/odoo#71122
X-original-commit: bd6ba50e073ffff0bd51b1a02d51260f09e36357
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
|
|
with this commit we disables autofill of autocomplete by setting
autocomplete=off, this was previously done in commit: 64293fbdb0a247f689c1b0b0c580d9ce577af510
but it was not working because we were setting autocomplete=none
it seems that none does not work all the time.
task-2462676
closes odoo/odoo#68271
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, evaluating a domain containing a like/ilike
operator with an evaluation context in which the value was false
crashed.
Moreover, those operators were wrong w.r.t. the case sensitivity:
like was case insensitive, whereas ilike was case sensitive, and
both =like and =ilike were case insensitive.
This commit fixes thoses issues.
The first issue was spotted on our prod, as we tried to add an
invisible attrs in a form view, using the ilike operator (it thus
crashed in create mode).
The second issue was spotted while writting the test cases.
To the best of our knowledge, those operators aren't used in attrs
(for now), explaining why those issues haven't been found before.
closes odoo/odoo#70876
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
In eg. 13.0 when refreshing sales analysis action of a product, we would
get an error because we have a single active_ids which is not expected
by the code.
With this commit, we use .toString() on the jQuery BBQ parsed active_ids
as it was done before 32b8cec5 refactoring (january 2018).
The added test with the fix fails with an error:
TypeError: state.active_ids.split is not a function
at Class.loadState (/web/static/src/js/chrome/action_manager_act_window.js)
opw-2471982
closes odoo/odoo#70279
X-original-commit: bf9a985f4b62cc6f1eef4f9fcca2a8dfbd453004
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: pvh-odoo <SwagSamaSempai@users.noreply.github.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
|
|
The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.
closes odoo/odoo#70008
X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, `getTZOffset` and `user_has_group` weren't
correctly reset to their initial values after tests. As a
consequence tests executed afterwards might behave unexpectedly.
closes odoo/odoo#69485
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Commit [1] recently fixed an issue with nested x2many fields and
onchanges: in some cases, all field values weren't sent to the
server as they should.
However, there is a small issue with this fix. We didn't correctly
apply the default value to option `changesOnly`: when not given,
it was considered false, whereas in this particular function it
should have been true.
It caused an issue in the following scenario:
Have a form view with an x2many field (say A) displayed as a list.
In the list, there is another x2many field (say B), and (whatever
its type) a field C with an onchange. When the user changes C, the
onchange is performed, and we send to the server the value of all
fields. In particular, in the row, we send the value for the
many2one field pointing to the main record (the inverse field of
the x2many relation). The value for that field is basically the
whole record, containing itself field A. For field A, the value is
a list of commands, and for the updated record, it is a command 1.
Before this commit, in the values sent for this command, field B
was the empty array, even if it wasn't empty.
This issue was reproducible in account.move, on an existing record
having already a line in invoice_line_ids (this is field A). In
that line, tax_ids (this is field B) must have a tax which is
included in the price. When changing the quantity of the product,
the subtotal wasn't correctly computed.
[1] https://github.com/odoo/odoo/commit/a8b43d02066b2299ac2f4b88056c37725e9ce6cd
opw~2489755
closes odoo/odoo#69167
Signed-off-by: Lucas Perais (lpe) <lpe@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
closes odoo/odoo#68294
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>
|
|
- 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
closes odoo/odoo#67543
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
closes odoo/odoo#67320
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@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
closes odoo/odoo#67767
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
|
|
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
closes odoo/odoo#67865
X-original-commit: ff19ee8d8b39a719a09dd9f6060faa3afa474da3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.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
closes odoo/odoo#67679
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
|
|
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
closes odoo/odoo#67358
Signed-off-by: Lucas Perais (lpe) <lpe@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
closes odoo/odoo#67373
X-original-commit: fa324ef071952d749f635f878bee0fa462cfa011
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: be5e5bc49cb9744c26ca75dcee74caf11447f250
|
|
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.
closes odoo/odoo#67228
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
The color_picker widget, that can be seen for example in the track form
view for event tracks, had an issue: if the user clicked on it, then
pressed TAB, a traceback was displayed.
The problem comes from the fact that the color picker widget inherits
from FieldInput, but is not a fieldinput, so many expectations made by
the FieldInput code do not hold, such as the code run when handling
navigation (by TAB and such keypress). Because of that, the code in
_onNavigationMove crashed, because it expected an input.
Since this is a bug fix, I simply disabled the navigation in that case,
so no crash happens. Sadly, this widget has still a big issue: it
clearly does not work as most users would expect: pressing TAB or arrows
should update the selection. But this would be a more complicated
refactoring, for a bug which is clearly not critical, therefore this
commit implements the simple and safe solution.
Also, we disable the focus outline to minimize the wrong expectation.
Seeing them kind of implied that one could update the selection with the
keyboard.
Note that the widget color_picker was moved from another addon to web/, without
any tests nor documentation.
OPW 2467369
closes odoo/odoo#67174
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
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: #2465808
closes odoo/odoo#66126
closes odoo/odoo#67138
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Let's assume the following scenario:
- have an action in target new (e.g. a form view)
- in the dialog, have an action/object button with confirm
attribute
- when clicking on that button, a confirm dialog opens
- if validated, the following action returned by the server
is again an action in target new
Before this commit, the confirm dialog remained in the DOM.
This issue occurred because it's parent wasn't correctly set (wrong
use of `this`), so when the first dialog was destroyed, the confirm
dialog wasn't automatically destroyed in turn.
OPW~2440712
closes odoo/odoo#66345
X-original-commit: 2016fe31af970976775c9df160a31abfbec742ba
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
|
|
before this commit: when there is only one page in the notebook tag and
there is a boolean field in form to show/hide that notebook page based on
invisibility attrs, if we toggle boolean field notebook hides, that's OK
but when we toggle boolean field again then notebook page is displayed but
it is not active and due to that content of notebook page is not displayed.
after this commit: when there is only one page in notebook and it has attrs
for invisibilty, when we toggle boolean field to hide/show notebook page
then notebook page as well as content is toggled.
task-2449053
closes odoo/odoo#66338
X-original-commit: a0b5ecd344d6ac79d8e4d194cfabf3d639259c73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, the 'mounted' method of the ControlPanel in
the client report action was called twice.
It happened because the client report action updated the ControlPanel
before being actually mounted, so mounted was called once when the
traceability report was mounted, and once when the update was applied.
Ideally, this should not be an issue (this isn't an issue with owl).
However, in Odoo, we mix layers of Owl Components and legacy
widgets. In these situations, the above scenario isn't properly
handled (and can't be).
As a consequence, in mobile (enterprise), it crashed because an
handler bound in mounted (thus twice) was only unbound once.
This commit avoids the issue as the update was actually useless.
Steps to reproduces (Mobile):
* Go to Inventory (Stock)
* Open the "burger menu"
* Select "Products" -> "Products"
* Select one product in the list
* Click on the "Forecasted" ("stat button")
* Select one "SO line" (sale order) to go to the form view
* Go back to the previous view using breadcrumb
* Optional: Go to another app if the screen can't scroll (e.g. go to Sales)
* Scroll the view => Bug
closes odoo/odoo#65522
Related: odoo/enterprise#16033
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Before this commit, in sample mode, cover images might be displayed
in kanban views. It isn't what we want as those images are real
images from the database, not sample ones, but randomly linked to
the sample records (the id of many2one fields is randomly generated).
This commit tweaks the SampleServer to always set many2one fields
pointing to model 'ir.attachment' to false.
task-2368505
closes odoo/odoo#66350
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
The support for "active_test" context key has been introduced in c2918c1
However, the context key is ignored in many mocked ORM methods (if not all).
This commit adds support for the `search` and `search_read` methods.
Note: this is done to easily write some tests in odoo/enterprise#16363
and it might be usefull to test futures features (or fixes) using this
context key.
closes odoo/odoo#66190
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
In a list view that allows the multi edition, select several
records, edit a field, and 'click' on Discard. In the confirm
dialog, click on 'Cancel'. The row is still in edition and the
changes are still there. However, before this commit, clicking
on 'Save' did nothing.
The reason is that the 'Save' button is fake. Typically, clicking
on it triggers a 'field_changed' event, thus saving the selected
records. In this above scenario, the changes have already been
notified, so nothing happens when the user clicks on 'Save'.
This commit fixes the issue by storing the last 'field_changed'
event, and re-triggering it when necessary. This isn't the cleaner
way to handle that scenario, but it is the simpler, so we go for
it in stable. In master, it would be nice to rework the multi
edition feature with this scenario in mind.
task-2376233
closes odoo/odoo#66045
X-original-commit: 18ed619baeda06f071779da00177beee01f8a896
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Let's assume a <groupby> node in a list view containing a button
with an invisible modifier referencing a many2one field, e.g.
```
<tree>
<groupby>
<field name="m2o" invisible="1"/>
<button string="do it" attrs="{'invisible': [('m2o', '=',
False)]}"/>
</groupby>
</tree>
```
Before this commit, the m2o field was correctly read, but it's
value wasn't processed by the model, so the modifier wasn't
correctly evaluated.
Issue reported on PR https://github.com/odoo/odoo/pull/65316/
closes odoo/odoo#66287
X-original-commit: bbaeeb76bbef4ea371d3db5821af91bf1fe9ac4f
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
References
Have grouped list with reference a m2o or a reference field
Select some records, edit them
Before this commit: the names of the reference fields and m2o disappeared
That was because the saveRecords function did not take into account a grouped list
manual forward port of #65999
After this commit: it works as expected
closes odoo/odoo#66043
closes odoo/odoo#66140
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
Have a list with multi_edit enabled
Have a widget boolean_toggle displayed on some field
Select some records to be in multi edit mode
Before this commit, the record on which the boolean toggle button was clicked was written
and then the multi edit feature was triggered and wrote on all the records
The first write is unnecessary and counter intuitive
After this commit, only the write with all the multi edited records is done
|
|
follows #59830
|
|
Before this commit, select the "No" option of a boolean field in the
search bar autocompletion menu would crash.
closes odoo/odoo#65896
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, occurences of 'null', 'true' and 'false'
strings as autocomplete values in the search view were replaced
respectively by None, True and False.
Fixes #65743
closes odoo/odoo#65900
X-original-commit: 74311c753e7286c27b83dca2b598e040ed9e586f
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, the form renderer would call "on_attach_callback"
only when the whole _render process was over. The problem was that this
process is asynchronous and this callback should be invoked as soon as
the widgets are appended.
As such, any asynchronous operation is performed before appending the
content in a new function "__renderView".
Task 2346540
closes odoo/odoo#60791
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, calling do_hide/do_show/do_toggle on a
widget that had been destroyed before being rendered crashed
(because this.$el was undefined).
Obviously, calling those methods in this situation is useless, but
with asynchronous code, it might happen that you call them in an
handler, and they have been destroyed meanwhile.
This commit checks if this.$el is set before accessing it to avoid
the crash.
closes odoo/odoo#65889
X-original-commit: 320c29f5b37d4f02b4d5f7b1b6ff64462b000c92
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
This commit update owl from 1.2.3 to 1.2.4, and
introduces a few fixes for code that was broken (because it accesses
private owl values)
Note the fix for the test menu code is interesting. Before this commit,
the handler for the click on the home menu component was not called, so
the click had a side effect: it modified the url to its href, which
caused the action manager to load the next application, even though the
home menu was not mounted.
With the update to Owl, this is no longer true: the handler is called,
and call preventDefault on the event. Because of that, the url is not
changed. However, since the home menu is itself not mounted, it cannot
communicate to the web client that we should load the next app. This is
why it was broken. The fix is simple: we actually make sure that the
home menu is displayed before clicking on the app menuitem.
closes odoo/odoo#65886
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Steps:
- Install mrp
- Go to Manufacturing > Master Data > Bills of Materials
- Create a BoM
- Components:
- Add a component
- Save
- Click the component
- Close the modal window
- Click the component once more
Bug:
Traceback here:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L147
Error: can't convert undefined to object
Explanation:
As seen on the line just above:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L146
`fieldsInfo` might not have the view we are looking for.
opw:2452142
closes odoo/odoo#65805
X-original-commit: b27c0698d95cbccaa6c35a1fd3faa852a71ac2c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
|
|
This commit partially reverts commit [1], and backports commit
[2] from 14.0.
Even though [1] correctly fixes the faulty scenario, there is a
variation of this scenario which isn't handled. It has been
fixed in 14.0 by [2], and that fix also fixes the original
issue of [1]. So we keep the tests of both [1] and [2], and
the fix of [2].
[1] dd97d446ee94a32089f200bb7122139d31e69873
[2] f6c06bd0b87dac11d76a3134eb61c7ef4eb59270
closes odoo/odoo#65562
X-original-commit: 63c60549ef5185f5ec61dc985f0bcc2cb82ccc89
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Issue
- Install "Field Service" app
- Create new task
- Try to select Planned start/end date and valid
Daterange picker is hiding when trying to scroll down to valid selection.
Cause
The daterange picker is closed when ev.target is not inside the picker,
however ev.target always return the document element.
Solution
Do not hide daterange picker on scrolling if on mobile.
Note : It will only apply if scrolling on the daterange picker and
will still hide if scrolling outside this last one.
opw-2428099
closes odoo/odoo#65423
X-original-commit: fb01006342c6d6fd902e13a5f4c2642c87fe452d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Steps to reproduce:
1. Go to Project App
2. Open and edit a task
3. Click on Customer => search more
5. Click on "Filters"
6. Click on "Group by"
=> The "Filters" and "Group by" dropdown are open at same time => bug
Since odoo/odoo@e4f87710e16357f24f388159a7b1e82eccda598a, we added a way
to prevent bs and owl dropdown to be open in the same time.
But when the web-editor is present, the CSS selector used to match the
opened modal ("search more" in this case) conflicts with the DOM created
by the web-editor (modals identified by the classes: .web-editor,
.note-picture-dialog, .note-link-dialog, .note-help-dialog).
To avoid this conflict, this commit uses a more restrictive CSS selector
to match only the first (active) opened modal (as web-editor doesn't
attach its modals at the root of the body).
closes odoo/odoo#65274
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
|
|
What are the steps to reproduce your issue ?
1. Install project
2. Open any project
3. Switch to list view and display by Stage
4. Open categoryA and select some records
5. Open CategoryB
What is currently happening ?
The button create is not displayed
What are you expecting to happen ?
Don't hide create button
opw-2423701
closes odoo/odoo#64136
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Let's assume the following situation: in a form view, there is a
one2many field A displayed as a list (non editable). In the list,
there is another one2many field B displayed with no widget (it
basically displays "X records"). In A's form view, B is also
displayed, but this time as a list.
There is an onchange on the main form view that adds a line in A,
(and simply sets B to [[5]], i.e. 'No record').
Before this commit, if the user opened the newly added sub record in
A, and clicked on 'Add a line' of B, it crashed.
The cause of the crash was that the wrong viewType was used to
create the new (default) record in B: it used the original
viewType, which was undefined (B is displayed with no widget in
A's list). With this commit, we use the viewType of B that is used
to edit it, in this case 'list'.
In the slighlty different scenario where B is displayed with
widget many2many_tags in A's list, there were no crash, but wrong
fieldNames were sent to the 'default_get' RPC. As a consequence,
default values for fields in B's list were potentially not loaded.
opw-2422806
closes #64793
closes odoo/odoo#65157
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Following https://github.com/odoo/odoo/commit/d675dbaa4c7174591e0e7c1a3caf3e76877312ce
Also updated tests to be more consistant.
Regex used to find problematic lines:
`\btype\b.*\b(out|in)_(invoice|refund)\b`
closes odoo/odoo#64915
Related: odoo/enterprise#15908
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
|
|
Before this commit, the `on_attach_callback` and `on_detach_callback`
callbacks are not called all the time on the `Dialog` widget when it's
attached/detached to the DOM. Relying on those callbacks could result in
unpredictable behaviours.
To be more precise, the `on_attach_callback` isn't executed on a regular
Dialog#open() call. But Dialog spawned by the ActionManager will execute
it.
This difference prevents from properly binding those callbacks later on
through an extend or include of the Dialog widget as we have no way to
know if they have already been called or not (e.g. which can result in
calling them twice).
This commit normalize this situation by ensuring that the
`on_attach_callback` and `on_detach_callback` callbacks are properly
called by the Dialog widget and allows any extension of this widget to
rely on them. Therefore the ActionManager is adapted accordingly.
opw-2438534
closes odoo/odoo#64780
Related: odoo/enterprise#15849
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closes odoo/odoo#64552
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Impacted versions :
- 14.0 and higher
Steps to reproduce :
```
1. generate an odoo.exceptions.RedirectWarning
2. click on the primary button
```
Current behavior :
```
1. the action (argument of the RedirectWarning) is properly executed
2. the WarningDialog is not closed
```
Expected behavior :
```
1. the action should still be properly executed
2. the WarningDialog should be closed
```
Tests :
Added a test to ensure this behavior will not be overwritten in the future.
The test is for the CrashManager service, and evaluates the following sequence :
```
Entry: CrashManager receives a odoo.exceptions.RedirectWarning (code 200) via rpc_error
Asserts:
- The RedirectWarning modal (WarningDialog) should be opened
* Upon clicking on the primary button :
- The modal should be closed
- The action passed as an argument of the odoo.exceptions.RedirectWarning should be executed
```
Origin :
the incorrect behavior was introduced with :
https://github.com/odoo/odoo/commit/b3d9647695065ea582e4a6b0603f3ebf9fde6976
Task ID: 2430100
closes odoo/odoo#64290
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Follow-up of odoo/odoo@598d036b59012af0a95894d759fe3b6276fc8ccb
closes odoo/odoo#64046
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Disabled in odoo/odoo@b992619840a70c600c50fac0383ad9396351af75
by mistake.
Also, restore the "failfast" for the QUnit tests (disabled in the same
commit...).
|
|
Since commit [1], it is no longer possible to unselect a row in a
one2many editable list if there is an html field in the form view.
The reason is that there is a '.modal' element (several actually)
in the DOM of the html field. This element is considered as an
opened dialog by the list renderer, which is wrong. This commit
refines the selector that determines whether there is an opened
dialog or not.
[1] 7d04ec7cca4f355295a06c1ce6f112b6cc533c87
closes odoo/odoo#64127
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Before this commit, in editable list views with a many2one, when
the user clicked inside the many2one dropdown, in the padding above
the first item or below the last item, the dropdown closed itself
and the row was removed (if it wasn't dirty yet). This commit fixes
that issue by ignoring clicks at those specific spots.
Task 2377864
closes odoo/odoo#63993
X-original-commit: dd40745dfdc98e82142e64ca58c0c976f6ad8d97
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
