It was discussed previously from:
- https://github.com/odoo/odoo/commit/b79d05fff0cacb4d99ebc1b60f44d8dab757b806
I quote Olivier Dony commit message:
"""
Having it in INFO should be sufficient for its purpose, and will avoid
impacting all CI builds done on a system that does not have the lib
installed.
For the record, this is not a hard requirement because the lib was not
available in Debian stable packages at the time of release. It is only
enabled on demand for those who want the feature and can install it
manually.
Fixes#22426Closes#22459
"""
closesodoo/odoo#40788
X-original-commit: 0394f5e95702087b38357070aad43f2b477c374e
Signed-off-by: Olivier Dony (odo) <odo@openerp.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
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 support more formatting options in phone tools,
to provide new API methods for phone numbers validatio. It also introduces
a method on sms.api to send SMS in batch. This one uses a new route given
in IAP services that send a batch of SMS instead of sending them one by one.
Concerning phone validation, tools are updated to correctly handle all
format supported by phonenumbers library. Indeed in addition to national
and international formatting phonenumbers library also supports E164
(international without spaces) and RFC3966 (beautification of phone numbers).
Let us support them and ease the use of our small tool methods in various
addons, notably sms.
Cleaning / check tools methods are added in phone validation module. Various
methods allow to sanitize phone numbers according to a context record and/or
some parameters. Those tools will be used in upcoming sms refactoring.
Another purpose of this commit is to add phone_validation in dependencies
of SMS application. Phone_validation module adds tools to parse and format
phone numbers and allow to replace the manual check done currently. Adding
it in dependencies of SMS does not change anything functionally as
* library is still optional. If phonenumbers library is not installed the
features are skipped without crashing;
* no model is modified as it introduces only tools and a mixin. Models are
updated in crm_phone_validation that updates lead and partner models;
Related to task 1922163
Linked to PR #34516
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Before this commit, when filing a phone number field on a model form (typically on website_form),
the module phonenumbers would try to parse the number against the country of the model.
However, this call fails when the number starts with 00 instead of + and that the model
doesn't have a country_id field or if said field is not set.
For this specific case, we chose to skip the number parsing altogether as providing a default
country to the parser can lead to a wrong parsing. i.e, phonenumbers.parse(+32477111111, 'US') will
find the number as US-based when it is a belgian number.
solves issue #22513
Also corrected a faulty behaviour where the option to have a number parsed in its international format
field `phone_international_format` on `res.company` was never properly assessed when the field comany_id of a
model was not present in the model's form view. Added company_id field on opportunity's form view for a proper fix.
Also fixed a syntax error in a logger.
During the formating method, the country code
was compared to the country phone code. Indeed,
phonenumbers python lib return a `PhoneNumber`
object having a `country_code` attribute
refering to the country_phone_code, and not
the country_code (like odoo means).
Consequence: changing the country on a lead
did not make the phone validation work.
Thus, it was required to give both code (country
and country phone codes) to the phonenumbers API,
in order to make a correct verification.
Using phonenumbers library this module adds tools methods as well as a
small mixin for models that want to activate phone number validation
and formatting.
Formatting can be done always using an international format or having
both national and international format. This is configured on the
company.
Note that phonenumbers library is optional. Installing this module without
having the lib installed just skip its use but should not crash.
Moisés López