the possible selections from the server instead of using the data sent by the fields_view_get. This
allows to dynamically change the possible values during edition with a domain on the selection field.
bzr revid: nicolas.vanhoren@openerp.com-20131022131525-d0i61sbm0w6katfs
Due to the relationship between fiscal position
templates and tax templates, the removal of
obsolete tax templates may crash if the corresponding
fiscal positions are not deleted before.
In a recent l10n_fr patch [1] a number of
templates disappeared, which causes an error during
subsequent updates on databases where the obsolete
templates are still present.
As a workaround, we can force a deletion of
all fiscal position templates before loading
them. This is relatively safe because the templates
are not connected to live data, and will be
re-created during the update (except for the
obsolete ones which will be gone forever).
[1] addons 7.0 rev 9515 rev-id: odo@openerp.com-20131010114424-atzr3bl9e9diir2g
lp bug: https://launchpad.net/bugs/1240265 fixed
bzr revid: odo@openerp.com-20131021124748-x4jnibwyab4gam23
When having emails not linked to a notification (mail.notification = False)
the link is generated without any clue about the source record.
However we can try to use model and res_id defined on the mail_mail record
to correctly format a link.
Added support of model and res_id in message_redirect_action. This method
now can redirect based on a message_id, or based on model / res_id.
bzr revid: tde@openerp.com-20131018144924-j4f22hen3lsua7cb
Similarly to the recent fixes in Purchase Analysis,
the Sales Analysis view must not group on the quantity
field. It is one of the columns that must be aggregated,
not used to fold PO lines into the same
result row.
The line count was also incorrect because of this, and
had to be corrected to actually count() the underlying
SO lines.
In addition, the JOINs were done in the wrong order,
which could cause problems (e.g. if an empty SO ever
landed in the database, all the SO line columns
would be empty in the JOIN, and cause errors)
bzr revid: odo@openerp.com-20131105103011-vkix07lsb6q3y9fd
The product quantity is one of the columns that must be
aggregated, not used to fold PO lines into the same
result row.
This, combined with missing aggregation operators
was causing multiple identical PO lines from the
same PO to be merged together and only counted once
in some aggregations.
bzr revid: odo@openerp.com-20131105101930-f2qbcp12luom08je
It is a common need to set a higher decimal precision
for `Product Price` (i.e. the product cost field) for
high volume / low value items. This may typically
require up to 4-6 decimals for e.g. EUR/USD-based
companies where the currency has 2 decimals.
In that case the product cost should be stored with
full precision without applying the currency rounding.
The appropriate currency rounding will be applied
anyway as soon as a transaction actually uses that
product cost (typically in a SO/PO)
bzr revid: odo@openerp.com-20131104173232-84g115x6ykxoc1rh
While processing a picking we must keep track of
previously processed lines as they modify the
stock on hand but are not yet included in the
`qty_available` function.
Negative stock on hand is handled as if
the stock was zero as far as the average
price computation is concerned.
bzr revid: odo@openerp.com-20131104171245-z1lgsplyu4cdz9gc
Without the right precision the default rounding is
applied and causes a possible loss of precision when
the `Product Price` precision is increased.
This can in turn lead to incorrect average price
computations.
bzr revid: odo@openerp.com-20131104170118-ls5q0yridevw0jgt
The starting table for Purchase Analysis is purchase_order_line
not purchase_order. The previous code was using a wrong JOIN
combination starting from purchase_order, which resulted in
a crash if an empty PO was created.
In order to prevent this an extra WHERE clause on product_id
being NOT NULL was added, but this was incorrect too as it
prevented PO lines with no product_id value from appearing
in the Purchase Analysis results, while being perfectly valid.
bzr revid: odo@openerp.com-20131104165826-kltuzlh4i8q89sk0
When processing a translation, the module used to replace the original term by the translated value for accounts (only object with force_write=True). Now getting real multilang feature.
Generates the accounts with no language to get the untranslated value
bzr revid: mat@openerp.com-20131104095729-hwh2cocudxnhunyz
Turkesh Patel (Open ERP)
niv-openerp
Christophe Simonis
Olivier Dony
Martin Trigaux
Launchpad Translations on behalf of openerp
Thibault Delavallée
Denis Ledoux