pengyuthon/odoo_source
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[FIX] mail: keep update of subtypes in dropdown

Browse Source 
Since saas-11.4 the subtype dropdown don't keep changes of subtype.

Before saas-11.4 the update was relying on the fact that the follower id
changes on each subtype edition. This is no longer the case.
The test is addapted to remove the hack simulating this behaviour.

The read_followers route is not called if no there is no changes
in the follower ids
https://github.com/odoo/odoo/blob/905e01921f3c3ef43ace6fc537d1d8c0d280002c/addons/mail/static/src/js/followers.js#L195
Leading to the follower list not being update

Note that the subtype update in dropdown was working fine after adding a
new follower: the read_followers will return a None as suptype when called
for a list of partner not containing the current user. Since the subtypes
was falsy, the render was not rendering the dropdown again, keeping
the value of the checkboxes. We can still create some inconsistency by
editing the subtype from the follower list. To avoid that a check is made
when updating subtypes after calling read_followers.

The chosen solution here is to keep the update on subtypes in memory.
This will avoid a call on read_followers to fetch information that we
already know, using the assumption that the operation was successfull
whish should be the case when a user edit subtypes on a record
he has access to.

Others solutions:
-force the call to read_followers with the current user, maybe by removing
it from this.follower after editing subtypes.
-call read_subscription_data explicitely

Obviously follower.js should be refactored to fix this a better way.

Task: #1886982
PR: #27093
This commit is contained in:
XavierDo
2018-09-19 14:10:19 +02:00
parent d30fa83114
commit 97dbdc418d
2 changed files with 13 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
addons/mail/static/src/js/followers.js
+12 -1
View File
@@ -203,7 +203,9 @@ var Followers = AbstractField.extend({
return $.when(def).then(function (results) {
if (results) {
self.followers = _.uniq(results.followers.concat(self.followers), 'id');
self.subtypes = results.subtypes;
if (results.subtypes) { //read_followers will return False if current user is not in the list
self.subtypes = results.subtypes;
}
}
// filter out previously fetched followers that are no longer following
self.followers = _.filter(self.followers, function (follower) {
@@ -290,6 +292,15 @@ var Followers = AbstractField.extend({
});
} else {
var kwargs = _.extend({}, ids);
if (follower_id === undefined || follower_id === this.partnerID) {
//this.subtypes will only be updated if the current user
//just added himself to the followers. We need to update
//the subtypes manually when editing subtypes
//for current user
_.each(this.subtypes, function (subtype) {
subtype.followed = checklist.indexOf(subtype.id) > -1;
});
}
kwargs.subtype_ids = checklist;
kwargs.context = {}; // FIXME
this._rpc({
addons/mail/static/tests/chatter_tests.js
+1 -5
View File
@@ -1449,11 +1449,6 @@ QUnit.test('followers widget: follow/unfollow, edit subtypes', function (assert)
_.each(subtypes, function (subtype) {
subtype.followed = _.contains(args.kwargs.subtype_ids, subtype.id);
});
// hack: the server creates a new follower each time the subtypes are updated
// so we need here to mock that weird behavior here, as the followers widget
// relies on that behavior
this.data.partner.records[0].message_follower_ids = [2];
followers[0].id = 2;
} else {
// follow
this.data.partner.records[0].message_follower_ids = [1];
@@ -1472,6 +1467,7 @@ QUnit.test('followers widget: follow/unfollow, edit subtypes', function (assert)
return $.when({
followers: followers,
subtypes: subtypes,
// caution, subtype will only be returned if current user is in args follower list
});
}
if (route === '/web/dataset/call_kw/partner/message_unsubscribe') {