summaryrefslogtreecommitdiff
path: root/addons/web/static/src/js/framework/dialog.js
AgeCommit message (Collapse)Author
2016-03-24[MERGE] forward port of branch saas-9 up to 59d3f63Christophe Simonis
2016-02-23[IMP] web: update Dialog classqsm-odoo
Update Dialog class with enterprise version.
2016-02-23[FIX] web: Dialog closingqsm-odoo
The Dialog class destroys the modal (and so removes it from the DOM) when the dialog closes but leaves the modal-open class on the body element if there are still other modal(s) in the DOM. The problem is that (maily on the frontend side) there may be others modal(s) in the DOM (not handled by the Dialog class) but which are not shown to the user, and in that case the modal-open class should be removed.
2015-09-01[IMP] web: dialog: wait for button's onclick handler to closeAaron Bohy
When a button in the modal's footer has an onclick handler and closes the modal, the action of closing the modal should wait for the potential deferred returned by the handler. For instance, if an handler performs an asynchronous call and, when resolved, triggers a notification, the notification doesn't reach the webclient if the modal is already closed because the widgets hierarchy is broken.
2015-07-29[IMP] web: alert/confirm dialogs default titlesqsm-odoo
Add "Alert" and "Confirmation" as default titles for alert and confirm dialogs
2015-07-27[IMP] Add Dialog.alert featureqsm-odoo
This allows to open a simple message dialog with potential action when the unique "ok" button is clicked
2015-07-01[IMP] web,web_kanban: Dialog.confirm apiAaron Bohy
takes now an object of options for the Dialog, containing two possible callbacks (for confirm and cancel).
2015-06-17[IMP] web, web_*, mail, board : New modals and dialogsqsm-odoo
2015-03-18[IMP] web+addons: improvement to module systemGéry Debongnie
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.
2015-03-18[REF] web: add module system to the web clientGéry Debongnie
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