This commit is related to 8d49639933 and b88755c431
When hitting buttons of type object, the active_model and active_id(s) were kept, and, therefore, when calling a feature using the active* args, this feature used the active* args from the previous action.
Nevertheless, concerning wizards, the active* args should be indeed the active* args of the previous action, as wizards expects to have the active* args from the previous action. Thus, we reset these active* args only when this is not a wizard (target === 'current')
For example, from a sales order, hit the 'view invoice' button, and on the invoice, hit the 'send by email' button: The active_id in the send by email wizard were the id of the sale order, not of the invoice
* oe_searchview_custom has been split in oe_searchview_custom and
oe_searchview_filter: a test need to take that into account
* in adjust_top, the parent might not have a $ method.
* separate the css class oe_searchview_custom into oe_searchview_custom
and oe_searchview_savefilter to be able to style them independently
* by default, the drawer has display:none
* fix a bug occuring when the user removed a custom filter (it hid the
remaining filters)
the header height is not fixed, it can change when the breadcrumbs
start a new line, or when there is only one view type (for ex, in most
reporting views). So, the top value of the view_manager_body has to be
adjusted accordingly.
the mail menu is a client action, so not subject to the same template
as regular views. so, it had to be patched to properly scroll like
other views (meaning: the 'header', left menu and top menu are fixed)
Also, changes the width of the searchbbar into a min-width css property,
to allow it to grow more. The reason is that we don't want the searchbox
to take two lines (or more), which will force the view_manager_header to be
higher, and which will cause slight issues with the scrollbar (absolutely
positioned)
[FIX] Multiple report fixes including better handling of rendering a report with one worker (and the removal of the workers creation) and some report views changes (address block more to the left)
(1) it seems that position:relative behaviour is undefined in a td,
so it has been moved to the div below oe_application
(2) the left menu bar can now scroll vertically if necessary.
when a view_manager is contained inside another, the
css rule for defining a scrollable zone (with position:absolute)
was also applied to the inside view manager.
etenesaca