When implementing Sponsoring Document Incoming Management, I added a route to be able to receive attached document by email. But it has the flaw to require a specific format (raw email or JSON).
There are many services that provides hooks for inbound email like Sendgrid, Mailchimp, Postmark or Mailpace. They use a JSON format with little variation and so they can not be used with the current document incoming route.
Also they usually push all the email to a single hook but we may want to have different processes per destination addresses.
Proposal
In a module named inbound_email:
Add a generic application route with a type as parameter (raw as default).
The type define how to parse the request. By default it expect a raw email.
Provide a generic structure to represent the content of an email. This structure is used by implementation to convert for example the JSON specific format into a common one.
A model inbound_email.rule implementing MatchMixin with criteria:
origin: the email address of origin
destination: the email address of destination (match any To, Cc or Bcc)
subject: a regexp pattern on the Subject
attachment name: a regexp pattern on the attachment names.
headers: a One2Many of:
name: header name
value: a regexp pattern
and:
action: a list of available processing methods (ex: document incoming). The methods receive as parameter the structured email. (same design as for ir.cron)
The route must support to receive a list of emails per call (as some services group them).
The module configuration is restricted to “Administration” group under the “Administration” menu.
Each module that want to support inbound email, has to extend the rule model to add its actions.
Usage
This design is not restricted to webhook providers, it can work also with for example procmail receipt (like the example in the document incoming documentation). But also using an IMAP or POP script that fetch emails periodically.
Such feature can be used get track also of all replies of emails send by the system (using email from client or by automatic notifications) and link them back to the proper system. It will be great to have a generic implementation of that.
Would it be possible to extend this further? For example a customer has a ditched their phone system and move to a cloud based one like https://www.voys.co/ . The provider also have the possibility to push the phone data as JSON. So not only email data, but phone data is also possible.
I do not think so. This is mainly implementing a MUA which is not a goal for Tryton.
But it could be possible to process bounce messages using Variable envelope return path - Wikipedia and so mark the email log as failed to delivery. This would require to store a unique ID on each log entry (probably prior to saving because it must be used in the envelop sender).
Or to plug to any kind of modules that would implement an email interface like an Issue tracking system - Wikipedia.
The structure of a phone call is different from an email. So it can not be processed by the same set of rules.
So there should be a module inbound_phone maybe.
Processsing bounces is like prorcessing replies, no?
Normally emails have In-Reply to and References which identify the parent message. So it is not hard to relate them.
AFAIK all email messages already have a message id which identifiers them. If you do not send them, the email server will generate one.
?