Activities now have recommended next activities. Based on next activities
configured on activity types, it allows to implement light workflows
using next activities feature.
This feature was removed when refactoring crm activities to generic
activities. People asking to remove it were visibly wrong and it is
now implemented back as it was in v10.
With this commit, the mimetype will be sent with the attachment.
That will allow some Mail Client (e.g. thunderbird) to 'understand' the
purpose of the attachemnt.
E.g. when you sent a text/calendar mimetype, thunderbird propose you to add
automatically the event into your calendar.
In 599bd509 for inline image in a mail the `Content-Id` of the
attachment was used as the file name to avoir an issue of several inline
images with the same name only displaying the first one.
This solved the issue but with it the file name when downloading the
image were lost as well as the extension which can be an issue.
This changeset refactor the code so the behavior stay the same but the
original file names are kept.
opw-725305
Redundant with `in` and removed from Python 3.
Removed odd, old and long-unused UpdatableDict (which defines and uses
has_key) and UpdatableStr (which was nearby and caught in the blast),
validated with al.
(lib2to3.fixes.fix_has_key)
* `<>` was removed and should be replaced by
`!=` (lib2to3.fixes.fix_ne)
* `\`` was removed and should be replaced by either `repr()` or the
`%r` format string modifier (lib2to3.fixes.fix_repr followed by
hand-rolled edition to replace concatenation)
The mass-mailing App suffered from severe issues due to its inability
to detect and handle duplicates "at the email level", and the absence
of any global blacklist system, leading to lack of user trust.
Mailing-lists typically include multiple records with the same email,
and it is critical to avoid sending them the same email several times.
A related problem is the unsubscription of an email that is present
in other records (duplicates). Opting out the first email should
automatically blacklist it for other records as well.
Ideally we should have a global blacklist table in order to
share the unsubscription requests globally across models (Leads,
Partners, Mailing-list contacts). It would also allow importing
it from other blacklist systems. (TODO for master)
This commit introduces a partial solution, made of several
small changes:
- In mail.mail: double-check that an outgoing email has the
correct status (`outgoing`) before sending it. This allows
adding emails in the queue and cancelling them before they
actually get sent.
- In crm.lead: force predictable recipients for mass-mailing,
by always using the email of the lead rather than the email
of the linked partner when there is one. This simplifies the
computation of the blacklist and seen list. Other areas in
the codebase already assume as much.
- In mass.mailing:
+ Before sending out a mailing-list batch, compute the
blacklist (all opted-out emails) and the seen_list
(emails who previously received this mail) to make
sure we only ever target valid recipients.
+ While delivering the mass-mailing, any email targeting
an address that is in the blacklist or "seen list" is
canceled before being sent. The corresponding statistics
entry is considered "not delivered".
Also updates the "seen list" continuously.
+ When a mass-mail belongs to a campaign with the
"unique AB/B testing" flag, the "seen list" is
common to the whole campaign, as an extra safety.
+ Auto-delete mass-mailing test messages sent with the
test wizard, to avoid polluting the mail_mail table
Note: this fix uses a simple regex for efficiently extracting
the blacklist in pure SQL from different models, and doing so,
assumes that each record only holds a single email
(no comma-separated adresses). This should be sufficient for
most cases. The regex:
([^ ,;<@]+@[^> ,;]+)
When setting an activity as done in chatter users now have the possibility
to add a feedback. This feedback is added in the generated message that
already contains the activity name and note.
Moreover users now can also immediately schedule a next activity. This is
very useful for chained activities and speeds up activities use.
Otherwise by default their alias are public. This makes no sense for
private groups to have by default public aliases.
Field is set as invisible on the view because it makes sense to configure
only the channel and not details of its alias. Anyway it is always
possible to tweak the alias configuration under Technical menu.
This commit makes channel use 'followers' based alias security use members
instead. Indeed channels do not use followers anymore. Instead channels
have members, and alias security of followers should use members instead.
Currently check of alias security is directly embedded in mail.thread
routing method. In this commit we move this check in the mail.alias.mixin
class itself. Doing this allows models to extend or improve the behavior
depending on how inheriting models use aliases.
Currently channel model manually defines alias and inherits instead of
using the alias.mixin. This commit proposes to use alias feature through
the mixin to have a standard behavior.
Using a m2m to partners does not allow a real management of members
because it allows to create partners, and require access rights on
partner model. Instead it now uses the o2m to channel members
allowing creation, update and removal of members without having
to work on partner records.
Commit 00bd7274c4 introduced speed improvements when
sending emails through batching and reusing an SMTP connection for a
given batch.
However exception management was slightly changed during that patch.
Previously to this patch all errors in the sending process were considered
as MailDeliveryException, except for MemoryError and psycopg errors.
However now mail_mail.send() may raise another kind of exception in the
SMTP connect process. Moreover a raise_exception parameter allows to
choose to either raise an exception, or just set emails in exception
state without raising an error. However since the patch it is not taken
into account correctly.
This leads to several issues, notably
* auth_signup waits for a MailDeliveryException when sending a password
request email. A badly configured SMTP server leads to a connection
error that is not caught. This prevents creating users, which could
be annoying.
* chatter does not handle exceptions as notification emails are sent
using raise_exception being False. Having an issue in the connect
process crashes the chatter.
This commit fixes the exception management so that it behaves like
before the patch.
Make sure the _send() method propagates the provided smtp_session
to benefit from the speedup obtained by avoiding multiple SMTP
sessions.
Cfr 00bd7274c4
Fix some dead code. This is a fallback for linking mail attachment with
its data. The issue was not reported since a long time since this just
disable a fallback which in my tests was not used anyway.
opw-710502
Work around performance issue when sending large mass-mailing:
1. Processing a large email queue would crash with MemoryError.
-> The queue agent will now browsing the emails 1 by 1 during
delivery to avoid filling the memory.
-> The agent will not select more than 10k emails per delivery.
The delivery rate can be increased by waking it more often.
2. Reopening a connection to the SMTP server every time is slow.
-> ir.mail_server.send_email() now accepts an extra `smtp_session`
optional parameter. When passed, that session will be used and will
not be disconnected after the delivery. The queue processing agent
prepares batches of emails to be sent to the same outgoing mail
server, and uses a persistent smtp_session to avoid the multiple
reconnection.
To account for MTA that would refuse to process a large number
of emails in the same session (that should be rare), a system
parameter can be used to set the batch size (default: 1000).
3. As a bonus, the ir.mail_server.connect() method is now
responsible for resolving the actual mail server parameters,
rather than having half of the logic in the send_email() method.
Warning: this commit drops support for "maildir:/" format in
outgoing mail servers hostnames. This feature is deprecated,
unused, untested, and was meant for debugging only.
- Create a SO with a new product configured as service, Track Service
"Create task and create hours" and link to "Internal - GAP Analysis".
- Confirm the SO
- Add a new line for the same product in the SO and save
A Odoo Server Error (Validation Error) appears "Error, a partner cannot
follow twice the same object"
It seems that the value of the related field `res_model` is not
correctly computed in the cache. As a workaround, we can use the
`res_model_id`.
Courtesy of @mart-e
opw-709790
Fixes#15589
Currently when scheduling activities, duplicate logs are created. Indeed
a message is posted when scheduling an activity, editing it and marking it
as done. This leads to a lot of noise being created on records.
This commit remove logs when scheduling and updating an activity. A sole
message is posted when the activity is marked as done.
This is a partial backport of commit 26940f8de4 targetting saas-15.
When computing default recipients to mail on some records, take into
account models having a partner_email field. Indeed this method checks
for some commonly-used partner or email fields to find recipients.
This allows to avoid having custom methods in each model. This commit
adds support for partner_email email field used notably in event and
track management.
Currently when scheduling activities, duplicate logs are created. Indeed
a message is posted when scheduling an activity, editing it and marking it
as done. This leads to a lot of noise being created on records.
This commit remove logs when scheduling and updating an activity. A sole
message is posted when the activity is marked as done.
Scheduled activity display in chatter is also improved to better
differentiate the user creating the activity from the user who is
assigned to the activity.
The boolean field `is_mail_thread` on `ir.model` allows to create custom models
that inherit from model `mail.thread`. The selection field `track_visibility`
on `ir.model.fields` allows to add tracking on custom fields.
Also change the order on model `ir.model` to make mail thread models appear first.
As message_post is defined on mail.thread abstract class its api.returns
is not automatically added on overridden versions of the method. This
commit add missing api.returns on all overrides of the method.
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
This commit cleans code to separate recipients computation in mail
message from notification mechanism in partner. There is no functional
change. Some variables have been renamed notably to know that
some of the record sets are sudoed during computation.
Currently if an user mentions someone in an internal note he is not
notified of any reply as replies create internal notes. This commit
ensure the author of the first note is notified of the reply even
if it is still an internal note.
Tests have been updated accordingly.
Christophe Simonis