| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* Tip are never destroyed when change view mode
* unbind methods
* mail: memory leak with unbind methods
* web: memory leak because 'ui-autocomplete' is never destroyed
* web_editor: memory leak for wrong unbind on destroy
* web: memory leak: must remove fileupload handler
* bus: memory leak: correctly debind handlers on window in bus.Bus
* remove handlers on switch buttons and views $buttons
* remove handlers on breadcrumbs
* web: memory leak: correctly debind handlers
* im_odoo_support: memory leak: remove fileupload handler odoo_support
Note: part of this commit was actually authored by aab
|
|
Commit of xmo that has been lost by the unduplication of webclients (6768bbfc).
|
|
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
|
|
Introduction of 'data_manager' service which handles meta-data related to
actions and views (fields_views, fields and filters). Ideally, all RPCs to
get that kind of information should go through data_manager, as it holds an
internal cache.
|
|
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.
Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.
The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.
Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
heavy processing.
- Remove view_type attribute from views as it was used to call
fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
lifecycle of widgets (init -> willStart -> start -> destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
action buttons to wrap handlers to ensure that they are executed only if
the form_view is the current active view. This is not useful anymore as
from v9, views and their control panel are appended in the DOM
simultaneously, so one can't click on a button of a view which is not the
current active view.
|
|
unused since rev. odoo/odoo@4a5cb1ebc478cb650a2bf33081f101e4f74bc6fe.
|
|
This attribute can be used when the view needs a searchview but wants it to be hidden.
|
|
Add a key icon in the view's prototype corresponding to the font-awesome icon
to display in the view switcher.
|
|
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.
|
|
|
|
type action in help message and fix account dashboard help message
|
|
this.options.$sidebar usage has been changed at rev. 1280bf25137ee210b555201157029da61ae3914f
and a flag this.options.sidebar was introduced ($sidebar now simply
represents a jQuery element where the sidebar has to be rendered,
whereas sidebar represents whether or not a sidebar has to be rendered).
The old variable $sidebar was still used for the rpc to get the content
of the sidebar stored server-side, resulting in a sidebar with missing
content.
|
|
The 'New node' button is inserted in the ControlPanel. Breadcrumbs
are now handled as well.
The 'multi_record' flag has been added to the views to distinguish views
displaying several records, like the List view, from views displaying
a single record like the Form view and the Diagram view. This flag is
used by the ViewManager to manage its view stack. Fixes the breadcrumb
bug when switching between Form view and Diagram view (the last element
of the view stack is now replaced by the new one in that case).
|
|
Change the logic of rendering and displaying/hidding the control
elements (buttons, sidebar and pager) of all views. The views do no
more render automatically their elements as this is rather done
through the render_[element] function called by the ViewManager.
This function only appends the element to the $node given as argument.
If no argument is given, then it may appends it to the DOM directly,
within the adequate div of its template.
This allows the ViewManager to attach/detach all elements of the
ControlPanel in an atomic may, to prevent the ControlPanel from
flickering.
Also detach the contents of the ControlPanel in headless mode. Headless
means that the ControlPanel exists, but is hidden. Detaching its
contents permits to have a cleaner DOM.
Also remove the oe_form_dirty class on the buttons in the FormView, as
this class is only used on the view itself.
Side changes:
* base_import: import.js:
Extend render_buttons function to be compliant with the new buttons
rendering logic
* board: dashboard.js:
Set flag search_view to True as the searchview is needed for the
Views displayed in the Dashboard to retrieve the records to display.
Necessary since we do no more construct the searchview when this
is set to false
* google_drive: drive.js,
share: share.js:
Module extending the Sidebar widget often add their own buttons
by extending the start(), which is called each time the Widget
is appended to the DOM. With our new design, this could be done
in start() anymore as it should be done only one. It is now done
in init() instead.
|
|
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
|
|
This commit introduces a new module system for the javascript code.
Instead of using global (namespaced) variables everywhere (like
openerp.web.whatever, ...), each file declare one (or more) module
with its dependencies. Each module will be loaded after its
dependencies, and will be given a reference to the return values.
This change is a massive departure from the way the client worked
previously. It will sadly break some/most history, but I am sure that
the future git ecosystem will allow you to easily browse the history
past this revision (one can dream).
This commit feature:
* main namespace is now odoo instead of openerp
* a way to define modules and dependencies (inspired by requirejs)
* many files have been splitted in simpler subfiles
* basic support for debugging in odoo.__DEBUG__
* no global variable (i.e. nothing in window.openerp)
* many bug fixes, many new bugs
Future vision: this modularization should simplify future code
development, simplify debugging and will allow a serious testing effort
|
