Before this rev., there was a traceback when grouping a list view
by a, e.g., many2one field, and then by a selection field. It
crashed when formatting the title of the group, because the type
of the grouped field was incorrectly determined (it selected the
type of the inner grouping level, not the current one). For
instance, it tried to format a many2one like if it was a selection.
When switching between records, the active tab of the previous
record is made active on the new record.
However, before this rev., this was done without checking that
this tab is still visible on the new record (there may be an
invisible attrs that makes it invisible), so it happened that
the active tab was actually invisible.
This was for instance the case when switching between stock
pickings, as the first tab ('Operations') is sometimes hidden.
This commit actually fixes a few problems:
1. the _visitChildren method in the basic model was not following the
changes, only the data, so it was not correct (for example, the isDirty
method was wrong for relational data, when no other change was done)
2. new records could not be discarded, because they had no data in their
data key. What we do here is to add a savePoint, so it is safe to
restore them (it caused a crash)
3. the save method was not properly following children when it was
called with the option savePoint=true
4. when the user tried to discard a form view, in an action with only a
form view, it was redirected to the previous url (via the history_back
action), instead of simply discarding the current form view
When fetching record, `bin_size` needs to be passed in the context
to notify the server to send the `bin_size` and not the whole base64
of binary fields.
The context sent when performing RPCs is a mix of several contexts
(user_context, action's context, context defined in a field's node
in an arch...).
In general, the action's context should not be mixed with the
field's context:
- for global RPCs (read a record, write a record, default_get...)
only the action's context should be given
- for RPCs triggered by fields (e.g. name_search in a m2o), only
the field's context should be sent.
The exception is for onchange RPCs, as in this case, both action
and field's contexts should be sent.
Before this rev, the action context was always sent, which might
produced tracebacks (e.g. go to Sales > My Pipeline > New > click
on Customer field > Create and Edit > boom).
Before this commit, the form dialog was open twice when you tried to
add a new record on a one2many if you were already in a modal.
The event wasn't stopped, so the first form dialog was correcly rendered
but the second one tried to load the same form view on a wrong model.
The views can specify js (and css) libraries to lazy load when
they are instantiated for the first time. The previous
implementation was too naive as it always loaded the specified
libraries in parallel. However, it may happen (e.g. gantt view)
that some of those libraries depend on other ones.
This commit implements a mechanism to handle libs dependencies
between each other. For instance, specifying:
js_libs: [
['a', 'b'],
['c'],
],
will load 'a' and 'b' in parallel, but wait for them to be
loaded before loading 'c'.
The new implementation still supports the old syntax. So,
js_libs: ['a', 'b', 'c'],
will load 'a', 'b' and 'c' in parallel.
In a notebook, tabs may have an invisible attrs. The first visible
tab should be active in any case. This wasn't working at the first
rendering of the view, because the invisible attrs was evaluated
for each tab, before processing the next ones, so the it couldn't
find a next tab to activate.
This fix ensures to process all tabs (i.e. generate their DOM
element) before evaluating their invisible attrs, and trying to
find which tab to activate.
Before this commit, concurrency issues were mostly handled by the mutex
in the basic model. That mutex makes sure that save and change
operations are properly serialized. However, this is not enough. Here
is an example:
1. we have a required field with an onchange and a current value
2. the user changes the value to an empty value. This triggers an
onchange
3. the user clicks on save, before the return of the onchange
4. the controller checks with the renderer if it can be saved. At that
point, the onchange is not yet complete, so the values stored in the
fields are still the initial ones, which are valid (non empty value
for required fields)
5. so, the controller request a save operation
6. the model add the save operation in the mutex, wait for the onchange
to complete, then apply the save operation
7. we end up with a required field with an empty value
The issue here is that the model properly saves and apply onchanges, but
the responsability to check if a record is valid (which depends on the
modifiers AND the field widgets) is the renderer's responsability (it
has to ask the question to all its sub field widgets).
So, we need to serialize 3 operations: applying the onchange, checking
if the save is valid, and saving the record. This cannot be only in the
model, so we need to add a concurrency control mechanism somewhere else.
What we do in this commit is to add a mutex on the basic controller (it
will most likely be used by the list controller as well). In this
mutex, we currently serialize the field change operation and the save
operation, but I assume some other operations will need to be handled by
the mutex.
In addition to this, we also change some asynchronous methods to return
a deferred, so we are ready for other kind of asynchronous behaviour in
the future.
Before this rev., some keys were added to the context of a record
if there were x2many fields in the form view with a context
defined on their node (containing *_view_ref keys, specifying the
fields_view to load to display the relational data). Those keys
should not be added to the main record's context, and it may cause
errors (e.g. click on the 'Procurements' stat button in the Product
form view).
when calling 'read' to fetch a record and 'search_read' to fetch a
list of records.
I don't know where (or if) it is used, but it seems more correct
like this (and mostly, it was the case in the old views, so we
re-introduce the same behavior).
Before this fix, default values for many2many fields (i.e. 'replace' commands)
weren't correctly handled by the model, so the default values weren't set for
those fields.
The editable list view (and the x2manys) have been reimplemented, but
the user experience was not totally (this is an understatement)
polished. With this commit, we reintroduce a good functionality:
pressing enter on the last line of the list creates a new line.
Also, this commit removes a 'debug: true', leftover by someone with a
trigram starting by F and ending by WI.
When we load a field data with many2many_tags widget, there is no views in the
field info but instead we need to fetch the default fields,
e.g. color, display name and id.
Before this commit, all the fields with value `false` on record creation
were deleted from the given parameters for the `create` rpc.
e.g. it was impossible to untick a checkbox in the settings, the `false`
value was not saved in the created record.
Before this commit, the code that handled buttons in list view was kind
of simple, and did not reload the view after.
But clicking on action button is not only a problem for the list view,
the form view already had something in the controller doing exactly
that. With this commit, we move that code to the basic controller, and
use the method in the list view.
With new records, it could happen that clicking on a button in the
header was followed by actions using the wrong id. This was caused by a
field name="id" in the view (see sale order view, in the
delivery.view_order_form_with_carrier inherited view).
In that case, the id was registered in the changes list, and caused
invalid data in the record: its data.id was set to null.
This commit solves two issues with deletion:
- deleting the last record in a form view now triggers a history_back
action, which means that the view will be changed back to the main
view (a list view for example), instead of staying in form view
- deleting a record did reload the view twice in some cases.
Before this commit, when a field was changed, it always triggered a
field_change event, with the new value, even if that value is not valid.
As a result, it could happen that an onchange was sent to the server
with a string as the value of a float field.
What we do in this commit is making sure that invalid values do not
escape the confine of a field, by returning immediately after detecting
that a value is not valid.
Also took this opportunity to refactor the code of pivot to adapt
the parts that were not up to date and remove the useless deferred
in sortRows, courtesy of aab.
The exportData function still needs reworking.
- When an one2many is displayed in a list view, the field data are not fully loaded
since only the number of record is displayed. Then when the related form view
is opened the one2many fields displayed need to be loaded.
- Optimized the fetch of x2manys without doing an useless rpc
if we don't need all the fields but only the relation records ids and adapt
the tests for this optimisation.
- Fix wrong inheritance for kanbanmany2many_tags
Before this rev., the context sent when creating (or saving) a
record was incomplete. Thus, the created record might be incorrect.
For example, go to Sales, open a team's pipeline, click on 'Create'.
The created record should belong to the selected team, thanks to
some keys specified in the context. This wasn't the case before
this rev.
The 'defs' attribute of the BasicRenderer is used to push the
rendering deferred of asynchronous fields. It is set to an empty
array before the rendering, and for each asynchronous field, its
deferred is pushed in the array, so that the renderer can wait for
all its fields to be rendered (no flickering).
The function '_applyModifiers' is called during the whole view
rendering (for each field in the view), and when some fields
change, as the modifiers are then re-evaluated.
As it is called during the whole view rendering, it can't delete
the 'defs' attribute, otherwise it will crash if one of the
remaining fields in the view uses an asynchronous widget (trying
to push a deferred in an undefined variable).
This rev. moves the deletion of 'defs' to the function that is
called when all modifiers are re-evaluated and applied.
The evalContext contains the current data of a record
(the value of the fields that have been fetched,
i.e. the ones referenced in the view).
However, 'id' is a particular field that should always
be in the evalContext, even if not in the view
(as we always know its value).
Before this rev., 'id' was in the evalContext if
the record already existed, but not on new records, so it crashed
on new records if 'id' was used in the context defined on a field's node.
Before this commit, all onchanges were applied if the field
was known on the model.
However it's not possible to apply onchanges on x2many not in
the view as we don't know their fieldsInfo.
The 'Add New Column' was still in `folded` mode after clicking on 'Discard'
because the mode was toggle two times: one by `_cancel` and another one by
`_onClick` which already toggles the mode.
This commit also use `_applyChanges` directly instead
of using `notifyChanges` to avoid the mutex which will
cause a deadlock (we are already in the mutex).
Since the new views, buttons were extracted of the <footer/> tags and
placed directly in the buttons area. While this would be a good idea,
this was ignoring the modifiers placed on the <footer/> tags. Multiple
solutions were possible:
1) Leave the <footer/> tag as it is (like before the new views)
This creates an useless <footer/> element in the DOM most of the
time.
2) Propagate the <footer/> modifiers to its children.
This requires some code to do the propagation and a modifier might
be evaluated multiple times for nothing (for each child).
3) Allow only one <footer/> tag in form views and divide buttons in
child <div/> elements.
Only creates the necessary DOM elements and modifiers are evaluated
only once.
While the third choice is obviously the better one, this commit is
implementing the first solution. Indeed, changing all the XML views
might not be a good idea in the current state.
before this commit when toggling allday flag in calendar form view, it was
possible to have one day error.
The input datetime is wrong when the user don't use the datepicker widget
(insert date by keypress instead of click on datepicker)
sometimes, the value could be null (crash because try to clone false)
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
Before this fix, active_id wasn't defined on non existing record.
For example: when you tried to add a new contact on a new partner.
Now, active_id is false if there is no id on the current record.
So, you can use this value to evaluate the context
Onchange results weren't correctly applied for many2manys, and
for x2manys inside x2manys.
More precisely, if an onchange RPC returned a command 4 (link to)
for a many2many field, this command was ignored. If it returned
nested commands (commands 0, 1 or 4 inside commands 0 or 1), they
were ignored as well.
The function that applies the result of an onchange is now
recursive, and it handles commands 0, 1, 4 and 5.
There were several issues with this widget, and the way the model
handles its requests (mainly the removal of values).
It crashed for instance on the product form view when the user
updated the routes field (field route_ids in tab inventory).
The readonly attribute of a field in its description can be
overriden in the views (e.g. with modifiers). So readonly fields
may actually be edited from views in which there is a modifiers
on their node overriding the default value.
Before this rev., readonly fields couldn't be saved, even if they
could be edited from views (with such modifiers).
For instance, it wasn't possible to change the value of the
partner_id field in a draft sale_order.
For one2many and many2many fields, you have several ways for specifying
a view other than the default one:
- to write the arch of the view in the field tag
Example:
<field name="many2many">
<tree>
...
</tree>
</field>
- to write xmlid of the view in a specific key (*_view_ref)
in the context of the field.
Example:
<field name="many2many" context="{'tree_view_ref':'module.tree_view_ref'}">
Before this fix, the second case didn't work.
the default view was loaded instead of the one passed in the context.
In fact, this context is evaluated after the loading of the record but
we need some static keys to load the view (before fetching the record).
When we try to archive a kanban column we get a traceback when the field
'active' exists on the model but not in the view.
This traceback is caused by an unecessary check of the active value of
the record.
To fix it, we apply the 'active' value on all records, and not only on
the ones where active value changed.
Traceback when:
* click on first row of calendar
* move an event somewhere else with drag and drop
* click on the mini calendar
* filter from the control panel triggers a traceback
* add an attendee: traceback
* day/week/month: traceback
* cannot add a leave, the fromViewDialog does not open
* one day oo server-side when select all day
The client must receive the tzOffset to apply this on all hours.
To use the date picker we must change the date to apply the change
in the user's tzOffset, without this change the result is wrong.
For datetime widget we must change like it to avoid max stack error.
The server send the tzOffset, if it's undefined, by default the client
use the browser time offset.
Every test are change to use tzOffset.
A test is added in calendar to use the click by position for the
fullcalendar lib. This test create and drag and drop an event to check
timezone error and error when we use default value in the context.
Use formating date like 2026-04-04T08:00:00Z instead of 2026-04-04 08:00:00
is important for phantomjs, because it's crash without information if the
formating is not the standard format.
For the parsing, when the client receive a server date the date is utc
formating but when it's parsed from the client is in the user's timezone
In a form view, if a one2many list view contained a many2many
field (e.g. widget many2many_tags), the commands for the embedded
many2many weren't generated for newly created one2many subrecords,
so this field couldn't be saved.
The method has not been correctly ported to the new view (in the new
model in this case).
The change (on the color) needs to be notified to the model before
updating the record.
Aaron Bohy