summaryrefslogtreecommitdiff
path: root/addons/test_mail_full/tests/__init__.py
AgeCommit message (Collapse)Author
2020-08-05[IMP] test_mail_full: add mass_mailing test, notably for preview / browser viewThibault Delavallée
Purpose of this commit is to add some mass mailing tests in test mail full (with all community mailing capabilities installed). In this commit we notably tests unsubscribe and view URLs computation in sent emails, as well as the invisible preview block for email clients. Task ID-2239327 Task ID-2239327 PR #49886 Related: odoo/enterprise#10091 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
2020-04-22[MOV] (test_)mail(_full): redispatch some tests and split test mail models fileThibault Delavallée
PURPOSE Have a cleaner test_mail addons SPECIFICATIONS Keep only mail-related tests, move odoobot in test mail full, send "update notification" tests in mail (specific to mail). Merge some test files to lessen number of files, perform light file renaming. Split test mail models file to prepare some cleaning in those models and tests. LINKS Prepares Task ID 2238597 (clean notification models) Prepares Task ID 2083854 (improve mass mailing technical flows) PR #49891
2019-08-12[ADD] mass_mailing_sms: support SMS in mass mailingThibault Delavallée
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 Create a new application called "Mass SMS" that follows the structure of mass_mailing application. General guidelines * use the fa-comment icon for this module; * add a "Notification type" field to the mailings: email or sms. Set it invisible and set as domain from context when choosing mass mailing or mass sms application (menus / action specific); * adapt the metrics from Mass Mailing to SMS * sent = received = whether the SMS was sent or not; * opened => we don't have this information; * replied => we don't have this information; * clicks = from link tracker (no change of behavior); * bounced = SMS that failed to be delivered because the format is wrong; * exception = any issue when sending SMS; * keep the Mailing Lists menu, hide email related fields on contact model; * settings: hide the "Specific Mail Server" feature Mailing form view * add an "SMS Content" tab between Mail Body and Options. In there, we should have the following fields: * content * opt-out link: provide a link to the Unsubscribe page. Make it as short as possible; * SMS Template * add an "SMS Text Message" Medium; Mailing actions * add an "SMS Sent" smart button. Use the fa-comment-o icon and it should redirect to the same list views as the "Email sent" smart button and list the contacts to which an SMS was sent; * add a "Mobile" field in the list views of the "Email sent" smart button: * adapt the TEST button > Test Mailing modal to SMS (we should have 1 button for Email and 1 for SMS); update description; * default value for the Recipients field should be Name of the current user, work mobile/phone number; * If there are no Work Mobile/Phone numbers set on res.users, display (123)-456-7890 instead; * rename the Send Sample Mail button into Send Sample SMS; * adapt the SEND NOW button > Confirmation modal to SMS. Change the message into "This will send the SMS Text Message to all recipients. Do you still want to proceed?" * hide the following elements: Subject, From, Reply to, Attachments, Mail Server, Mail Body tab; Opened, Replied; * adapt the label of the following "warnings" to SMS * x SMS Text Message(s) have been ignored and will not be sent. * x SMS Text Message(s) are in queue and will be sent soon. * x SMS Text Message(s) could not be sent. Mailing kanban view * hide the following stats: https://nimb.ws/grvBn0: Opened, Replied; Mailing list / contact management * following fields should be left empty: https://nimb.ws/3HBeJL: Opened, Replied; * when browsing through mailing lsits and contacts through the Mass SMS application, update actions and views to hide fields related to email and display only phone-related information; UTM Campaign * form view > Related Mailings tab: the following fields should be left empty if notification type = SMS: https://nimb.ws/nfvr1O: Opened, Replied Mass Mailing > Reporting (mail.trace.report model) * adapt the reporting based on the fact that we do not have the following metrics for SMS: Opened, Replied; Mass Mailing > Configuration > Blacklist * do not display any email information (phone blacklist is about phone); * support phone blacklist. Phone blacklist is therefore a separate model from mail.blacklist to simplify management. It is included in sms sending process like mail blacklist when mailing in mass; Opt-out and blacklist handling * we do support mailing lists because they could come from different sources and are a way to communicate with a specific audience (and not just a list we bought), e.g. subscribe to this list to be kept updated whenever this product is back in stock, or to receive results of this ... * if the SMSing is from a list, opt-out removes ourselves from the list; * if it is from the contact ==> Sent to blacklist; * allow to attach unsubscription links in sent SMS, redirecting to a new route in mass mailing SMS allowing quick unsubscribe and/or blacklist of phone numbers; Error management * if the user clicks on Send Now / Schedule / Test and does not have enough credits, open the "Insufficient credits" modal in a lazy option (aka when having failed statistics linked to insufficient credits); * on the mailing, we however display this failure as : * a message on the mailing kanban view * a message on the top of the form view + same behavior as the mailing and "Could not be sent" https://www.screencast.com/t/BExgd1Gc; LINKS Task 1997464 PR #34424 Original SMS addition: Task 1922163 (4287481)
2019-08-12[IMP] phone_validation: add blacklist mechanismThibault Delavallée
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)
2019-07-18[IMP] sms: allow to send SMS from server (and automated) actionsThibault Delavallée
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
2019-07-12[IMP] sms: allow to resend and cancel SMS notificationsThibault Delavallée
Purpose of this commit is to allow SMS notification management. It is based on what has been done in mail for notification: resend and cancel. In this commit we add wizards allowing users to resend and cancel failed SMS notifications. Resend allow to change the contact number, as well as resending only a subset of notifications. Future commits will improve the UX itself. Related to task 1922163 Linked to PR #33510 Co-Authored-By: Thibault Delavallee <tde@odoo.com> Co-Authored-By: Pierre Rousseau <pro@odoo.com>
2019-07-12[IMP] sms: add SMS template and its support in SMS composerPierre Rousseau
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>
2019-07-12[REF] sms: refactor message_post using SMS notificationsThibault Delavallée
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 be2795513644f09f6b443f462bb67cc5a0762e8d: performance and notification code improvements Co-Authored-By: Thibault Delavallee <tde@odoo.com> Co-Authored-By: Pierre Rousseau <pro@odoo.com>
2019-07-02[ADD] sms, test_mail(_full): add basic SMS tests and improve test toolsThibault Delavallée
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