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.
When clicking on a form button, the saveRecord method is called, which
will then call the toReadonlymode method, which will rerender the form
view, even if it was already in readonly mode.
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.
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.
- remove edit workflow link in debug manager. The workflow feature was
removed, but there was still a link in the debug manager. Clicking on
that link was a crash.
- the rpc to fetch a view was wrongly updated, so the return value was
not properly used.
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.
The `DebouncedField` class has a `_onInput` method which is called when
the user is typing text and which is debounced so that its action
(setting the field's value) is not recalled too quickly.
The problem is that if we have to do other actions which should not wait
for the debouncing (or wait for another debouncing) when the user is
typing text, this would imply to namespace the "input" event to add
another handler, which is not very elegant.
Instead, this commit changes the `DebouncedField` so that the
`_onInput` handler is not debounced but instead calls a private method
which is debounced (`_doDebouncedAction`).
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.
Before this commit, it could happen that a crash at the wrong time (for
example, while loading a view) cause the web client to crash for various
reasons. For example, it assumes that the active view always has a
valid controller. Or the action manager could not detach the previous
view, so we had the 'double view' rendering in the web client.
With this commit, we add some protections at various points. Those
safety measures should help the user keep working even if a specific
view did crash.
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.
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.
Onchanges triggered in a relational fields are now directly
triggered on the main form view as well. This was not the case
before and there were some steps (or parts of steps) checking
that.
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.
The new form view does not really work well with the TAB key. This is
partly caused by the fact that the tab event is preventdefaulted.
With this commit, we reintroduce a basic navigation with TAB and
shift+TAB.
When an onchange is resolved after a discard, it caused a traceback. We
now make sure that it does not happen. Note: I think that the test is
quite neat.
Input fields notify their changes when the user is typing text at a
rate of max 1 per second (by default) and when a change is confirmed.
This last case was handled by listening to the "focusout" event. The
"change" event is however more suited to handle that.
This commit also solves a problem with the related test. Before this
commit, the test triggered some "input" events on an <input/>, then
waited some time so that the debounced action is executed, then
restarted triggering events... the problem is that this "some time" was
long enough to trigger the onchange but not necessarily long enough
to be sure another onchange can be started. Indeed, the mockserver get
rid of RPC delays but not of CPU delay. As two subsequent onchange
cannot be done at the same time (the second one is done after the first
one is finished (see Mutex)) and that this test simulates a 3ms delay
for the onchange, there is no guarantee that waiting x ms (even > 3ms)
will be enough, indeed sometimes we had this sequence:
1) trigger "input" event
2) trigger "input" event
3) start delay of 75ms
4) debouncing time (3ms) is finished: call `_setValue`
5) basic model mutex (already resolved)
6) start async onchange RPC
7) (1) -> (6) took more than 75ms CPU time, the delay started in (3)
is finished: trigger "change" event
8) call `_setValue` (no debouncing of "change" events)
9) basic model mutex... NOT resolved as the async onchange RPC
started in (6) did not had the opportunity to continue its
call sequence (no matter the time it would take)
To solve this problem, the 75ms delay had to be replaced by a non
arbitrary waiting: the mutex resolution. As the test does not know
about this mutex, the only way to be sure it is finished is to wait
for the `mockRPC` to be finished thanks to a deferred and then wait
for another callstack to be completed thanks to a 0ms delay.
When focusing a checkbox field and hitting the "enter" key, the
checkbox should change its status. Before this commit, this produced
a traceback instead as it was trying to call the `_onKeyDown`
function while it was defined as `_onKeydown`.
Also the `_onKeydown` method is in fact declared in the `AbstractField`
parent implementation, so there is no point in declaring the event
binding twice. Also, part of the `FieldBoolean._onKeydown` code was in
common with its parent `AbstractField._onKeydown` code so remove it as
there is no point in duplicating it.
Note: this `_onKeydown` method has to be refactored as it is breaking
form view navigation anyway.
Also modify an existing test to check the checkbox keyboard navigation.
+ Document and refactor the files using the new guidelines
* Now only non-technical names are used when building field chains and
domains (technical names can be used in debug mode).
* Better warnings are displayed when using the field and/or domain
selector widgets (also checks domain validity in both domain field
AND domain selector widget).
Also improve design (thanks to original work of @stefanorigano):
- Hovering 'remove' highlights the element that will be removed
- Hovering 'add node' btns shows where the new node will be created
- Restyle debug domain input field (make it similar to a text editor)
- Improve design and layout
- Resize inner fields
Géry Debongnie