Add trigger/action for e-mail notification

Would you agree that this won't fix, if we would implement #351698: Use entities for Feedback messages? New features go into 6.x first, and in 6.x, there are default actions for the "node creation" trigger. My point is that I would want to configure the recipient's mail address (and not bug the site owner, resp. client with feedback messages), but the whole mechanism would already be available in Drupal core if Feedback would use nodes to store feedback messages.

Yes, if it is clean & solid, and does not become burden with me. ;) I'd rather like to invest time in the back-end abstraction / node based back-end...

I would also be very interested in a patch that supports notification. Storing it in a database is awesome, but there should be a way to have it sent to someone, or at least notify them of a new entry.

You shouldn't need to constantly check a log, just to handle user feedback in a timely fashion.

I agree that the node based / trigger approach would be a better end solution, but a quick and dirty configurable email address to send notifications to would be a nice added feature for now.

me agree.

I have added a hook to my copy of this module, in the feedback_form_submit() function. This allows me to intercept the feedback submission in another module (our custom project module) and take whatever action we wish.

In the function feedback_form_submit(), I have added this as the first line:

module_invoke_all( 'feedback_form_submit', $form, $form_state );

Now, in a module called 'foo', we can create a function foo_feedback_form_submit(), and it will be called whenever feedback is submitted.

Sun, any chance of adding this hook to the module? It is trivial to add, and provides an enormous increase in flexibility to developers.

Here is my custom module's implementation of this hook (with names changed to protect the innocent), which sends out a notification email to all users with a particular role ID:

<?php
// implementation of hook_feedback_form_submit
// sends notification email to all users with Admin role
function foo_feedback_form_submit( &$form, &$form_state ){
	global $user;
	
	$location = url( $form_state['values']['location'], array( 'absolute' => true ) );
	$agent = $_SERVER['HTTP_USER_AGENT'];
	$message = $form_state['values']['message'];
	
	$body = "A feedback message has been received from My Site Name\n\n";
	$body .= "User:\n$user->name ($user->mail)\n\n";
	$body .= "Location:\n$location\n\n";
	$body .= "User Agent:\n$agent\n\n";
	$body .= "Message:\n$message";
	
	// load all users with role ID = MY_ADMIN_ROLE_ID
	$result = db_query("SELECT u.mail FROM {users} u INNER JOIN {users_roles} ur ON u.uid=ur.uid WHERE ur.rid = %d AND u.status = 1", MY_ADMIN_ROLE_ID );
	$emails = array();
	while ($u = db_fetch_object($result)) {
		$emails[] = $u->mail;
	}
	
	$mail = array(
		'id' => 'feedback',
		'to' => implode( ', ', $emails ),
		'subject' => 'My Site Name - User Feedback',
		'body' => drupal_wrap_mail( $body ),
		'headers' => array(
			'From' => variable_get('site_mail', ini_get('sendmail_from')),
			'MIME-Version' => '1.0',
			'Content-Type' => 'text/plain; charset=UTF-8; format=flowed; delsp=yes',
			'Content-Transfer-Encoding' => '8Bit',
			'X-Mailer' => 'Drupal',
			'Reply-To' => $user->mail
		)
	);
	
	drupal_mail_send( $mail );
}
?>

Hope this helps someone.

Absolutely, I would love to see an "out of the box" solution for notification as well. It sounds like Sun wants to implement this using Nodes though, so I'm thinking that won't be for a while.

In the meantime though, I'm happy with my one-liner hook addition... trivial to re-add if the module is updated.

Ideally, we could have both. Admin interface for ease of use, hook for maximum flexibility.

I thought if I attached a patch, sun might be more likely to commit :)

Patch adds brian_c's hook from #9

Well...

1) This patch contains coding-style issues.

2) It does not add the requested functionality. Instead, it defers to a yet-unknown (any) module to take over the notification.

sorry about that. sloppy copy and paste. also just realized it's just as easy to form alter and add a custom submit function.

ok. So what I want to see here is an implementation of actions (and triggers), because that's a future-proof way of doing things. That way, the e-mail notification is configurable, can be toggled, and users could even assign other actions to Feedback's trigger (f.e. displaying a message or whatever).

Implementing triggers / actions would be ideal.

Agree. Subscribing.

Attached Patch does the following.

