PURPOSE
Overall cleaning of subscription and exclusion management code from portal.
This code comes mainly from v12 and can now benefit from cleaning and update.
SPECIFICATIONS
In this commit we rename ``mailing.contact.subscription`` model into the
shorter ``mailing.subscription``. This is sufficient to explain the model
purpose. As we plan to add an opt-out model this also allows to have sub
models with suffixes without being too long.
We also rename ``subscription_list_ids`` field on contact model to
``subscription_ids`` as this is shorter and clearer.
Finally the ``mailing_contact_list_rel`` table name that comes from old
implementations (simple m2m table) is renamed to ``mailing_subscription``
to match the model name.
Task-2669037 (Mass Mailing: Refactor js/portal for subscription)
Part-of: odoo/odoo#86084
Use name instead of email, as contact is notably used in sms marketing
application with mainly phone numbers. Better use the name as primary
ordering field. Then use ID to avoid non deterministic behavior.
This requires to fix some tests in 'test_mass_mailing' so that they
use test models instead of existing models. That way they are not
dependent on existing data and existing models definition anymore. An
issue with ordering rose as we modified the ordering of contact model.
Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#86084
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS: MAIL COMPOSER IN MAILING
When using the composer with a mailing, it currently skips recipients whose
email is a multi-email due to the strict usage of 'email_normalize'.
We can improve multi-email support by effectively checking for the first
email found, using the "less strict" mode of normalize. It means more emails
are detected as valid, and therefore sent.
Due to lower support of multi-emails when sending emails, this even allows
to send multiple emails as all emails are mailed.
SPECIFICATIONS: DEFAULT RECIPIENTS
Mailings are generally done using default recipients, aka using a model method
that returns the people to mail: customers ('partner_id'), customer emails
('email_from'), specific implementation, ...
This is implementation using '_message_get_default_recipients' that returns
'partner_ids', 'email_to' and 'email_cc' that are then used in the mail
composer to generate final recipients.
In this commit we better handle the content of email fields to avoid issues
with multi-emails. For that purpose we correctly split the content of those
fields. We now have several 'email_to' for records having multi-emails instead
of a single badly-formatted 'email_to'.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@4a0d87d44f
Part-of: odoo/odoo#134934
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Oversight of odoo/odoo@e7c2209406 . A whole model was duplicated due to a
bad conflict resolution. Indeed 'mailing.contact.subscription' model has been
moved into its own file at odoo/odoo@4f39a80e76 but original code was
added back in the contact file when forwarding the bug fix.
As model was created / defined twice, the second definition was simply
overriding the first one, hence no issue arose.
Prepares Task-2150462 (Mass Mailing: Improve subscription management)
Part-of: odoo/odoo#122106
The goal of this commit is to fix the problem introduced by the PR 106519.
How to reproduce the problem:
- Go to the "Email Marketing" app
- Go to the "Mailing Lists" menu
- Click on a "Mailing List"
- Click on the "Recipients" stat button
- Click on the "Import" button
Before this commit:
A dialog opens and no mailing list is selected.
After this commit:
A dialog opens and the mailing list we are in is selected.
closesodoo/odoo#106732
Related: odoo/enterprise#34453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit, we will convert all the customisations of the list view
consist in adding an always present button in the control panel that
performs an action/calls a model's method.
To do this, we will use the new display="always" parameter applicable
to buttons in the header of list views. This allows us to define a
button that is always visible in a list view.
closesodoo/odoo#106519
Taskid: 3082303
Related: odoo/enterprise#34387
Related: odoo/documentation#3044
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit when creating a mailing contact with a mailing
list opt_out at creation the unsubscription_date wasn't set.
Indeed, from the mailing contact view the mailing list uses an
editable list that passes all the values at create even when not set
contrary to when one update the contact only the changed values are
passed. This commit fix this issue.
Task-3070852
closesodoo/odoo#106682
X-original-commit: e7c22094068ce5cdff7f30178cea6d4f39f09137
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Hoste Patrick (pko) <pko@odoo.com>
PURPOSE
Reorganize addon according to guidelines, helping finding and updating code.
SPECIFICATIONS
Move subscription model into its own file, to ease future improvements. Do
the same for its views.
Also move menu entries into a specific file for menus, allowing to easily
understand menu organization in mass mailing.
A duplicated menu about link trackers in SMS is also removed.
Task-2864264 (Mass Mailing Module Reorganization)
Part-of: odoo/odoo#92509
PURPOSE
Reorganize addon according to guidelines, helping finding and updating code.
SPECIFICATIONS
Perform various code linting and cleanups, line breaks, linter issues...
No code or feature change should occur with this commit.
Task-2864264 (Mass Mailing Module Reorganization)
Part-of: odoo/odoo#92509
Currently when user starts using the app and tries to 'import records' from
'Mailing List Contacts', there is no templates available to assist the user.
This commit adds import template for mailing contacts to assist the users
in importing records.
taskID-2763984
closesodoo/odoo#84804
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Allows the user to easily import mailing contacts.
Specification
=============
Add a button "import" on the top of the mailing contact list view. This
button open the wizard <mailing.contact.import>.
So the user can select the mailing list and import his contacts with a
text field, one line for each contact.
Task-2703521
closesodoo/odoo#82333
Related: odoo/enterprise#23263
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
Since 576556d846 we merged the list
coming from the context key default_list_ids and the list given by the
user in subscription_list_ids. It worked well because the 2 fields
"list_ids" and "subscription_list_ids" were not in the same view at the
same time.
But if we want to create from the backend <mailing.contact> by giving
a value in "list_ids", the context key "default_list_ids" must be
ignored (like standard Odoo fields).
Task-2703521
Part-of: odoo/odoo#82333
PURPOSE
Remove hardcoded list of models on which mailing is possible. Indeed it is
not modular and not really smart with enterprise code not being reachable
in community.
SPECIFICATIONS
Replace hardcoded list of models on which mailing (both mail or sms) is
possible by a computed searchable field on ``ir.model`` based on a class
attribute.
It allows to cleanly define models having mass mailing capabilities and add
this attribute in bridge modules (when existing) or directly on base model
definition to avoid bridge modules.
In this commit we introduce a basic ``_mailing_enabled`` class attribute
activating mailing on model.
Mailing models may also have a ``_mailing_get_default_domain`` method allowing
to define a custom default domain when sending a marketing mailing on records
on this class.
Mailing models can now define a ``_mailing_get_opt_out_list(_sms)`` method
allowing to define custom behavior to fetch opt-outed records. Instead of
defining a model-based behavior on Mailing itself, it now calls the model
defined one. We still have two methods, one for mailing and one for SMS
opt out computation as it relies on different underlying models and fields.
LINKS
Task ID-2431217
COM PR odoo/odoo#67322
ENT PR odoo/enterprise#16876
UPG PR odoo/upgrade#2236
This commit introduces a new wizard that allows adding existing contacts of a
specific mailing list to another mailing.list.
It's typically used on the list view of a mailing.list where you tick a bunch
of contacts and add them all at once to another mailing.list (existing OR new
one that you create on the fly).
That tool will help users manage their mailing.list a bit easier and avoid some
tedious copy/pasting if mailing.lists need to share common contacts.
Wizard has two options: either simply create a new mailing list, either create
it and use it directly in a new mailing. It allows to cover the following
user flow
* select contacts;
* add them in a new list created on-the-fly;
* jump on a new mailing targeting this mailing-list;
* fill body, launch, enjoy !
Task-2453990
closesodoo/odoo#65965
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Noureddine Bensebia <neb@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Before this commit:
While trying to duplicate a mailing contact within particular
mailing list, it throws an user error saysing that 'A mailing
contact cannot subscribe to the same mailing list multiple times.'
After this commit:
User can duplicate a mailing contact from a mailing list without
the user error. In this case, we simply remove the default_list_ids
from the context, because all the mailing lists will be simply be
copied over from the existing contact and so we don't have to
re-add the default ones.
closesodoo/odoo#67094
Task-id: 2431344
X-original-commit: b92ebf3a47b7b1263669ac020ac8c213027400ea
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, on duplication, the contacts who opted-out from the
original list have the opt-out field set to False on the duplicated list.
After this commit, on duplication, for a contact who has opted-out from the
original list,the opt-out field will be set to True on the duplicated list,
Because when a recipient opt-out from a mailing list, chances are high that he
does not want to be included in the new duplicated list.
This commit also brings some fixes to the update and create methods on the
mailing_contact_subscription model so that
- The unsubscription_date is set to now only when no unsubscription_date is
given, because when another value for unsubscription_date is given by the
user it should be applied
- The opt_out field is set to True when the user sets an unsubscription_date,
because when a date is set for unsubscription_date, it means that the user
has opted-out from the list
We also update name of mailing list when duplicating it, adding a copy
mark to it.
Finally we also avoid copying mailing_ids through m2m relationship as it
may impact existing mailings.
Task ID-2431383
closesodoo/odoo#65277
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When creating new contact coming from a mailing list a default_list_ids
context key is set. It is used to give a default value to list belonging
and also to compute opt_out.
However subscription_ids field is displayed on contact form view, allowing
to add the contact to mailing lists. We may end up in situation where a list
is given twice to a contact: once through default_list_ids and once through
subscription_ids field manually completed by users.
In this commit we therefore merge those two values when creating contacts.
Also improve some wording while we are at it.
LINKS
Task ID-2300385
COM PR odoo/odoo#59872
ENT PR odoo/enterprise#14031
X-original-commit: 30bab79183b4b9f1a571d6ebd9bbc1f3c0692457
In mass mailing (_sms) when you set `Mailing Contact` as target model the
`opt_out` field is added to the default domain. However as it is a computed
field depending on a single mailing list given in context it should not be
used that way. Moreover current implementation raises a warning as only some
custom views can use this field accordingly.
This commit removes `opt_out` field being set by default in mailing domain and
also removes the UserError raised by the search function, thus avoiding
unwanted warnings.
Opt-out field is automatically taken into account when sending mass mailing on
contacts (see ``_get_opt_out_list``) so removing it from domain is actually
even better for coherency. Opt-out is not an option in sending process.
Task Id-2300427
PR #57310closesodoo/odoo#60262
X-original-commit: 5ccf5b51feaa348d775890e107fd30cd750699d8
Related: odoo/enterprise#14200
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Revamp the kanban view of the mass mailing (and mass SMS)
model to be more concise and readable. Also fix the issue of no border progress
bar in community version (same view).
- In the kanban view of mail marketing, when mailing list model is
targerted, the count of record was not correct.
Create a display condition if mailing list is used to fix the issue.
TASK_ID : 2075733
- 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
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
Prepare mass mailing module to addition of mass_mailing_sms.
Mailing model: mailing type
* add a mailing_type selection field;
* mass mailing contains only 'mail';
* synchronize medium accordingly;
* update actions of mass mailing application to add a domain on mailing
type being 'mail';
Mailing contact
* remove is_email_valid field as its purpose is achieved by email_normalized
field coming from address mixin (added by blacklist management);
Mailing contact subscription
* clean a bit fields and views as this should stay a technical model;
Trace model and report: trace type
* add a trace_type selection field;
* mass mailing contains only 'mail';
Various
* clean some bits of code in views, remove old code bits;
* add anchors to ease view inheritance to be able to customize views for
SMS mailings;
* ensure all views in mass mailing filter content on mail type (mailing
and traces being type mail only);
* rename some methods to be more updated with current guidelines, notably
main action methods;
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing.list and mail.mass_mailing.list to mailing.list
and mailing.list.merge. Rename mail.mass_mailing.contact to mailing.contact.
Rename mail.mailing_list.list_contact_rel to mailing.contact.subscription.
Rationale :
* those new names are easier to understand: mailing.list and mailing.contact
are less mail-related, especially taking into account that SMS will allow
to be less mail-oriented;
* those names are easier to read / find / understand;
* align wizard and sub-models naming with the main naming;
* have a mailing as first part of namespacing;
MIGRATION
mail.mass_mailing.list model -> mailing.list
mail.mass_mailing.list.merge model -> mailing.list.merge
mail.mass_mailing.contact model -> mailing.contact
mail.mass_mailing.list_contact_rel model -> mailing.contact.subscription
mail_mass_mailing_contact_list_rel table -> mailing_contact_list_rel (specific
case of a decorated m2m)
fields updated (no column change)
* mailing.list: subscription_contact_ids -> subscription_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
Thibault Delavallée