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
X-Original-Commit odoo/odoo@987d974ccbclosesodoo/odoo#71178closesodoo/odoo#71205
X-original-commit: 642816d0a819bf74927ed5aa11b6843cbb97d4df
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
X-Original-Commit odoo/odoo@3ba3054f0a
X-original-commit: a9ac2582eb508daa21fd0d3a5a551261ecc18f8b
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 be27955136: 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
Thibault Delavallée