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)
Denis Ledoux