From 6c97aeee8de0ba495d48e659c9e50a5b4ca33d40 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?G=C3=A9ry=20Debongnie?= Date: Thu, 19 Apr 2018 14:11:40 +0200 Subject: [PATCH 01/42] [FIX] web: use FieldText as fallback for html fields Currently, the default field widget of type html is not defined in the web addon, but in the web_editor addon. It uses the summernote library and different assets. The web_editor addon is defined with auto_install=true, so it is usually not an issue. However, it could happen that there is some issue with the web_editor asset bundles. In that case, any form view with a field of type html will crash. With this commit, we define a default widget of type html in the web addon. This will render as text (so, not exactly what one might expect), but it is still better than making the web client unusable. --- addons/web/static/src/js/fields/field_registry.js | 1 + 1 file changed, 1 insertion(+) diff --git a/addons/web/static/src/js/fields/field_registry.js b/addons/web/static/src/js/fields/field_registry.js index 6692663d5f9..fb7dc432154 100644 --- a/addons/web/static/src/js/fields/field_registry.js +++ b/addons/web/static/src/js/fields/field_registry.js @@ -26,6 +26,7 @@ registry .add('datetime', basic_fields.FieldDateTime) .add('domain', basic_fields.FieldDomain) .add('text', basic_fields.FieldText) + .add('html', basic_fields.FieldText) .add('float', basic_fields.FieldFloat) .add('char', basic_fields.FieldChar) .add('link_button', basic_fields.LinkButton) From b8bf945335f2e52dbd07f2560108f2ee4637598d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?G=C3=A9ry=20Debongnie?= Date: Thu, 19 Apr 2018 14:34:00 +0200 Subject: [PATCH 02/42] [FIX] web: do not change pager when discarding changes Here is a scenario that could happen before this commit: 1. go to a list view with more than one record, say 3 2. click on the 3rd record to open the form view 3. the pager says 3/3 4. click on edit button 5. click on discard button 6. the pager says 1/3 (but the record displayed is still the same) It is often necessary to restore the offset for the sub records, because the number of pages in a one2many could have changed. However, it is not a good idea to do that for the main record, since it interferes with the usual flow of operations. --- .../static/src/js/views/basic/basic_model.js | 2 ++ addons/web/static/tests/views/form_tests.js | 30 +++++++++++++++++++ 2 files changed, 32 insertions(+) diff --git a/addons/web/static/src/js/views/basic/basic_model.js b/addons/web/static/src/js/views/basic/basic_model.js index 8fdcb305ddc..969e81576b1 100644 --- a/addons/web/static/src/js/views/basic/basic_model.js +++ b/addons/web/static/src/js/views/basic/basic_model.js @@ -347,6 +347,7 @@ var BasicModel = AbstractModel.extend({ var element = this.localData[id]; var isNew = this.isNew(id); var rollback = 'rollback' in options ? options.rollback : isNew; + var initialOffset = element.offset; this._visitChildren(element, function (elem) { if (rollback && elem._savePoint) { if (elem._savePoint instanceof Array) { @@ -365,6 +366,7 @@ var BasicModel = AbstractModel.extend({ delete elem.tempLimitIncrement; } }); + element.offset = initialOffset; }, /** * Duplicate a record (by calling the 'copy' route) diff --git a/addons/web/static/tests/views/form_tests.js b/addons/web/static/tests/views/form_tests.js index 8acae55b915..dfd58db57c2 100644 --- a/addons/web/static/tests/views/form_tests.js +++ b/addons/web/static/tests/views/form_tests.js @@ -6525,5 +6525,35 @@ QUnit.module('Views', { testUtils.unpatch(mixins.ParentedMixin); }); + QUnit.test('do not change pager when discarding current record', function (assert) { + assert.expect(2); + + var form = createView({ + View: FormView, + model: 'partner', + data: this.data, + arch: '
' + + '' + + '', + viewOptions: { + ids: [1, 2], + index: 0, + }, + res_id: 2, + }); + + assert.strictEqual(form.pager.$('.o_pager_counter').text().trim(), '2 / 2', + 'pager should indicate that we are on second record'); + + form.$buttons.find('.o_form_button_edit').click(); + form.$buttons.find('.o_form_button_cancel').click(); + + assert.strictEqual(form.pager.$('.o_pager_counter').text().trim(), '2 / 2', + 'pager should not have changed'); + + form.destroy(); + }); + + }); }); From dea07fc29116c36c8a3773eec0fce526a972ba08 Mon Sep 17 00:00:00 2001 From: XavierDo Date: Tue, 20 Mar 2018 12:48:44 +0100 Subject: [PATCH 03/42] [IMP] project, portal: group tasks by project on portal. The portal view for tasks previously listed all task of all projects without grouping them. It was a problem, mainly when we want to make the distinction on project label_tasks, to make the difference between tasks, issues, ... Grouping task by project by default allows to show the label_tasks before each project. Grouping the tasks removes the possibility to define a primary ordering. We want to be able to ungroup the tasks in some cases. The implentation was done in the portalsearch bar adding a group by option. The portal proposes two grouping options, project (by default) and none (to keep strict ordering). Task: #1827950 PR #23769 --- addons/portal/views/portal_templates.xml | 15 +++++ addons/project/controllers/portal.py | 18 +++++- .../views/project_portal_templates.xml | 57 ++++++++++--------- 3 files changed, 63 insertions(+), 27 deletions(-) diff --git a/addons/portal/views/portal_templates.xml b/addons/portal/views/portal_templates.xml index c02573f7613..fef256890ae 100644 --- a/addons/portal/views/portal_templates.xml +++ b/addons/portal/views/portal_templates.xml @@ -195,6 +195,21 @@ +
+ + +
+