Now that recipients in notification process are always partners due to
simplification of MailFollower model we can safely simplify the structure
used to collect and propagate recipients information.
Before this task it was a dictionary with a list of partner related data and
a list of channel related data. It is now simply a list of partner related
data, leading to various code cleaning.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
Channel model is a mail.thread enabled model behaving strangely with followers,
notifications and discuss. Its code should however be simplified to be more
self contained and avoid unwanted side effects on other models.
PURPOSE
Remove channel ability to follow records as it mainly adds noise without a lot
of added value. Simplify channel notification flow by using directly members
and not a delegation through a channel self-following trick. Remove followers
being channels and posting with added listeners being channels.
SPECIFICATIONS
As there is no way to add channel-based follower anymore we can remove all
fields and code supporting this feature. Notably we can remove ``channel_id``
field on ``mail.follower`` model as well all code using it, notably compute
methods.
In this commit we also make ``partner_id`` field required as now followers
are always partners. Email, name and active fields are now simple related
fields on the partner.
Code computing data about subscription is also updated and simplified. As
we do not have channels anymore but only partners all custom SQL queries
are now simplified.
JS models for Discuss are also cleaned. Following python change, JS models
are simplified to match the backend models. Channel_id is removed, partner_id
is now required, and various code is updated according to the simplified
model.
Side note: we could probably get rid of specific index on ``partner_id``
field. However we have to ensure we never search for followers without being
in a model / res_id context. This will be done in another cleaning step to
be sure performance are not broken.
LINKS
Task ID-2070632 (main task)
Task ID-2419762 (followup task)
COM PR odoo/odoo#62859
ENT PR odoo/enterprise#15172
UPG PR odoo/upgrade#2005
RATIONALE
A bit of history. Link between a message and its recipients has been added
at first mail refactoring towards a Chatter / Discuss feature. It was done
in v7 at d64f3c9783 with the base addition of mail notification model (lots
of commits follow that one but that's the first one about notification).
Due to some people thinking that it was unnecessary to keep a model for
notification it has been removed in v9 at 88b8cd0587. Notification table was
renamed from mail_notification to mail_message_res_partner_needaction_rel.
It was proven to be a mistake even if those "some people" were warned and
model made its way back to Odoo in v10 at 72dfcae2a4 . Table name mail_message
_res_partner_needaction_rel was kept to ease migration and backward
compatibility.
It is now time to complete the circle and rename it to mail_notification.
SPECIFICATIONS
Rename ``mail_message_res_partner_needaction_rel`` to ``mail_notification`` .
RIP JEM.
Never forget.
LINKS
Task ID-2477444
Prepares Task ID-2377974 (trace management cleaning task)
Prepares Task ID-2070632 (channel members main task)
Prepares Task ID-2419762 (channel members followup task)
COM PR odoo/odoo#67382
UPG PR odoo/upgrade#2245
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
This commit adds user feedback in the form of a message logged on the related
document (mailing.mailing) when testing a mailing/sms.
Before this change, when sending an email to your own mailbox for testing
purpose, or when sending an SMS to your phone, you did not get any interface
feedback on whether it worked or not.
Now, a logged message will show if it's successful and if not, explain why it
failed with a short error message (no IAP credits / misconfigured outgoing mail
server / ...).
In addition, email and phone inputs are now split on the '\n' character instead
of a coma, which allows easier validation of the email addresses.
Task-2375526
closesodoo/odoo#63421
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Problem
-------
_search_is_mail_thread_sms is looking for ir.model
in the database and then fetch them from the registry
without verification. This can lead to key error
when a model is present in the database but not in
the python anymore. This situation can happen
after a migration.
Solution
--------
Check the model is present in the registry
closesodoo/odoo#60001
X-original-commit: 448626d86a1f06b9f8a7a88111f7cb01600488cd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Clean and improve IAP tools integration in Odoo. Introduce bridge modules
to extract common features, notably for CRM and Partner.
SPECIFICATIONS
In this commit we reorganize IAP module to better understand its content
and ease future cleaning
* have models separated from tools;
* rename some tools to find their grep. An iap_ prefix is added to ensure
we don't clash with other global functions or methods;
* perform some linting;
To provide backward compatibility support we keep some import in init file of
IAP addon. Standard code is about to be updated but we want to avoid too
much issues when migrating code to 13.5 . Compatibility layer will be removed
after v14 final freeze.
LINKS
Task ID-2248367
Community PR odoo/odoo#53214
Enterprise PR odoo/enterprise#11258
Upgrade PR odoo/upgrade#1363
IAP PR odoo/iap-apps#191
While creating contextual action for an sms template, the composition mode
may be decided on the fly, based on number of records and on context the key
`default_composition_mode`, which is set to 'guess'.
It used to work before a recent refactoring[1], because the composition
mode was changed in the default_get, and was being set to appropriate
value instead of 'guess'.
After this refactoring, the composition mode is not being set in the
default_get but is being computed, so the key `default_composition_mode`
tries to set the composition_mode selection field to 'guess', which is not
available in the selection values, resulting into traceback.
This commit fixes the issue by renaming the context key(removing 'default'
prefix) to avoid setting the mode directly and instead let the compute method
decide the composition mode based on context key and number of records.
[1] - https://github.com/odoo/odoo/commit/e02137c48562d824e3e01054e31dae383e5843e2
TaskID - 2286959
closesodoo/odoo#54938
X-original-commit: 2b9ea3d93445e05cb0440aab33f2bf9e066b0fa5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Taking a self and a separate action seems unnecessary given self *is
an action*.
Only do this change for the "new" naming scheme, so the old one keeps
working as-is.
There is no reason to call these directly, in fact it's not really
possible to do so as they expect an `action` object as first
parameter.
* warn against the presence of rpc-public runners
* move runner selection outside of ``run``
* improve doc a bit maybe
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.
Bug
===
Go to CRM, in the lead list view and select a lead without
phone number. Then, click on the action "Send SMS Text Message".
Then, enter in debug mode and go to the SMS form view. The
number will be "0" instead of being empty.
Task-2244195
closesodoo/odoo#51389
X-original-commit: 8805c16bfb1bfb001e674d9a2755ad0e98fcb834
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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 #2209567closesodoo/odoo#48512
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When no valid phone number was found on a record, and when using _message_sms
directly, no SMS and no notification was created. You could therefore think
everything was ok while it was actually not.
Instead we now create failed notifications. It allows to be notified of it
and fix numbers through cancel / resend wizards.
Task ID 2244192
closesodoo/odoo#50486
X-original-commit: baecdfaa2d31714a20d1fb8af7799af1805cd939
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When no valid phone number was found on a record, and when using the composer
in single recipient mode, you had a crash at sending as composer tried to
write on a field called False.
Instead we just take the first available phone field of the record. As they
are all void we can update them safely.
Task ID 2244192
X-original-commit: 2306d7d79d8e64597912f15365cede7473589731
In this commit we order fields more logically to ease reading and prepare
future modifications. We also rename the class and some field strings to
be more user friendly.
LINKS
Prepares Task ID 2238597 (clean notification models)
Prepares Task ID 2083854 (improve mass mailing technical flows)
PR #49891
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
The purpose is to have more common code for failure and notifications, with less
override in `sms` and `snailmail`.
task-2176017
closesodoo/odoo#44170
Related: odoo/enterprise#9140
Related: odoo/upgrade#918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.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.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
Merge rendering tools used in mail and sms templates as well as partially
in mailings and move them directly in mail.render.mixin.
SPECIFICATIONS
Move tools related to language computation from mail.template model to the
mail.render.mixin. It allows to update both
* mail.template: simply update calls accordingly;
* sms.template: remove code doing what is now available through mail.render
.mixin inherit;
Lang field is moved to mail.render.mixin as it is used notably for the language
computation. It therefore adds the field on mailing.mailing model although
not used currently.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
We also have to update code calling directly the rendering itself. Indeed
some code bits does some rendering directly on jinja-enabled input and not
through templates. Those calls have to be updated accordingly.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
Clarify mail.template, mail.render.mixin and sms.template code organization.
SPECIFICATIONS
Reorganize fields according to their main use.
Remove an unnecessary onchange in mail template model. As "model" field on mail
template is a computed field its computation is sufficient.
Add some docstrings and code separations.
Prepare future code change.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
After this commit
* the SMS button is visible next to a phone number in mass_mailing, and
mass_mailing_sms
* when sending an sms to a single contact, its phone number is now an
editable field in the wizard and there is a warning if the number is
invalid;
* if operator updated the recipient number, update record number according
to the new number only in single recipient mode (aka, solving number
issues directly from interface);
LINKS
Task ID 2088303
Community PR odoo/odoo#40482
Upgrade PR odoo/upgrade#873
Co-Authored-By: Florimond Husquinet <fhu@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Purpose is to improve information given back, adding notably
* whether the value comes from the customer (partner_id field) or directly
from the record we are looping on;
* the actual field used when no specific field is enforced;
LINKS
Task ID 2088303
Community PR odoo/odoo#40482
When we send a SMS in the contact form view, exact body is sent by SMS and
displayed in chatter. If some manual HTML is added chatter will display it
as HTML while sms receive HTML tags.
We want that the SMS content in the chatter is the same as the SMS sent and
that HTML tags are removed to avoid being interpreted.
To achieve that goal we call html2plaintext in ``_message_sms`` and in
``prepare_log_body_value`` that are two entry points to send SMS.
We also update ``html2plaintext`` to strip result in order to avoid having
unnecessary spaces left.
Task ID 2126123
PR #40441closesodoo/odoo#46362
X-original-commit: 4b7b14a5ea5e6ab521838c01813fa478154682fd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue
- Install Calendar
- Technical > SMS templates > Calendar reminder > Add context action
- Calendar > Tree view > meeting > action is there
- Delete SMS template and/or uninstall calendar_sms
Template deleted but action still there with a traceback
when you click on it.
Cause
The action is never deleted.
Solution
Delete the action when the template is deleted.
OPW-2161653
Closes#42328closesodoo/odoo#43984
X-original-commit: eb95f06f19c60babc775de57813a293ffc35c581
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Below points are improved in automated action
- Set no_create on model_id, crud_model_id, partner_ids, and channel_ids
- Set widget many2many tags and change string for trigger_field_ids
- Rename 'Trigger Condition' to 'Trigger'
- Change on_change_fields into a many2many to ir.model.fields
- Set 'Hours' as default of field trg_date_range_time
- Rename label of crud_model_id to 'Target Model'
- Rename label of sms_mass_keep_log to 'Log as Note'
- On creation of template set the default model
- Hide the 'Security' tab
- Set no_create on fields resource_ref and col1
- Make 'value' readonly when col1 is not set
- Rename 'Link using field' to 'Link Field'
Task-2082503
closes odoo/odoo#39622
Closes: #39622
Related: odoo/enterprise#6515
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PURPOSE
Upgrade the "mass_mailing" and "mass_mailing_sms" modules with a dynamic
placeholder generator as it already exists in "mail module" as depicted in
https://www.screencast.com/t/cnFA0gIY.
SPECIFICATIONS
As duplicated code already exists for that and that a third version of this
code has to be added, instead create a mixin for this dynamic placeholder
generator to avoid code duplication.
Thereby
* a mail.render mixin for the dynamic placeholder generator must be
created in mail;
* dynamic placeholder generator code present in mail.template.py must be
moved to that mixin and replaced by a simple inherit;
* use the mixin in
* mail templates: mail.template.py (mail module);
* mass mailings: mailing.py (mass_mailing module);
* sms templates: sms.template (mass_mailing_sms module);
In a near future, some code will be added in this mixin, notably the template
rendering that could be moved outside of mail.template core model and moved
in that rendering mixin.
LINKS
Task ID 2070612
PR #36722
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Batch of 10 text messages was ok for testing. Production environment should
be able to handle more of them.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
sms, in the form view of sms composer (mass composition) : we got a blocking
message when we validate the composer sms with records which doesn't have a
phone number.
However we generally explicitly handle void numbers: in composer in comment
mode there is an User Error, and mass mode has specific error code to put on
sms records telling number is void (and sms is in error, meaning it will not)
be sent.
As sms record is required notably for mass mailing traces and marketing
automation traces we have to keep sms records with void numbers. We therefore
remove the required attribute on sms record.
Task ID 2073016 (sms fixes)
PR #37185
- Change the name of "Mass SMS" by "SMS Marketing"
- Improve the Mass Mailing views (kanban, form)
- Improve the Mass SMS views (kanban, search, form)
- Hide the sanitized numbers from views (sometime replace by mobile)
- Fix demo data of sms
- Explain the language field of sms template
- Improve the render of the sms composer wizard
TASK_ID : 2053631
In the SMS template, we add the ability to create (and remove)
a contextual action on the targeted model from a sms template.
We change the sms composer to guess the composition mode,
and then to be usable by contextual action. The guess compostion mode
works differently if there are multiple target
selected (mass) or a single target (comment).
TASK_ID : 2053631
- Cancel button in the sms form view not related to a action :
When we click on the cancel button of the sms form view, get traceback.
Fix the issue by adding the cancel action in sms model.
- Mass mailing contact - False as the display name :
The display name was the mail address but when the contact didn't have
mail address a ugly False was print to described the contact (form view).
Then change the _rec_name to print the name as the display name.
- Fix SMS composer for the res.parnter tree
Only the first record was truely selected when open the sms composer
(mass) from the tree view of partner. Fix that by bind the actives_ids
in the context and also fix the names of related actions.
TASK_ID : 2053631
This is a performance optimization: modifying a regular record will not
trigger some recomputation on a transient record. Most transient
records are simply waiting to be garbage-collected, so there is no need
to keep their fields up-to-date.
closesodoo/odoo#35909
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.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
Limit use of templates to models that are really capable of sending
SMS. Templates are now available on models that inherit from mail.thread
and effectively have fields used in SMS sending.
Technically this is done through a not stored field on ir.model that is
searchable. SMS sending capabilities is based on
* having fields holding phone numbers, as defined on mail.thread in SMS;
* having fields holding partners, as defined on mail.thread in SMS;
This implied some code rewriting notably about finding default SMS
recipients on a given model, in order to have fields instead of directly
returning partners.
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
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
Clean the use and options of sms composer after FP feedback :
* see https://s.nimbusweb.me/share/3167586/ap1xpy95rz29a5cys576 as basis;
* globally, do not display invalid recipients, only valid / invalid count
as well as current selection / active domain counts;
* consider logging a note as default behavior when using the composer;
* simplify code: when doing a mass SMS, send SMS and attach a simple note
to the document;
Some other points
* make name of sms templates translatable;
* improve various wording, notably in sms widget;
* display error code in sms list view;
* update sms composer actions accordingly by correctly setting active id
or ids;
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
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 support blacklisted and already-done numbers
when sending SMS.
* blacklist support: necessary to avoid sending SMS in batch to people that
asked to stop being spammed;
* already-done support: when performing mailing in batch or doing A/B testing
we may have already-done SMS;
When sending SMS in batch, already update state and error code of SMS that
should not be sent
* blacklisted number: set to canceled, with blacklist error code;
* duplicated number: set to canceled, with duplicated error code;
* invalid number (cannot sanitize): set to error, with either missing number
if void or wrong format if not void;
Support of blacklist / duplicated / invalid will notably be used when
performing SMS marketing (mass SMS) and marketing automation using mass
SMS.
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
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)
Partner / Contact model may hold valid mobile numbers in mobile or phone
fields.
LINKS
Task 1997464
closesodoo/odoo#35599
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Followup of merge 4287481 .
SPECIFICATIONS
wrong_format_number is actually now called wrong_number_format. This commit
propagates this renaming through SMS code and tests.
LINKS
Task 1922187
closesodoo/odoo#35025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Followup of merge 4287481 .
SPECIFICATIONS
Notification type is now a selection -> use 'sms' instead of True;
Fix typo in method renaming not correctly propagated to its view;
LINKS
Task 1922187
PURPOSE
Send SMS from server/automated actions. Indeed we can already send emails from
server actions. The goal is to have the same thing for the sms.
SPECIFICATION
Purpose of this commit is to add support of sending batch SMS through
server actions. This means sending SMS will be available also for
automated (base automation) and scheduled actions (cron).
A new type of server action is added: sms. User choose an sms.template
to use to send SMS in batch. An option allow to choose to keep archive on
selected records. If no archive is kept, a batch of sms is created. With
archive a _message_sms is performed with note subtype, allowing to have
a discuss messages with only sms customer being notified.
Linked to task 1935280
Part of PR #34864
PURPOSE
Improve use of SMS. Followup of merge 4287481bf0 .
SPECIFICATIONS
Currently when sending an SMS through the UI a message is posted using the
comment subtype. However it is better to lessen number of notifications
and log using the note subtype as it is mainly a log to know something has
been sent.
Order SMS by ID desc to ease finding them in technical menu.
Mail, sms: fix wording of mail / SMS failures
Linked to task 1925950 and 1935280
Part of PR #34864
PURPOSE
Purpose of this commit is to add options and improve sms composer behavior.
Followup of merge 4287481bf0 .
SPECIFICATIONS
* mass mode: add an option to keep archives when doing mass sms. This mode
is actually a _message_sms in batch using the note subtype to speedup the
process;
* improve _message_sms_schedule_mass to allow more fine-tuning of options
when calling it;
* do not block sending SMS in batch if some recipients are invalid. Indeed
using notifications there will be traces of failed SMS;
* avoid reload of form view;
Linked to task 1925950 and 1935280
Part of PR #34864
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Purpose of this commit is to allow users to have a feedback on SMS
notifications status in chatter. This commit contains notably
* an update of systray widget that now handles SMS failures. Those are
displayed in another item of the systray and redirect to documents having
an SMS failure;
* an update of chatter widgets to support SMS notifications in messages.
Failed notifications appear in red and allow to use the SMS resend
wizard;
Mail message model gains a new has_sms_error computed and searchable field
allowing to filter on messages having failed SMS notifications. Mail thread
model gains a new message_has_sms_error computed and searchable field, based
on the one on mail.message. It allows to filter on records with failed SMS
messages directly from the systray. That way clicking on the systray entry
redirects to the right records.
Related to task 1922163
Linked to PR #33510
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
Thibault Delavallée