Rules support for Mail Editor

I've tried to explain to you in another thread that it can't work this way.

You've forked Mail Editor (which you certainly have the right to do), and now you're asking us to put the pieces back together? or to throw out our code (which is in production use on 2000+ known sites) in favor of yours, without knowing what will happen out there?

Setting back to active, there's nothing here to review.

I agree with salvis that this isn't the way to go about this, but after trying both versions I think the improvements in Pasqualle's version are so numerous that they should be considered as a 2.0 branch or the basis for a rewrite of this module.

EDIT: Although there's a bug in it. :p

On line 153 in edit.inc where you do:
drupal_write_record('mail_edit', $template, 'id');

It should be:
drupal_write_record('mail_edit', $template, array('id', 'language'));

or else it will complain about duplicate keys when you have more than one language enabled.

Thank you, TwiiK. Getting this out as 6.x-2.x-beta1 is an interesting idea. The problem is that we really need to be working on the D7 version. In my experience, there's very little feedback for projects like this one, and there'll probably be even less for an old version.

We can't push a major 6.x-2.x update and port 6.x-1.x as 7.x-1.x at the same time, because upgrading would then be a step back. We need a stable 6.x base to port. We can't afford to wait with porting until 6.x-2.0 can be released.

It could work if we get a D7 version of Pasqualle's fork, so that we can concentrate on one version to test.

@Pasqualle: I'm looking at your fork of Mail Editor.

You've re-purposed it from "Allows editing of all mails" to "Allows translation of mail templates" according to your .inf file and added dependencies to locale.module and i18nstrings.module.

The original idea of Mail Editor was just to support editing templates. litwol expanded it to support translations, which is a great thing, but his version still worked just fine for a single language, too, and especially, it didn't have those dependencies. This is a no-go for your version.

Also, you've removed the variables help information ('Replacement patterns'), which is an essential feature — another no-go.

The Rules support is nice, but couldn't it just as well go to its own module?

I like your filterable list though, and I've adapted and merged it into the -dev version — thank you! AFAICS that's the only feature that makes sense in our context.

@everyone: Please try out the -dev version and let us know how it works for you.

What do you mean with

The less used module should add the support the for more used module,
and not the other way around.

? Rules support? Why would that need to be part of Mail Editor? Couldn't it be just as well a separate module? possibly a submodule packaged with Mail Editor?

I think it was just poor wording on Pasqualle's part. A submodule would be the way to go and is how most other modules handles it. That way the user can choose to enable it if he needs rules support.

I agree that you should focus on D7. I can help backport(correct word? :p) the module to D6 if I see awesome features I feel a need to have. :)

Subscribing

Changing the title to what's left here: Rules support and creation of new templates (for use with Rules).

The stream-lined list with filtering has been integrated — thanks, Pasqualle.

If anyone wants to extract and pour the Rules support into a new D7 add-on module, then step up here. Backporting to D6 is possible after D7.

These hooks will add mail templates for each email action of all rules.

/**
 * Implements hook_mailkeys().
 * The mail key for a rule is 'rules_action_mail_RULE-MACHINE-NAME__DELTA'
 */
function rules_mailkeys(){
	//get all rules
	$rules = rules_config_load_multiple(FALSE, array());
	
	$mailkeys = array();
	
	foreach($rules as $key => $rule){
		
                $iterator = $rule->elements();
		foreach($iterator as $k => $child){
			$pluginName = $child->getPluginName();
			
			if(in_array($pluginName , array('action mail','action mail_to_users_of_role'))){
				$mailkeys['rules_action_mail_'.$key.'_'.$child->elementId()] = $rule->label;
			}
		}
		
	}
	
	return $mailkeys;
}
/**
 * Implements hook_mail_edit_text().
 *
 * @param string $mailkey
 * @param object $language
 *
 * @return array
 */
