- Sep 01, 2016
-
-
Thibault Delavallée authored
Having followers having an email address being an alias is rarely a good idea.
-
Thibault Delavallée authored
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.
-
Thibault Delavallée authored
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 / ...
-
Thibault Delavallée authored
Using after commit event notifications emails are now send once the current transaction is finished. This allows having issues with emails being sent while the transaction failed sometimes after email sending, but still in the same transaction. A small hook is done to allow invitation emails to be sent directly as some data related to mail.message is unlinked directly in the wizard.
-
Thibault Delavallée authored
This commit remove required alias on res.users model. It also removes the inheritance of mail.alias.mixin. The field alias_id is kept and allow people to use aliases on users if they want. However there is no default void alias created for each user anymore. Default from of mail.message does not use user alias anymore. Indeed this creates issues with aliases not being correctly configured and can be confusing compared to private channels. Using user aliases is therefore now done manually instead of being a default behavior.
-
Thibault Delavallée authored
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.
-
Thibault Delavallée authored
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.
-
Thibault Delavallée authored
This is an old compatibility code. It is time to remove it as it is not used sinces ages.
-
Thibault Delavallée authored
Previously Return-Path were composed using bounce_alias-<mail_id>-<model>- <thread_id> . However this may lead to return adresses not supported by the incoming mail server. We now form the bounce alias using bounce_alis+ <mail_id>-<model>-<thread_id>. Using a + indicates that the right part of the address is for information and used to manage the bounce. Only the left part is used for the email routing, allowing the return email to effectively land in the alias mailbox.
-
Thibault Delavallée authored
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.
-
Thibault Delavallée authored
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.
-
Thibault Delavallée authored
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.
-
Thibault Delavallée authored
Previous version of the test was actually not correct. Mailgateway was not considering references as in-reply-to when trying to find answers that have to be considered as a new thread instead of an answer to an existing thread. Purpose of the test is actually to be sure that answers considered as a new thread have no parent_id set. Otherwise you may have threads linked to messages belonging to other records, leading to access right issues. Moreover if this email begins a new discussion thread it makes no sense to have a parent message set. A new test is written to better simulate the test case. It sets a message_id containing reply_to which is the way odoo uses to indicated that answers to a message have to be considered as new threads. This is used notably in mass mailing for example.
-
Thibault Delavallée authored
We already know that a user is a shared user. This means a partner created for a customer for the purpose of sharing data. However sometimes it is interesting to know that a given partner is a customer or a partner linked to a shared user. This will be used notably in the Discuss app.
-
- Aug 31, 2016
-
-
Thibault Delavallée authored
-
Raphael Collet authored
This drops the backward compatibility with the old API: - remove method wrappers; - convert all the remaining old-API calls to the new API; - remove the processing of _columns, _defaults, _inherit_fields, _all_columns; - remove all old-API fields; - implement sparse fields; - modify the registry to become a mapping model_name -> model_class; - adapt XML-RPC and JSON-RPC gateways.
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
For the sake of simplicity, the method adapter `call_kw_multi` does not look up for `ids` in keyword arguments, instead it expects it in positional arguments.
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
Also refactor the test to prevent private methods to be remotely called.
-
Raphael Collet authored
Methods can no longer be called in both APIs.
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
In method `_auto_init`, use new-API fields instead of columns. Also remove the deprecated attribute `size` from reference fields.
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Raphael Collet authored
-
Denis Vermylen (dve) authored
when purchasing products from website, if partner did not have a country set the "pay now" button was broken. Now you get redirected to the billing form to fill in your address.
-
Denis Vermylen (dve) authored
take the payment icon from the acquirer image field, instead of a static unchangeable icon. Change the acquirer image on all acquirers data.
-