RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Simplify model custom code when dealing with phone and sms by using helpers
and standard behavior defined on all models.
'_sms_get_partner_fields' was introduced at odoo/odoo@bdebcab0ce to have a generic
implementation of finding partners on a record. Since then another version
has been added directly in 'mail' module, using '_mail_get_partners'.
'_sms_get_number_fields' was introduced at the same time to have a generic
implementation of finding numbers on a record. Since then a generic and
improved version has been added directly in 'phone_validation' module, see
'_phone_get_number_fields'.
Those method can therefore be removed, and replaced by the generic ones
available on BaseModel.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Move 'mail' and 'phone_validation' helpers directly at model level, allowing
to rely on those methods in all models instead of only when inheriting from
'mail.thread' or 'mail.thread.phone'.
Those helpers are used to find primary email, phone numbers or customers in
flows involving sending emails or SMS. A default behavior exists that is
generally valid for most models. Method can then be overridden to implement
their own custom behavior.
Future commits will improve them and remove duplicated computation between
mail, phone_validation, mass_mailing and sms modules.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
before this commit, if user need to bypass the validation
added for the length in custom module, the entire function
has be rewritten in the custom module.
scenario:
* add the phone_mobile_search field to the name search of res.partner model
* then open sale order form, and in the customer field enter any letter or digits, this user
error will be raised
after this commit, users just need to change the class
attribute: _phone_search_min_length in the
inherited module.
closesodoo/odoo#122411
X-original-commit: b89f948ef4789ec8dc400ef8c8e40778d5bbe406
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently the search method defined on 'phone_mobile_search' supports either
a boolean (is set / is not set) search, either considers all searches to be
"like TERM". This is coming from the main usage that is the search view
that sends domains like "[('phone_mobile_search', 'ilike', term)]".
In this commit we improve the method to correctly support
* direct check (=)
* negative operators (not (i)like)
* like / ilike (previously like were considered as ilike)
Idea is: a positive operator check that any of the phone fields respects the
domain (phone or mobile is TERM). A negative operator checks that all phone
fields respects the negative domain (both phone and mobile do not contain TERM).
Tests are added.
Task-3012789
X-original-commit: 8e905343f38a4dae828ccaddc62ce5c6a2f754db
Part-of: odoo/odoo#104111
To reproduce
============
Go to Contacts and try to filter by phone/mobile is/not set. A traceback is
raised.
Problem
=======
The search method responsible for this field didn't take into account Value
to filter by to be a boolean.
Solution
========
Correctly support this case in search method.
Add unit test.
Task-3012789
opw-2980542
X-original-commit: 62b7da527c6ddb4654fbccf5c6d8c94158915ebc
Part-of: odoo/odoo#104111
Currently the search methods defined on ``phone_mobile_search`` field forces
the usage of ``phone`` and ``mobile`` fields on model. This currently works
on models using by default this search field (lead and partner). However this
breaks on any model not having those two fields and inheriting from the
'mail.thread.phone' mixin.
In this commit we use the result of ``_phone_get_number_fields`` to know which
fields to use in the SQL query.
Tests are added to ensure it works as intended.
Task-3012789
X-original-commit: 6b235868da6fed1b2a0eaa7a25dc2202c6fefaa0
Part-of: odoo/odoo#104111
When the user searches a phone number, the search function will generate
a pattern by removing the "+" sign as well as well as the prefix "00" from
the input string.
Problem:
If the input string starts with "+", it means that the phone number will
be prefixed by something different than "00". As the function will
systematically remove the first occurrence of "00" from the input string,
the function can remove part of the input string that does not correspond
to a prefix. The search results can hence be incorrect.
Example:
If the user types "+32485001122", the function will remove the "+" sign
and the first occurrence of "00" from the input string. In the provided
example, the function will search phone numbers matching with the pattern
"324851122" which is incorrect.
Solution:
The function should remove the first occurrence of "00" iff the phone
starts with "00".
Task id: 2479277
COM PR: odoo/odoo#69729closesodoo/odoo#70954
X-original-commit: 53b4a7cf045df8828716e31e6d2a56cf93123bba
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If country is updated on a record inheriting from mail.thread.phone
its sanitized number should be computed again. Indeed without this
trigger it is not computed and may lead to inconsistencies between
phone numbers and sanitized number.
Task ID-2528169
closesodoo/odoo#70734
X-original-commit: odoo/odoo@d00b291167
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This commit aims to simplify the phone filter of the lead search view
to better manage phone numbers containing letters.
SPECS
The current phone filter will remove all non-digit characters from the
input string. When the user enters an american phone number containing
letters, the filter can sometimes return phone numbers that do not match
exactly with the provided input string.
eg: If the user types "hello123" in the search bar, the filter will
return all phone numbers matching with "%123%". This pattern will indeed
match with "hello123" but it will also match with many other phone numbers
containing only "123".
To fix the issue, the phone filter will no longer trim all non-digit
characters from the input string. The filter will be more standard and
will better manage phone numbers containing letters.
LINKS
Task ID-2424185
COM PR odoo/odoo#64078
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit the user had to type in the exact same formatting to find contacts.
After this commit the user will be able to get better search results and does not have to type the same formatting.
To avoid code duplication, the existing _search_mobile_phone method has been moved to the mail_thread_phone class, so that it could be used by both the crm and res_partner models.
Task-2435233
closesodoo/odoo#64490
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make sure to assign a value to the computed fields
`mobile_blacklisted` and `phone_blacklisted`
in their compute method for all record included in `self`
Otherwise, not assigning a value for one record included
in `self` can result in a cache missing error.
```
Traceback (most recent call last):
File "/tmp/tmp3l14ain7/migrations/base/tests/test_mock_crawl.py", line 143, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp3l14ain7/migrations/base/tests/test_mock_crawl.py", line 212, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp3l14ain7/migrations/base/tests/test_mock_crawl.py", line 238, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3001, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3021, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5620, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 980, in __get__
raise ValueError("Compute method failed to assign %s.%s" % (record, self.name))
ValueError: Compute method failed to assign crm.lead(974,).phone_blacklisted
```
closesodoo/odoo#59870
X-original-commit: 55d7b9d3304f75aa2089c32c4a907066da4dc4b8
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315
Minor UX tweaks for more consistent and correct wording, visualization,
and editing ability for mass_mailing and mass_mailing_sms. Specifically:
- Fix all "This email is blacklisted for mass mailing" => ".. mass
mailings" typos
- Make phone blacklist not editable (to align w/ email blacklist)
- Add "Archived" ribbon to phone and email blacklist
- Update menu items and actions
- "Phone Blacklist" => "Blacklisted Phone Numbers"
- "Blacklist" => "BLacklisted Email Addresses"
Supports task: 2117635
Issue is that when a model inherits from phone.Validation.mixin, then from
mail.thread.phone (which inherits from phone.validation.mixin) we have
an issue :
TypeError: Cannot create a consistent method resolution
order (MRO) for bases BaseModel, base, mail.thread, phone.validation.mixin,
mail.thread.phone
As fixing it could be complicated we have a way to avoid it: move conflicting
code as it is used only in mail.thread.phone .
In this commit we also import a file forgotten at d2809cbd94 which triggers
the issue itself.
Task 2063049 (bug spotted)
Task 2061765 (triggering the issue)
closesodoo/odoo#36580
Signed-off-by: Thibault Delavallee (tde) <tde@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)
Thibault Delavallée