It shouldn't be possible to duplicate ir.model.fields. Add attribute
´duplicate´ which can be set to false to hide the duplication option in the
action menu.
Odoo modals are supposed to be instantiated thanks to the Dialog JS
class. This allows to not duplicate modal structures and to properly
handle multi modals (which bootstrap is not supposed to).
Problem since commit 7dcb8fea64:
The support for inline modals has been broken without providing a
solution for all cases. Indeed, some modals are placed directly inside
form view xml. See an example here:
https://github.com/odoo/odoo/blob/dd0533897e397dfd78ad456fea42a5a12db51246/addons/website_twitter/views/website_twitter_settings_views.xml#L24
While waiting for a new way to instantiate these inline view modals,
this commit restores their deprecated support.
If `d.message` is an empty string, `!!d.message` is false and the
crashmanager will try to display `d.error.data.message`… which does
not exist as it's a warning with an empty message not an upstream error.
That causes the crashmanager itself to crash, and even the warning
name/title to be lost.
This simple return allows submodules to be able to know when a dialog is shown and modify something in it.
Note from GED: I am aware that this is a IMP in a stable version, and I really don't like that... But it looks like it really helps many people, as shown by the PR, and the risk induced by this commit is definitely extremely low, so I will make an exception.
(PR: #15579)
The ModelFieldSelector keeps an internal cache for the fields_get.
This cache needs to be cleared in the tests environment because
a model with the same name may be defined several times accross the
tests modules, but they may contain different fields.
This could also be a problem with studio: when a field is created,
the ModelFieldSelector cache must be cleared as well (in addition
to the data_manager one).
We thus introduce a new 'clear_cache' event on core.bus. When
triggered, the ModelFieldSelector and the data_manager clear their
respective cache.
We use this event in the test environment to ensure that the cache
is cleared at the end of each test using a mockEnvironment. This
rev. also fixes an infinite loop in the override of destroy() in
the mockEnvironment, which occured when both session and config
were specified in the params.
When the root node of the arch has attribute 'create' set to '0',
the generated DOM element must have classname 'o_cannot_create'.
This is used to correctly display the nocontent helper (when there
is no record).
Before this rev., the helper indicated that the user can click on
'Create' to create a new record, even if the create action was
disabled. This was for example the case in Point of Sale > Orders.
The problem occurred in form views with a many2one field, when the
user reproduced the following steps:
- type some text in the many2one
- click on 'Create ...' in the many2one dropdown to quick create
(name_create RPC) the record
- before the name_create returns, click on 'Save'.
When this happened, the record was saved before the many2one was
updated with its new value. So the record was incorrectly saved,
and the view was again dirty as soon as the name_create returned,
even if it was in 'readonly'. So after saving, a 'Changes will be
discarded' dialog opened when the user tried to leave the form.
We fix this issue by making the controller wait for the name_create
to return, and for the many2one to update its value, before saving.
This issue could also occur in list views.
There were two main problems with the datepicker since the lib was
updated:
- it appeared broken in the search view "Filters" menu
- it did not overflow the parent which scrolls
Indeed, before the update, the datepicker was placed in the <body/>.
Now this is a lib option. Unfortunately, the option is broken (I don't
know why they broke it since it worked before the lib update...). As the
lib does not expose its internal functions, the only found workaround was
to patch the lib code itself.
opw-745311
opw-745625
The autofocus worked fine when switching from 'readonly' to 'edit',
but not when clicking on 'Create' from the multi-record view. This
was because in this case, we were trying to focus the field while
the view wasn't in the DOM yet. This rev. ensures that we wait for
the view to be appended to the DOM before trying to set the focus
on the default field.
Also ensures that the first visible field is correctly focused.
Before this rev., if the first field was invisible (or simply
not focusable), no field was focused.
Credit goes to @msh-odoo for the preliminary work.
The 'Add an item' button of one2many editable lists is deactivated
once clicked (since rev. f9a1241) to prevent concurrent record
creation. It is re-activated when the record has been created.
Unfortunately, it might happen that the record is actually not
created, so in this case the button is never re-activated.
This happens for example on the customer invoice form view, if
the user tries to add a line before selecting a partner.
This function should return a deferred, as indicated in the
docstring. However, in some cases, it doesn't. It then crashed
as the FieldX2Many tries to call done() on undefined.
This happens for instance on the customer invoice form view:
create a new record, select a partner, add a line, select a
product, directly click on the invoice date field (this will
trigger an onchange which will totally override the value of the
one2many). The FielX2Many calls setRowMode to switch the edited
row back to readonly, but this row doesn't exist anymore as the
one2many value has been overriden by the onchange, so setRowMode
wrongly returns nothing, and it crashes.
Suppose that a default_get returns the value [[6, 0, [1]] for an
x2many field (i.e. put id 1 in the relation). A read is performed
to fetch record of the comodel whose id is 1. Suppose that there
is another x2many field of the comodel. This x2many has to be
fetched (if not empty), and processed by the BasicModel (i.e. a
dataPoint must be created for it) as well.
Before this rev., the second x2many wasn't fetched nor processed,
and it produced a traceback for example in Expenses app, when
clicking on 'Submit to manager' from an expense form view.
Before this fix, if the start field is readonly, the user could not create
an event. With this commit, it is also ensured that the context sends the
right default values to the view
In case of a MemoryError, there is no error message, the user gets a
"Database restore error: "
without any details.
Instead fallback to the repr.
This way, a wrong password is
"Database restore error: Access denied"
and a memoryerror
"Database restore error: MemoryError()"
Closes#17393
Previously, when an update operation was performed, the list of
ids in the x2many field was emptied beforehand.
It kinda worked in lots of cases where one would expect it to
fail because in thoses cases the widgets send link_to commands
along with the update one, thus re-adding the removed line.
Now the behavior is more consistent accross the board. We start
with the current list of ids and apply the requested changes.
Otherwise some changes can create rpc errors that are silently caught
and never seen as long as, out of (un)luck, the end result is the same.
Tests which need to create a server error can just simulate it using
the mockRPC mechanism.
When the user writes something in a Many2One input, after a short
delay, a name_search RPC is done with the value written in the
input, and results are displayed in a dropdown. Then, if the user
clicks on the input, the dropdown closes. If he clicks again, it
should do again a name_search RPC with the value of the input.
Before this rev., it was doing it with the empty string.
Suppose that we have a many2one which is set (has a value) in
a form view. Before this rev., if the user unset the value (by
erasing the input content in edit mode), and then reset the same
value, the input remained empty, and the old value wasn't actually
reset.
Problem occured with checkboxes in editable lists: when pressing
up, down, right or left with the focus on a checkbox, in addition
to navigating in the requested direction in the list, the page
scrolled (if there was a scrollbar of course). This was because the
event wasn't 'preventDefaulted'.
When creating a new record where the ´domain´ widget is set in the view
with an associated model but this model field has no value, an rpc
(search_count) was done on an unknown model, that causes a traceback.
To avoid this, the rpc is not done if the model is not set.
Christophe Simonis