don't create new analytic lines at move creation, will do it once the move is balanced
don't remove analytic lines (to avoid duplicates) at the begining of the validation of a move, will do it once we create the new correct analytic lines (opw 597719)
bzr revid: mat@openerp.com-20131206131125-fvzy62qqx3gnwmw5
Deliveries to invoice in sales menu should display delivery order only (no incoming shipment). This was already the case thanks to the domain [('type','=','out')], but since the refactor of the module stock, and the division of stock.picking to stock.picking.in and stock.picking.out, the model of this view should be stock.picking.out instead of stock.picking (for instance, to get the actions binding (ir.values) of stock.picking.out model).
+ typo fix in action binding
bzr revid: dle@openerp.com-20131206111336-dg01y92jvjnxy5oi
remove analytic lines (to avoid duplicates) only when create new one instead of each validation of the account move
don't create new analytic lines at move creation, will do it once the move is balanced (unbalanced move should not create analytic lines yet)
bzr revid: mat@openerp.com-20131206104659-vct8a5l9o4nmhwqs
More consistent behaviour. Was not able to access unauthorized data (retrieving data on x2m field would trigger security rules) but make sure it raises an exception instead of silently retrieve no data.
Move construct domain inside if clause as no needed before
bzr revid: mat@openerp.com-20131205113254-j3j4bb0p6ed23oht
case: web_kanban_gauge has been added in the dependance of sale_crm. This module used to auto install when module sale and crm were installed. With this new dependance, the module sale_crm auto install when sale, crm and web_kanban_gauge are installed. We auto install kanban gauge so sale_crm auto install on installation of crm and sales, as web_kanban_gauge will be already installed
bzr revid: dle@openerp.com-20131205093615-1c9z0g5439xokdbt
Force readonly="0" on field image in preferences view, otherwise the readonly can be set by access rights.
Preferences are written with the UID 1, if the fields are in the WRITEABLE FIELDS list of the object res_users.
This is why any users can edit their preferences even if they do not have the rights to write on res.users.
Forcing readonly="0" to make fields editable in the form.
bzr revid: dle@openerp.com-20131204145923-f7jwoah722q188d7
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
This allows to field a purchase.order without showing the units of measure if not product is selected
Revision 7677 was integrated to fix lp:958897 (no change of uom when selecting a product whose uom is in the category 'Units'). This fix did not solve it properly (only for initial value) and introduced another problem. A better fix will be done on the onchange product.
bzr revid: mat@openerp.com-20131129143522-i85e4hvf0p4h3ynn
When choosing to link to an existing customer, then changing the action to create
a new customer or to avoid linking, the newly created opportunity was linked
to the previously chosen customer, due to the partner_id field not being
reset and used in the conversion process.
This field is not reset when changing the conversion action, leading to the action
being correctly taken into account.
lp bug: https://launchpad.net/bugs/1208436 fixed
bzr revid: tde@openerp.com-20131129101706-ccsn5u60sw8isroy
When generating pure email mass mailing, the values are directly sent to mail_mail.create() instead of going through mail_thread.message_post(). We therefore have to process attachments (coming from email_template, as a list of tuples (attachment_name, b64-encoded attachment_content)) as well as attachment_ids, like it is done in message_post.
As this behavior is the same as the one already implemented for message_post, this feature has been moved into its dedicated method called by message_post or called before going into mail_mail.create(), depending on the mailing type.
[FIX] email_template: when generating reports in batch, correctly attach the generate attachments to the various record ids we are iterating on.
bzr revid: tde@openerp.com-20131129094406-90cijc5ac4pmp4y7
Martin Trigaux
Denis Ledoux
Cecile Tonglet
Launchpad Translations on behalf of openerp
Christophe Simonis
Mohammed Shekha (OpenERP)
Antony Lesuisse
Thibault Delavallée