| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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 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>
|
|
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
|
|
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>
|
|
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>
|
|
Issue
- Install Sales
- In Sales > Configuration > Settings -> Enable "Sale Warnings"
- Go to Sales > Orders > Customers
- Pick a customer/company
- Go in Edit mode and go to "Internal Notes" tab
- Switch "Warning on the Sales Order" from "No Message" to "Warning" and add any warning message then save
- Press the "$ X Sales" smart button
- Create a new Quotation
- Validate the warning message
- Go back to the previous menu (using the breadcrumb) or save the quotation
- Create a new quotation
The quotation form editor does not appear.
Cause
If we use the breadcrumb (or save then create), it will call the `_reload` function
(instead of `load` when the form view hasn't been opened yet).
In this case, creating a new record, it will call `_makeDefaultRecord` without
setting `allowWarning` param to true (like it is done in the ref. commit bellow).
Solution
Set `allowWarning` param to true before calling `_makeDefaultRecord`.
related commit : https://github.com/odoo/odoo/commit/a41db9a2cf410bb233b021651a5633180eaddf18
opw-2374857
closes odoo/odoo#62534
X-original-commit: 5c8101102f999cfac6aec7658b98e376d4ed0596
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
|
|
Consider the following situation:
- have a form view with an x2many field displayed as a list
- the x2many field has a form view that contains an x2many field,
which isn't in the list
- for that x2many field, we can also open a form view to see/edit
the related records.
As the x2many field isn't in the list, when we open a subrecord, we
modify the fieldsInfo to add the information about the x2many field
we didn't know before. Doing so automatically applies raw changes
that we might have stored earlier (from onchanges) for that field,
because we couldn't apply them before knowing the type of that
field.
Before this commit, the function that applies the raw changes was
called recursively on the dataPoint and all its children (thus on
the x2many list datapoint), which produced a crash as this function
is designed to work on dataPoints of type record.
Actually, calling it on sub datapoints is useless, as it properly
works recursively, and applies raw changes on x2many fields itself
when necessary.
This commit ensures that we don't call this function on list
datapoints anymore.
Closes #62334
OPW 2389991
closes odoo/odoo#62399
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Commit e10fd34682a0c55568cba66eb271b3aa5bed7c1d introduced batched reference fields name_gets
across groups but was also buggy as follows:
Have a grouped list view showing at least 2 groups
Have a reference field with different values showed in the list for each record
Before this commit, the name_get of those reference fiels were fetched only for the last group
After this commit, the name_get are fetched in a batched fashion (by model) for each group
and display correctly
closes odoo/odoo#59903
X-original-commit: bbb608a1eff638040f0fc7b951fedf1579cc15b2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
An older commit (50bf8309) had refactor part of the basic field _applyX2ManyOperations.
During this refactor, the reference field was forgotten to be included
in a condition that made the field no longer do the quick create behavior.
The name_create function in the backend was no longer called.
Adds a test for the reference field checking the call to the name_create
function and fixes the problem.
Task id 2322048
closes odoo/odoo#59013
X-original-commit: e7d4baa3d52dc73c9631365801fbe41a4d54e3a1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Issue was spotted in list views containing the "badge" widget with
decorations (e.g. in the Purchase Order list view). At first, the
decorations were correctly applied, but they weren't anymore after
a reload (e.g. after toggling a filter).
They weren't because the list renderer didn't called
'on_attach_callback' on its subwidgets at reload (thus, 'mounted'
wasn't called on its subcomponents, and the decorations are applied
in the mounted hook).
This commit moves the logic from the FormRenderer to the
BasicRenderer, so that it applies on List, Kanban, and Form views.
This commit also removes the transition scss rule on the badge
field widget as it caused a flickering at reload.
Task 2336440
closes odoo/odoo#57762
X-original-commit: 713bce22e8f412f2c26e663b9e30fdd64933ff0c
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Let's assume a list that is multi editable and contains a m2m field
displayed with widget many2many_tags. Moreover, there are enough
values in the comodel s.t. the 'Search More' option is available
in the many2many_tags dropdown, and field 'display_name' isn't
in the list view that opens in dialog.
Enter multi-edition, edit the many2one field to add a value
(click on 'Search More', and pick a value from the list): the
picked value isn't correctly displayed in the confirmation dialog.
The issue occurred because we didn't wait for the display_name to
be fetched before opening the dialog.
Task : 2150384
closes odoo/odoo#57481
X-original-commit: ccf5834045d8b4fff9af7ddf60814c3a640e8318
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Dhruv Patel <dhp@odoo.com>
|
|
This issue only occurred in community.
Steps to produce:
1) Create/Edit any record.
2) Change the menu using menu switcher
3) You will get the discard dialog at the instance and after some
time it will also display another duplicate discard dialog.
So, we have one extra redundant discard dialog on menu switching.
It is working fine when we have dirty form and then click on the
breadcrumb or click on any internal child menu.
Task : 2312437
closes odoo/odoo#57343
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Have a kanban with a filter
Quick create a record in one column that won't match the domain
Before this commit, the noContent helper was displayed. This was because
the count of the group was reset to zero after the web_read_group call.
After this commit, the noContent helper is not displayed.
Note that in the quick_create situation, the records are not re-fetched
i.e. there is no search_read after the read_group.
Task-id 2251734
closes odoo/odoo#57066
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`. When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.
Tests (and the MockServer) have been adapted accordingly.
NOTE 1. If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save. This change in behavior
may prove problematic, although the overall risk is small. Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.
NOTE 2. Putting a context on a many2one field may change the value
returned by `name_get` for that field. By default, the calls to
`name_get` are done by `onchange`. If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field. In that case, every `onchange` that changes the value
will trigger an extra `name_get`.
NOTE 3. Suppose that a one2many field has a list view with field A, and
a form view without field A. When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A. The value will appear on the list view, but not
in the form view. The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.
NOTE 4. A test surprisingly adds an extra call to `read`. The test was
actually wrong before. With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored. As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't. But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.
Task 2261084
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Currently, only List and Kanban view supports the action helper and
display the folder icon with the helper text.
With this commit we have also provided the action helper support for
other views. The logic for no content helper has been moved in
abstract_renderer.js so that it can be accessed by all views. This was
done mainly to give the action helper to the gantt view.
closes odoo/odoo#53902
Task: 2284779
Related: odoo/enterprise#11563
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
This commit introduces a new semantics to define action and method buttons
in the list view.
The aim of this feature is to be able to do some actions on selected records, or on the entire
records' domain with the help of buttons located in the controlPanel, much like the form view header buttons.
To define such buttons, one must add a `header` node in the list view's xml definition
```
<tree>
<header>
<button type="action|object" name="actionId|methodName" string="button's text" context="{}"/>
</header>
<field name="fieldName" />
</tree>
```
task-2246383
|
|
This commit handles 2 things:
1) the merging of the `py_utils.context()` into the evaluation context
returned by `BasicModel._getEvalContext` to access the same time-related
keys,
2) the addition of 2 new keys into the `py_utils.context` (thus
transmitted to the basic model): `today` (an alias for the already
present `current_date`) and `now` which represents the current date and
time value.
Task 2269697
|
|
There are orm models that don't have _rec_name defined. The orm doesn't
allow creation of record via name_create if _rec_name is not defined in
the model. This commit considers this fact, such that if name_create
returns false, we don't proceed on displaying the non-existing record.
Note: _rec_name defaults to 'name' if not specified so only few models
don't have _rec_name.
closes odoo/odoo#54270
Task-id: 2285036
X-original-commit: 676c2b8e4fdf7347d44bc5afb7ca51d39338a527
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
The on_attach_callback methods on the widgets (comming from a tag
'widget') of a form renderer were not called at an appropriate time.
They were not called at all or called before the widgets were actually
in the dom. This was made manifest in the dashboards that generally use
pie charts widgets. Each time a pie chart widget is renderered,
a new canvas with a unique id is created. The above mentioned problem
explains why Chart.js was not able to acquire the canvas contexts: they
are obtained by looking for a specific id in the dom.
The present commit fixes that problem by doing in the class FormRenderer
what was already done correctly in the child class DashboardRenderer and
remove the unapropriate calls to on_attach_callback in _renderWidget.
Task ID: 2278717
closes odoo/odoo#53853
X-original-commit: 7641c7074616b4375f1eb4f1fcb5a96e2ed39f94
Related: odoo/enterprise#11537
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Currently, when kanban card drag and drop, it call onchange method
when onchange fails due to python error raised, e.g. UserError, kanban
view is not reloaded and kanban card stays in dropped column while
kanban card should come back to column from where it is dragged i.e.
kanban view should reload if onchange fails.
After this commit, if onchange trigerred from kanban drag and drop fails
then kanban view will get reloaded and card will come back to column
from where it is dragged.
note: in not stable version, forceFail option will not be added and
promise will fail in all cases but it is not done in stable for safety.
task-2267444
closes odoo/odoo#53695
X-original-commit: 27257d34c8b7374bfd8037de71f175f4ecb2913e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
On a re-render, when:
- a field is not yet started (still in willStart because of RPC)
- then an action is executed
we can get a traceback because we try to save the field before it is
started and `this.el` is not set.
eg. in MRP on a work order:
- click on + to get new serial number
=> page is re-rendered with RPC call to update duration to
mrp.workcenter.productivity().search_read to update time
counter
- click on "Record production" before RPC is finished
=> traceback because we try to save `duration` that is not already
started (`this.$el.toggleClass` when `this.$el` is `undefined`)
Without change, added test fails with:
"Cannot read property 'toggleClass' of undefined"
in BasicRenderer.canBeSaved
"Expected 6 assertions, but 5 were run"
Before saas-11.3 5faec34a3c this.el was always set in `init` so this
issue did not happen.
opw-2272117
closes #53532
closes odoo/odoo#53612
X-original-commit: befcad51fd236fdaf284f76cea5624d21c070b0e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Previous commit introduces the sample data feature in list and
kanban views. When sample data is displayed, most parts of the
renderers can't be clicked on, to prevent the user from interacting
with sample records (e.g. to open a sample record in form view from
the list). This commit disables keyboard navigation as well, as
those sample records could still be accessed with the keyboard.
To do so, several refactorings have been done in views:
- _giveFocus function added on controllers (so that we can hook
on the moment where we want to focus the renderer, and prevent
it in sample mode), it kind of replaces giveFocus of ActionMixin
which wasn't use from the outside
- updateRendererState -> _updateRendererState as it is private
- _setState function added on controllers, to have a hook when we
set a new state (already existed, but only in kanban)
- _renderView function moved from Basic to AbstractRenderer, so
that we have a proper hook to deactivate clickable elements in
sample mode
Task 2232801
X-original-commit: 4482a03fe2f083f4f44fc6eb76d90ae22afbff91
|
|
With this commit, it is now possible to display sample (fake)
data in empty views, in the hope of easing user onboarding.
This can be enabled (in list and kanban views) with attribute
sample="1" on the arch root element. In this case, if there is
no data to display, sample data will be generated based on
heuristics (depending on field types and names). This can be
used in addition to the no content helper.
Task 2232801
X-original-commit: 7c8e627ff5029cb539d702705e5ce53d658c76ed
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Jérémy Hennecart <jeh@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closes odoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
|
|
closes odoo/odoo#52826
Related: odoo/enterprise#11084
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
PURPOSE
The purpose of this task is to improve the interface by removing the
fa-building icon which is automatically appended by the property field
(i.e. company-dependent) and, instead, indicates that a field has
company-specific values in the tooltip of the field.
closes odoo/odoo#52313
Taskid: 2266519
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, the options of the tooltip where set inline.
After this commit, the options are returned by a function.
This allow us to adapt these options in another module.
Task ID: 2152124
closes odoo/odoo#52170
Related: odoo/enterprise#10864
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
When a resequencing is done inside an object hierarchy of two
controllers, since 9b90d8727d we would call resquencing code one time
per controller.
So if for example we are in a list view inside a form view (eg. a
"Search More" modal in a form view) the resequencing would work for the
list view, but then cause traceback when it is handled by form view.
With this changeset, the first controller that get the event
`resequence_records` even gobbles it up.
Without change, added test fails because of original traceback:
Cannot read property 'res_id' of undefined@ 202 ms
Source:
TypeError: Cannot read property 'res_id' of undefined
at /web/static/src/js/views/basic/basic_controller.js:744:67
...
opw-2256818
closes #51827
closes odoo/odoo#52018
X-original-commit: eef4b99fdb9469c040af80d055933eda367b7b3d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
... when there is no data and user clicks anywhere in the no content
helper.
Task 2239617
Co-authored-by: Jinal Patel <jip@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
* A step has been added to the sale tour in order to ask the user
to update the company data. As a page reload breaks the tour test
we need to prevent it in such situation.
TaskID :2187222
closes odoo/odoo#46167
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
This commit refactors the way the decoration-xxx attributes are
applied to field widgets/components, in a way that it can be
overridden in a given field or component to generate the approriate
className. By default, 'decoration-x' applies className 'text-x'.
This will be necessary for the new 'FieldBadge' component, which
needs to apply 'bg-x' classNames instead of 'text-x'.
Part of task 2195254
|
|
Before this commit, when a list contained owl field components,
the mounted hook was called twice on those components. This may
cause tricky issues like handlers being bound twice, and memory
leaks.
closes odoo/odoo#50127
X-original-commit: 206dd91e78f7896fc6b01020507657e61771787f
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
There's a traceback when we edit an activity on a campaign
* Create a child activity
* Save the activity (not the campaign)
* Edit again the activity
* -> Traceback
Introduced in a9cebd5
Task ID 2220930
closes odoo/odoo#49698
X-original-commit: efa8952c39b0bcb0969013dc22e05b5d61ff1c66
Related: odoo/enterprise#9964
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
before this commit: from commit: https://github.com/odoo/odoo/commit/d58d6e270f4106d717821438490f60bc4f71306e parent context
was propagated to sub views, propagating whole context to sub view creates
issue as it contains default_* key inside it, there is a chance that sub view
has same field name which matches with default_fieldName in context,
e.g. go to sale order form view and create sale order line, while selecting
product, write in product_id field so that Create and Edit option comes,
select Create and Edit option, so whatever previously written in product_id
field will be added in product.product form's context as default_name,
now go to Purchase tab of product form and try to create Supplier, but note
that Vendors One2many should be editable, if it is not then to produce this
issue, make Vendor o2m list editable top/bottom, as soon as you click on
Vendor o2m's create button traceback generated which comes from name_get of
res.partner, issue raised because vendor o2m has m2o of res.partner and field
name is 'name', when default_get for vendor o2m is called it will propagate context
and context has default_name='typed string in product_id', as name field is
m2o with res.partner it will generate traceback as m2o accepts (id, name) tuple
not string
after this commit: propagate context to sub view but remove default_* keys
from parent context
task-2121161
closes odoo/odoo#49075
X-original-commit: 2e3756e0ce96a9e0c5fa304632a2600cbd832ef5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
* account
This commit adds a new field registry for component fields.
This field registry is used to only register the new field components
and the other one should register the legacy fields.
Those two registries will be used together while all legacy fields are
not converted to owl component.
As the legacy registry now throws an error when adding a component
field the existing component fields (account.ShowGroupedList and
account.ShowResequenceRenderer) are moved into the new registry.
This commit also refactors some field managers (form renderer, list
editable renderer, calendar popover) to use the new registry and thus
support the component fields.
task id: 2193996
|
|
Following the new selection feature in list views, this commit
adapts the delete action.
Part of task 2185145
|
|
Following the new selection feature in list views, this commit
adapts the archive and unarchive actions.
Part of task 2185145
|
|
|
|
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).
closes odoo/odoo#48116
Signed-off-by: Géry Debongnie (ged) <ged@openerp.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
closes odoo/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>
|
|
Some web actions/controllers/viewsl have been adapted to properly instantiate the
newly refactored control panel and update it accordingly. We needed to adapt the
starting mechanism of actions and controllers to ensure that the control panel
instantiation did not delay the loading of any widget.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@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
closes odoo/odoo#47491
X-original-commit: 17d53cea1043054dfa9c39b16b430539c4082a9d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.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.
closes odoo/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.
closes odoo/odoo#47171
X-original-commit: af411b866aa2052c01168342f8f05ae3dabad83e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
