| Age | Commit message (Collapse) | Author |
|---|
|
For consistency, every static test folder should be named 'tests', with
a s.
|
|
When evaluating a domain, we need to add the user context, so domains
can use a key such as uid.
|
|
`makeRecord` is now asynchronous as it will load data
for relational fields (X2manys and many2ones if `display_name`
is not fetched).
This change has implied a refactoring in all `makeRecord`
occurences to adapt with the returned deferred.
|
|
It might happen that some code in a widget (callbacks given to
other function calls) is executed after the widget's destruction.
For example, trigger an event up with a callback in option, the
event is handled by a parent that performs an rpc, meanwhile, the
child widget is destroyed, then, the rpc returns and the parent
executes the callback.
This shouldn't happen, because it means that the callback is
executed for nothing. Worst, it crashes if the function _rpc is
called inside the callback, because the widget being destroyed,
there is no parent to handle the request, and _rpc thus returns
undefined.
This rev. protects the code from crashing by making _rpc return
a pending deferred instead of undefined.
|
|
Before this commit, clicking on buttons did not reload the current
record, which is good. However, it kept the reference to the record
after saving, even if that record could have been changed, which is
definitely the case when starting from a new record and saving it (it
will have the correct res_id, which is really important).
|
|
When saving a new record, with the option reload=false, a datapoint in the
basic model could be left in a wrong state: the x2many fields were
deleted, with all the changes, but the values in the data key were still
null, which means that the x2many field has no valid corresponding
datapoint, as far as the basicmodel can see.
So, with this commit, we make sure to push the changes into the data, so
the datapoint is in a proper clean state.
|
|
When we click on a button in a form view, we don't need to reload the
data for the form view.
|
|
In some case ´default_get´ returns values for relational fields that are not
in the view so we cannot create a datapoint for these field. Furthermore, we
cannot discard these fields in order to save their values correctly in the newly
created record.
|
|
When the ´default_get´ returns default values for a x2many field, it needs
to be set as changed fields in this x2many field. Previously, it was wrongly
assumed that these changes were non existant.
|
|
When clicking on a button in a form view, the current data should be
saved but the form view shouldn't be re-rendered in readonly.
Before this commit, the view was re-rendered, causing a weird glitch
in dialogs as buttons that were supposed to be moved to the dialog's
footer appeared inside the view when the button was clicked.
Also forces the default mode in form view to readonly, so that it is
correctly redrawn in readonly when coming back using the breadcrumbs.
|
|
When a field with an onchange is changed, if there is a context
defined on the field in the arch, this context must be added to
the context sent with the onchange RPC.
|
|
|
|
Before this commit, we lost the functionality of editing records top or
bottom. However, it as almost ready, but we needed to change the way
commands are generated, to respect the actual order in the UI.
Also, the mock server needed to be updated, to make sure he also save
the new ids in the correct order.
|
|
When there is an onchange on fields of a one2many, the data given
to the onchange RPC should contain an additional key for the
corresponding many2one, mapping to the current data of the parent
(main) record.
This wasn't working before this rev. for new o2m records created
when the one2many wasn't editable inline (with a list view
editable), because in that particular case, the reference to the
parent record wasn't specified correctly.
|
|
|
|
Assume that there is an onchange on a form view that upates the
records of a one2many field. Before this rev., if the user edited
one of those one2many records (in a dialog) after the onchange,
the onchange values were lost.
|
|
It may happen that an onchange returns values for unknown fields in
the view. In that case, the corresponding values need to be ignored
as the postprocessing base on the field type can't be done, which
may lead to errors later on (e.g. when saving).
For example: one2many list in a form view which doesn't display
a many2one field that exists on the related model. If an onchange
on the main form view updates the value of the many2one inside the
one2many, it will crash later on when the user will try to save
(because the value [id, display_name] will be sent to the server).
|
|
Without this commit, the statinfo field in a button but
not in a buttonbox are not rendered.
With this commit, when the button is rendered, the children are
processed and then the statinfo field is rendered (e.g. bank account(s) statinfo
in the Sales & Purchases tab in the res.partner form view).
|
|
Readonly fields can be modified with onchanges, but they should
not be saved.
|
|
Before this commit, the FieldSelection did not work properly in edit
mode with a many2one. This was because it did not take the correct
value into account, and the test did not notice it, so both had to be
fixed.
|
|
When a button is clicked in a form view, the event 'execute_action'
is triggered up and catched by the view_manager, which can do
various async stuff. Meanwhile, the form view might be destroyed,
and in this case, the handlers shouldn't be executed when the
async stuff is done.
|
|
Before this commit, when a numeric value was not set (for example, a new
record with no default_get value), then it was not properly evaluated as
0 in a domain.
We also slightly refactored the code so we always use the same method to
compute the evaluation context.
|
|
This commit fixes two problems. First, the commands weren't
correctly generated for relational fields inside relational fields.
For example, if a form view contained a one2many containing itself
a many2many, the commands weren't generated for the many2many
inside the one2many. Thus, it's value couldn't be saved.
Second, when doing an onchange RPC, all record data should be sent
to the server, not only what have changed. Before this rev., for
x2many fields, commands were sent only if the field had changed.
|
|
This didn't work when the test has been written, but it does now.
|
|
When clicking on a stat button in a form view, an action is executed.
The button might also be given a context which have to be used when
running the action. This context was ignored since the context
refactoring made with commit 26a7fe7de1b6258989bc63335321f8f8e83435af.
|
|
Before this fix, when the user dared press 'TAB', the move_next event
was propagated from the sub one2many to the outer form renderer, and
caused the form view to try to focus another totally unrelated field.
Also, the event was sent twice, because we are in a case where a field
widget is contained in another field widget.
|
|
We still did not properly evaluate domains in kanban view. The proper
eval context is quite tricky to get right, because we need to perform
some computations. With this commit, we simply use the code that was
already in the basic model.
|
|
This reverts commit 839a07fbed4720fc71c070507c591295722df350.
Indeed, the system will need the `resetOnAnyFieldChange` option as the
`FieldMonetary` will need to be re-rendered if the currency changes.
This does not use the `_fetchSpecialData` system as it will be
refactored later and the currency can be fetched without RPC.
|
|
Before this commit, the `render` method of the monetary field added
the <input/> and currency elements without removing the previous
ones. As this was called on each related `onchange`, the DOM was
growing at each of these changes.
|
|
Before this commit, if a field was declared as a "Monetary" field in
the model, the `FieldMonetary` was adding the currency symbol in the
<input/> in edit mode.
|
|
|
|
The lazy option in read_group is by default true, so when we want to
override it with false, it needs some special care.
|
|
This is not a complete work, but it introduces the basic infrastructure
to properly edit various more sophisticated editing behaviours.
The main focus of this commit is to handle discarding invalid lines in
one2many, potentially asking the user for confirmation. So, the
relevant methods have to be modified to return some deferred, because
the operation is now asynchronous.
|
|
Before this commit, we did not properly update all fields in a one2many.
I assume that it was because the list renderer crashed if it tried to
display a field that did not exist in the list view, but in that case,
we simply can ignore these fields.
|
|
Before this commit, the basic model used the real data array as changes
in the method _applyX2ManyChange, which means that each change was also
done to the data array.
|
|
In a one2many, when we click on 'Add an item', we need to unselect the
current row. Otherwise, its changes will not be committed and it will
be in practice discarded.
|
|
The pivot view had various small issues causing a crash when
transitioning from and to a 'no data' state.
|
|
In a one2many field, when the user clicks on the 'Add a line' button, we
need to create a new record. This means that we call the default_get
route, then call the onchanges. The onchange can return a 'warning'
key, which is displayed to the user. But in the specific case of a
one2many, we don't want to actually create the record. So, we reject the
deferred to prevent that from happening.
|
|
To add a record to a list, the list controller called the
addDefaultRecord method. But that method did not made the changes to
the _changes key, it edited in place the data key.
So, this means that it was not possible to discard the add a line.
|
|
With this commit, updates of existing o2m records are now
correctly saved in DB when clicking on 'Save' in the main
form view.
|
|
A record of the basic model may need to be displayed in different
views (e.g. a o2m record is displayed in the, e.g., Kanban view
inside the main form view, and if clicked, it is also displayed
in the form view opened in a dialog). However, the fields present
in those views may differ.
The previous implementation of fieldsInfo in the record didn't
handle that, as it was a dict whose keys were field names. With
this commit, the fieldsInfo is dict whose keys are view types, and
the values are dicts whose keys are field names (the fields of
the corresponding views, with they attrs in the view).
This allows to create multiple o2m records in a row in a form view.
|
|
Before this commit, the web client displayed a confirm dialog when
opening the app switcher (enterprise version) if a record is dirty, then
again when doing the next action. With this commit, we make sure that
the second time we ask confirmation to discard changes, no dialog will
be opened.
|
|
|
|
|
|
|
|
This commit also adds the special_click property which is used to mark
a DOM element such that clicks on it will not be intercepted by the
list view.
Basically, we need this on elements which rely on bootstrap events,
since those need to bubble all the way up. If we catch them in
the list view, to open a cell or a record, then they never get to
bootstrap's level and so the widgets relying on these elements
cannot work.
We plan to remove it at some point, when we have more time to figure
out a way for the click event to reach bootstrap from inside the list
view without breaking the list view behavior itself.
|
|
|
|
The original reason why this widget was created is because sometimes,
the id is a virtual one, represented by string in the webclient. As
such, the integer widget could not render it properly since it could
not parse the integer from the string. This led to the following bug,
which in turn led to the creation of the id widget:
https://bugs.launchpad.net/openerp-web/+bug/919184
Now, virtual ids are not handled within the record data itself anymore,
making it a non-issue to render the id field in the webclient since
it is not given a value until a proper id is created. The virtual id
management is completely out of the view scope now, rendering this
widget useless.
|
|
|
|
|
