Right now, you select command plugins to use in the parser configuration using a multi-select box. I think this should at least be converted to checkboxes, and descriptions should be added to each of the plugins.
Also, I should consider if this field is even necessary, or if all available command plugins should just be run. As long as there is only a small set of command plugins provided by Mailhandler, I don't see this being a problem.
Or I could just make all plugins enabled by default, so the field is still there but shouldn't need to be touched by most users.
Comments
Comment #1
weavie commentedFor me the confusion was probably my fault because part of my immediate need was to post emails to a node with text, image or text+image so I went in with the assumption that attachments would be parsed out of the box. Stepping through the Feeds importer (admin/structure/feeds) was the obvious place to look but if I didn't have some experience with Feeds I may not have thought to go there.
Since there are only three Command plugins I'd vote for the default being all active, though I can see how allowing users to mail comments and wanting to control attachments could be a common case and I don't know what would happen if the Files processor was active and I emailed text+image and the target content didn't allow an image. Would the text portion fail? (Part of the issue with posting via email is the lack of feedback on actions - the user doesn't know if the email didn't post because of a system problem, an email problem, a permissions problem, etc. The only feedback is a successful post and even that requires an extra action, i.e. check the site.)
It may just be case for more detailed instructions. I'd be happy to contribute to that if you can suggest the right place to post it.
thanks.
Comment #2
danepowell commentedYeah, the lack of feedback isn't just bad for users, it also makes my life hell sometimes ;) Ideally any errors show up in the watchdog, but some Feeds errors won't. So another issue worth spinning off might be looking at creating a unified error-handling function that can display errors on-screen, in the watchdog, and/or in an email bounce, depending on user preferences. We'd have to be able to capture Feeds errors as well though, which might be tough and require patches there.
Comment #3
weavie commentedIs it possible to match the email sender to a Drupal User by email address? I don't see a mapping in Feeds to User email, but if it's possible then I can see a path to providing feedback to users for at least successful mailhandler processes. Logging failures seems much trickier since there are so many points of failure.
Comment #4
danepowell commentedMapping from email address to Drupal UID happens in the Mailhandler Parser's Authentication Plugins.
Comment #5
weavie commentedI see it, in MailhandlerAuthenticateDefault.class you get the UID.
I'm sure there are many ways to go about this, but one method I thought about is related to the Feeds log since that is recording when a new node is created based on a Feed Node type. That's why I was wondering if there was a way to have Feeds map the sender to the UID.
Comment #6
danepowell commentedIn addition, I should consider whether Authentication and Command plugins should be combined, since the end-effect is the same. The only difference is that authenticating command plugins would need to run before (i.e. have a lower weight than) all other command plugins, and throw exceptions to stop processing if necessary.
Also, I should make it clear what the links are between command plugins and mapping sources. So next to each command plugin, display which mapping sources result from it; and in the legend for each mapping source, display which command plugin produced it.
Comment #7
danepowell commentedHere's a preliminary patch...
Comment #9
danepowell commentedHow about this one...
Comment #10
danepowell commentedhttp://drupalcode.org/project/mailhandler.git/commit/6d161fa
I removed the command plugin selection box on the parser configuration form. I don't see any way that having a command plugin run would pose a security risk, because you still have to map any commanded sources to processor targets.
I'll open separate issues about providing better feedback, considering combining the auth/command plugins, and displaying the link between command plugins and mapping sources.
Comment #11
danepowell commentedSpun off:
#1562030: Unified error-handling function
#1562032: Combined authentication and command plugins
#1562036: Display of links between command plugins and mapping sources
Comment #12
danepowell commentedComment #13
danepowell commentedhttp://drupalcode.org/project/mailhandler.git/commit/4696dd7