In some rare cases the dependencies have changed, and modules that newly depend
on a module that is not installed cannot be loaded on the first pass.
For technical reasons all installed/to upgrade/to remove modules have to be
processed before starting to consider new installations, so this requires
two passes.
In trunk the inner loop inside `load_marked_modules()` will be dropped
because it should be unnecessary.
bzr revid: odo@openerp.com-20130909150859-k8xykkorgnmv0xx0
In some rare cases the dependencies have changed, and modules that depend on an uninstalled module
will not be processed on the first pass.
bzr revid: odo@openerp.com-20130909095004-n1dp2w5wnlb36742
As of v7 search views will replace the value of any `self`
literal in a @context attribute by the name of the
record, whereas it used to be its ID.
This means that the `Pricelist` filter used to display
the product list with a specific pricelist would not
work anymore.
The fix requires a rather hackish name_search()
override for product.pricelist because the display
name of pricelists includes their currency, while
that could be a valid name for a pricelist too.
To avoid side-effects the name_search() override
only picks up the special case used by the
product.product._product_price() method when it
tries to apply the context pricelist, that is
with operator explicitly set to `=` and no extra
domain `args`.
Also avoid useless warning in log by disabling the actual
filtering for the dummy pricelist_id field, whose
only purpose is to alter the context.
Finally, add a default _order for pricelists that is
a bit more intuitive than the default sort by `id`.
An explicit _order was required for the application of
the `limit` in pure SQL, and using `name` seems slightly
better than `id`.
lp bug: https://launchpad.net/bugs/1178835 fixed
bzr revid: odo@openerp.com-20130906161422-0huf2uwjg42shdqp
As of v7 search views will replace the value of any `self`
literal in a @context attribute by the name of the
record, whereas it used to be its ID.
This means that the `Pricelist` filter used to display
the product list with a specific pricelist would not
work anymore.
The fix requires a rather hackish name_search()
override for product.pricelist because the display
name of pricelists includes their currency, while
that could be a valid name for a pricelist too.
To avoid side-effects the name_search() override
only picks up the special case used by the
product.product._product_price() method when it
tries to apply the context pricelist, that is
with operator explicitly set to `=` and no extra
domain `args`.
lp bug: https://launchpad.net/bugs/1178835 fixed
bzr revid: odo@openerp.com-20130906155047-7dmozy2jpe1ca1p2
Turns out when code looks somewhat odd there may well be a good reason
for it, and changing it without wondering breaks the pager.
In this case, `/web/dataset/search_read` has a significant difference
with Model.search_read: it returns the records slice specified by
(``limit``, ``offset``) but it also returns the *total number of
records* for ``domain`` which is sort-of useful to generating the
pager.
lp bug: https://launchpad.net/bugs/1218266 fixed
bzr revid: xmo@openerp.com-20130906150101-2qb349fzaz6rye36
The main reason for the semi-random behavior
observed during auto-completion is the
missing ORDER BY clause in the pre-filtering
SQL query.
The ORDER BY clause is expensive but inevitable
if we want to apply a correct LIMIT, otherwise
we would return random `limit` results among
all the possible matches.
The current SQL query seems convoluted due
to the duplicated CASE clause but it
performs slightly better than the equivalent
CTE-based (WITH...) query, so it was preferred.
There is still a chance of returning too
few results due to double limit application,
as further discussed in bug 1203727
lp bug: https://launchpad.net/bugs/1203727 fixed
bzr revid: odo@openerp.com-20130906134950-gi0szic3uw3onyuv
The main reason for the semi-random behavior
observed during auto-completion is the
missing ORDER BY clause in the pre-filtering
SQL query.
The ORDER BY clause is expensive but inevitable
if we want to apply a correct LIMIT, otherwise
we would return random `limit` results among
all the possible matches.
The current SQL query seems convoluted due
to the duplicated CASE clause but it
performs slightly better than the equivalent
CTE-based (WITH...) query, so it was preferred.
There is still a chance of returning too
few results due to double limit application,
as further discussed in bug 1203727
lp bug: https://launchpad.net/bugs/1203727 fixed
bzr revid: odo@openerp.com-20130905170251-x47w1zrm43d0k9wb
Olivier Dony
Anael Closson
Martin Trigaux
Thibault Delavallée
Antony Lesuisse
Fabien Meghazi
Samus CTO (OpenERP)
Turkesh Patel (Open ERP)
Chirag Dodiya (OpenERP Trainee)
Sunil Sharma (OpenERP Trainee)
Launchpad Translations on behalf of openerp
Frédéric van der Essen
Xavier Morel
Stephane Wirtel