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
The delete-rule was initially set to `cascade` in revision
6897.16.13 revid:odo@openerp.com-20120705141706-5gm5mmqode3bvkuc
because the ORM would not allow anything else for the FK of
an _inherits relationship.
This constraint was later lifted in 7.0 server at revision
4681 revid:odo@openerp.com-20121212210247-emrz5rf9ewcwdggu
so we can now switch to the intended default behavior:
when deleting mail aliases we never want to cascade delete
the child records, as that could lead to unwanted deletions.
On the other hand the aliases are automatically deleted when
the record they belong to is deleted, as a kind of internal
dependency. This is the intended safe way to delete them.
There is a special case when the same alias is manually set
on multiple records, in which case you will not be able to
delete any of those records. This is an acceptable exception
and should be manually handled if ever needed, by temporarily
linking the records to delete to new dummy aliases.
bzr revid: odo@openerp.com-20130827150708-62hqk8p7twd527n0
Launchpad Translations on behalf of openerp