| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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
|
|
Fixes #15147
|
|
If the graph view was left while a nvtooltip was shown (thanks to
keyboard shortcuts or during loading time), the nvtooltip remained
and was only destroyed when leaving the action.
Now they are automatically removed with the view as they are now
placed inside of them instead of inside the body element.
|
|
When clicking on the trash to remove a line (e.g. a sale order line
in a quotation form view) while editing another line, it produces a
traceback (in most cases), or behaves randomly (less frequently)
like removing both lines, or one of them, or maybe none of them.
Anyway, this feature doesn't work at all, so this commit simply disables
it when we are in edition mode.
In a perfect world, we would fix the feature instead of disabling it,
but the code of the list editable is so instable that it would most
certainly break something else.
Closes #13778
|
|
This tries to be the smallest patch possible in order to avoid triggering
another display issues, so we only patch in the ms-hight-contrast section
which only applies on ie 10/11.
* The view-manager weren't displayed correctly; they didn't fit 100% of
the screen width. This is fixed by explicitely seting the top, right,
left, bottom attributes.
* The modals content were not displayed. This was due to 2 issues:
* The rule that we patch in the first point set the position of
`oe-view-manager` as absolute with an importang flag. Because of
this important, the rule that reset the position of the
`oe-view-manager` as static in modals.less was not honored. So
we also patch this rule with an important flag inside the same
file (so that all the fixes related to ie10/11 are in the same
place).
* Now that the modals are displayed, they do not fit 100% of the
screen. It's because the `max-height: 100%` of `.modal-content`
set in modals.less does not work in ie10/11, due to some bug
with the flex displays. We set the height to 450px so that the
modals are kind of correctly displayed on a 1366x768 screen
(their content are still scrollable).
related to rev 1ccd87a03753c69a2e12c585de388434ef9ff557
closes #12929
|
|
Makes the fix in f992c8ee192c075b38bf14dd5dcfb10fba7dd2ef
specific to the view manager of the main oe_application
container, in order to avoid disrupting other view manager
occurrences (such as the ones in modal windows or x2many
list views).
Fixes #11629 (again)
Note: Hopefully the Blink team will fix Chrome so we can
get rid of this hack in the future:
https://bugs.chromium.org/p/chromium/issues/detail?id=603507
|
|
This reverts commit f992c8ee192c075b38bf14dd5dcfb10fba7dd2ef which
should not be forward-ported.
|
|
|
|
A 100% height is not distributed anymore to the children of a table-row
if they are not themselves table-cell in Chrome 50. This breaks the
indenpendent scrolling of the menu and the view manager.
However, setting the `table-cell` display breaks the layout in Internet
Explorer.
When the webclient is loaded by Chrome 50, we load a stylesheet
forcing a `table-cell` for display.
Seems to be related to https://bugs.chromium.org/p/chromium/issues/detail?id=353580
and https://chromium.googlesource.com/chromium/src.git/+/8876584335b48c99cf8df552ef4d8efebb131041
Related to e1a99192bda1019a50be879cb0baaa72d447956a
Fixes #11629
|
|
or how to break every internet explorer releases while
attempting to fix chrome 50
|
|
The height was not distributed anymore to the children of a `table-row`
element if they are not themselves `table-cell` elements.
Fixes #11629
|
|
In languages where the thousands separator is a space, numbers could
be wrapped over multiple lines.
|
|
When editing a line, leave the buttons visible.
Also remove the 3px gap between fields so that readonly field texts
does not move when entering the edition mode.
|
|
In most backend views using CTRL+P to use browser printing would only
print an header without the content.
stumbled-uppon-when-checking: opw-659430 opw-660763
|
|
In most backend views using CTRL+P to use browser printing would only
print an header without the content.
stumbled-uppon-when-checking: opw-659430 opw-660763
|
|
As .oe_form_sheetbg was not position:relative, tips position was
sometimes wrong as the statusbar is loaded after the tips positions
are computed.
|
|
Like view manager containers, client action containers needed the
overflow:auto property to compute their correct height inside their
flex context. This also allows client action as the reconcilation in
accounting to not care about their height.
|
|
(backport of enterprise version)
* JS/XML refactoring
* Allow user to override default options for the picker
|
|
Elements which are not displayed (display: none) cannot be positionned
correctly by jQueryUI in a listview editable. Therefore, the solution is
to make them visible (but opacity: 0) during the time their position is
being computed.
This was a problem because a listview editable field may become visible
under some conditions AFTER their position was already computed.
|
|
* Convert CSS to LESS.
* Put file in assets_common instead of both backend and frontend.
|
|
The widget SelectCreatePopup display the search view drawer directly
after the search view input field. But in current firefox version this
could lead to an issue with float positionning.
fixes #8462
opw-648999
|
|
|
|
|
|
oe_form_binary_form -> o_form_binary_form
oe_form_binary_file -> o_form_input_file
Required for new design compatibility (classnames accessed in addon mail)
|
|
A 'display: none' rule on hover has been added for boolean buttons, on each
'o_stat_button o_stat_text' that hasn't classname o_hover. This applies on
every stat button that isn't a boolean button, so their content is always
hidden on hover.
|
|
The widget now provide labels that depend on widget option "terminology". For
each terminology, it provides four button labels that are shown depending on
the field's value and hover status on the button.
|
|
translations
In practice, we replace:
<field name="active" widget="boolean_button"
options='{"true": "Active", "false": "Inactive"}'/>
by:
<field name="active" widget="boolean_button">
<span class="o_stat_text o_true text-success">Active</span>
<span class="o_stat_text o_false text-danger">Inactive</span>
</field>
|
|
|
|
Widgets and website display images or display the type with icon like pdf, doc...
|
|
|
|
Remove the style defined on oe_button as it overrides bootstrap rules like
btn-primary, btn-default...
|
|
The widget was completely broken when usign the horizontal display.
It has been fixed, hopefully in a way that lessen the xml and
css.
|
|
|
|
In internet explorer, writing direction can lead to wrong text direction
when combined with rotate.
A fix was already in place for IE up to version 9 but the issue also
happens in next versions which are more difficult to differentiate
(especially the current spartan/edge version).
So this fix use the same css property value for all browser and it doesn't
seem to have an impact (other than correcting the issue in IE).
closes #7955
opw-646430
|
|
Add a key icon in the view's prototype corresponding to the font-awesome icon
to display in the view switcher.
|
|
The DOM structure and elements's classnames diverge in community and enterprise
editions. Tips must work perfectly with both editions, obviously.
This rev. updates some classnames in the community edition for the tips's selectors
to match in both editions.
The following classnames have been renamed/introduced:
- oe_form_buttons_view renamed to o_form_buttons_view
- oe_form_buttons_edit renamed to o_form_buttons_edit
- oe_form_invisible renamed to o_form_invisible
- oe_list now also has classname o_list_view
- header tag in form views now has classname o_form_statusbar_buttons
Other changes like these might be required later if other tips are introduced...
|
|
Buttons that are not stat buttons couldn't use font-awesome icons, as it
automatically fallbacked on the icons in /web/static/src/img/icons. This was
the case for several templates where the icon thus couldn't be found as it was
looking for a font-awesome icon in the icons folder (e.g. fa-cog.png).
Also cleans some unused less rules defined on the stat buttons in
enterprise_compatibility.less
|
|
Since rev. 16eb36ff, do_show() and do_hide() on widgets toggle the classname
o_hidden on which the rule 'display: none' is defined, instead of calling
jQuery's show() and hide().
The method do_toggle(), sharing the same logic, has been introduced in rev.
74c5f772.
From now on, every widgets should call do_toggle() instead of $el.toggle() as
it will have undesiderable effects (they should call do_show() and do_hide()
instead of $el.show() and $el.hide() as well, this as been done in 16eb36ff).
This rev. replaces all calls to $el.toggle() by do_toggle(). It also adds
an optional argument to do_toggle() to force hidding or showing the widget.
|
|
Refactoring of the DOM structure and classnames of the list view's action
buttons (in the control panel), for new design compatibility. This refactoring
was required as some addons shared between both editions (e.g. base_import)
define their own buttons and extend the ListView.buttons template to insert
them.
|
|
this way we can style the div and use the trick to have the child of a
flex-item filling 100% of its parent (flex item in relative position and
flex child in an absolute position). It is needed to have a consistent
look betwenn Odoo enterprise and Odoo community.
|
|
|
|
instead of the others, which are displayed in purple.
|
|
The problem of $el.show()/hide() is that calling show() on a jQuery element on which
there is no display rule in the stylesheet automatically sets 'display: block'.
However, when a jQuery element is not yet in the DOM, the rules defined on it are not yet
applied, meaning that calling show() will set its display to block (in inline style),
even if there is different a css rule (e.g. 'dislay: flex'). As the inline style takes the
priority over the stylesheet, the correct display won't be applied, even when the widget
will be appended in the DOM, resulting in a possibly broken layout.
|
|
Adapt the Favorites menu so that addons appending stuff in it are compliant with
the enterprise edition.
Mainly, creation of dashboard.less from of dashboard.sass so that we can use mixins
defined in the web addon.
Some changes as well in the dashboard view to make it compliant with the enterprise
edition.
Use correct naming convention: classnames with underscores, less mixins with hyphens.
|
|
|
|
If too many tags (or too long tags) where present in a many2many tags
widgets, it could go over the field and cover other thing in the UI.
Now the field size expands with the content (and in a way it is more
visually similar before and after 'Edit' so it is nice).
closes #7579
opw-644236
|
|
for html field) and website
|
|
|
