There is a missing depends on subscription_ids fields, meaning it is not
correctly refreshed when contacts are updated. When dealing with m2m using
the o2m model as relational table, depends have to be specified on field
itself to allow recomputing the fields.

Task ID-2431217
COM PR odoo/odoo#71140

Right now, when o2m/m2m are set from default_get from web client,
the compute methods from the records being set yield `NewId` when
we try to get ID for the record, even if the records are existing.
It can result into wrong computation when the ids of the records
are used in preparing the data.

The same thing happens in the wizard that is used to merge mailing
lists. When we select multiple mailing lists and open the wizard
to merge them, they are set in the `src_list_ids` of wizard, but
number of recipients are always zero for them, because the method
that computes `contact_nbr` (recipients) on mailing lists fetches
data from the query, but we can't match (or find) the stats from
query result because we don't get the actual ID in recordset for
existing records.

This commit fixes the behavior by using `_origin` on the records
while finding data in the compute method, and thus getting the
correct recipient count.

Task ID-2471692
COM odoo/odoo#67213

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Fix traceback when creating a new contact by checking the id list is not empty.

Task ID : 2302578

closes odoo/odoo#58555

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.

Add sudo for other operations on ir.actions.*

Purpose of this commit is to call toggle_active or archive / unarchive methods
instead of manually writing on active field. Indeed this allows to trigger
business code related to archive / unarchive which is normally located
in toggle_archive (called by action_archive and action_unarchive).

Task ID 2170708
Community PR odoo/odoo#46563

Issue

	- Install Mass Mailing
	- Create 2 mailing list (x & y) with differents
	  contacts
	- Create a mass mailing with x & y, send it

	Ok, sent to everyome

	- Archive mailing list y
	- Duplicate the last mass mailing, send it

	Not ok, sent to y contacts too

	When a list is archived, I can't manually
	remove it from the mass mailing (it disappears)

Cause

	When archiving a list, it still remains in
	contact_list_ids

Solution

	Prevent archiving a mailing list if any mass mailing
	using it exist with state != 'done'

	Re-evaluate the domain field at copy

OPW-2202111

closes odoo/odoo#47094

X-original-commit: 4346f1da7a26a11f49c8e76f6ed8d6d6078a1d8a
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>

This branch is the combination of several optimizations in the ORM:

* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;

* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;

* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);

* make method `modified` take advantage of inverse fields to inverse
dependencies;

* filter records by evaluating a domain on records in Python;

* a computed field with `readonly=False` behaves like a normal field
with an onchange method;

* computed fields are computed in superuser mode by default.

Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.

closes odoo/odoo#35659

Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>

PURPOSE

SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...

Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.

SPECIFICATIONS

Prepare mass mailing module to addition of mass_mailing_sms.

Mailing model: mailing type
  * add a mailing_type selection field;
  * mass mailing contains only 'mail';
  * synchronize medium accordingly;
  * update actions of mass mailing application to add a domain on mailing
    type being 'mail';

Mailing contact
  * remove is_email_valid field as its purpose is achieved by email_normalized
    field coming from address mixin (added by blacklist management);

Mailing contact subscription
  * clean a bit fields and views as this should stay a technical model;

Trace model and report: trace type
  * add a trace_type selection field;
  * mass mailing contains only 'mail';

Various
  * clean some bits of code in views, remove old code bits;
  * add anchors to ease view inheritance to be able to customize views for
    SMS mailings;
  * ensure all views in mass mailing filter content on mail type (mailing
    and traces being type mail only);
  * rename some methods to be more updated with current guidelines, notably
    main action methods;

LINKS

Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)

PURPOSE

Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.

SPECIFICATIONS

Rename mail.mass_mailing.list and mail.mass_mailing.list to mailing.list
and mailing.list.merge. Rename mail.mass_mailing.contact to mailing.contact.
Rename mail.mailing_list.list_contact_rel to mailing.contact.subscription.
Rationale :

  * those new names are easier to understand: mailing.list and mailing.contact
    are less mail-related, especially taking into account that SMS will allow
    to be less mail-oriented;
  * those names are easier to read / find / understand;
  * align wizard and sub-models naming with the main naming;
  * have a mailing as first part of namespacing;

MIGRATION

mail.mass_mailing.list model -> mailing.list
mail.mass_mailing.list.merge model -> mailing.list.merge
mail.mass_mailing.contact model -> mailing.contact
mail.mass_mailing.list_contact_rel model -> mailing.contact.subscription
mail_mass_mailing_contact_list_rel table -> mailing_contact_list_rel (specific
case of a decorated m2m)

fields updated (no column change)
  * mailing.list: subscription_contact_ids -> subscription_ids

LINKS

Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938