On invoice residual amount computing, we ignore reconcile entries line if their invoice are not of the same type of the current invoice
The above revision(s) will be removed
bzr revid: dle@openerp.com-20140205100324-5tyquozmylcp40p1
- tracking unlink does not fail anymore
- do not track virtual fields on res.users model (would for .column call)
- make sure read calls with one id works (launchpad bug lp:1214149)
- select the correct model when tracking x2m fields values
bzr revid: mat@openerp.com-20140204151136-51cm1tbgvcsnlsoe
iter only on fields on __all_columns, this avoids getting inexistant fields such as 'in_group_42' for res.users
make sure read method calls works when passing only one id (lp:1214149)
when itering on change values, if different model (eg: if field is o2m) make sure make name_get on the model of the field and not on the parent model
lp bug: https://launchpad.net/bugs/1214149 fixed
bzr revid: mat@openerp.com-20140204141449-2f922k5awixh1kzt
revert because was breaking the rendering of forms using oe_title as clearfix hack
adding clear on .oe_form_group to fix the journal form on firefox (block was unaligned, some fields out of the screen)
bzr revid: jke@openerp.com-20140203173926-ohabh1vahcwqijug
Without this you could not have a sum value on a column belonging to the parent model (eg: 'unit_amount' when grouping on hr.analytic.timesheet)
bzr revid: mat@openerp.com-20140203140247-n090tx2yf8mujkcz
When importing invoices to a bank statement the bank statement lines are created with statement date instead of today
Set the date on the created voucher in the same wizard to the statement date instead of invoice date (problematic if different period)
When creating the account moves (at bank statement confirmation), make sur the date and period of the vouncher are synchronised
bzr revid: mat@openerp.com-20140129172009-vbp5n1nco51kaly8
On purchase order confirmation, if the order_line comes from a procurement order created by a sale order,
it tried to write on the location_id, whatever the move state was, even done.
Or, sometimes, the stock move associated to the procurement order (from the so) was already done, for example because we forced the availability of the stock move.
It makes sense to not write the location_id if the move is already done, because the location_id is already good.
bzr revid: dle@openerp.com-20140129163238-1s1t9oc814z4z7f3
The original query did two passes (SQL query and orm search). This was a problem due to the limit parameter where the second query could reduce the number of results to a smaller number than the asked limit.
This code reproduces the orm _search behaviour to execute only one SQL query mixing both the ACL clauses and the complexe name_search without degrading the performances (removing the limit in the first query would have).
bzr revid: mat@openerp.com-20140129132240-eamnzs37k0i65gpe
The original query did two passes (SQL query and orm search). This was a problem due to the limit parameter where the second query could reduce the number of results to a smaller number than the asked limit.
This code reproduces the orm _search behaviour to execute only one SQL query mixing both the ACL clauses and the complexe name_search without degrading the performances (removing the limit in the first query would have).
lp bug: https://launchpad.net/bugs/1203727 fixed
bzr revid: mat@openerp.com-20140129105548-dd6zmy9uc2cuowpq
This had as side-effect to not allow splitting BOMs
(a manufacturing order for 1 unit of a BOM producing 10 units consumed the lines like it was 10 units, not 1)
This fix was to avoid having a fraction of a unit (for instance, 0.5 unit).
But, finally, it is preferable to allow splitting units:
1. Most users do not use several uoms, and in this case, the unit is the default uom (hidden).
2. At the moment, it is allowed to ask a manufacturing order splitting up the unit uom
(It is allowed to ask the production of 0.5 USB Adapter, for instance)
Thus, we should allow the splitting up of the unit uom in the lines too.
bzr revid: dle@openerp.com-20140124120102-we2yxio553ws2yz4
Launchpad Translations on behalf of openerp
Martin Trigaux
Denis Ledoux
Cecile Tonglet
jke-openerp
Christophe Simonis
Antony Lesuisse
Anael Closson