Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
In order to properly create user accounts during checkout, we need the following condition and action for Rules:
Condition: User exists - Checks if a user exists already for an e-mail address.
Action: Send an account e-mail - Lets you send one of the configured account e-mails to a given user.
I suppose we can track these in an issue here (so it's in the dcsprint5 list) and test them with checkout but write it as a patch against Rules itself. When it's ready to go we can kick it out to the Rules issue queue.
Comment | File | Size | Author |
---|---|---|---|
#22 | rules-action-user-mail-1031530-22.patch | 3.19 KB | Nebel54 |
#22 | interdiff-1031530-13-22.txt | 452 bytes | Nebel54 |
#20 | rules-action-user-mail-1031530-20.patch | 3.12 KB | Nebel54 |
#20 | interdiff-1031530-13-20.txt | 1.17 KB | Nebel54 |
#13 | rules-action-user-mail-1031530-13.patch | 3.26 KB | nedjo |
Comments
Comment #1
fago>Action: Send an account e-mail
Yep, that would be a very very nice action!
>Condition: User exists
Hm, yes - however we might want to make this generically work. There is already the action "Fetch entity by property", with which you should be able to load users by mail address. Then we'd need #1019744: Condition: 'Data value is empty' to check for it being not existing.
To easing using that maybe it would be a good idea though to build this into a separate condition ala "Entity exists" which just works like the "Fetch entity by property" action?
Comment #2
pcambraI'm attaching a patch for this condition & action.
I've done all the work in the checkout_commerce module, but at some point we should merge this into rules itself.
Related: #1041240: Replace entityCondition by propertyCondition in entity_metadata_table_query of callbacks.inc
Comment #3
pcambraComment #4
pcambraComment #5
rszrama CreditAttribution: rszrama commentedI took what you had and ran with it a little bit. I had to rework pieces of the code to take advantage of an API function _user_mail_notify(). This lets us use the same function that the User module uses to send e-mails... I understand it's "namespaced" with the underscore, but it appears safe (the function definition hasn't changed in D6 at least).
If you wanna give this a look over, I'll get on building some default Rules to take care of anonymous checkout. What do you think of it, fago?
Comment #6
rszrama CreditAttribution: rszrama commentedI updated the action for sending an account e-mail to be a part of the User group instead of System.
Comment #7
fagoPatch basically looks good. Imho, both the action and condition are a very useful addition, so I'd be happy to add it directly to Rules too.
You got a tab in there:
@condition:
Yep, we should make it use the entity API stuff + add the necessary property info for that.
Comment #8
rszrama CreditAttribution: rszrama commentedAlrighty, here's a first pass at putting the condition and action into the Rules module in appropriate files. I tried to use existing callbacks as well. To test this, I used the following rule... it just checks to see if a user exists when they login (obviously TRUE) and then sends a welcome e-mail as a proof-of-concept.
When this lands, I'll update Commerce accordingly.
Comment #9
fagoGreat! I've done another, more in-depth review.
Looking at _user_mail_notify(), it only sends a mail depending on a configuration variable, but the action should work regardless of that setting. So let's just extract the parts of the function we need - that way we also don't have to call a private function ;)
We should use entity_query() here, such that it works with fields / any other given callback too.
I guess we need to update this descriptions :)
>+ $this->save[$selector] = array($immediate ? $wrapper : clone $wrapper, self::$blocked);
You got a hunk from #1044342: Errors creating and using newly created entities in rules in your patch.
Comment #10
fagoComment #11
mitchell CreditAttribution: mitchell commentedAny update on this?
Comment #12
jpstrikesback CreditAttribution: jpstrikesback commentedWould be cool to pull this:
http://drupal.org/node/1349924
Back into rules
Comment #13
nedjoThis issue ended up with two pieces that are pretty much unrelated, so I pulled one into a separate issue, #1777204: Add condition "Entity exists by property".
Here's an untested patch for the remaining piece, a "Send account e-mail" action. I've followed fago's comment in #9 and pulled relevant code from _user_mail_notify().
Comment #14
nedjoComment #15
jlporter CreditAttribution: jlporter commented#13 - patch applied cleanly and option was available in user section of add action
however I got a blank screen in the overlay with just an error "Unknown action user_send_account_email." but the save button is there?!
Comment #16
jlporter CreditAttribution: jlporter commenteddoh! Clearing cache worked!
The only issue now is that it's not getting all the data it needs such as uid from the created entity.
Here are the warnings that showed when the email was triggered by the rule:
Notice: Undefined property: stdClass::$uid in user_pass_reset_url() (line 2295 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$pass in user_pass_reset_url() (line 2295 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$login in user_pass_reset_url() (line 2295 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$uid in user_cancel_url() (line 2317 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$pass in user_cancel_url() (line 2317 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$login in user_cancel_url() (line 2317 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$uid in user_pass_reset_url() (line 2295 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$pass in user_pass_reset_url() (line 2295 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$login in user_pass_reset_url() (line 2295 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$uid in user_cancel_url() (line 2317 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$pass in user_cancel_url() (line 2317 of /mnt/var/contracts.blr.com/modules/user/user.module).
Notice: Undefined property: stdClass::$login in user_cancel_url() (line 2317 of /mnt/var/contracts.blr.com/modules/user/user.module).
I'm going to try a different email type, we aren't setting their password. Not sure which one to use but this was from the "Welcome (new user created by administrator)" email type.
Just tried Account Activation type and got similar errors. I wonder if I should fetch the newly created user entity over again? I will test that in the morning and use the fetched entity to see if it gets uid/login/etc.
Good work nedjo! Bumping this back down to needs work. I might be able to finish this up if I learn rules internals a little better :)
Comment #17
jlporter CreditAttribution: jlporter commentedI figured out that the entity needs to be forced to save and it populates the uid and other fields properly! Works great! Please merge!
Comment #18
fagoI don't think this is necessary.
This should pass the right language also.
Comment #19
jlporter CreditAttribution: jlporter commentedI think the issues brought up by fago should be moved to another issue as no work has been done on this in 3 months.
Having this functionality working in the next release outweighs the recommendations/observations made.
Comment #20
Nebel54I have updated nedjo's patch to address fago's suggestions, but i cannot figure out which language other than language_default() should be used for the admin notification mail. This part is directly copied from the user-module's _user_mail_notify() function - so it looks pretty ok for me.
Comment #21
fagoI'm sry, your interdiff shows that I was wrong with
$types = rules_user_account_email_options_list();
- we'll need that to keep proper replacements. It's just the include loading that should go.
True - I've missed that this is just the admin notification. So I agree that's fine.
So let's re-add that part and fix the issue.
Comment #22
Nebel54I reverted to patch #13 and just deleted the redundant include:
module_load_include('inc', 'rules', 'modules/user.rules');
So the patch should be fine now.
Comment #23
Nebel54I just tested the patch and sorted out that the module_load_include was necessary.
So in short: Patch #13 does work and does what it is supposed to do.
Patches 20+22 are not necessary anymore. As @jlporter already tested #13. And the code works for me too I reset the status to RTBC.
Comment #24
fagoThanks, yes this looks good now. I improved the check for authenticated users to check $account->uid and committed it
Btw usually, you are not supposed to RTBC your own patches/changes. ;-)
Comment #26
artresys CreditAttribution: artresys commentedSorry. It was a mistake from my side.