Mail statistics are now stored onto a separated object (mail.mail.statistics), allowing to
handle emails separately from statistics (among other removing mail.mail entries while keeping
statistics).
Everything linnked to opened/replied/bounce is not managed by mass_mailing, removed added code
in mail module.
bzr revid: tde@openerp.com-20130913115408-322cyjipdg680as6
Those widgets come from widgets previously defined in crm (for gauge) and sale_crm (for sparkline). As other modules will soon use them (mass mailing, gamification, accounting dashboard), they have been moved into their own web modules.
bzr revid: tde@openerp.com-20130913082930-044s5dmgmepn7flf
This fix replaced the fix merged into 7.0 / saas-1 (rev 9434), by adding a new currency_id field on
the model. XML data for the various COAs have been updated accordingly.
bzr revid: tde@openerp.com-20130912132032-8k2dj2t3n5hi6s43
Most of 7.0 commit about COAs (9434) has been discarded, because another fix has been implemented
for the trunk branch. This new fix will be merged right after this forward port
of 7.0 / saas-1 branch.
bzr revid: tde@openerp.com-20130912131546-2f8p23bwwcc7930c
The previous fix in revision 5072 only allowed user names
that contained the exact same emails, but users will do
the wildest things like having `someone@domain.com` as
name but setting their email to `someone@domain2.com`.
This was blocked by our sanity check looking for a single
email in the From header. As this check is only done
in order to provide a better error message, it should
not impact valid cases.
Modifying the check to pass when at least one email
was found should be enough to catch most invalid cases,
without requiring a more advanced analysis of the
header value (the RFCs allows very strange things!)
bzr revid: odo@openerp.com-20130918143807-wqqpqomyu1ppa2ih
The project_mrp process extends the sales process at
the procurement phase, however that part of the sales
process has now been moved to the `sale_stock` module,
which is not a dependency of `project_mrp` anymore.
There is however little reason to duplicate that
process node, so as a temporary hack, we can copy
its external ID, even though there is no direct
dependency between the two.
For next version we should fix this hack by moving
the node to a common dependency between sale_stock
and project_mrp, such as `sale`.
lp bug: https://launchpad.net/bugs/1223276 fixed
bzr revid: odo@openerp.com-20130918074002-wrhnq0w4t8xx3rgv
The project_mrp process extends the sales process at
the procurement phase, however that part of the sales
process has now been moved to the `sale_stock` module,
which is not a dependency of `project_mrp` anymore.
There is however little reason to duplicate that
process node, so as a temporary hack, we can copy
its external ID, even though there is no direct
dependency between the two.
For next version we should fix this hack by moving
the node to a common dependency between sale_stock
and project_mrp, such as `sale`.
lp bug: https://launchpad.net/bugs/1223276 fixed
bzr revid: odo@openerp.com-20130917160337-lih7bjqastozga8w
When a new inheriting view is imported during a module
installation, it is validated thanks to the _constraints
on the ir.ui.view model. However the validation uses
a rather convoluted system for validating the whole
view tree at once (root view + all inherited changes)
while only taking into account the views that belong
to modules that are currently loaded.
This complicated system is necessary to be able to
operate on-the-fly at any point during the registry
loading/initialization.
Now because _constraints are checked during create()
this particular validation happens *before* the
external ID (ir.model.data entry) of that new view
can be created (it obviously needs to wait until
the view record is inserted). As a consequence the
view validation cannot determine the module to
which that new view belongs, and was erroneously
ignoring it.
Changing the view filtering to also include views
that have triggered this check.
Manually created views are not check during registry
update.
bzr revid: chs@openerp.com-20130912141018-qmcyase8zqov9d01
Currency is found by adding values in ir.values and retrieving it when installing the COA.
In trunk/8.0, a new currency_id field will be added allowing to retrieve directly the currency.
bzr revid: tde@openerp.com-20130912113247-esuwq1zppcq2gakk