* Load views before loading data.
* Load the view used by the mode (by default use kanban for mobile)
* Add attribute useSubview on the widget to load view of the related model
The focus() method of the FieldMany2One was private (named
_focus()), but it is called by from outside by the
FieldMany2ManyTags (which called focus(), so it produced a
traceback).
Before this commit, x2many fields embedded in x2many fields were
not fetched. This was for example the case for many2many_tags in
one2many fields.
This commit enables the recursive fetch of x2many fields.
There is still a missing piece, as the list of fields to fetch for
those embedded x2manys is still unknown. This will come in a
future commit.
The m2o choices that a status field works with are determined using the
associated domain. If the current value is not matched by this domain,
the current value should still be visible so the domain is
automatically extended to match this current value. The problem is that
the current value in edit mode or in create mode is not given by the
`data` attribute of the associated datapoint. Indeed, user changes and
default get are stored in the `_changes` key and it is those values
that must be used if they exist.
If a m2o field status has an associated domain, it is used to match
the records to display as status choices. This domain is extended so
that it always matches the current status value. The code which was
in charge of that was buggy when the status had no value (in that
case the domain should not be extended).
FieldStatus was broken:
- With a selection, the statusbar_visible attribute forces the choices
to display, the discarded ones do not appear at all (even folded)
- With a m2o, the fold_field option tells the field to check in the
relation to know if the choice has to be folded or not, this was not
properly supported
- Changing a m2o value was broken as the parseMany2one function did
not exist
- The status were misordered
- ...
* Also refactor the way the rendering is handled.
* Also modify all statusbar tests so that the statusbar widget is
placed in the form header tag (as it is the common use case).
Some field widgets need additional data to render themself. These data
should ideally be fetched in the data fetching phase. In 10.0, these
data were fetched during field rendering which implied that the data
fetching was done sequentially. To limit this effect, before this
commit, these special fields were flagged by the basic view according
to some field properties and the basic model flagged the fields with
the required data. Now, the system has been improved. The field widget
classes can define a key "specialData" which refers to a BasicModel
method. These methods will be used to fetch the required data at the
right time and these data will be available at
`this.record.specialData[this.name]` in the AbstractField instance.
The new system also fixes a bug: the required data was fetched only
at record loading but should in fact be re-fetched at each view
change.
Before this commit, the field properties (attrs, fieldNames, fields)
were not correctly given to sub views in many case
expected:
* use widget many2many on one2many field
* create record when click on save in formDialog
* do not send create command to the server
* use the fields defined in the field node (instead of tree view fields)
* use the fieldNames instead of the record to get field values
It is quite rare, but it happens that a one2many field has to be edited
with a many2many widget: it allows the fact that records are directly
created, and only later linked to the main record. But the BasicModel
only used the field type to determine which commands it had to send.
In this commit, we introduce a magic flag _forceM2MLink, which, if set
to true, tells the BasicModel to treat the field as a many2many.
There is no list (resp. kanban) controller for x2many list (resp.
kanban) renderers embedded in form views. So the action buttons
events need to be handled by the form controller. To do so, we
uniformize the event API of 'button_clicked', but the handler
remains specific in each type of controller.
This commit tries to refactore the management of contexts and domains
in the webclient.
- Get rid of CompoundDomain: use standard array manipulation to
join multiple domains or use the Domain class (to be improved)
- Get rid of data.js build_domain and build_context methods
- Link this.record to the data point from the basic model for all
fields (not only relational fields)
- Add a getContext and a getDomain function to the basic model
data point (localData element) so that AbstractField implementations
can use them thanks to their this.record element.
- Remove the autocontext binding for field RPCs (see FieldManagerMixin)
We share the basic model record between views, and we have to make sure
that everything is properly coordinated. The main issue solved by this
commit is the fact that we can now edit a one2many record, then close
the dialog, then edit it again and finally cancel the changes, which
bring us to the previous step.
Also, we had to slightly improve the AbstractView API
When we have a many2one widget in a one2many, editable, the context was
not properly computed: it expected the parent to be a record object, but
in that case, it is a list object.
With the new JS test framework, we had experimented with an autodestroy
feature, meaning that all views/widgets are automatically destroyed
after a while. By default, it was 50ms, because we could not hook some
code to run after the end of the current test.
For various reasons, this was not a good idea: some side effects, such
as modifications of the session or of the DOM (with modals) could
interfere with other tests. This commit disable the feature.
From now on, we will have to destroy each widgets created in a test.
The code for selectCell was active, when the user clicked on a td. No
test caught that, because we simulated a click on a tr, not on a td.
I guess that the lesson of the story is that our tests should be as
close as possible to the real conditions, so we should simulate the
click on the innermost element.
Before this commit, the form view opened by a one2many did not check
that the required fields were properly set, so it could lead to pretty
strange results.
Before this commit, the rawify function assumed that any object is
necessary a record object. This was true until recently, when we
decided that dates should be internally stored as a moment instance.
Some fields need to do some model RPC calls (name_search, name_create,
...). Before this commit, they did not use the performModelRPC method
but an explicit trigger_up so that the BasicController (the
FieldManagerMixin) catches it and ask the BasicModel to perform the
RPC. This was designed to let the BasicModel handle the context.
This commit makes the context be automatically binded without the need
to explicitely call the BasicModel for each route in the
FieldManagerMixin. It also ensures that the field own context is
properly merged with the user/action/search contexts.
Now, the fields use the performModelRPC method and the
FieldManagerMixin catches the associated "call_service" event. Then, it
can get the full context from the BasicModel instance and let the event
continue its propagation. To know which field context has to be fetched,
the performModelRPC method is overriden by AbstractField to
automatically add the dataPointID and the field name in the options
parameter.
We replace a bunch of formatting and parsing functions by an object
(parse or format) which can be used to dispatch on the correct type. It
allows us to remove the format_field and parse_field functions.
Also, we camelcase our new code and add some comments.
The field_utils date method have been modified recently, and the idea
behind those changes is that the BasicModel keeps at all time a moment
instance as its internal representation of a date or datetime.
But the parse and format methods did not properly support unset dates,
so we have to slighlty change them to support the case where their values is
not set.
Until now, those tests failed if the window did not have the focus. We
solve the issue with 2 different fixes:
* instead of checking that the focus property is set, we can check the
activeElement instead, it seems to work.
* instead of calling the focus method, in some tests, we can trigger a
* 'focusin' event. I don't know why this works, but it does.
Note that this might make the tests work in phantomjs
Before this commit, the odoo web client used strings to represent dates.
Now, the date is parsed into a moment object when the value is read from the
server side. The widget formats the object to display the value. When the
widget value changes, the value is parsed to a moment object. The value is
automatically formatted to server value in ajax calls (toJSON method).
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
Christophe Matthieu