Some modules that implement hook_mailhandler_post_save need information from the original email/node in order to act, not just the nid and node information that's already been saved. This patch simply passes the original $node as an additional parameter, which shouldn't interfere with modules that already implement this hook and will allow other modules to function.

If you need more motivation - this is part of a larger effort to get Mailhandler/Mailsave/Mailcomment/Comment Driven to play nicely together as part of a unified workflow with attachments and Driven-based tracking. Basically, after Mailhandler posts an incoming comment via email with attachments, Mailcomment implements hook_mailhandler_post_save and can add those attachments to the parent node with the changes being noted in Comment Driven. Note that Mailcomment can't implement hook_mailhandler, because at that point the comment hasn't been saved and we need to know the cid before we save the parent node for Comment Driven to work. Hence the need for this patch to hook_mailhandler_post_save - to have the same amount of information about the original post as we would if we'd implemented hook_mailhandler.

Comments

danepowell’s picture

FYI, issues in other queues that are part of this project are #813356: Expanded support for mailcomment attachments and #825304: Support comments not inserted via FAPI.

obrienmd’s picture

Subscribe. Thanks for all the hard work, Dane!

arhak’s picture

subscribe

arhak’s picture

I'd say this patch is way too much
you already have the $nid, if you want the $node do your own node_load

why do you need to be fed?

danepowell’s picture

The comment/email object (inaptly named $node) has certain properties (specifically, the list of files attached to the incoming email) that do not get preserved when the comment is saved. Thus, we need access to that original object even after it's saved as a comment, so we can get those properties and attach them to the parent node.

arhak’s picture

it doesn't bothered me the first time I read this patch
but today it yelled at me

now I re-read the comment:
// Pass in the $nid (which could be a $cid, depending on $node->type)

so, having an Id wouldn't tell you if it is a cid or nid
and the $node variable is not a comment neither a node, rather the comment/email object

wow, it seems that this module could use some cleanup and commented code
but not your issue

BTW, maintainers we mean no harm, it's just that we are dealing with it and we get lost
PS: I'm sure that by "inaptly" Dane meant "inappropriately" rather than "incompetently"

danepowell’s picture

Indeed, I meant inapt as in "unfitting", not "unskilled" - I have the utmost respect for everyone involved with these modules :)

danepowell’s picture

@Ian- how do you feel about this patch?

Also, would you indulge me with your thoughts on some constructive commentary? Working on this issue has gotten me to thinking that it might make sense to decrease Mailhandler's scope a bit and just make it responsible for pulling in content from a mailbox. It could then invoke a hook to pass the content off to other modules (such as Mailcomment, or a new "Mailnode" that would replace the existing functionality in Mailhandler), and those modules would actually save the content (using node_save or comment_save). It seems a little roundabout that Mailhandler passes comments off to Mailcomment but then saves them itself, and nodes as well, leading to code-comments like // Pass in the $nid (which could be a $cid, depending on $node->type) :)

Ian Ward’s picture

@Dane, just wanted to let you know I see this thread and I should get around to the queue next week. WRT the scope of mailhandler, I agree it needs to be cut back. I started Mailhandler 2.x awhile ago and it's getting close to alpha http://github.com/ianshward/Mailhandler-2.0 ... it leans on the Feeds module framework, with the base module just handling parsing an IMAP stream. You can then write a processor which takes the parsed message information and does something with it, like create nodes. The node-centricity is completely broken out from the base mailhandler module and lives in a mailhandler_node module which implements its own node/comment processor. You can also write custom command parsing plugins, etc. This should make its way back into Drupal CVS soon http://github.com/ianshward/Mailhandler-2.0

Ian Ward’s picture

Attached is a patch which changes the name of the misleading $nid param and adds a comment about what's going on. I figured we may as well take this opportunity to improve that $nid param name. I couldn't think of anything better than $saved. But, I agree that $nid is confusing, and $id doesn't make sense either since it's sometimes an object.

Ian Ward’s picture

I just marked #801992: $nid in hook_mailhandler_post_after as a dupe of this.

arhak’s picture

I would prefer the first parameter to be an $id (whether cid or nid)
$type will make the distinction and the original $node object will be passed anyway
but I guess backward compatibility must be preserved, sigh

BTW patch at #10 is too short, $saved is not even initialized (and I'm not clear about what's in $node at that point)

  if ($node) {
    if ($node->type == 'comment') {
      $nid = mailhandler_comment_submit($node, $header, $mailbox, $origbody);
      $type = 'comment';
    }
    else {
      $nid = mailhandler_node_submit($node, $header, $mailbox, $origbody);
      $type = 'node';
    }
  }
Ian Ward’s picture

@arhak thanks for the review. Here's an updated patch. I agree about the backwards compatibility.

danepowell’s picture

Yeah, it looks like $saved still needs to be set, but other than that I like this. Thanks Ian.

@arhak - yeah it's not the cleanest implementation, but I think it'll do until mailhandler-6.x-2.x drops, which is a huge and lovely refactor I hear :)

danepowell’s picture

I didn't see how this patch could break anything, so in the interest of clearing out old issues I went ahead and committed #13: http://drupal.org/commitlog/commit/96/939e05bb2e01b2bc9a66f046fb05f61a03...

danepowell’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.