| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
A `default_get` for a x2many field can return a new list of commands for one of
its x2many field, like
[[0, 0, {
'groups_id': [[6, 0, [1, 2, 3]]],
}]]
where [1, 2, 3] is a list of existing ids.
This use case was not correctly handled by the BasicModel because
`_makeDefaultRecord` was not recursive.
Closes #22401
|
|
In a grouped Kanban view, when the user clicks on 'Load More' to
load more records of a given column, then opens one of those
records in the form view, and goes back using the breadcrumbs, the
formerly loaded records should be reloaded, so that the user does
not have to click again on 'Load More' to get to the position he
was previously.
This rev. increases the limit of the given column when the user
clicks on 'Load More' to force this behavior.
|
|
|
|
|
|
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
|
|
When creating a record with many default values, it could happen that
the number of ids returned by the default get (or onchange) exceeds the
limit for the form view.
For example, we can see the issue in the expenses list view. We can
increase the limit in the pager, to a value higher than 40. Then,
clicking on select all, then on 'Submit to manager' in the action menu
will result in a traceback.
The Submit to manager action will trigger a new action with a context key
'active_ids' with a large number of ids. After that, the web client
will execute the server actions, which will return a new action with a
context key 'default_expense_line_ids' with a bunch of ids. Then, it
will attempt to create a form view. This will call the
makeDefaultRecord method in the basic model. This method will generate
the commands for the one2many, for all ids, but will only load the 40
first sub records. After, it will attempt to apply the onchanges, with
some code that assumes that all operations of type 'ADD' correspond to a
local datapoint.
In this commit, we fix the code to properly work with operations of type
ADD with a res_id, but with no id. In that case, we simply generate a
command 'LINK_TO', since the value has not been changed.
opw 804370
|
|
When fetching x2manys in a x2many, the basic model did not properly sort
the internal data structure before fetching the data. This is usually
not an issue, except when we have an order which is different from the
order of the res_ids. In that case, it can cause crash in some
conditions, because the results from the fetchx2manybatched were applied
to the wrong datapoint.
To reproduce this issue, some specific conditions needs to be met. I
think that it is easier to refer to the test, instead of trying to
explain that.
In this commit, we properly sort the data at the correct place. Note
that this probably solves a bunch of other related issues, caused by the
fact that the internal structure was corrupted.
|
|
Cleaning dead code from these commits that have been reverted:
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-54fd886cc58f994ad518ee72df4d3edeR50
2a5488619da22cfd901963dd141e722b195e82ab#diff-f96b339a9374f74489f1f98755e9787bL9253
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-86d6d41b5bb7499bf055258d05549d59R3111
With these final changes, we hope to stop the many issues that have occured with
binary fields, from these commits:
255e8ca3d92e3a77d7c2a145677623518bc2f978
7813a8e714f268983b0be88827ae1c8ad887e6c7
41fe7f9d1113d026b226b136b4477aaaf9f1f638
2a5488619da22cfd901963dd141e722b195e82ab
What remains is the format of binary fields in list views without widgets,
which shows the bin_size instead of the base64 string representation...
... Rest assured, the computation is in JS, so there are no 'bin_size'
shenaningans!
|
|
This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.
The main changes are:
- there is no ViewManager anymore, its work is now handled by the
ActionManager itself, but isolated in a specific file ; this
eases a lot of things, as the breadcrumbs handling for example.
- the ActionManager code is converted to the new coding principles
and guidelines ; mainly, children widgets communicate with it by
triggering events up, and not by function calls anymore.
- the ActionManager layer is now testable, and a lot of tests have
already been written.
- the code in other addons has been adapted consequently.
What's coming next:
- introduce the 'AbstractAction' Widget, and make client actions
and view controllers inherit from it ; this widget will
implement a common API that could be used uniformly by the
ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
getTitle()...).
- move the ControlPanel handling from the ActionManager to the
AbstractAction.
|
|
Revision on 41fe7f9d1113d026b226b136b4477aaaf9f1f638
This commit intended to reduce the network load when reading records with
binary fields. This was made possible by enforcing the contextual key
`bin_size` to be set for records with binary fields.
However, it is causing some issues (see #22222, #22231) which are:
- write with bin_size:true generates a traceback
- read/search_read with bin_size:true breaks some images
on some views (e.g. base.view_partner_form)
Since the problems outweight the gain of these changes, we revert them.
|
|
|
|
Field widgets now have a key 'context' that let them
extend the context of the dataPoint (e.g. list).
In particular, widgets on binary fields enforce the contextual
item {bin_size: True}, so that the server gives the size of the
binary field as its value, instead of its content.
This change on binary fields reduces network load when accessing
a view with binary fields.
|
|
When we have a form view with a one2many with an onchange, and with
lines which contains a x2many, and more lines that the limit (so more
than one page), and the read is not in the same order as what is
displayed because we have a widget=handle, then we might have a problem
when we delete one of the lines, if the onchanges tries to change the
x2many.
This is due to the fact that the order of the basicmodel datapoint is
not preserved by the various operations going around. I think that we
may still have a few other issues of this type, but it is actually quite
difficult to establish.
In any case, this situation is now properly handled.
opw 804530
|
|
|
|
|
|
Issue: create 60 lines in ordered x2many with the same value (0) for the order
field and make a change ; the displayed records will be switched.
The problem appears because the sorting function is not stable and the
records with the same values can change place (hence change page), which is
quite disturbing for the user.
|
|
Two attempts of dealing with sorting (and resequencing) in tabbed (multi-pages)
x2many editable lists (see odoo/odoo@c2563db and odoo/odoo@983c7ae) have been
previously done, using a static attribute (`keepChangesUnsorted`) on the
datapoint.
This solution sadly only covers both cases separately, not if they are combined.
Morever, onchanges were not correctly managed in neither of these two cases.
A new approach is used here, by "freezing" and "unfreezing" the datapoint when
needed, which is more flexible.
Some modifications have been introduced:
- when ordering a x2many, all records are now considered (and not only the
records on the current page) ; an additional read is thus done on the sorted
field for all records in the x2many relation
- `setSort` is now asynchronous as a `read` might be needed
|
|
When the 'id' field is present in a x2m form, the x2m actions generated
on create of the parent object are incorrect.
|
|
|
|
Before this commit, the way mode was handled was not optimal. The end
result was correct (the widget were properly created/displayed in
edit/readonly as required), but useless work was done. In particular,
if we have list/x2manys with widgets and modifiers, it could happen that
widgets were created in edit mode, then destroyed and recreated in
readonly mode.
This could happen in some important views, for example, any view with a
field many2many_tags with a readonly modifiers (pretty much all views
handling taxes)
In this commit, we add a 'editable' attribute to list renderer. This is
necessary, because the list renderer is not actually editable when it is
in a x2many in a form view which is in readonly mode. Also, we need to
manage the distinction between the fact that a list view is editable,
and the fact that some widgets are created in edit and other in readonly
mode, depending on modifiers, and on which line is being edited.
We also add a benchmark (courtesy of CHM) to be able to measure the
performance impact of edit/readonly/onchange in a larger form view.
Before this commit, running this form benchmark on my machine gave a
number of 0.4 op/sec, and after, it increases to 1.26 op/sec, so a
pretty large improvement.
|
|
|
|
|
|
Before this commit M2Mtags widget did not translate.
This was because no context was given to the rpc that fetched the fields
Hence, the lang was not passed.
After this commit, M2Mtags translate well
OPW 784396
|
|
When fetching batched namegets (typically after a default_get), we need
to evaluate the context that we send to the server. This may be
important for models with a custom name_get method. (note: overriding
namegets should be avoided if possible)
With the new views refactoring, this was not done properly and the
'view' context was sent instead. This is not really critical, the proof
is that it took a few months before getting some complaints, but this is
definitely a bug.
To reproduce, simply add a context attribute to a m2o field in a form
view, with a non empty value in a default get, and look at the context
sent to the server.
|
|
- make delegate/undelegate events private
- remove $el before start
- make replaceElement private
- remove one _ from __render_and_insert... method
- update documentation
- remove make and improve make_descriptive (also, it is private)
- ...
|
|
|
|
|
|
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
|
|
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
|
|
With the new views, empty char fields were sent to the server as ''
(empty string) instead of false. This is not the correct behaviour, and
actually cause some problems. For example, if you have a char field
with a unicity constraint, then you cannot set it to '', since there is
only one record that can take that value.
|
|
Consider the following situation: a form view with a one2many which
contains sub x2many fields (for example a m2m_tags). Suppose that the
one2many has more than 40 records. Before this commit, trying to delete
one of these records caused a crash.
The reason is that when we delete a record, we need to reload the
missing records in the one2many field. We actually do that with a
_readUngroupedList. However, the _readUngroupedList method did not
process x2many fields, so the information stored in the datapoints was
'raw', and the rest of the web client expected it to be a datapoint.
To reproduce the issue in the testing environment, i had to use
onchanges and a readonly attrs, to reach a situation where a crash could
occur. This shows that, while the issue is critical, it was not totally
trivial to be impacted by it.
|
|
|
|
|
|
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
|
|
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
|
|
Before this rev., sorting groups in list views wasn't supported. It
hadn't been implemented in the new views.
This rev. activates the feature, so groups can now be sorted on
their aggregates again. It also implements a basic (first level
only) sorting in mockReadGroup, in the mock server.
opw 781288
|
|
|
|
|
|
Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
B which modifies A
In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work
The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields. However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.
Note: the test system had to be adapted to more closely simulate what
actually happens. In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code. This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.
|
|
Before this revision, only the FormView allowed to reuse the same datapoint.
This was only used when opening a FormViewDialog when opening the form view
of record in a one2many field.
However, this could be useful in other places for other views. In Studio for
example, we need to instantiate a x2m view without the parent view ; we thus
need to be able to reuse the same model for all basic views.
|
|
Here is a scenario that could cause an issue:
- open a form view with a many2one
- click on edit button
- click on small external button for many2one. this opens a modal form
view
- click on save in the modal (without changing anything)
- click on save in the main record
- exit form view. this opens a discard dialog
There were two issues here:
- saving the modal dialog automatically marks the many2one field as changed.
This was necessary to force reloading the data, because editing a sub value
in the modal form view could have changed the display_name of the manyone
field. However, this is not necessary when no change was done.
- when saving a record, the _isDirty flag was reset to false only if an
actual rpc was done. However, it may happen that the flag is set to
dirty (for example, when modifying a value inside a many2one), but the
main record has no changed fields.
In this commit, we also remove the on_save handler in the
formviewdialog. This is a small refactoring in a stable version, but no code
currently use it, and I believe that it will make the code much easier
to maintain (the previous code was really awkward), so I think that the
tradeoff is acceptable.
|
|
|
|
|
|
When an onchange fails (for example, because the onchange python code
raised a ValidationError, it is convenient to revert the form view to a
valid state, which is the previous state.
To do that, we keep in the _applyChange function the initial state, and
restore it in the case the onchange fails.
|
|
Suppose that we have a form view with a one2many field o2m_1,
displayed as a list. The model of o2m_1 contains a one2many field
o2m_2 which isn't displayed in the list view, but which is in the
form view. If an onchange sets the value of o2m_1, e.g. with a
command 0 to create a new record, and that the value of o2m_2 for
this new record is set (e.g. with a command 0 as well), it crashed.
|
|
A traceback was raised when opening a new record for a model with a
one2many displayed inside a one2many (e.g. simply displaying the
number of records in the relation), and with an onchange setting a
default value to the inner one2many (for example, linking it to
existing records).
As the inner o2m has no subviews, it has no fieldsInfo, and the
code assumed that fieldsInfo was always set.
This was for example reproducible from v11 as follows:
- create a product (with MTO/Buy and call for tender (need
purchase agreement module))
- create an SO with this product and confirm it
- go to purchase order form view and add a move_dest_ids field in
the tree definition of field order_line
- go to menu purchase agreement and choose the PA generated by
your SO
- add a vendor, confirm the PA and click on 'New Quotation'.
|
|
The ORM doesn't automatically link subrecords when it receives an
update command for a one2many. However, it may be necessary when
the default_get returns existing records for a one2many field. It
only worked before this rev. for the hr_expense model because of an
hack from 2016 (to reproduce: go to Expenses, check some expenses
from the list view, in Actions, click on 'Submit to Manager', the
new hr_expense_sheet contains the checked expenses (one2many), and
the webclient only sent an update command by linked subrecord).
This rev. fixes the problem properly: when the default_get returns
existing subrecords for a one2many field, a link_to command (4) is
generated alongside the update (1) command.
|
|
onchange are performed
|
