Report errors via email

Add mailhandler_set_message($msg) and mailhandler_set_error($errmsg) functions.

mailhandler_set_message($msg) would append a message to a global array of messages to be returned to the sender if user preference is set to do so. Message would be formated as a status message and list all actions taken (listing urls to new nodes created, for example). The purpose of this is to indicate to the user when the message was accepted and processed.

On the user profile page, there could be a checkbox indicating that these status messages should be sent and an optional alternate email address to send them to.

The mailhandler_set_error function would be setup basically the same way, but the message format would indicate that an error occurred while processing email. The status message could be prepended to the error message as well if the mail was partially processed, but not completely. This should give the user some indication of what follow-up action to take, if any, or what file types are not accepted, etc..

An example of a mixed error/status message would be if a user sent in multiple files in a single email, and one was of a type not accepted, then a message would be returned detailing the success and failure of processing each attachment of the email.

I've implemented a tentative patch for this. I have not thoroughly tested it, so I'm hesitant to even throw it out here, but I might not have time to work on it tomorrow.

I coded it against version 4.5.0, so I'm changing the version of this request to 4.5.0. I will need to update the cvs version of mailhandler with this once it's accepted.

could we not use the standard drupal_set_message() and then finally retrieve with drupal_get_message()? these functions already have a $type param for positive or error messages.

I considered using drupal_set_message for this. In fact, I modeled my solution around it. I had two issues with using it:

1. It uses sessions, which I think would be unnecessary overhead for these messages. The lifespan of the set of messages is the time it takes to process a single mail message. On a server that sends session data to the database and has a large mailbox to read, this could greatly slow things down.

2. I don't want to pollute the regular webpage-bound messages with content that's being sent to email recipients. I couldn't see an easy way around this, as drupal_get_messages grabs and displays all content while clearing out the array for the next request. I considered creating and removing the appropriate sub arrays within drupal_set_message's data structure, but if ever the implementation changed, I'd be screwed. Also, any pass-by-reference instances have their own set of issues.

Should the following messages use watchdog in addition? they will usually happen during a cron run: -
drupal_set_message("Sending error email to sender $fromaddress");

Oops..that was meant for debugging purposes, but I guess it might be a good thing for site monitoring. We should probably discuss all of the messaging here and determine the current validity of it all as well as where it should go and when. I tend to prefer excess information, but I know it can be difficult to see real issues when there's so much data. I would like help figuring out what real users would prefer.

we usually submit patches in 'diff -u' format.

I just happened to be looking at the page in the Drupal handbook on contributing patches, and the -F^f option was mentioned there. I didn't know who, if any, prefers that format over the -u option. I think I like the -u option better, too.

There are a few lingering issues, like what controls how/when return mails are sent? Do we prefer the user preference or the mailhandler setting (or use the user preference conditionally based on the mailhandler setting)? I didn't alter the existing code where responses were sent. Would it make sense to merge both of these pieces of logic?

Also, should there be a limit to keep mailhandler from going off the deep end and sending 10Mb of error messages?

Also missing is the alternate return mail address. I still need to add this.

I rearranged the hook_user in addition to my changes. The version I started with didn't seem to be functional with 4.5.

diff -u version of same patch

The thought occurred to me that error/info messages could be constructed such that if the user replies, that their reply could be associated with the original post in the form of a comment or perhaps other information. This might qualify as a separate feature request, but I would suspect that just sending some form of reference to the original post (such as a $node->nid or $comment->cid) could be used in the reply to determine what to do with it (post comment for example).

