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>
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
Courtesy of Transifex's translators for reporting bad/unclear sentences. closes odoo/odoo#62539 Related: odoo/enterprise#15032 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Fix traceback when creating a new contact by checking the id list is not empty. Task ID : 2302578 closes odoo/odoo#58555 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use _for_xml_id to replace all the self.env.ref().read()[0] This has the advantage of having a single point of control and to add the fields filtering and model verification. Add sudo for other operations on ir.actions.*
PURPOSE Subject field on mailing has not the same use in email marketing (subject of emails) and in SMS maketing (used internally as there is no subject in SMS). Purpose of this commit is to improve mailing form view to better distinguish email and SMS flows. SPECIFICATIONS This commit changes helper for mailing subject and update its label according to mailing_type (mail or sms), as well as the sms content field to enable emoji support in mailing subjects. This is done through a fake sms_subject field that is a text without emojis while standard subject allows emojis. Helpers depends on the displayed field. Override CRUD to synchronize sms_subject on subject to have only one field used to store data. Also allow emojis in SMS content, suing the enable_emojis option. LINKS Task ID-2224393 PR #49096
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.
Since January 2020, users are required to validate their IAP account via SMS code validation. This new behaviour needed to be properly ported to the client to correctly inform the user. This commit adds support of a new failure_type: 'Unregistered Account'. Task #2209567 closes odoo/odoo#48512 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With this commit, Selection fields with `required=True` which are extended via `selection_add` are given proper ondelete policies to ensure the cleanup of records containing these extended options during uninstall of the extending module. This commit also cleans up leftover uninstall hooks that were being used to handle the same set of problems prior to the ondelete mechanism being implemented for Selection fields. closes odoo/odoo#46325 Related: odoo/enterprise#9117 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
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