Review: Needs Fixing Hello,
I think we can simplify the overall structure of the merge. Actually the model of votes is quite similar to the followers models. 1/ vote_ids becomes vote_user_ids, a many2many relationship, using mail.vote as relational table. 2/ in mail_message.py - define vote and unvote, that perform writes with (4, id) or (3, id) on the field - like message_subscribe, return the new value of the field, to be used by the js - in _message_dict_get(): add to the returned dict : -- vote_user_ids: name_get of the field -- has_voted: boolean, telling if uid is in the voters 3/ in js: the code here is not good, because you are doing a call to the server for each displayed message ... very heavy ! 3-1/ render_vote should only empty the vote part of the message, and re-render it with the message values. Using the message_id parameter, fetch in the thread records the message data, find its related DOM element, then update the vote rendering. 3-2/ when (un)voting, call (un)vote, then update the thread records message with the new value (that you get directly as return value of (un)vote; calculate the new value of has_voted), then call render_vote with the message id to update the vote display. Best regards, Thibault. -- https://code.launchpad.net/~openerp-dev/openobject-addons/trunk-openchatter-mail_vote-part-4-atp/+merge/123098 Your team OpenERP R&D Team is subscribed to branch lp:~openerp-dev/openobject-addons/trunk-openchatter-mail_vote-part-4-atp. _______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-gtk Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-gtk More help : https://help.launchpad.net/ListHelp
