Rules integration [#768188]

I was wondering if there is any plan for Rules integration with this module.

I've noticed that there is integration with the Actions module to subscribe a user to a list. In some cases, I have required additional logic to be applied, so I've been using the Rules module and I find myself using php code within a Rules action to subscribe/unsubscribe folks from a list as the most efficient way to accomplish background EMF tasks. Situations that I use this for are signing the user up for a list when they create a new account after I change some hidden profile fields that I use for segmenting. Also, I have to keep the list segmenting updated when a user updates their membership level which ultimately involves detecting a change in role to fire off a list subscribe/unsubscribe/field change.

I would think that the basic requirements of Rules integration for EMF would be:

Actions:
Subscribe to a list
Unsubscribe from a list

Conditions:
Is Subscribed to list
For a particular list, test field value

Events:
User is subscribed to list
User is unsubscribed from list

Just wondering if any work has been started or planned on Rules module integration.

Thanks,
Jeremy Zerr
http://www.zerrtech.com

Comment	File	Size	Author
#12	rules-subscribe-action-768188-12.patch	3.53 KB	Cyberwolf
#11	emf.rules_.inc_.zip	1.61 KB	Cyberwolf
#10	emf.rules_.inc_.zip	1.51 KB	Cyberwolf
#5	rules.tgz	947 bytes	Cyberwolf
#2	rules.tgz	10 KB	Cyberwolf

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Cyberwolf CreditAttribution: Cyberwolf commented 14 April 2010 at 15:10

I currently share the need of rules integration with EMF. A customer wants to give away some stuff regularly to website visitors, therefore they need to submit a node with their name and e-mail. There's also a checkbox in that content type, "Subscribe me to your newsletter". Trying to accomplish now that if that checkbox is checked, the provided e-mail address gets subscribed to a list in EMF.

I will consider contributing the action to this project, once I've coded it.

Comment #2

Cyberwolf CreditAttribution: Cyberwolf commented 14 April 2010 at 18:13

File	Size
rules.tgz	10 KB

Extract the attached file and put the emf.rules.inc in the emf module directory. It provides a rules action "Subscribe to an EMF list". You can configure the e-mail (textfield, use token in there) and which list to subscribe to.

I'd like to add configuration for custom fields as well, still need to find out a good way to do that.

Comment #3

jeremy.zerr CreditAttribution: jeremy.zerr commented 14 April 2010 at 20:05

Thanks for contributing your code, that's a great start. I have a question for you on your implementation. Why did you choose to require that the Email be filled in when configuring the Rules action? If you have your EMF Field mapping set up for the list, you already have the tokens that would pull the values directly off of the submitted node, leading to a much cleaner configuration in the Rules action by not having to specify the token to pull email twice, once in the Rules action, once in the EMF Field mapping.

I can think of possibly a couple situations that you'd need to define email like that, but I'd like to hear what particular use you have for it.

Again, thanks for contributing that code, that will be a great base to start with.

Thanks,
Jeremy

Comment #4

Cyberwolf CreditAttribution: Cyberwolf commented 15 April 2010 at 06:59

Hi Jeremy

I thought the tokens in the field mapping were mostly meant to configure the subscription page/block as you can view in Site Building > E-mail Marketing Framework > 3rd column "View page". The map building interface also does not know about the context in which the rule will take place, so you do not have all tokens listed there which are available in your rule (to name one, in my situation: the submitted node and all its fields). In different rules you might want to use different tokens as well, so the Field Mappings won't be enough in that case.

If you have any idea how to solve this in a good way, I'm happy to hear :)
I guess the best way is to partially reproduce the field mappings interface in the rules action: only the name of the custom field and the 3rd column, the value for that field.

Comment #5

Cyberwolf CreditAttribution: Cyberwolf commented 15 April 2010 at 09:40

File	Size
rules.tgz	947 bytes

I re-factored the code a bit and implemented a separate subscribe action for each list. The custom fields mapping is there now as well.

Comment #6

jeremy.zerr CreditAttribution: jeremy.zerr commented 15 April 2010 at 14:51

As far as the mapping thing goes, my situation is that the fields I'm mapping come from a saved node too, it happens to be a content profile node. So I have CCK field tokens in my EMF Field mapping. I reworked your initial code, where I took out the mail field out of the Rules action, and added a type => 'user' field in the parameter list for the action. That's how to get the context of "acting user" or "content's author". Works with all custom fields, as I just copied the method the EMF Action module integration was done. I got this working yesterday.

Knowing how other rules work, why do you need to have a separate Rules action for each list? The previous code already had a way to select the list. Wouldn't it be better to keep the Rules action non-list specific, allowing to choose the list, and then if you want multiple list subscriptions, you would just add in multiple instances of that action, each would have a different list specified? To me, that seems like the common way to do things with Rules.

I'm working on adding in unsubscribe and some conditionals too, then I'll attach the code I have.

Comment #7

Cyberwolf CreditAttribution: Cyberwolf commented 15 April 2010 at 15:53

A list can have different custom fields, that's the reason for having different actions per list as well, so I can map the custom fields in the action's configuration.

I see the advantages of your solution, for quicker configuration. But you won't be able to solve every case with that.

Comment #8

jeremy.zerr CreditAttribution: jeremy.zerr commented 15 April 2010 at 17:29

Maybe a good option would be to show the fields (email and custom fields) in the Rules action but make the fields not required, so if they are blank, it will use the default mapping you set up via the EMF List field mapping. If you fill the field in the Rules action, it will override the defaults. The ability to choose to take the default Field mapping would make it so you didn't have to duplicate setup. But the ability to still override would handle those new tokens coming in scope with the Rules action.

I think dynamically pulling the list of custom fields once the list is chosen would be a better implementation instead of a Rules action for each list. Like a multi-step form like the CCK Rules action does. Its more complicated, but I think it would be the right thing to do in the long run.

Comment #9

Cyberwolf CreditAttribution: Cyberwolf commented 15 April 2010 at 20:31

Ok, I will take a look at the CCK rules actions as an example when I have some more time. Thanks for your feedback!

Comment #10

Cyberwolf CreditAttribution: Cyberwolf commented 18 March 2011 at 08:43

File	Size
emf.rules_.inc_.zip	1.51 KB

Small update, added a check if there is no subscription request yet for the same e-mail + list id (which will cause a MySQL notice).

Comment #11

Cyberwolf CreditAttribution: Cyberwolf commented 14 April 2011 at 06:43

Status:

Active

» Needs review

File	Size
emf.rules_.inc_.zip	1.61 KB

I implemented the multi-step form as suggested by jeremy.zerr, and removed the Rules datatype as it currently did not really have a purpose .

I did not implement the fallback to the default field mappings if something is left empty, as I believe it'll make configuration counter-intuitive. In most cases the context in which the rule action is executed will differ a lot from the context in which the EMF form is retrieved and submitted anyway.

I think this is ready for review now...