function rules_mail_edit_text($mailkey, $language){
	 $message['subject'] = t('subject');
      $message['body'] = t('body');
	  return $message;
}
/**
 * Implements hook_mail_edit_token_types().
 *
 * @param string $mailkey
 *
 * @return array
 */
function rules_mail_edit_token_types($mailkey){
 return array();
} 

Please post a patch and follow the coding standards (two spaces per indenting level, space before {, etc.).

I wrote a module that allows messages to be sent with rules using mail edit templates. Enable it, create a rule action that sends mail using mail edit templates. The rule action will show up in the mail edit templates.

http://drupal.org/sandbox/_KASH_/1635740

Any Rules users out there? Please review this and provide feedback in _KASH_'s sandbox!

@_KASH_: could you please include an example configuration? This would be a big help, as I haven't used this module before. Also, I think including this functionality as a patch here would make more sense than in a separate project. We could also mark this as 'needs review' then.

Also, I think including this functionality as a patch here would make more sense than in a separate project.

I disagree. Support for Rules isnot a core feature for ME. And I'm not going to maintain and support it.

> Support for Rules is not a core feature for ME.
That confused me for a sec. I think desirable or planned are better word choices, since this isn't a module with a "core". Anyway, it looks useful.

> ? Rules support? Why would that need to be part of Mail Editor? Couldn't it be just as well a separate module? possibly a submodule packaged with Mail Editor?
A submodule or separate module are odd (uncommon) choices. Adding a module.rules.inc won't degrade performance any further than a submodule on sites that don't have rules enabled. Plus, doesn't it make more sense to embrace a wider user base?

> And I'm not going to maintain and support it.
That worked fine for quicksketch in flag. He just committed patches as long as the people who wrote them or reviewed them were people he trusts and they said it worked / passed tests (granted most came from fago, amitaibu, and moofie...). I'm sure there are other examples, but I can't think of them at the moment. That's a good one though if you consider this module an extensible API. You don't have to use every feature it comes with in that case. Also, Pasqualle write good code, so he might be able to carry out that role.

If I remember correctly, there was more than just a module.rules.inc file in Pasqualle's branch, and it was intermingled with the rest of the module. Didn't it have a Rules-specific UI, too?

I don't have a public environment available for an example configuration. I described how to configure in post #15 of this thread. Configuration should be pretty straight forward. I agree with salvis that rules support would not be a core mail edit feature. Mail edit is designed to be hooked. This is an advanced implementation of mail edit hooks, a bridge for the rules module.

testing http://drupal.org/sandbox/_KASH_/1635740
rule appear in mail template page but tokens are not working

correction : tokens are working just not showing in the tokens in mail edit
thank you for your work
any plans for a stable release?

Great discussion everyone! So, I came across this thread because I was searching the internet for a solution for rules to be able to send out translated emails. Has there been any progress with this either supported rules or perhaps just the rules module supporting the translation of the emails themselves?

Basically I have a site with 4 languages and I have rules that trigger when users add content to the site. The rule sends out an email to the user. By default the rule was written in English, now I would like to have language specific emails sent out. I guess I could write 4 separate rules basically doing the same thing except each would have a check for which language is selected for that user in their profile and then firing the appropriate rule with the translated email. I would much prefer to just have one rule and translate the email subject and body text like I do through the Drupal translate interface page or by switching the language mode while on the edit page (in a multilingual variable scenario).

Any idea how I can accomplish this?

@drupalfan81, Rules supports i18n now. Check out rules_i18n module from Rules project.
For now I personally prefer Message Stack for emails. It supports translations own of the box.

@Kalabro...Thanks! I don't seem to see this anywhere. Is this only for D7 version of the module perhaps? I am on D6. I will check into Message Stack as well. But if you could comment on the other that would be great. Or did you mean there is a separate module or patch somewhere that I can apply?

Thanks!

#26 is a fluke.
#2526500: Weird secondary commit messages posted after pushing 8.x-1.x contrib branch