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
When you try to empty a date or datetime field, you get a traceback
saying that 'clone' and 'isSame' are not functions.
This error occurs when you empty the field because the value is 'false'
and you cannot call 'clone' or 'isSame' on false.
To fix this, we ensure that value is not false before calling these
methods on it.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/c32724eae06c987e74a0600f1669696e499edc33
The 'mode' attribute can be used for x2many fields to force the
view mode. Before this rev., it was ignored and if a tree view
existed in the view description, it was selected by default.
This was mainly a problem in mobile as in this case, kanban views
are prefered, and the data_manager forces the mode to be kanban,
so the data was fetched according to the kanban view fields, but
later on the list view was instantiated instead of kanban by the
x2many field, so it crashed if both views didn't share the exact
same fields.
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.
The fieldsInfo attribute on the basic model's datapoints is used
by to determine which fields need to be loaded for a record/list
of records. This information wasn't correctly specified in some
cases. As a result, the display_name of many2many fields (e.g.
using widget many2many_tags) inside list views were fetched, and
thus empty tags were displayed.
No test is added by this commit, as it already makes a broken test
pass (this test didn't pass since the previous commit).
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
The field widget html wasn't implemented yet in the new views. A
very basic implementation was done in addon web. It only handled
the readonly mode so that the field were displayed in studio.
This commit removes this basic implementation from web, and re-
introduced the old one, converted, in addon web_editor.
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.
One could want to render something else than a `button` in the
buttonbox (even if the name seems to imply that it will contain
buttons).
In this case, we render the method corresponding to the tag instead
of a button.
Debounced fields do not notify their environment each time their
value changes, but rather wait for a given delay after the last
change. Input fields allowing the user to type text should be
debounced. The AceEditor is one of them.
Note: this should be tested, but i can't find a way to simulate
text entries in the ace editor.
`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.
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).
Christophe Simonis