From 2014fabfbaf2e24a047881deb404844a81c7bbc1 Mon Sep 17 00:00:00 2001 From: Nicolas Lempereur Date: Tue, 30 Jan 2018 15:01:39 +0100 Subject: [PATCH 1/5] [FIX] web_editor: firefox editor hidden mass mail When saving a modified mass mailing, the editor will do a number of things to improve the mail readability accross mail client. One of those is replacing font awesome icons by image, but firefox acts differently than other browser. On a display:none iframe, doing .css('color') or .height() on an element returns respectively `undefined` and 0. This caused an error when getting the color that we could solve by doing a fallback for firefox like this: window.parent.getComputedStyle($font[0]).color But to get the height() of an element, it seems we always need the iframe displayed. With this change, when the iframe is hidden and the browser is firefox, the code try to display the iframe (with "visibility:hidden;height:1px") when this part of the code happen. note: backport of 10.0 13c326caaa opw-807180 closes #22701 --- addons/web_editor/static/src/js/backend.js | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/addons/web_editor/static/src/js/backend.js b/addons/web_editor/static/src/js/backend.js index 2b3c0e0790c..8677b683da5 100644 --- a/addons/web_editor/static/src/js/backend.js +++ b/addons/web_editor/static/src/js/backend.js @@ -407,7 +407,19 @@ var FieldTextHtml = widget.extend({ var layoutInfo = this.editor.rte.editable().data('layoutInfo'); $.summernote.pluginEvents.codeview(undefined, undefined, layoutInfo, false); } + var $ancestors = this.$iframe.filter(':not(:visible)').parentsUntil(':visible').addBack(); + var ancestorsStyle = []; + // temporarily force displaying iframe (needed for firefox) + _.each($ancestors, function (el) { + var $el = $(el); + ancestorsStyle.unshift($el.attr('style') || null); + $el.css({display: 'initial', visibility: 'hidden', height: 1}); + }); this.editor.buildingBlock.clean_for_save(); + _.each($ancestors, function (el) { + var $el = $(el); + $el.attr('style', ancestorsStyle.pop()); + }); this.internal_set_value( this.$content.html() ); } }, From 76665df0cfc765483c8d2856ad9579e9d7b6b58d Mon Sep 17 00:00:00 2001 From: qsm-odoo Date: Wed, 31 Jan 2018 13:11:18 +0100 Subject: [PATCH 2/5] [FIX] website_forum: allow portal users to post replies to replies Before this commit, when connected as a portal user, the user was not able to post replies to existing replies. This is because the textarea section was marked to be displayed for connected internal users only. This commit removes the whole group restriction. Indeed, it makes sense (as a fix), to show the textarea section for public users too. Indeed, the "Reply" button is already shown to public users but does not do anything. With this commit, clicking the "Reply" button shows the textarea section for everybody and, if the user is not connected, redirects to the login page when posting the message. This of course needs usability improvements in master. Note: the problem had originally been fixed for regular answers with commit https://github.com/odoo/odoo/commit/b81b03c82d282dc94595a9beb94444041509ef25 Note 2: both mentioned problems were originally introduced by commit https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7 Closes https://github.com/odoo/odoo/issues/22648 --- addons/website_forum/views/website_forum.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/addons/website_forum/views/website_forum.xml b/addons/website_forum/views/website_forum.xml index d6bef90930a..e06f78e4108 100644 --- a/addons/website_forum/views/website_forum.xml +++ b/addons/website_forum/views/website_forum.xml @@ -667,7 +667,7 @@