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
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
A couple of places in the processing of bounces only
accepted a single matching partner. But there could
be multiple partners matching an email address, and
we should handle them all.
There might also be no matching `bounced_thread_id`
matched by the regex, so we should guard against a
bounced_thread_id == None.
Before this commit, 'select all' into a list view, and use an action that assign
a user_id to all the records will send n² email, because the function send_mail
use active_domain instead of the current record.
Now, we keep mass_mail mode, but simulate the case where we have clicked on
each record one by one and not all the records matching the active_domain.
So we send only one email by record.
How to reproduce:
create a action server "record.write(dict(user_id=env.user_id))"
add this action in context menu
select all records in a list and apply the action server
When you write on user_id in a model, that will automatically send an email
to the new user_id assigned.
In case where it is write in batch, that can be considered as spam.
In some case, the user will be aware from another way that with this email.
When Odoo sends emails their Message-Ids are either generated by Odoo or
use the original Message-Id in the case of an incoming email going through
the mail gateway.
When the mailgateway handles replies to those emails it checks their
References or In-Reply-To in order to find matching Message-Ids and find
the reply's parent. Currently it is limited to Message-Ids matching the Odoo
pattern. However if an external email began a discussion thread, references
will not hold any odoo-like pattern.
Previously to commit 0028c42136 this was hidden due to a bug when
managing private messages. This code was also managing replies to external
emails due to a probably undesired side effect.
Correct way of checking if an incoming email is a reply to a thread is to
check that References or In-Reply-To Message-Ids match some stored Message-Ids
of mail.message. They don't have to match Odoo patterN
Old versions of Odoo did not correctly manage message_id of mail messages.
Thread formation was based on information present in References and/or in
In-Reply-To of replies to emails. Message-Ids could contain model and
res_id of a record. Thread formation was done using this information.
However commit 8253453d64 fixed that behavior
by correctly checking in existing mail_messages to find matching message-ids.
Message found was set as parent and thread formation was correctly done without
collision or possible issues with badly formatted Message-Ids.
A compatibility mode was introduced at the same time to handle previous versions
of Odoo. This commit removes this compatibility as it was done long enough
to ensure compatibility is not required anymore.
[TESTS] mail: tests updated, compat mode should raise in all cases now
Move code related to redirection in its own class method. This way all
controllers perform their own actions and checks before calling the
redirection itself. Moreover it is necessary for some controllers to be
able to call the redirection independently outside of the mail/view
controller scope.
This commit also fixes some links generated for mail notification email
buttons. Assign and (un)follow buttons now effectively use the link helper
when generating the associated URL instead of manually crafting it.
Custom routes for notification buttons used in HR and CRM are added.
Indeed in order to be able to fine-tune the behavior called by those
buttons, using dedicated controllers is simpler than trying to use
a generic one. As there are few custom buttons in notification emails
using dedicated controllers does not lead to a code overhead.
When changing tracking mecanism in v9 'always' tracked fields lost their meaning.
They were managed like 'onchange' fields. This commit sets the old behavior back.
* 'onchange' fields are displayed in tracking every time they change
* 'always' fields are displayed in tracking every time they change or whenever
other tracking exist; those are used to display some contextual
information
There is now a single method easier to inherit to add specific behavior
for the display of access button as well as actions buttons. All addons
using this mechanism are updated accordingly.
* Assign controller now effectively redirects to mail/assign instead of
mail/assign
* Follow and Unfollow button now uses the helper that generated the link
If the 'To' of an incoming email is an alias on another model we now consider
this emails as a forward to a new alias. A use case for this is an email on
a task that should be considered as an issue and forwarded to another alias.
When a user is assigned to a model on a user_id field an email is sent to him
containing a link to the document. This way the user is warned he is now
responsible of the task / issue / lead / ...
Handle bounces using bounce alias directly in mailgateway. Previously bounces
were used only in mass mailing to update campaign statistics. Now the
mailgateway tries to find data from standard delivery status emails. This
data is used to update state of emails sent to customers, to display it in
the Chatter. It is also used to increment the message_bounce counter on the
bounced partner and bounced record, if any and if the field exists.
Previous more generic code that detect bounces is kept. This code is more specific
to standard delivery failure notifications by parsing its content.
Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.
This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.
Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.
When a new answer comes in a thread the mailgateway finds if the recipients
are linked to existing aliases. This allows notably to check if the author
can effectively contact this alias. Previously only the To was checked.
However we cannot ensure the recipient is contained in To as it could be
in Delivered-To for example. We now check for all possible recipients.
The purpose of this commit is to clean a bit the code related to email
routing in the mailgateway: message_route and message_route_verify.
message_route is now clearly separeted into two categories. First one
handles emails considered as answers to existing threads. Second one
handles emails that have to create new threads, either through alias or
default behavior of the mailgateway.
message_route_verify has been a bit facotrized to simplify the various
overrides that appeared lately in the codebase.
This commit only contains code cleaning. No functional change should occur
due to this commit.
mail.mail and mail.thread have methods to decode headers. This commit
move them in mail tools. It is indeed simplier to have all email tools
in the same file. Moreover they have been renamed to avoid confusion
with standard library methods: decode and decode_header already exist.
* decode in mail_message is now decode_smtp_header
* decode_header in mail_thread is now decode_message_header
A method to data from references is also moved into tools. A regex was
already defined in tools. Now the method using it is already put in tools.
Mailgateway will now simply call this method.
* mail_message.message_read() method is not used anymore since the chatter
refactoring in v9. message_format() is used instead. Tests for this method
are also removed, as they have no use anymore.
* mail_thread.message_set_read() is not used anymore. set_message_done is the
only method used by the new chatter as there is no read state anymore.
* removed an unused parameter in set_message_done, by the way
Rev. 15174e9a70 explicitly
cached ir.ui.menu entries, and required an explicit
cache invalidation when users changed their mail.group
subscriptions (mail.group used to override the ir.ui.menu
search(), cfr e.g. 89e404301b)
The menu search() override is gone as of 9.0, so it's time we get
rid of the unnecessary cache invalidation.
When posting a comment after an answer in the forum, a mail
was sent to each subscriber with 'Re: False' as title.
In fact the title has to be 'Re:' + the name of the parent
record of this message.
When a mail is sent from the post, a link to access the subject
of the forum must be included in the mail.
opw:679073
When posting a comment after an answer in the forum, a mail
was sent to each subscriber with 'Re: False' as title.
In fact the title has to be 'Re:' + the name of the parent
record of this message.
When a mail is sent from the post, a link to access the subject
of the forum must be included in the mail.
opw:679073
Nicolas Lempereur