This would be useful for mobile users who can only send text or binary, but not both. They could create a node full of binaries, get a reply message from the server, then reply to that to add a comment or append to/change a node body. Additionally, a comment hook could be configured to email the user all comments posted to a mailhandler-submitted node (again, separate feature request, I'm sure).

Does this sound like a practical feature, or am I just dreaming up busy work for myself? Moshe, I could see this taking on the form of the list handler syntax that you originally suggested. Are X-headers sent when a message is replied to? I'll test this out.

the only headers that get sent back upon reply are in-reply-to and/or references. mailhandler already parses these headers and adds them to the $node object which is handed to hook_mailhandler. you can encode as much info as you wish ni thesde headers. see listhandler.module for example usage.

The main use case that I would want to offer is for users to be able to post comments to the nodes that they just created. I suppose I could configure some in-reply-to headers to point their reply back to the just-posted node. Since multiple nodes could be created from a single email, does it make sense to send multiple response emails for this purpose? Maybe mailhandler_set_message should be configurable to accommodate this by specifying what node to associate what messages with. This would only work for messages generated after the node was created.

it seens to me that not many moblog users would be happy with a 2 step solution where they mailed binaries and then mailed text (or vice versa). the second interaction makes it just too annoying IMO. thats the whole reason we are avoiding authentication via a confirm email.

I would say, definitely, that a 2-step process for the initial post would be too painful for most mobloggers. However, if a user is at an event (away from computer) and posts content, I would like for them to have some facility for adding follow-up comments to that node, as well as being able to respond to comments that are posted to the node. Editing node properties of an existing node would probably not be very useful.

Do you know if a module exists already that sends email when a comment is posted to a node? If so, does it allow a user to reply to the comment via email? I know mailhandler handles comment posting, but I don't think it currently handles sending comments to an email address. Am I correct, and does that sound useful to you?

I sometimes wonder if I'm not unnecessrily adding complication to the problem, which is why I solicit your opinions. Does any of this seem useful to you?

Ok, I suppose determining how and when to send an email may be up to the individual module. I guess I was confused by the fact that mailhandler accepts nodes and comments via email, but does not send any emails that have headers compatible with mailhandler_process_message()'s logic.

I grepped through the contributions directory and found that: listhandler and project both use mailhandler, as well as several sandboxed modules.

After browsing through some of these modules, I can see how to construct an email so that it's reply should be associated with a particular node or comment (at least, in theory). I've started writing some code to handle this, but I've placed it within the moblog module.

Ok, more code!

Here's a patch against current CVS mailhandler.module that adds the following:

* mailhandler_perm: 'post by mail' permission: this is now wrapped around the calls to hook_mailhandler
* mailhandler_switch_user now returns the user being switched to (used for user_access() call)
* mailhandler_set_message: sets 'error' or 'info' messages for later processing
* mailhandler_get_messages: gets messages for processing
* mailhandler_email_response: If there are any messages and user pref allows, email is sent
* mailhandler_user: updated to work with d4.5, added 'send errors', 'send info' checkboxes and 'alternate reply email address' textfield to user prefs
* mailhandler_settings: added settings hook to allow admin to specify email/info email subject/titles.

Things that it doesn't have and (IMO) are beyond the scope of this feature:

* changing all calls to user_email to instead use the mailhandler_set_message functionality
* any intensively researched security changes due to the mailhandler_perm addition
* a means of formatting the error/info message bodies that involves all possible variables. Maybe some other day.

Please try this out when you get a chance. I don't think I've broken anything, but that's a common attitude among developers ;) I've implemented all of the major parts required to finish this feature, so all I suspect is left are bug fixes. I'm very curious to see how, if at all, this affects other mailhandler modules (listhandler, project).

If any further modifications are made to existing user_mail calls, I'd prefer them to be a separate feature, as this patch is already very big.

Ahem, now in unified diff format..

As far as enhancements to drupal_set_messages(), I would think that the cpu overhead of using sessions would be negligible compared to the pain of duplicating code. What would help would be able to pass an argument to drupal_get_messages($type=NULL) that, if specified, would return and clear just the messages of the specified type.

Maybe user mail options should go under their own user profile tab? I could see mailhandler, mailalias and others being grouped together like this. Which of the options do you think should be optional? I agree that it is cluttered looking. Maybe an "advanced" tab for more options?

Are you OK with the mailhandler_settings page (admin/settings/mailhandler) being separate from the mailbox management page (admin/mailhandler)? Should these be on the same page (but separate tabs), or do you think anyone would care?