With the new client web from v9, we start the new action before to destroy the old one.
When we switch from Apps (store) to Update and vice-versa, iframe was not loaded correctly.
In case of the Apps widget, we are binding event of the new iframe during the start,
and when it is ready, we destroy the old ifram and so unbind the listener of 'message.apps'.
Using a uniq id, we ensure to bind new event, and only unbind old event during the destroy.
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.
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)
By default auto_search is set to `True` on window actions, this mean
that for example on a list or kanban view the records will be searched
on the view opening without any user action needed.
Setting it to `False` disable this.
Doing this had two drawbacks:
- depending on race condition, the view could be displayed before the
search view was loaded,
- the code expected `active_search` to be present which was not the case
in this instance.
Before 151c9074 the second issue would not happen (active_search was set
directly resolved if a search was not to be done) and this commit also
wait for the search view being ready before showing the view.
opw-741186
opw-741546
closes#16805
On IE (from 9.0 up to at least IE EDGE 14) we have this behavior
for the method serializeToString of XMLSerializer:
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0])
'<b xmlns="http://www.w3.org/1999/xhtml">"</b>'
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0].firstChild)
'"'
Whilst browser such as chromium or firefox have:
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0])
'<b xmlns="http://www.w3.org/1999/xhtml">"</b>'
> (new XMLSerializer()).serializeToString($('<b>"</b>')[0].firstChild)
'"'
Hence for IE9 and over, if in a `<t t-extend/>` a `t-jquery`
sub-directive (without `t-operation`) is available, we can have
broken javascript if a " is transformed into an " at a unfortunate
location.
This commit favour node.data over XMLSerializer serializeToString to
avoid the possibility of this issue when a text node is processed.
opw-727283
In v8, it was not allowed to create a DB with a name containing a space.
This should still be the case from v9 since it causes issuesfor backup
scripts, for example.
Reintroduces 1a0e9063d4
opw-727613
In 9.0 in some particular instances with embedded views, if:
- an x2many list view is editable,
- we go from a form view of an existing record to creating a record,
- the timings of deferred resolving are in a certain order
the x2many list view could be tought as loaded whilst in reality it is
the 'editable list view' row editing 'form view' that has been loaded.
This could cause sometimes issues after bc031379 because the onchange
computation would happen before the list view is really loaded.
This is probably an issue with the deferred system in one of the views,
but it would be rather hard and dangerous to change it.
So this fix introduce an additional test which ignore relational views
if there is an embedded view.
opw-726701
opw-726768
note: only needed for 9.0, the relational views have been changed as of
saas-11 and this issue is not present.
When expanding a textarea of an editable list,
by putting a long description for instnace,
with multiple lines,
some elements were put above the textarea,
making the content partially hidden
opw-709894
Closes#16083
Before this patch, #15920 was happening. The problem was that calling `render_cell` produced a call to [`record.set(column.id + '__display', value)`][1], which triggers the `change` event, which called `render_record` the first time, which called again `render_cell` and produced the 2nd data fetch.
After this patch, `render_record` is only called if there is some place where to put the result, which does not happen in those situations.
There is still the problem that there is one call to name_get for each many2many widget found in a list view (instead of one per full view rendering), but at least they are not two calls!
[1]: https://github.com/odoo/odoo/blob/5d17749ff47c02294d5ff2ae56bbcef9d082562e/addons/web/static/src/js/view_list.js#L1125
The CompoundDomain class allows to regroup several domains with an
implicit "AND"; these domains can be either a string, an array or
another CompoundDomain. A CompoundDomain can then be converted to
an array thanks to pyeval.js.
For example, if a CompoundDomain is initialized with `[A, B]` and
`[C]`, the array conversion gave `[A, B, C]` (which is expected).
However, a hackish method was used with CompoundDomain. If one of the
domain of a CompoundDomain is equal to `["|"]` (an array with the
OR operator in it), the two next subdomains were supposed to be joined
by a OR operator. Indeed, for the case of a CompoundDomain initialized
with `["|"]`, `[A]` and `[B]`, the array conversion gave `["|", A, B]`
(which is expected). However, if initialized with `["|"]`, `[A, B]` and
`[C]`, the array conversion gave `["|", A, B, C]` which is very wrong
as what was expected is `["|", "&", A, B, C]`. The problem is that the
given `[A, B]` contains implicit "&" operators.
This commit fixes the problem by normalizing only if the CompoundDomain
starts with a ["|"] or ["!"] array which is the standard odoo case.
This allows to limit breaking custom code (e.g we want a simple "AND"
of `[A]` and `[B]` to stay `[A, B]`, not become `["&", A, B]`).
The commit also modifies a test so that it checks that the problem is
properly solved.
In a form view, when a field onchange lead to a change on a x2many,
there was two different behavior:
- if the x2many had an embedded view (eg. a tree view inside a form
view) the onchange would notify that it expected the x2many field in
this embedded view to be changed and handled the changes correctly.
- if the x2many had a default view, the onchange ORM would not be
aware the x2many could be modified and would not sent the changes
back causing blank or not updated x2m lines and error on save.
---
Two solutions were birthed to solve the second point:
=> PR #10557 = solving everything
With this PR the onchange in the ORM is aware of every fields in the
current view (even field in a x2m in a x2m in a x2m in a form view) and
if any of these are change the javascript gets back the value of the
fields present in the view.
This PR has currently not been merged by fear of changing too much and
anyway could only be done in master.
=> PR #12249 = if no field for x2many, send its form view fields
With this change, if the ORM onchange is not aware of the fields in the
x2many widget to returns, all the field in the x2m default form view are
returned.
This was merged in bbdf960 but introduced a number of other issue:
- in most situation the x2many is represented by a list view, which may
have fields missing of the form view, so the original is still present.
- the view used may differ from the default form view in other way
(depending on value in context or other possibilities).
- the form view could have fields not present in the form view which
could end up in `write` on fields which should not be written to.
---
This commit reverts bbdf960 and adapts a small part of #10557 so the
x2many with default view works as an embedded x2many. For more than one
level (eg. a x2many in a x2many) this would still not work but it is
only solvable by a PR such as #10557 which could only be targetted for
master.
With this commit:
- the list of fields sent to ORM onchange is computed at the first onchange
- the fields from a x2many field default view is sent for onchange
- the initial onchange on record creation is delayed to when x2many are loaded
closes#12249, closes#15336, closes#15890fixes#11236, fixes#12249, fixes#15129, #15419
opw-705965 opw-716095 opw-715619 opw-710440
note: already present in 10.0 (with a test) as f65475d68
To reproduce:
- Get a slow connection, e.g. activate throttling in debug mode of the
browser.
- Create an invoice with at least one tax.
- Change a price unit.
- Click on 'Save' then repeatedly on 'Validate'
The tax lines are duplicated.
The issue comes from two identical `write` calls whose purpose is to
delete the existing tax line and create a new tax line.
The two calls are issued by the click on 'Save' and the click on
'Validate', which triggers a 'Save' since it doesn't consider the form
as being saved yet.
There were several issues:
- The buttons from the statusbar were not disabled
- The buttons were enabled too soon. They should be enabled again when
the form is reloaded, otherwise the call to 'Validate' doesn't
consider the form saved.
This is an extension of commit
https://github.com/odoo/odoo/commit/bbbf3db581b5cf883
opw-710642
Odoo Translation Bot