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
This will only display newly posted messages, not already existing.
To do so apply the following SQL command:
UPDATE mail_message SET model = 'stock.picking' WHERE model = 'stock.picking.in' OR model = 'stock.picking.out';
lp bug: https://launchpad.net/bugs/1197169 fixed
bzr revid: mat@openerp.com-20130828151434-5nu7o0ybguh86w6f
Turkesh Patel (Open ERP)
Chirag Dodiya (OpenERP Trainee)
Launchpad Translations on behalf of openerp
Olivier Dony
Martin Trigaux
Christophe Simonis
Denis Ledoux
Yannick Vaucher