Drupal Association members fund grants that make connections all over the world.
I've never been fully satisfied with Feeds, partly because I just don't think the concept of a "feed" completely applies to a mailbox. A feed implies an ordered, unilateral (one-way) read operation between the feed and the Importer. But a mailbox is inherently bilateral- we have to write back to mark emails as read, etc... This makes some types of error-handling almost impossible to accomplish with Feeds.
The complexity of Feeds gives it an unforgivingly steep learning curve, which I think turns a lot of people off from Mailhandler 2.x, but the rigidity makes it hard to break out of the "fetch->parse->process" workflow for any reasonably interesting edge case.
Use Rules instead of Feeds. Develop a proof-of-concept in D7, then migrate it to D8. I don't want to support too many major branches simultaneously, so the plan would be to maintain 6.x-2.x and 7.x-2.x for the foreseeable future, work on developing 7.x-3.x/8.x-1.x (Rules-based branches) during that time, and when D8 lands stop supporting 6.x-2.x and only support 7.x-2.x (Feeds-based) / 8.x-1.x (Rules-based).
Tasks required for proof-of-concept:
- Start a 7.x-3.x branch to develop a proof-of-concept
- Implement Mailbox configurations and retrieval plugins just like in 7.x-2.x, as well as permissions to administer mailboxes
- Create Mail entities that represent imported emails. The question here is should all reasonable headers be broken out into fields (From, To, Message ID...) or should there just be a single Headers field, and command plugins can provide tokens for from/to/etc based on the headers. I really like making things granular, but the Token-based solution sounds better since we'll already be providing tokens for User ID.
- Write importer code (mailhandler_collect_mail()) to turn new emails into mail entities on cron.
- Write code to provide tokens for authenticated User ID (From address) and other common headers
- Create a quick-start set of rules to turn new emails into articles.
Big issues still to consider:
- How to implement command plugins
- Probably just like they are now- text boxes on Rules that define available plugins. Problems with this: is this even possible, and how can you turn these entries into tokens for use on the same Rules? How can you define default values at import time?
- How to accomplish workflow proposed in original report
Other features currently provided by Mailhandler that need to be reimplemented in 8.x-1.x:
- Help pages
- Filters plugins (distinguishing comments and nodes)
- Input Filters
- Authentication via Tokenauth and Multiple Email
User interface changes
Example import flow:
- hook_cron or Rules scheduler fires mailhandler_collect_mail()
- mailhandler_collect_mail() checks all mailboxes, and turns any new mail into Mail entities. This will be accomplished using the existing Mailbox configurations and retrieval plugins. This process should be pretty "dumb" - Mail entities should match the original emails as closely as possible, with a bare minimum of processing/sanitization. Mail entities will have the following fields:
- Headers (To/From/Message ID/etc...
- Body (HTML)
- Body (Plain text)
- A trigger "After mail save" allows Rules to act on new Mail entities. Authenticate plugins provide Tokens for Authenticated User ID (From address), Authenticated User ID (Tokenauth), etc...
- A Rule creates a new node (or whatever else you want), and sets the field values using these provided Tokens, replicating the mapping functionality currently in Feeds
Original report by heylookalive
This is an idea I'm working through as I'm thinking it could be really good and figure I should bounce it off other people.
Instead of using Feeds to process emails we could use rules instead, this means that you could perform pretty much any action including creating nodes (though would need to work out a mapping solution). It wouldn't be without complexities but would be inherently more powerful as the current solution assumes that we want to create.
I'd think that this would need to be a new branch (7.x-3), any interest?
An example flow for a site:
- User comments on a node (requires approval first)
- Site sends an email with rules to admins with the identifier "[c:9999]" in the subject (comment entity, entity id 9999). This email has a reply-to of the mailhandler email address
- Site admin replies to this email with either the text "approve" or "reject"
- Drupal draws in this email, triggers any rules with the action "mailhandler processes email", in this case the rule would approve the specified entity if the message body contains "approve"