It is better to use another naming than re-using class names. Somehow it
seems sometimes we have MRO issues.
Task ID-2390314
PR odoo/odoo#62384
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
LINKS
Task ID 2229050
PR #51159
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aymane Taibi <ayt@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Modules holding tests and helpers
* link_tracker: mainly mock, asserts and tools for link tracker tests
(MockLinkTracker);
* mail: mainly gateway mock and base for mail tests
* MockEmail -> mocks for mail gateway;
* MailCase -> tools and asserts for mail tests;
* MailCommon -> base for mail functional tests);
* sms: mainly SMS gateway mock and base for sms tests
* MockSMS -> mocks for SMS gateway;
* SMS Case -> tools and asserts for mail / SMS tests;
* SMSCommon -> update of MailCommon with SMS capabilities);
* mass_mailing: mainly asserts and tools for mass mailing tests
* MassMailCase -> update of MailCase for mass mailing tools and asserts;
* MassMailCommon -> update of MailCommon with mass mailing);
* mass_mailing_sms: mainly asserts and tools for mass SMS tests
* MockMassSMS -> update of MockSMS for mass SMS tools and asserts;
* MassSMSCommon -> update of MassMailCommon with SMS capabilities);
Modules for tests
* test_mail: module for mail app tests (TestMailCommon);
* test_mass_mailing: module for mass mailing app tests (TestMassMailCommon);
* test_mail_full: tests integrating all discuss features, currently mainly
mail and SMS (TestMailFullCommon);
Enterprise: update test_mail_enterprise and test_marketing_automation
Task ID 2247037
Community PR odoo/odoo#50384
Enterprise PR odoo/enterprise#10266
Upgrade PR odoo/upgrade#1122
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
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>
In this commit we perform some cleaning in composer model before adding
number update feature:
* remove partner_ids field that is not used anymore. It comes from early
implementation of SMS composer and is now dead;
* rename recipient_count to recipient_valid_count to better reflect its
use;
* rename recipient_description to recipient_single_description to better
reflect it is used only in mono-recipient mode;
* add a new single comment computed field, allowing to display some
information only when sending an sms to a single given record;
We also fix computed fields by making them work in batch.
LINKS
Task ID
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>
This reverts commit 976e560a87.
Even if it didn't looked like a bad idea, this need some more thinking.
This new version of query count creates random failure of runbot builds.
closesodoo/odoo#43820
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- take advantage of runbot multi-build capabilities
- get similar result when running them locally during dev
- better detect when other modules add extra queries
Query counts are split in the base value (testing with just test_mail installed)
+ the extra modules overhead.
Part of task-2178641
closes odoo/odoo#43666
Pr: #43666
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
PURPOSE
Currently tools and asserts for mail tests are located inside test_mail
module. It makes difficult to re-use them in apps tests or force them to
write custom quick and dirty tools and asserts.
SPECIFICATIONS
Update this module to new tools / asserts / helpers / classes defined in mail
and test_mail.
In this commit we remove the ``BaseFunctionalTest`` and replace it by a fresh
``TestSMSCommon`` that is the combination of ``TestMailCommon`` from mail and
mass mailing with SMS mocks capabilities. That way all mocks and asserts are
available in all sub test classes.
``MassSMSBaseFunctionalTest`` is not necessary anymore as everything is
available directly with ``TestSMSCommon``.
Coming from common update, we have notably
* ``BaseFunctionalTest`` class is replaced by the new ``TestMailCommon``
pimped one;
* ``assertNotifications`` is replaced by ``assertSinglePostNotifications``
(shortcut for a simple message_post) or ``assertPostNotifications``
(complete asserts involving several messages and notifications);
* correctly invoke ``mock_mail_gateway`` when mocking email sending;
* replace manual check of sent emails or ``assertEmails`` by
``assertSentEmails``;
* remove custom mocks / checks and replace them by now standard mocks
and assertions (if any);
LINKS
Task ID 2068986
PR #38070
load_lang was a kind of hybrid method trying to active or creating a
language if not found. This was error prone.
Instead rely on two methods with clear purpose:
ResLang._create_lang(lang, lang_name=None)
- create a new res.lang entry using the locale of the server
return the res.lang record to match the API of _activate_lang
ResLang._active_lang(code)
- activate the given code lang
Most of the time, _active_lang is what is expected
tools.trans_load_data and IrTranslation._load_module_terms no longer
activate the language if not active.
Loading the translations should be explicit on an activated language,
it is too error prone to silently activate/create a language if not
found.
Remove lang_name from trans_load_data as no longer needed.
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
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)
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
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>
Purpose of this commit is to improve and add tools, methods and data to test
mail and SMS features. We also add tests for current implementation of SMS
feature, allowing to better understand future changes.
[ADD] test_mail_full
* have a module depending on mail sub-applications like sms or snailmail.
Its purpose is to check that standard mail features work effectively with
all overrides and extra behaviors activated;
* add a new model specific for SMS gateway, with default recipient
computation;
* add SMS tests for SMS module adding SMS capabilities linked to mail
feature. This commit tests SMS feature before the upcoming refactoring
and improvement of SMS module in community: posting with SMS and sms
composer usage;
In test_mail
* add necessary mobile information on test partners;
* improve assertBusNotification that was not correctly asserting all items
in message of bus notifications;
In sms
* add mock for SMS sending. Purpose is to mock the connection to IAP
services by mocking the call to IAP server. It allows to perform SMS
tests without having to contact (and pay) for this service;
* allow some customization when calling the SMS gateway mock to simulate
errors and test corner cases;
Related to task 1922163
Linked to PR #34516
