| 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
* 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>
|
|
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>
|
|
Following the new selection feature in list views, this commit
adapts the archive and unarchive actions.
Part of task 2185145
|
|
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>
|
|
* modify client-side domain normalisation to error if the domain is
invalid (not enough terms / segments for the number of operators)
* add better error reporting to attrs / modifiers parsing
* add a few layered error augmentation to provide clearer context
e.g. "error: invalid domain <thing>" is helpful but "error while
parsing modifiers for field foo: modifier invisible: invalid domain
<thing>" is much more helpful
* rework _evalModifiers to deduplicate it in order to more easily
implement this contextual augmentation
* test that improper domains are properly found improper
* fix a bunch of incorrect attrs domains
* also removed an apparently undefined (& unused) "options" argument
to a _applyModifiers call
closes odoo/odoo#44642
Related: odoo/enterprise#8175
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
Purpose
=======
At the second res.company creation, the multicompany mode is 'enabled'.
But to get the company selector dropdown, the user needs to reload the page.
Specification
=============
Force a reload at res.company creation, similarly to the forced reload when updating the language (lang) of the user.
closes odoo/odoo#44386
Taskid: 2127257
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Issue
- Install Employees & Studio
- Configuration > Check Skills Management
- Go on an employee form
- Remove all data in Experience, Education & Skills
- Open Studio
- Click in the blank space before Skills
- Edit Form View
Traceback
Cause
The ORM tries to get the parent fields because the generated
datapoint includes them. (45bc7c9)
Normally the parent model is the same than the child model
but not in studio.
Solution
Merging the fields in the datapoint only if the models are the same.
OPW-2125214
closes odoo/odoo#43695
X-original-commit: d2dbc4faaad0988d71f591be7f50c94d455541b0
Related: odoo/enterprise#7849
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
|
|
*sale,sale_product_configurator
Let's assume a form view containing a many2one with an onchange
that updates the value of a one2many. Do a quick create in the
many2one. While the name_create request is pending, add a row to
the one2many but do not leave it. When the name_create returns, and
the onchange has been performed, the one2many is reset, and the row
is no longer in edition (worse, it could be invalid, i.e. in a state
that the user could not have reached in a normal situation).
This commit fixes this issue by considering the whole [name_create +
onchange] operation as one. This operation is executed in the mutex
of the model, so the other request (adding a row to the one2many) is
delayed until the many2one value has been correctly set.
This fixes an issue with the sale and rental tours (on sale_order),
that had been deactivated for a while.
|
|
Before this change, fields.Reference displayed into the popover of
a calendar view was always empty. This was because the popover view
generated from a double click on an element in the calendar view
creates its own recordModel in JS and the function to create this
record did not handle the reference field case.
This commit detects if a reference field is defined into the record
and adds the necessary processing to process its value and creates
the corresponding dataPoint.
opw 2151635
Closes #41262
closes odoo/odoo#42707
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
|
|
Steps to reproduce:
1. Go to the Accounting / Invoicing apps
2. Open Taxes (Configuration -> Accounting / Invoicing -> Taxes)
3. Try to create a new tax and the client crash.
It occurs because the `_processX2ManyCommands()` method doesn't handle
correctly a missing `fieldInfo` on some X2Many tags.
On mobile, when calling `load_views` the kanban view is used by default.
But if the kanban isn't defined, a default kanban view with only the id
of the model is used.
In the case of the taxes form, the `default_get` retrieved for this
form refers to a Many2Many (`tag_ids`) inside a One2Many. But this field
isn't present inside the loaded kanban view, so when we process the
command defined by the `default_get`, the `field_view` item doesn't
exist (because the default kanban loaded only contains the id of the
field).
Now instead of using an undefined `fieldInfo`, we fall back to an empty
object on the missing field to avoid the crash.
closes odoo/odoo#40617
X-original-commit: 47a306a31ac6d3c9e68e83b77a80426d5c6ceb05
Signed-off-by: res-odoo <res-odoo@users.noreply.github.com>
|
|
Before this commit, m2m fields were not updated when multi editing
in a grouped list.
Now, the fields are updated no matter how many levels of groupBys
are applied to the list.
Part of task 2078807
closes odoo/odoo#37589
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Go to Accounting > Accounting > General ledger. The view is grouped
by account. There is a layout issue as the first column (date) is
positionned after the group names, leaving a large blank space.
This is because the date field is considered as an aggregated field
(for sorting purpose, in python), but the JS can't (and we don't
want to) display it. This rev. ensures that such field types are
completely ignored by the JS, s.t. they do not impact the layout.
closes odoo/odoo#37113
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
For the moment, when we click on (un)archive and if the toggle_active
retrieve an action to execute, the page isn't reloaded at the end.
id=2072891
closes odoo/odoo#37027
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
closes odoo/odoo#36721
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Before this commit if `display_name` was in the view, the breadcrumb when
creating a new record, the breadcrumb would display either `Unnamed`,
either the last value of `_title` in `action_mixin`.
The default value when creating a record should be `New`, but the return
was ignored because `display_name` was found in the view
closes odoo/odoo#36565
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
closes odoo/odoo#36491
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Let's assume an editable grouped list view with a <groupby>
node containing subfields, and an onchange. Edit a row to trigger
the onchange. Before this rev., it crashed because the onchange
specs was incorrect: it followed the relation of the many2one
and thus included its subfields (whereas it should only follow the
relation for x2many fields).
For example, go to Accounting > Accounting > Sales and edit the
label of a move line.
Task 2044187
closes odoo/odoo#36001
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
|
|
|
|
has a country
- Change the company's country to Finland;
- Go to Contacts and click on Create;
- Tick the Company box above the Name field;
- Start typing into the Name field;
- Click on a company with a VAT number under its name.
Before this commit, a Traceback appears. This occurs because the
response of the request with the suggested company has the fields
'company_name' and 'company_code' and these fields are not in
res_partner.
Now, the suggested company is parsed to correctly field the country
field.
opw-2049636
closes odoo/odoo#35631
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
|
|
Before this commit, a simple optimization was done: if a field was
modified in such a way that the new value is the same as the initial
value, then it is not considered changed.
However, with the new changes in the ORM, it may be an issue, because
doing so loses the intent of the user. If an onchange changes a field,
then the user changes it back, the server is not aware of that fact.
With this commit, we simply keep the field in the list of changes to
send to the server.
opw #2057230
closes odoo/odoo#35890
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
|
|
|
|
|
|
|