• Adds "After feedback has been submitted" Trigger.
• Adds "After feedback has been processed" Trigger.
• Adds "administer feedback triggers" permission.
• Adds "Send current user an e-mail" Action.
• Makes all system and user Actions avaliable for use.
• Passes Coder. :-)

Hope it helps.

Thanks for your work antgiant.

Any chance of a 5.x patch?

@davidlerin not from me. Sorry.

However, the Actions project (http://drupal.org/project/actions) may cause this patch to work in 5.x. (I can't verify as I don't have any 5.x installs.) Hope that helps.

Note that the original issue was about sending an e-mail to a list of addresses (usually site admins or developers) while the latest patch sends an e-mail to the user who was giving the feedback. I've taken antgiant's patch from #19 and developed it a bit further:
- Added a configurable list of recipients to the action.
- The primary object passed to actions should not be a user object but an instance of the feedback object itself.
- Also feedback is NOT node-specific, so I've completely removed the node/taxonomy stuff used in the e-mail generation. Instead you have now access to almost all feedback object properties.
- If there can be found a way to #470146: Track title of current page, we could add another replacement token for it.

This patch is completely UNTESTED.

@smk-ka You don't need to modify the action I provided to send it to a list. You can use the existing action provided by the system module to "send email...". I like the idea of sending the feedback object as the primary object. I just wasn't sure of its impact on existing user and system actions.

Subscribing.

subscribing

In #492094: Rules integration: rules event when submitting feedback I have submitted a patch that provides integration with the Rules module, a more powerful approach to core actions/trigger

Subscribing

Attached is an updated version of the patch from #22 which fixes some issues (like not having access to the variables when sending the message) and seems to work ok for me.

I can see the action but how is this triggered? Just setting the action doesn't send any email.

Once you have an action configured (at admin/settings/actions/manage) you should go to admin/build/trigger/feedback and assign that action to the 'After feedback has been submitted' trigger.

/admin/build/trigger/feedback gives "You are not authorized to access this page. " - access denied. I am uid/1 so something is wrong with the patch.

@charos, have you tried clearing the menu cache to see if that had an effect?

cleared all cache few times,run cron , nothing changes.

Updated patch fixes a couple of things (the interpretation of 'status' was inverted in previous patch).

Unfortunately core actions in 6.x expects the use of a hook_feedback with an $op parameter, so we do have to do it this way.

I tested it and all the token replacements are working.

I'm going to try to extend it to work with rules to combine this with #492094: Rules integration: rules event when submitting feedback.

We should do #402438: Add proper API functions and hooks to allow other modules to interact with Feedback messages first.

Minor issues of the current patch:

+++ feedback.module	31 Dec 2010 19:30:15 -0000
@@ -224,8 +224,19 @@ function feedback_mask_path($path) {
+  ¶
...
+  ¶

@@ -236,3 +247,166 @@ function feedback_user($op, &$edit, &$ac
+ ¶
...
+ ¶

Trailing white-space.

+++ feedback.module	31 Dec 2010 19:30:15 -0000
@@ -236,3 +247,166 @@ function feedback_user($op, &$edit, &$ac
+/**
+* Implementation of hook_hook_info().
+*/

1) Bogus indentation.

2) (Always current) coding standards for hook implementations are "Implements hook_FOO()."

Powered by Dreditor.

This still needs some work, commenting and testing. I want to add an action to delete an entry as well and test this out with flag_actions module to see if this will work well in combination with #453820: Views integration to allow changing the feedback entry statuses with flag.

Here's a new patch that I think is ready to go. Includes tests.

Once this goes in I can work on #1089318: Flag integration and #675092: bulk clear/remove feedback messages

Subscribe.

@dwhutton please use the 'follow' button on the top of the issue

The patch in #40 allows sending an email which is parsed and received correctly, but if I go back to the Actions page and click "configure" on the "Send email of feedback" action, I get an empty form (that is, I would have to reconstruct the entire form, not just edit it with different information).

I have tried to apply the patch, but nothing happens. I can not access to /admin/build/trigger/feedback - nor I can see any new action. Perhaps I am missing something.

marameodesign: This patch is for Drupal 7.

Here's a new patch to fix the issue in #43.

Hm. I wonder whether this is architecturally + strategically the proper way...?

Technically, we're implementing a standard/common entity now — are we sure that there is no way to relay almost all of this code and logic to the Entity API module?

At least, most of this looks so generic to me that I can't really believe that Entity API + its ecosystem doesn't provide generic solutions for all entity types already...?

Anyone familiar with that? :)