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
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
By default everybody should be able to read and modify
filters, and this is coupled with a global ir.rule that
only permits viewing and touching global filters and
owned filters.
bzr revid: odo@openerp.com-20130903172606-7vn0z2gz71urfdtz
account: move button on analytic chart wizard to bottom
account: use button Target Moves in financial report views (bug lp:1078146)
project: set duplicated task in default stage instead of current
bzr revid: mat@openerp.com-20130903093640-7jfbmhc441pnrz7y
Denis Ledoux
Christophe Simonis
Frédéric van der Essen
Martin Trigaux
Olivier Dony
Anael Closson
Samus CTO (OpenERP)
Turkesh Patel (Open ERP)
Chirag Dodiya (OpenERP Trainee)
Launchpad Translations on behalf of openerp
Moises Lopez
Bharat R. Devnani (OpenERP)
Amit Dodiya