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
As `_renderInnerGroupRow` is returning the row, appended to the
previous result, and not only the row, it was not possible to
override the method to add, for example, another row.
This commit doesn't change the behaviour, only the return of
private functions.
As `create_view` is asynchronous, it is possible that there is an
active view without any associated controller.
We thus test here if there is a controller before calling its method.
In a recent commit, the fields object describing all fields of a
model is (deeply) frozen by the data_manager. As a consequence, if
a field has a domain (represented by an Array), this domain is
frozen as well.
Moreover, when the function getDomain is called on a dataPoint,
the returned domain is the one in fields, not a copy.
Problem is that the Many2One field updates this domain to add the
blacklisted ids, which produces an error if the domain is frozen.
Before this commit, every field changes were sent upstream and triggered
a notifyChange, potentially causing multiple (onchanges) RPCS in rapid
succession.
It is useful to have a feedback of the new values of the fields even
without needing to lose the focus, but it should not be done for each
keystroke.
With this commit, we debounce the onInput handler, so the method
setValue is in practice debounced as well. We need to add a handler on
the focusout event to make sure that if the user changes input, the
setValue is immediately called.
Note that we had to add support for that in the test utils environment
(and not only in the createView method: field widgets can be
instantiated in other environment, such as the reconciliation widget)
With the new `field_utils` parsing functions, many field types were
not able to be used with the domain selector anymore.
* a m2o value is now parsed to an object with an `id` key and a
`display_name` key. This object cannot be placed in the `<input/>`
holding a `DomainLeaf` value in the domain selector widget (right
now, it is showing [Object object] because of this parsing). If
the value is an object, display its `id` key or nothing if this
key does not exist.
* a date(time) value is now parsed to a moment object. Adaptation had
to be made so that it is correctly displayed for the user and
properly converted to its server format when building the char
domain.
* an array of char is formatted to an empty string... obviously the
selector implementation is wrong here and should format array
values individually. However, as the widget only support arrays
for char values, the formatting is useless so it can simply be
disabled in that case while waiting for better implementation.
Note: the parsing and formatting code in domain selector should be
improved to be more accurate and understandable. This will be done
in a future update.
A big problem is that the read_group method has a variable API: it
sometimes returns values in a __count key, sometimes in a
[somefield]__count key.
Before this commit, the graph view was not using the correct value in
some cases.
With the new views, we totally broke the dashboard. This commit
rewrites all the code to comply with our new coding guidelines, and make
sure it works, with some tests.
Note that a big change is that we don't instantiate an action manager
and a view manager, we directly instantiate the views.
Also, this is not the best way to organize the dashboard. I think that
it should be a client action, not a form view, so we don't have to
overload all the form view classes and we don't depend on form view
behaviour/view caches/...
In some cases, the view manager do_load_state method can receive an
empty string as id. This was the case when we refresh the dashboard for
example.
This is not a perfect fix (the do_load_state and the url mechanisms
should be improved), but it makes things more robust.
One2Many fields edition (creation of new related records or
edition of existing ones) needs a specific handling, because the
related records aren't saved when the user clicks on 'Save' in
the dialog, but when he clicks on 'Save' in the main form view.
To make this work, the model (instance of BasicModel) and the
representation of the edited record in the model must be given to
the form in the dialog.
Problem is that the fields to display in the kanban or list view
and the form view in the dialog may be different, so when opening
the dialog, the list of fields in the record is updated, and this
list must be reset to its original value when the user closes the
dialog. This last part wasn't done correctly before this commit,
which causes tracebacks when the kanban/list view contained fields
that weren't in the form view.
Géry Debongnie