Added delivered field, number of delivered emails
Improved kanban view of mass mailing campaign
Improved statistics of segments, now daily instead of monthly
bzr revid: tde@openerp.com-20130910104623-7ljg0q9pebbcqk7m
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