When performing an sms marketing on a model having only a ``partner_id``
field available (aka no ``phone`` or ``mobile``) it crashes due to seen
list computation (aka already contacted recipients). This is due to an SQL
query not taking into account those models as it works only for those with
a phone field.

We fix it as done in ``mass_mailìng`` app, aka fetching information on the
related partner if available.

Some tests for models using a 2many relationships towards recipients are
added. Note that this kind of model does not really support complete SMS
notification, as only the first found partner is notified. Mass SMS on this
kind of model is currently not possible as seen list is not supported. There
is no standard use case of this in Odoo codebase.

Correctly support sms marketing on sale model by defining the necessary
methods. As sale order has only a partner_id field available we have to
correctly override phone related methods for SMS.

LINKS

Task ID-2431217
COM PR odoo/odoo#71140

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

Purpose is to test specific behavior of opt-out for SMS marketing. This is
currently not tested and working a bit strangely, as they are flagged as
blacklist. This will soon be updated in another task but at least current
behavior is logged somewhere.

We also update some test models in order to reflect potential strange and
non-default behavior, notably partner_id field used as contact field. It
will be used soon when cleaning some opt-out behavior.

Tests are added to check phone sanitized is correctly taken into account
in default domains when inheriting from the phone blacklist mixin.

Some counters notes are also updated next to some last updates.

Task ID-2431217
COM PR odoo/odoo#71140

Currently phone_sanitized computation on lead model works only if crm_sms
is installed. Indeed an override of ``_phone_get_number_fields`` is missing.
However ``_sms_get_number_fields`` coming with ``crm_sms`` and its ``sms``
dependency hides the issue as those modules are auto-install. However if
``crm_sms`` is uninstalled phone_sanitized is not correctly computed anymore.

Task ID-2528169
Oversight of odoo/odoo#45315

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

Limit use of templates to models that are really capable of sending
SMS. Templates are now available on models that inherit from mail.thread
and effectively have fields used in SMS sending.

Technically this is done through a not stored field on ir.model that is
searchable. SMS sending capabilities is based on

  * having fields holding phone numbers, as defined on mail.thread in SMS;
  * having fields holding partners, as defined on mail.thread in SMS;

This implied some code rewriting notably about finding default SMS
recipients on a given model, in order to have fields instead of directly
returning partners.

LINKS

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

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

Purpose of this commit is to add a blacklist mechanism for phone numbers
used to send SMS like what already exists for email addresses when sending
emails.

Define a new phone.blacklist model, holding a number and the state of the
blacklist (active field), as well as tools methods to access it. Make it
as private as possible, accessing it in sudo once access are granted.

Also clean phone validation tools: lessen number of tool functions and update
caller to simplify code readability. Some fixes are also included in this
commit, notably blank spaces cleaning in phone numbers.

Improve phone.validation.mixin to add a tool method computing a sanitized
number, in addition to formatting it to national / international.

Define a new mail.thread.phone mixin computing the blacklist status of a
record. This mixin

  * inherit from phone.validation.mixin in order to have access to some
    base phone number parsing capabilities;
  * computes a sanitized phone number based on ´´_phone_get_number_fields´´.
    It takes first sanitized value, trying each field returned by the
    method. That means one sanitized phone number is available per record
    even if several fields are available;
  * compute blacklist state of records. It is based on phone.blacklist
    model and give an easy-to-use field and API to manipulate blacklisted
    records;
  * give some API methods :

    * ``_phone_set_blacklisted``: set recordset as blacklisted;
    * ``_phone_reset_blacklisted``: reactivate recordset (even if not blacklisted
        this method can be called safely);

Put menus in technical in order to have access to it. Add a Phone / SMS
menu below "Email" and use it to store SMS / Phone actions.

Finally prepare tests addition by performing some light cleaning while adding
blacklist tests. Purpose is to ease future tests related to SMS.

LINKS

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

Purpose of this commit is to better include SMS notifications when posting a
message. SMS is now just another way of notifying people along with Inbox and
email. Following recent mail merge improving notification mechanism [1] we
have to define a _notify_record_by_sms method on mail.thread.

When a message_post is done using message_type being ``sms`` notification type
of customers is set to sms. Customers can be computed on model (generally based
on partner_id field) or directly set usign partner°ids. Notification model is
updated to store this information directly inside the notification itself.

An new ``_message_sms`` helper method is introduced in SMS module allowing
to send messages using sms type and notification with a reduced parameters
number. It is just a shortcut to message_post, easier to use. Either it
computes default recipients on the record set, either it is based on given
partners and numbers to notify.

The following use cases are notably supported

  * default computation: find customer, notify by sms;
  * force recipients to notify by sms (partner_ids);
  * give a set of numbers to notify by sms (sms_nubmers), not necessarily
    linked to existing partners;
  * force number / customer relationship independently of mobile number defined
    on customer (for example when sending an SMS directly from a mobile field
    on a lead linked to a customer);

Tests are updated accordingly. Performance tests are added in order to have
some insights on queries generated when sending SMS, like already done for
mail.thread alone.

Related to task 1922163
Linked to PR #33510

[1] see be2795513644f09f6b443f462bb67cc5a0762e8d: performance and notification code improvements

Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>

Purpose of this commit is to improve and add tools, methods and data to test
mail and SMS features. We also add tests for current implementation of SMS
feature, allowing to better understand future changes.

[ADD] test_mail_full

  * have a module depending on mail sub-applications like sms or snailmail.
    Its purpose is to check that standard mail features work effectively with
    all overrides and extra behaviors activated;
  * add a new model specific for SMS gateway, with default recipient
    computation;
  * add SMS tests for SMS module adding SMS capabilities linked to mail
    feature. This commit tests SMS feature before the upcoming refactoring
    and improvement of SMS module in community: posting with SMS and sms
    composer usage;

In test_mail

  * add necessary mobile information on test partners;
  * improve assertBusNotification that was not correctly asserting all items
    in message of bus notifications;

In sms

  * add mock for SMS sending. Purpose is to mock the connection to IAP
    services by mocking the call to IAP server. It allows to perform SMS
    tests without having to contact (and pay) for this service;
  * allow some customization when calling the SMS gateway mock to simulate
    errors and test corner cases;

Related to task 1922163
Linked to PR #34516