Before this rev., there might be a crash when the user quickly
clicked several times on the browser's back button. This crash
occurred in the code saving/restoring the scroll position of the
current action.
When clicking fast on the back button, several actions are
executed but don't wait for each other (those actions are triggered
by the hashchange event), so when it is fast, and mainly when the
appswitcher is involved, it may happen that we try to get the
scroll position of an action that isn't loaded yet.
opw~741814
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
In PostgreSQL, a field of type `integer` must be in the range
-2147483648 to +2147483647. If the user enters a lower or a larger
value, a traceback is thrown.
opw-740286
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
As the export dialog has always lots of content, the design was made
so that it always takes 100% of the viewport height. This allowed to
design the dialog content so that the fields panels do not overflow
the modal and are individually scrollable and so that the buttons are
vertically centered.
The problem is that this was not properly working on IE. Indeed, the
`.modal-body` element overflowed the `.modal-content` one. The solution
is in two parts:
1) IE does not properly distribute heights when combining flex elements
with max-height containers. The `.modal-content` has to be forced
to `height: 100%;` for this to work. This is done in javascript as
there is no way to detect `.modal-content` elements specific to
export dialogs.
2) IE does not properly render `flex: 1 0 0;` elements. The rule is
supposed to tell the browser "render the element as if it was of
dimension 0 and was able to grow to fill its parent container".
Fortunatly, a workaround with `flex: 1 1 auto;` combined with
`min-height: 0;` seems to achieve the same behavior for this
case (by telling "render the element by shrinking or growing
it to fill its parent container, without caring of its minimum
size").
opw-725391
Cherry-pick of odoo/enterprise@dd059f0af7
When there is a lot of texts to display in a tooltip, it will overflow
the viewport vertically as the max-width of the tooltip is set at 200px
(bootstrap default). This commit increases the max-width to the
viewport full-width.
opw-725804
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
Clicking on an editable list row makes the row editable. Clicking on
an editable list row while another row is being edited, first make
the row being edited readonly before making the clicked row editable.
The row which goes back to readonly have to be reloaded, operation
which is not instantaneous. If another row is clicked while a row
is going back to readonly (this typically happens if a row is double
clicked while another one is being edited), a form view dialog was
opened to edit the row (behavior which was not expected).
opw-710627
Aaron Bohy