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
When an input is saved with an invalid value, it gets the
`o_form_invalid` class. This makes the border red. In enterprise, there
was a bug as required inputs have also a different border color and the
rule was more important. Unfortunately there is no avoiding
the !important rule here. Indeed, other solutions would require to make
more rules in enterprise or to change the order of files (which would
create many problems).
Forward-port of https://github.com/odoo/enterprise/commit/8a55b3f9f7a7524583effb8198c03ebf695131bd
There are multiple problems with the editable view list. It should be
solved once and for all in the work-in-progress master.
This commit fixes a bug with readonly checkboxes. When a field is
readonly, the table cell gets the "o_readonly" class which changes
its style and behavior. When entering edition, the cells are hidden
except the ones with this "o_readonly" class so that their style are
not affected. The "o_readonly" cell content however was hidden thanks
to a "color: transparent;" rule to let the form readonly field show
the value. The problem is that checkboxes... are not hidden with this
"color: transparent;" rule. Also, the "o_readonly" class is not toggled
during edition while the readonly status could be... so the right fix
would be to get rid of this "o_readonly" class and let the inline form
handle the behavior, but this would affect style and possibly break
unknown behavior.
This fix adds rules to handle the checkbox case correctly.
Fix and issue is similar to odoo/odoo@1f06cc416
When clicking on delete icon before saving current list row edition (by
clicking outside the editable field), it could lead to traceback in some instances
because the deletion and saving are done concurrently.
closes#627
opw-695743
Since Chrome 53.0.2785, the input select is hover the existing tag.
With this fix, the existing tag are displayed at the right side of
the input to create a new one.
This commit closes#13655
Courtesy of @8cells
Change color #a24689 to #875A7B
Commit https://github.com/odoo/enterprise/commit/8ac1c19fac7615fecd51e670f798d13158a4e53c
changed the odoo interface violet by changing the main LESS variable
but forgot there was many direct occurences in XML/HTML/... (for
example for the mobile browser color).
Even if it's community the odoo interface violet is used at many places
(module description, XML demo data, ...).
Since the merge of the two modules 'web' from enterprise and community
it was impossible to scroll in the side menu and in the main content
of a community database from Internet Explorer 10 & 11 but it is working in
Edge.
This was due to missing css 'height' attribute on the '.o_main' class
that should be set to 100% for IE to let the flex elements know the
size of their parent.
This was introduced in rev https://github.com/odoo/odoo/commit/977db823c
* display all lines and don't display the scroll bar into ace editor
* lazy read ace lib and add missing lib file
* use not minified version of ace lib
* Move ace lib from website to web
* Added ace widget for webclient
* XML mode for view text box
* Python mode for server action text box
* Removed web_ace_editor.xml, instead added template in base.xml itself
* Added widget=ace_editor in compute field of ir.model.fields
When positioning an element in an editable list view, that element is
temporarily forced to display: block thanks to the class o_temp_visible
The rule is written in LESS thanks to:
.o_list_editable .o_temp_visible { display: block!important; }
which is ok for normal invisible form fields because it is written as
.o_form_view .o_form_invisible { display: none!important; }
which has the same priority but is defined before the o_temp_visible
rule, so the display is properly forced to block.
However, for some reason, there also is the rule:
.modal .modal-dialog .o_form_invisible { display: none!important; }
which has a higher priority than the o_temp_visible rule.
This is why appearing invisible fields in editable list view in modals
are at a wrong position.
The solution introduced by this commit is the safest: adding a new
rule to force display block!important on the selector:
.o_list_editable .o_temp_visible.o_form_invisible
The main content of the web client was set to grow/shrink so that it
fills the window (thanks to flex). However, to be able to shrink as
much as necessary the min-height needs to be forced to 0.
Without this fix, the web client was overflowing on the bottom of the
page, making impossible to access some menu items.
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.
This reverts commit f38f8930f0.
Revert for internal choice. Odoo want to use qweb in template and remove jinja support on next version.
If users want to use jinja they can change the view to use text widget instead of html widget.
The preview change the content because the browser try to fix the dom.
If a user use jinja and activate the preview, the jinja code is (re)moved by the browser and broke the template.
With this commit, actions can have a type=fullscreen. This means that
the navbar will be hidden, for the action and for all subsequent actions
open in the breadcrumb
There is no real security behind this, this is just a feature for
convenience, so users can bookmark an url an open some action in a way
that they are not distracted by anything. In short, this is some kind of
light 'kiosk' mode.
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.
Mainly:
- JS refactoring and linting
- Conversion of .sass into .less split into multiple files
- Templates cleaning and DOM simplification
- Re-generation of web.pot, and update of .po files
In 9.0's 05adb7f the `<div class="address_format"/>` wrapping an address
city, state_id and zip fields was removed.
There is a hack on fields_view_get which transform this block depending
on the company country, so without the block the feature isn't enabled.
This commit adds a class on the new block `<div class="address_format"/>`
used to wrap the whole address which will change the sizing of the city,
state_id and zip fields as it was before version 9.
To fully follow what was done previously, the zip is aldo moved before
the city if the address format needs it.
Thus we now have as before the three format as follows:
[default format]
city state zip
[format .o_city_state (brazil)]
city state
zip
[format .o_zip_city (belgium, netherlands, ...)]
zip city
state
Another change is brought by this commit, before most element attributes
from city, state_id and zip fields were lost whilst doing the hack, now
they are all kept.
closes#10692
opw-666567
Christophe Simonis