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>
Purpose of this commit is to provide users templates to use when sending
SMS. It is inspired from what already exists for mail templates. This commit
* adds templates for SMS
* users can now create template for SMS Text messages similar to mail
templates;
* jinja syntax is supported for body like mail templates, which is why
templates are linked to a given model;
* refactor the SMS composer
* templates are supported in composer like the message composer. This is
supported only in mass mode to avoid bloating the interface in standard
composition mode;
* composer code is rewritten to support various use cases (comment, mass
sms, numbers, ...) and better fits all use cases;
* composer is extended to support notably mass SMS without posting messages;
Templates will also be used in a near future in mass sms sending (mass
mailing application improvement) and in marketing automation (for enterprise).
Tests are updated and added to ensure feature works.
Related to task 1922163
Linked to PR #33510
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Co-Authored-By: Pierre Rousseau <pro@odoo.com>
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>
message_post_with_sms method allow to give either numbers, either partners
or to fall back on default computation. Giving explicit partners does not
work because of wrong indentation in code not fetching their numbers.
Related to task 1922163
Linked to PR #33567
Thibault Delavallée