This is triggered by the interaction of the `-webkit-overflow-scrolling` [1]
rule that is set on the top of the modal (div.modal) and the fact that inputs
elements are displayed over the table with an absolute positioning (that's
how the editable lists work).
Indeed, the `-webkit-overflow-scrolling` rule creates a new stacking context [2]
and is inherited by all the children of the modal (and so on), resulting in this
situation:
.modal
/ \
... (new S.T.) ... (new S.T.)
/ \
... (new S.T.) ... (new S.T.)
/
.o_list_editable (new S.T.)
/ \
.o_form_view (new S.T.) .table-responsive (new S.T.)
/ | \ \
input input input table (new S.T.)
This explain why the input are not visible: actually, they are displayed
behind the table. In this case the document order is used to know which
div should be in front of another div[3], that's what rev odoo/enterprise@304b790004 [4]
tried to change. However, this was not enough for iOS 9.3 / iphone 6
because, for some unknown reason (but probably due to the fixed position
of the modal that seems kind of broken on safari mobile), the inputs where
still displayed under. Note that the fix was ok for ios 9.3 / ipad air 2.
The fact that `-webkit-overflow-scrolling` creates a new stacking context
at every node seems odd, unfortunately removing the rule result in a non
scrolling div at all.
The fix is to explicitely tell the input to appear over the .table-responsive.
This is done by sharing the same stacking context under the common parent
between the form and the list view: .o_list_editable. For that, we prevent
the creation of a new stacking context under .o_form_view by reseting the
`-webkit-overflow-scrolling` to "auto" and we set a dummy z-index to the
inputs element. As they are the only one to have a z-index in this dom
range, they will always appear on top of the table.
With this solution, the `-webkit-overflow-scrolling` is still inherited
correctly and the div is still scrollbale.
This fix unveils another issue with the editable list: if the screen is
too small resulting in an horizontal scrollbar, the table in itself is
scrollable but the inputs aren't.
opw 683169
cherry-pick of odoo/enterprise@35f285e50a
[1] this rule allow a smooth scrolling of the content of a div on iOS
https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-overflow-scrolling
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
[3] https://www.w3.org/TR/CSS2/zindex.html
[4] This commit has been reverted with odoo/enterpise@287cff02c7
and never forward-ported to saas-10.
When the webclient calls do_action from the app_switcher, it toggles it when
the returned deferred is resolved.
The logout client action didn't return anything, so when logging out from the
app switcher, the webclient directly toggled the app_switcher and displayed
the last opened action if any, and a gray screen otherwise.
This commit makes the client action return a deferred which is never resolved,
so the app_switcher isn't toggled when logging out.
This is done in order to enable the tour service only for the
superuser. Commit 6ef1644a7b changed the meaning of `is_admin`
to achieve this but broke the fact that some features of the debug
manager are available to admin and not only to the superuser. Anyway
a `is_admin` key should mean that the user is in the admin group.
We could have checked client side that the uid is equal to 1 but
adding a `is_superuser` key is more elegant and easier to grep.
Also fix the only occurence of a uid check in the weblcient.
This reverts commit 6ef1644a7b.
The tour mechanism displays a tour if the `session.is_admin` key
is set to True. For this key to bet set to True, you need to be
in the system group.
Default options adds the system group to any created user, however as
there aren't any ir.model.access rule defined on the `web_tour.tour`
model, when you try to login as this created user, you get a traceback.
As the only way to reach a `web_tour.tour` record is to have the
superuser_id, update the `is_admin` condition accordingly.
get_formview_action and get_formview_id are methods used notably in a
redirection called from a mail controller used in notification emails.
Those methods however are defined as cr, uid, id and are interpreted
as api.one when called by a new-api style method.
With modules being converted into the new API, those methods are called
as api.one and the result is encapsulated into a list.
To avoid having to take the first element of the returned list we decided
to simplify the call chain and migrate the methods as multi methods, using
ids instead of id. Various addons have been updated accordingly. A temporary
support of ids being an int / long has been added to avoid conflict with calls
using id (for example if javascript is not updated).
The fith arguemnt of the search method in count in new API.
Passing all arguments as positional arguments will make the context passed for
the value of the `count` argument.
bbc67ec is a similar fix in 9.0
Closes#12830
Since version 6.1 the functions set and get on ir.values are deprecated.
The overwrite of the function get on "ir.values" didn't set the context
at the right argument.
opw:682883
This is a temporary workaround, which probably deserves
further thinking by @ged-odo, as the root cause
stems from commit 96bf5b2656
The problem is that the list view looked for composite group_by
keys such as "create_date:month" within `fields_get`, which
only contains true fields.
When there is no `color` field on the model
e.g. On invoice line taxes
The color class to apply on the badge was set to
`o_tag_color_undefined`
which doesn't exist. It must be set
from `o_tag_color_0` to `o_tag_color_10`
in order have a color.
Because of this, the taxes in the invoices lines
were not visible, because they were written in white
on a white background.
This has been broken by the below revision:
fe66472e2c
removing the or statement (`||`) to set a default
color for models not having a `color` field.
We choose to set `10` as default value, so the color
remains the same compared to the previous release
(light grey). However, if the new behavior chosen
by the usability is to have these in black, it should then
be changed to `0` again.
Now that the debug URL parameter can be equal to "assets", the session
debug variable has to be updated to not only be true or false. Now, its
value is false if the debug parameter is not specified in the url and
a the URL parameter string value otherwise (or 1 if the value is an
empty string).
Also modify all redirection which kept the debug mode to also keep
=assets. Use the $.param.querystring function.
Before this rev., the debug manager's state was only updated when pushing a new
action but not when coming back to a previous action using the breadcrumbs.
So when the latter case happened, the debug manager was desynchronized with the
action manager and it allowed to edit an action that wasn't the current action.
issue: xml template are not translated anymore
rev d56b35e2 moved qweb code inside the `qweb.js` file and also changed
the behavior with the introduction of a `QWeb` factory returning instances
of qweb rendering engine. However, we have to set on the rendering engine
instance a `preprocess_node` function that will translate the qweb
templates.
The solution for this issue (also introduced with rev d56b35e2) was
to set this function on the prototype of the QWeb factory, and it was
obviously not enough as it has to be attached to the rendering engine
instance.
In order to benefit from the fact that the `preprocess_node` function
is attached to the prototype of the QWeb factory, we could attach it to
the rendering engine instance with something like
`qweb.preprocessed_node = this.preprocessed_node`, however i find that
conceptually attaching a translate function to a factory does not make
sense, si i simply made `preprocess_node` a free function and i set it
on rendering engine instance.
When using the abbreviated month in the language
date format (`%b`),
e.g. `%d %b %Y`
in some languages, the parsing of the date
from this format to the database format (YYYY-mm-dd)
failed because of a dot `.` added from time to time
to the end of the abbreviated name
e.g., in French, `5 juil. 2016`
This is a bug of `moment.js` < 2.13.0,
handling badly this dot.
This is solved from `moment.js` 2.13.0,
thanks to the below revision
moment/moment@41fdb58572moment/moment#3078
Unfortunately, we cannot update this library to its latest
release in stable release of Odoo (e.g. 9.0),
as this is seen as an unstable change
(if some API changes occured in the given library)
Instead, if the parsing of the date fails with the
strict mode (meaning the date must respect the format
exactly), we perform a second pass without the strict mode,
so this dot will be ignored,
and the date can be correctly parsed.
The issue can be reproduced by loading the French language,
and setting `%d %b %Y` as date format, and then performing
an advanced search on a date field. The value of the date
in the advanced search will be empty without this revision
(for the months having more than 4 chars,
other than `mars`, `mai`, `juin`, `aout`).
Fixes#11854
opw-682534
set_bundle is called twice (one time by the session, another time
by the web_editor). As the `set_bundle` actually drop the dict of
translations instead of updating it and as web_editor only load
the terms of its module, depending on which call to `set_bundle`
ends first result on having your translations or not.
This commit update the database of translation instead of dropping
it, which fixe the current issue (the dict of traductions empty of
the traduction you really need) but another fix would be to remove
the useless call by web_editor when launched in the backend (which
is probably there because it was needed when the web_editor was only
working in the website).
The `on_attach_callback` and `on_detach_callback` callbacks are
called when an a widget is attached / detached according to the
`is_in_DOM` variable. As the community's action manager cannot
be detached from the DOM, we can hardcode this value to true.
This allow to run these callbacks when needed.
In the below revision:
c0db6aec56
The dialog close `reason` was introduced
to not reload the current form if the dialog
has been closed for a reason
(e.g. a window action was returned by the server).
This is to prevent the record reload, which:
- Is useless, as another action has been launched
and the user therefore redirected elsewhere
- Can fail, in the case the initial action deleted
the current record
(e.g. when merging a lead in an opportunity, the
lead is removed, and therefore this is not possible to reload
it).
opw-680180
* Remove dead code + optimization
* Use Dialog API from web module
* Reorganize files
* Correct buggy $() function for snippet option class
* Add comments
* Fix the snippet parent navigation :
If a page contained a three level snippet structure (i.e A contains
B contains C), when editing the following bug occured :
If B or C was selected first, parenting buttons were correctly set.
But if selecting A then C, clicking on the parent lead to going back
on A instead of going on B.
* Fix snippet thumbnail layout
* Better isolate ui css from themes
* MediaDialog image list : prevent displaying empty attachments
* ...
Thibault Delavallée