From 3d6420d4b3f062f12d7c18d7d9a976e2299b3444 Mon Sep 17 00:00:00 2001 From: Aaron Bohy Date: Tue, 25 Jul 2017 13:27:07 +0200 Subject: [FIX] web,*: display dashboard panel if no content *board,crm Before this rev., the dashboard panel (e.g. of the sales team dashboard) wasn't displayed when there were no record to display, whereas it should. Only the nocontent helper was displayed. This was a bug introduced with the new view: the views' controller was in charge to display the renderer (if there were data to display) xor the nocontent helper. As the dashboard panel was rendered by the renderer, it couldn't be displayed alongside the nocontent helper. This rev. moves this logic to the renderer. So now, the controller always contains the renderer, which decides what to render (the data or the nocontent helper). This way, the dashboards can display their panel and the nocontent helper. --- addons/web/static/src/js/views/basic/basic_controller.js | 11 ----------- 1 file changed, 11 deletions(-) (limited to 'addons/web/static/src/js/views/basic/basic_controller.js') diff --git a/addons/web/static/src/js/views/basic/basic_controller.js b/addons/web/static/src/js/views/basic/basic_controller.js index cc72816a85d..54c8ccfbf51 100644 --- a/addons/web/static/src/js/views/basic/basic_controller.js +++ b/addons/web/static/src/js/views/basic/basic_controller.js @@ -361,17 +361,6 @@ var BasicController = AbstractController.extend(FieldManagerMixin, { model: this.modelName, }; }, - /** - * Used by list and kanban views to determine whether or not to display - * the no content helper (if there is no data in the state to display) - * - * @private - * @param {Object} state - * @returns {boolean} - */ - _hasContent: function (state) { - return state.count !== 0; - }, /** * Helper function to display a warning that some fields have an invalid * value. This is used when a save operation cannot be completed. -- cgit v1.2.3 From 28bf5f007fd777f7cf2c8f85ea9938b288d391f0 Mon Sep 17 00:00:00 2001 From: David Monjoie Date: Mon, 31 Jul 2017 14:48:50 +0200 Subject: [FIX] web: fix action context with no explicit context When I did efd15852, I accidentally undid d20074c5. That commit wanted to filter out unwanted values from the action context, but it was too violent, as it was discarding the action context. (See bug described in efd15852) My original commit aimed at avoiding the filtering of the action context by having it devoid of unwanted values altogether. The idea was "if this is an action button, we don't want the element context". However, the default behavior of the _getContext function was to add the element context. There were options to force to add the element context despite being in a case where it should not be added, but we needed the opposite: do not add the element context. We used "additionalContext" in this fashion, the idea was: "if I give you specific context values, don't polute it with the element context". This was efd15852. However, not all actions have context defined explicitely in their definition. In this case, since additionalContext was undefined, the element context was added again, despite our will not to add it for actions. We solved this by simply always giving an additionalContext to getContext, providing an empty one if needed. To reproduce this bug (which is the same as efd15852): - Go to Manufacturing - Click on menu Master Data then Products - Open a product - Click on the "Bills of Materials" stat button - Click on create - The create crashes because of the "default_type" context key that is erroneously passed from the "Products" action to the "Bills of Materials" stat button action. --- addons/web/static/src/js/views/basic/basic_controller.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'addons/web/static/src/js/views/basic/basic_controller.js') diff --git a/addons/web/static/src/js/views/basic/basic_controller.js b/addons/web/static/src/js/views/basic/basic_controller.js index 54c8ccfbf51..39e596db5b8 100644 --- a/addons/web/static/src/js/views/basic/basic_controller.js +++ b/addons/web/static/src/js/views/basic/basic_controller.js @@ -238,7 +238,7 @@ var BasicController = AbstractController.extend(FieldManagerMixin, { var recordID = record.data.id; this.trigger_up('execute_action', { action_data: _.extend({}, attrs, { - context: record.getContext({additionalContext: attrs.context}), + context: record.getContext({additionalContext: attrs.context || {}}), }), model: record.model, res_ids: [recordID], -- cgit v1.2.3 From 211961c3747b5948e80ad8eb6f097636bc61b46d Mon Sep 17 00:00:00 2001 From: Martin Geubelle Date: Tue, 1 Aug 2017 17:55:24 +0200 Subject: [FIX] web: handle `mutexify` in standalone widgets The rev. https://github.com/odoo/odoo/commit/99ae418bf24171fbc6bb27584059c27efb857e77 introduced a trigger_up `mutexify` when quick creating a record in a many2one ; this broke the behaviour when the many2one was standalone (because it has no BasicController and mutexify is handled in the latter). An attempt to fix this issue has been made in the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7 by adding an option `standalone` in the field widget options. In this case, the action was directly executed instead of the trigger_up. While this correctly works, this implies that the option needs to be added in every standalone many2one (and only many2one as the others won't use the option), which is not very convenient. An other attempt is made in this rev. by moving the mutexify handler from the BasicController to the FieldManagerMixin ; as a widget that instantiates a field widget needs to extend this mixin, both cases will work and we won't need to specify the option anymore. This commit thus partially reverts the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7 --- addons/web/static/src/js/views/basic/basic_controller.js | 12 ------------ 1 file changed, 12 deletions(-) (limited to 'addons/web/static/src/js/views/basic/basic_controller.js') diff --git a/addons/web/static/src/js/views/basic/basic_controller.js b/addons/web/static/src/js/views/basic/basic_controller.js index 39e596db5b8..3a47f65ab03 100644 --- a/addons/web/static/src/js/views/basic/basic_controller.js +++ b/addons/web/static/src/js/views/basic/basic_controller.js @@ -8,7 +8,6 @@ odoo.define('web.BasicController', function (require) { */ var AbstractController = require('web.AbstractController'); -var concurrency = require('web.concurrency'); var core = require('web.core'); var Dialog = require('web.Dialog'); var FieldManagerMixin = require('web.FieldManagerMixin'); @@ -19,7 +18,6 @@ var _t = core._t; var BasicController = AbstractController.extend(FieldManagerMixin, { custom_events: _.extend({}, AbstractController.prototype.custom_events, FieldManagerMixin.custom_events, { discard_changes: '_onDiscardChanges', - mutexify: '_onMutexify', reload: '_onReload', sidebar_data_asked: '_onSidebarDataAsked', translate: '_onTranslate', @@ -39,7 +37,6 @@ var BasicController = AbstractController.extend(FieldManagerMixin, { FieldManagerMixin.init.call(this, this.model); this.handle = params.initialState.id; this.mode = params.mode || 'readonly'; - this.mutex = new concurrency.Mutex(); }, /** * @override @@ -526,15 +523,6 @@ var BasicController = AbstractController.extend(FieldManagerMixin, { } FieldManagerMixin._onFieldChanged.apply(this, arguments); }, - /** - * @private - * @param {OdooEvent} ev - * @param {function} ev.data.action the function to execute in the mutex - */ - _onMutexify: function (ev) { - ev.stopPropagation(); // prevent other controllers from handling this request - this.mutex.exec(ev.data.action); - }, /** * When a reload event triggers up, we need to reload the full view. * For example, after a form view dialog saved some data. -- cgit v1.2.3