for widgets that don't use it, instead of hidding it directly. Doing so, the
control panel is hidden simultaneously with the old view, and there is no more
flickering.
only if the control panel if visible.
This fixes a bug on the settings view (form view), on which the control panel
is hidden (the bar containing 'Apply' and 'Cancel' is unfortunately not a true
control panel). When clicking on 'Apply', for some weird reason, the event
'change:title' is triggered and the control panel is updated with the new title
('New'). However, as the flags hidden isn't mentionned, the control panel
visibility is toggled.
If the module barcodes is installed, a BarcodeEvents singleton is
automatically instanciated. It listens to keypresses and, when a
sequence of keys represents a barcode, it broadcasts a 'barcode_scanned'
event on core.bus containing the barcode string.
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.
When clicking on the breadcrumb to come back to a previously loaded action, the
restore() function is called. With this rev, this old action is shown only once
the Deferred returned by the optional on_reverse_breadcrumb callback is
resolved, i.e. when the action is ready, as it should be.
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.
Bootstrap bind on document to do an element, in some case the bounce effect
on the edit button might cancel the bootstrap action.
e.g in the crm.claim form view, the `group` tag arround a notebook element
break the tab change on the notebook.
opw-646012
note: in 8.0 the issue didn't happen since the tab change was done by
jquery ui which happened before the bounce effect.
The enterprise web client had to be modified to fix a crash. This crash
does not occur in the community web client, but this commit makes sure
that the semantics of the notification manager is the same as the
enterprise version, to prevent future problems.
Many2One fields were broken in views opened by default in edit mode, since rev.
a0ddaf8. The autocomplete widget was appended to the DOM at
'.oe_application > *:visible:last', but since the mentionned rev., the views
are rendered in fragments detached from the DOM, and once they are ready, the
old content is detached and the new one is attached instead. It means that by
appending the autocomplete widget within '.oe_application > *:visible:last',
it is detached from the DOM with the previous content, and Many2One fields can
thus not work.
This rev. simply removes the appendTo option of autocomplete, so that the
widget is directly appended to the body.
Also updates a tour's selector matching an autocomplete ul as it isn't inside
the .modal anymore.
* Correct inheritance of async method
* Correct calls to do_hide/show
* Fetch the template in `willStart`
* Correct bootstrap structure for the layout, remove useless branding
and dom depth
* Each planner page is now in its own bootstrap grid
* Compatibility between both webclients
In previous releases, the search view ignored the selection widget when
the field is a many2one. This behaviour is justifield by the fact that
the selection widget just doesn't work, and the default search input
actually does work.
The search view was refactored extensively in late 2014, and this
behaviour was lost. As a result, every many2one with a "selection"
widget stopped working (for example, warehouse/products, a search for
"you" does not give anything on "location" or on "warehouse"). This
commits simply fix the issue by ignoring the selection widget in search
views (with many2one fields).
boot.js log:
* ``Missing dependencies``:
These modules do not appear in the page. It is possible that the JavaScript
file is not in the page or that the module name is wrong
* ``Failed modules``:
A javascript error is detected
* ``Rejected modules``:
The module returns a rejected deferred. It (and its dependent modules) is not
loaded.
* ``Rejected linked modules``:
Modules who depend on a rejected module
* ``Non loaded modules``:
Modules who depend on a missing or a failed module
Each module can return a deferred. In that case, the module is marked as loaded
only when the deferred is resolved, and its value is equal to the resolved value.
The module can be rejected (unloaded). This will be logged in the console as info.
Remove if_dom_contains from the website, the modules return a rejected deferred if
the DOM doesn't contains the seleted values.
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.
The main purpose of this commit is to be consistent with the enterprise edition,
in which the event 'DOM_updated' is triggered when new content is inserted in
the DOM. This way, addons that need to know when a view has been attached in the DOM
(e.g. web_tip) can listen to this event and will work fine with both editions
of the web addon.
With the actual structure of the webclient (action_manager, view_manager),
there is no easy way to decide whether or not a view is attached in the DOM,
because every rendering is performed in a detached element. For instance,
when a view_manager instantiates a new view, it appends it in its $el once
the view is ready, but it can't know if its $el is attached in the DOM (it is
only the case if the view_manager is the current action of the action manager).
This rev. introduces utility functions to centralize the appending/prepending of
content, so that an event can be triggered (at a unique place) when the content
is really in the DOM. These functions are used by the the action_manager and the
view_manager.
Another change is that the action_manager keeps the view_manager informed when
they are attached in/detached from the DOM, through the variable is_in_DOM.
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
qsm-odoo