Including:
- sales team members are displayed
- fixed sparklines whose numbers were incorrect
- sparklines now redirect to a correct report view, filtered for the sales team, grouped by month, in order to have matching results between the vignette links and the displayed reports
- custom css in crm put in a sass file
- sale_crm extend the crm reports, to add the section_id field in the reports, allowing to filter / group by salesteam. The analysis view has been put into several methods to allow extension.
bzr revid: tde@openerp.com-20131205160029-1tljp52ovcavwxel
- sales report: the group by salesteam was wrongly placed in the view
- sale_crm: fixed computation for sparklines, now bar graph should display the same
result as the sales analysis
- added a forgottent cursor: pointer for a gauge
- moved the gauges in the dom
- sale_crm: report: removed extra content not necessary
bzr revid: tde@openerp.com-20131205144505-jfsd8lh91r1b13a1
- moved css into sass file to standardize the process
- commented some records added in the xml file of crm.case.section that do not seem necessary
bzr revid: tde@openerp.com-20131205124749-3a1quhetgxq2d224
When processing an incoming email, we try to find a parent for the email based on references. Before this merge, it was done using openerp-<model-<res_id> pattern. However it is buggy. Indeed having two OpenERP sending emails to each other leads to messages being inserted in a wrong thread (model and res_id of the first OpenERP for both instances).
Now we search for an exact match between the references and the stored message_ids. As each message_id can be considered as unique the number of collisions is lessened. This won't cause any issues with OpenERP >= 7.0.
A compatibility mode is implemented for <= 6.1: as in those versions the message_id is not stored, we fall back on the previous behavior for records having messages without message_id. This indicates that the record was created before 7.0.
Tests have been updated accordingly, and a test added for the compatibility mode.
bzr revid: tde@openerp.com-20131205100534-2rlyun8wqng3qa6f
- removed a debug print statement
- now searching all references once instead of each reference one at a time
to lessen the number of queries; as the newest message will be the first
in the search result, it's ok.
bzr revid: tde@openerp.com-20131205093921-h7sits57vqc51c8p
Because defaults get function of partner_id of wizard read the partner_id of the opp and return the first item of the tuple, but if there isnt a partner on the opp, the read return a false for this field, not a tuple.
No return the first item of the tuple if the partner_id is set, else False
bzr revid: dle@openerp.com-20131204133633-t7wfbnipv3jtss82
In im_session model, field channel_id was a many2one to im_user, or, obviously, this should be a many2one to im_livechat.channel
Well, obviously, this is a copy/paste error (or distraction, your choice!). This fix should normally not be pushed on a stable branch (like the current one, saas-2), but considering the severity of the problem, and the few changes in database (alter foreign key only), this is acceptable. Why such a big mistake has not been seen earlier ? Do you even test or read back what you write ?
bzr revid: dle@openerp.com-20131204122727-q0ch5j2v8rrli41e
Returns were partially ignored when typing keystrokes, thanks to a return; when event which equaled 13, but the default behaviour (press on the focused input/button) was not prevented. This is now the case thanks to preventDefault. For instance, just after a discount set, the focused input was pressed and the associated value was added when scanning a new product with the scanner. Therefore, if we entered a discount of 30%, scanning a new product added '0', the last pushed button, to the discount, and then added the product.
bzr revid: dle@openerp.com-20131209145652-3g9rgnfz1w8k0whw
The set method of the field, set_followers, is now using message_subscribe and message_unsubscribe to have only one access point to adding or removing followers. Previously to this fix it was directly creating entries in the mail_followers table, neglecting the calculation of subtypes and default subtypes.
bzr revid: tde@openerp.com-20131209100822-f19udgfuubshhrg3
Martin Trigaux