| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Create an invoice for a customer, send him an email from the chatter, in
the mail template set a specific "Reply to" and send the email. The
"Reply-To" template mail header is ignore and the one generated by
`mail_thread._notify_get_reply_to` is used.
See also 1c57d5e and 7b0806b
opw-2041640
closes odoo/odoo#35127
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
|
|
This reverts commit 7273719b880cc7c57e55a3334ffe99de36b27651.
Reply to header of templates should be used only for mass mailing purpose.
It is a known limitation and should not be changed in table without more
in-depth testing.
closes odoo/odoo#35354
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
The stable behaviour of the mail composer is the following:
- if a template adds new attachments, the composer only has this list
- if a template doesn't add attachments, the list is unchanged
- if no template is set, the list is cleared up
In the case of templates, we also check that both static and dynamic attachments
are added to the list.
We clean up after c6d718f2118 and subsequently 516f22c3987 which failed to take
into account the fact that the attachement list could be a blend of commands
and ids.
Transforming that is taken care of by _convert_to_write, which semantics was
changed by c6d718f2118.
To keep the second behaviour, we thus need to add a (5,) command.
opw 2003197
closes odoo/odoo#33707
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
|
|
|
|
Fine-tuning of 516f22c3987.
This commit missed attachments that are linked to a mail.template,
which should be added to every mail sent using the template.
To make sure that we both fix the duplicates and the generation issue,
we add a test.
opw 2000515
opw 1998782
closes odoo/odoo#33653
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
|
|
|
|
|
|
|
|
Open a mail.compose.message wizard.
Select a template that generates an attachment.
Reselect it. A second attachment has been generated.
Can be repeated ad infinitum.
At template onchange, the template is rendered to overwrite the composers values
This includes the attachments.
Let L1 be the list of attachments generated by the template.
When _convert_to_write(values) is called with {'attachment_ids': L1},
it gets self.attachments_ids = L2, and generates a [(6, 0, L1 + L2)] command.
As a result attachments are only added,
the previous ones need to be removed manually.
Since c6d718f, the semantics of _convert_to_write changed.
Before, it always returned an empty list for new records (without an id).
In other words, wa always had L2 == [].
As a result we need to adapt the wizard to keep its old behaviour.
To solve it we bypass the _convert_to_write for 'attachment_ids' and directly
generate the 6 command with the list of ids L1 generated by the template.
We only do this for templates that add attachments to keep the templates
composable (a template only overwrites the values it defines).
Unfortunately, we don't have any way to know which attachments have been added
manually, so we can't preserve these (which was the old behaviour anyway).
opw 1997430
opw 1987169
opw 1998115
opw 1998782
closes odoo/odoo#33387
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
|
|
|
|
Allow to specify the `model_description` when sending an email to take
into account for cases where the same model is used for different
business concepts.
opw-1915230
|
|
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
|
|
Apply the mail.address.mixin on blacklist mixin. So that every model
inheriting the blacklist.mixin will also inherit the address.mixin.
That simplify also the comparaison to - and the searches on - the
blacklist.
Task ID 1896677
|
|
Until now, a recipient with a formatted email like 'John Doe
<john_doe@example.com>' could be reached by email even if its email address
was blacklisted. Now when sending a mass mail using the composer, the email
is sanitized before comparing it to blacklist entries.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
|
|
Purpose
=======
Remove the method 'render_template' in mail.compose.message as the indirection
is not useful. Call the method on the correct model (mail.template) directly.
|
|
Several quick fixes:
- repair malformed SQL queries and injection problems
- proper token comparisons (consteq)
- better translatable terms (less context-lessplaceholders)
- basic testing of case-(in)sensitivity of blacklist
- safety check for non-implemented cases in search methods for computed
field
More testing and review is needed for case-sensitivity and email
extraction from generic "addressing fields".
|
|
Purpose
=======
- Apply the blacklist implementation to Improve mailing subscription to be more
compliant with the European GDPR law. Keep a list of people who does not want
to receive promotional emails (or mass mailing in general) anymore.
- Allows the recipient to update himself his mailing preferences
Specifications
===========
This commit is regrouping some main changes on mass mailing.
Apply Blacklist for following models through blacklist.mixin :
- crm.lead
- res.partner
- mail.mass_mailing.contact
- mail.channel.partner
- Opt_out per mailing list instead of per mailing contact.
- Replace opt_out by blacklist in crm.lead + res.partner models
- Added 'ignored' state for mass_mailing. Ignored = blacklisted, opted-out
Ignored email are not included into final statistics to avoid confusion.
- Unsubscribe(d) pages migrated from website_mass_mailing to mass_mailing module
as thoses pages should work without having the website module installed
Detailed implementation
===================
Mass-mailing :
- A blacklisted email is notified by the ban icon next to the email field.
(at the left of the email field for display purpose)
- Renaming the '_get_blacklist' method that was actually
searching opt_out list into 'get_opt_out_list'
- Opt out per mailing list : Add opt_out + related fields (for display and
ergonomy reasons) on the relational model
- Display relational model tree view instead of mass_mailing.contact tree
view when clicking on mass_mailing_list in kanban view
-> In order to be align between contact_nbr displayed in kanban tile and
the content of the tree view
-> mass_mailing contact is accesible via the user icon in this tree view
- Remove custom filters 'filter_contact_subscription' and
'filter_contact_unsubscription' as opt_out is not on mass_mailing.contact
model anymore
- Add 'is_public' to mailing list
The name of this mailing list can be seen (or not) by recipient in
the unsubscription page
If the mailing lists used in the mass mailing are not public,
the user in only informed that he has been unsubscribed.
If the mailing lists are public, the user is informed that he has been
unsubscribed from the mailing lists
and he has the choice to modify his subscription to all the public
mailing list he is or was subscribed to.
- Unsubscription Page :
- mass_mailing_contact :
Opt_out per mailing list, done by email and not by id, as multiple
contact can have the same email
The recipient can add/remove himself to/from the blacklist
The recipient can send a feedback about why he unsubscribed
- crm.lead + res.partner :
Once the recipient unsubscribe, he is automatically blacklisted
The recipient can 'Come back' and remove himself from the blacklist
if he changes his mind
- Show blacklist button parameter added in config :
The idea is to enable/disable the fact that the recipient can add
himself to the blacklist by showing or not the 'blacklist me' button
Only applies for mass_mailing.contact. The recipient, once
blacklisted, can always, no matter the value of this parameter,
'come back' and unblacklist himself
crm.lead + res.partner :
- Replace opt_out by blacklist in crm.lead + res.partner models.
As when a res.partner or crm.lead unsubcribe, we assume that the recipient
does not want to receive mass mailing anymore, at all, even if we adds him
to a mailing list afterwards. He is then blacklisted to avoid this.
With this behaviour, if a new lead is created with the same email address,
he won't be able to receive mail in mass_mode.
But he will still be able to receive '1 to 1' direct email.
Task ID 33224
Closes #25966
|
|
Purpose
=======
Improve mailing subscription to be more compliant with the European GDPR law.
Keep a list of people who does not want to receive promotional emails
(or mass mailing in general) anymore.
Specifications
===========
This commit is regrouping some main changes on mass mailing.
- Added blacklist : Avoid sending mass mailing to blacklisted recipient
(blacklisted = email address that doens't want to receive mass mailing anymore)
Detailed implementation
===================
Mail :
- Add Blacklist mechanism in mail module (NOT in mass-mailing) :
as we can send mass-mail without the mass-mailing module
- Unicity in email -> To avoid error in import, override the create and return
the existing record if any, else, create the record normally.
- Blacklisting is done by email address and is cross model.
Will apply to model that inherit the blacklist.mixin.
- field 'is_blacklisted' -> computed : check if email is in blacklist
+ search method to be able to filter on is_blacklisted
- When a email address is blacklisted, it will never get mass mailings anymore.
Even if the email address is added to another mailing lists
- Avoid sending notification to blacklisted recipients when sending email
in mass mail mode. If the recipient is blacklisted, we should not even send a
notification in the recipient's chatter for an email that he won't even
receive.
- When a email address is blacklisted, it can still get 'normal' mailings.
- The blacklist shoud be accessible in
Mass Mailing / Configuration / Blacklist
and Settings / Technical / Email / Blacklist
-> Renaming Settings / Technical / White / Black List config menu item
into Channel Moderation to avoid confusion with Mass Mail Blacklist
- Add indexes to the blacklist table (on email) to make it fast for access for
the different use cases
- _primary_email : attribute that must be overriden to specify which field must
be used as email in the blacklist mechanism.
- Filtering the blacklisted recipient in mail composer :
done in mail._get mail value()
In case of real mass mailing, we need the statistics to be computed in order
to know how many recipients were ignored in the mail.
So we cannot avoid sending mail but instead flag the mail as canceled.
Task ID 33224
|
|
This commit allows the user to link some mail template to activity type
with res_model.
When a activity has template, buttons appears in activity, allowing the user
to send mail based on templates.
Task: #1844563
PR: #25620
|
|
|
|
|
|
|
|
wrong indent.
|
|
Only the add_sign from notif_values is usefull for a resend. We can consider
that a mail on resend can be delete in every case, and we can find the
model_description from model since a resend can only be performed on
message linked to a model.
The other notif_values are now parameter in order to ease the understanding
of what can transit through this flow.
Task: #1860054
PR: #25622
|
|
This commit proposes to ease the use and specification of layout used to
encapsulate email body when sending notification emails. This is done
through two means
* message_post_with_template now supports the custom layout parameter
that allows to set the layout to use when sending notification emails
in the message_post process. We have to rely on the context as it is
the current way of using it in the composer. It is likely to change in
a near future;
* composer now supports through context (as we have no other choice)
specific notification values to give to the notification layout rendering;
This commit is related to task 51122 (and PR #24052).
|
|
message_post and various mail.thread related code still support a thread_model
context key allowing to redirect message post on another model. Purpose of
this commit is to get rid of that context key and support model / res_id
fields coming from either the record on which we run, either parameters of
message_post. Indeed those parameter match the one used as fields on mail
message. It makes sense to support them for customization if necessary
instead of using a context key.
This context key exists since a lot of time. It is difficult to find the
source as history is quite complex when the mail was refactored in 2012.
See notably 6aa4f80b2d9696a8dcbcc970bbd656b5842b02d4 and 2c4ed841b915cef42fe1f65d27427b7d86d659cd for example.
|
|
mail.thread mixing class defines several methods used in notification process
that are not specific to mail.thread enabled models. It means some models
could override it while some other models do not even have a direct access
to that method.
When calling those methods we have to manually check for method being
available on a record or call a default implementation from mail.thread
even if the model does not inherit from the mixin.
In this commit we propose to hide this check in generic wrappers located
in mail.thread class. It checks for method existence on record and call
the model-specific implementation or falls back on standard behavior. It
allows to be sure the right method is called.
Functionally behavior should stay globally the same. However when updating
some addons code has been updated. Previous code could lead to records not
having correct alias which should not be the case anymore. This commit is
linked to task ID 47934.
|
|
As explained in previous commit we can use xmlid_to_res_id instead of ref()
which leads to some query gain. This commit update some other less important
places: when setting activities as done and in the composer. This lead to
a gain in tests involving activities and composer, including tracking
triggering a template. On community runbot this leads to a gain of about 1K
queries.
|
|
Purpose of this commit is to allow to give additional values when rendering
notification emails and to make some parameters explicit.
This commit updates the _notify API. It allow to propagate a dictionary
containing values given to the rendering of the notification template.
This allow to have more complex templates and/or to control the rendering
depending on some parameters. Indeed currently only some fixed values and
values coming form the message to notify are given to the rendering
context.
First use will be soon when pushing notification emails not necessarily
linked to documents. In this process some values will be given by the caller
and not only by the message context anymore.
This commit also moves some context key used to control the notification
process directly in values given to the _notify method. It allows to make
those parameters explicit and rely less on context.
The _notify method now takes a values dictionary that may contain
* add_sign: add user signature to notification email, default is True.
It replaces the ``mail_notify_user_signature`` context key;
* mail_auto_delete: auto delete send emails, default is True. It
replaces the ``mail_auto_delete`` context key;
* other values are given to the context used to render the notification
template, allowing customization.
It allows to remove some context switch notably in the composer. A values
dictionary is computed and given to message_post and then propagated to
the notification mechanism.
|
|
Purpose of this commit is to clean the use of custom_layout in context
in order to have more explicit argument.
Several mail.compose.message instances are called using the
custom_layout magic key. As this parameter is now managed directly
by message_post API we can remove its management in the notification
process and add it explicitly in the wizard's message_post call.
|
|
Purpose of this commit is to perform a light cleaning of the email
notification process. It renames method by prefixing them by _notify
in order to easily spot them. It also makes them private because they
should not be called outside of other methods. Indeed those methods
are technical and do not provide useful information to external
people.
Future commits will probably improve the notification process in order
to clean it and try to reduce its query count.
This commit perform the following renaming
* message_get_email_values -> _notify_specific_email_values
* message_get_recipient_values -> _notify_email_recipients
* _message_notification_recipients -> _notify_classify_recipients
* message_get_reply_to -> _notify_get_reply_to
|
|
* one dead method;
* one unnecessary method to inline;
* one unnecessary wrapper;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
|
|
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
|
|
* Reverse wrapper courtesy of @rco-odoo's original P3 branch
* thin compat module stripped down from werkzeug (to augment as needed)
issue 8530
|
|
Remove unrestricted "read" access. To make code internally using `ir.model`
work, add a private method `_get` on `ir.model` to retrieve the record
corresponding to a model name, without access rights issue.
Change signature of method `get_authorized_fields` to make it use a model name
instead of a model id. This removes the necessity of a search on `ir.model`.
|
|
84a650e33aadb29661121410813e3de37a5ad3e9
|
|
This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.
New models are
* mail.activity.type: used to categorize activities. Each type is a different
kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
available for all models using activities; or specific to a model in which
case res_model_id field should be used.
* mail.activity: an actual activity to perform. Activities are linked to
documents using res_id and res_model_id fields. Activities have a deadline
that can be used in kanban view to display a status. Once done activities
are unlinked and a message is posted. This message has a new activity_type_id
field that indicates the activity linked to the message.
This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.
Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.
There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.
Next commits will aim at integrating activities inside main Odoo addons.
Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.
|
|
|
|
|
|
Oversight of previous forward-port.
|
|
|
