Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hellow, i have a Drupal 7 site. Anonymous users can create a node and here they have to write their mail.
When the node is created, rules will create a new user account and then send an email which contains username and one-time login url.
The user account is successfully created, and mail is successfully sent but in the mail is not the one time url, but only this: [entity-name:one-time-login-url]. Is the problem in Rules?
I hope i described it well.
Comment | File | Size | Author |
---|---|---|---|
#90 | interdiff_88-90.txt | 8.61 KB | Nikolay Shapovalov |
#90 | 1289898-90.patch | 7.43 KB | Nikolay Shapovalov |
|
Comments
Comment #1
eric-ie CreditAttribution: eric-ie commentedYeah the token is not being reinterpreted. So we literally see [account:one-time-login-url] instead of a link in the website. Having the same problem.
Comment #2
Lios CreditAttribution: Lios commentedSame here. Any way to fix it?
Comment #3
berkas1 CreditAttribution: berkas1 commentedHave anybody found any solution?
Comment #4
HenrikBak CreditAttribution: HenrikBak commentedSubscribing
Comment #5
eiriksmI agree that it is strange that the token says it is supposed to output one thing, but does not work. However, you can also use this solution:
Use the PHP evaluation (enable PHP module) and make sure you have a user loaded (often when it is created, it's created by default as $entity_created).
Use this snippet:
Hope that helps someone!
Comment #6
klausiHere is a patch that adds the restricted user tokens to the Rules token input evaluator. Not sure this is the right way to do it. Please test.
Comment #7
fagoI guess the cause for this strange implementation is access, so taking over user accounts for people isn'T possible as soon as they can use tokens....
Thus, we somehow need to implement this access restriction in rules too. Tokens don't support access restrictions though. I could see this work via an separate action that generates those tokens and gives them back as text variables. Then tokens for those text variables can be used (though I think that needs to be fixed for rules2 first).
Probably, even better than an action would fit exposing those parameters as entity properties. However, first we should fix entity-tokens to don't provide tokens of sensitive properties, but then those properties would be unusable again in Rules again - as long as one doesn't copy them in new variables ;)
So I think the action would be the was way to proceed. E.g. "Generate user login tokens" ?
Comment #8
klausiMeh, too complicated. At the moment there are only 2 restricted tokens in token.module, so I vote for this simple approach before we start over-engineering here. Also token.module does not provide any hint which callback to use for the restricted user properties, so Entity/Rules would have to add this manually anyway.
And I don't understand the security concern here: people that can administer rules have super permissions anyway, so what's the harm?
Comment #9
fago>And I don't understand the security concern here: people that can administer rules have super permissions anyway, so what's the harm?
No. Rules does access checks, thus you can grant 'administer rules' without giving away full site-privileges. The super permission is not 'administer rules', but 'bypass rules access'.
The patch from #6 would allow each rules-user to take over the site, just with 'administer rules' and might even work for users of VBO..
Comment #10
klausiIndeed, just learned that "administer rules" is not a p0wning permission. So the @todos are:
* Remove user login/cancel URL tokens from the replacement patterns listing (I think this needs to go into the Entity API tokens stuff?)
* Provide the "Generate user login/cancel URLs" action that provides the two URL variables. Permission required: administer users?
* Expose primitive (text, URL, decimal etc.) Rules variables as tokens.
Right?
Comment #11
fagoSounds good, yes. Although I don't think entity tokens provide login/cancel tokens as there are no such properties, my guess would be token module.
Comment #12
fonant CreditAttribution: fonant commentedSubscribing
Comment #13
klausiStop subscribing, start following: http://drupal.org/node/1306444
Comment #14
cmseasy CreditAttribution: cmseasy commentedHi,
Is this issue about 'user' (the logged-in user) or also about 'entity-created(user)'?
In my setup a user kan create an other user with a webform. After the webform is submitted a rule creates the account: entity-created(user). Works fine.
In the email sent by a rule I want a one time login for the new entity-created(user). No way: the tokens are available but are not links in the email: [entity-created:one-time-login-url] and [entity-created:edit-url].
Php snippet #5 and the patch #6 did not help,
Is there a workable sollution available for this?
Comment #15
eiriksm@cmseasy: D7 or D6?
Comment #16
cmseasy CreditAttribution: cmseasy commentedd7
Comment #17
eiriksmDarn it. Just found my snippet didn't work after all (#5). Don't have the time to investigate right now, will post back when i get the time.
Comment #18
berkas1 CreditAttribution: berkas1 commented#6: 1289898-rules-restricted-user-tokens.patch queued for re-testing.
Comment #19
jeuelc CreditAttribution: jeuelc commentedsubscribing
Comment #20
jeuelc CreditAttribution: jeuelc commentedfound a solution/work around
instead of using the replacement pattern [account:one-time-login-url], call the function that is supposed to be replaced by that token which is user_pass_reset_url() and user $account as its parameter.
so, the email should go something like this:
-------------------------------------------
[account:field-complete-name],
You are now a member [site:name]
print user_pass_reset_url($account);
The link above will log you in to the site where you can reset your password.
After setting your password, you will be able to log in at [site:login-url] in the future using:
username: [account:name]
password: Your password
Comment #21
j4 CreditAttribution: j4 commentedThank you jeuelc! you are a savior. Works like a charm.
Comment #22
leex CreditAttribution: leex commentedI had a real bad time getting this to work with Drupal Commerce. I applied the patch from this thread: http://drupal.org/node/1430694 but to no effect, the tokens weren't becoming available. I also have display suite installed and using the display suite code format with the default token [user:one-time-login-url] somehow works :D
Comment #23
Summit CreditAttribution: Summit commented@leex: can you tell me the exact steps you did to get this working? I am not succesfull in this using drupal commerce..
greetings, Martijn
Comment #24
Summit CreditAttribution: Summit commented#20 gave me this email in drupal commerce using php as input format:
Somehow drupal commerce (commerce email) doesn;t interpreted the php correct..
greetings, Martijn
Comment #25
leex CreditAttribution: leex commented@Summit I think the reason your php isn't working is because you need to have the PHP Code text format selected for that textarea, if it isn't available then you need to enable it under the core modules.
If you want to do what I did, you will need to install the Display Suite module. This will make the 'Display Suite code' appear in the text format drop down. I used this text format with the token from my post above and it works.
Comment #26
Summit CreditAttribution: Summit commentedHi @leek, I have php code text format selected.
See this issue: http://drupal.org/node/1606862
I think php is somehow not working using commerce email and rules...
greetings, Martijn
Comment #27
leex CreditAttribution: leex commented@Marijn It didn't work for me either, the display suite code did.
Comment #28
nicodv CreditAttribution: nicodv commented#20 workaround was great, If there is a simpler fix than installing displaysuite I´m all ears, meanwhile, it´s a relief.
Thanks, @jeuelc
nico
Comment #29
Jeff Veit CreditAttribution: Jeff Veit commentedCode in #5 is a good work around if you are ok with enabling PHP eval. (This has some security risks.) But the code as given won't work: PHP variable names cannot include dashes. It should be $one_time rather than $one-time.
And if you try this, you may find other errors being generated: the entity you get from rules for the newly created user is not completely filled in with all values because it has not been saved yet.
The code you may need to use is:
This assumes that the user entity created was given the variable new_user, and not the default, which is entity_created.
Comment #30
mitchell CreditAttribution: mitchell commentedI'm not really sure of the status of this issue. Would someone please extract the meaning of #14-#29 according to #10?
Comment #31
rar CreditAttribution: rar commentedPart of the confusion above is that in rules there are two ways to send emails.
1. Add New Action -> User -> Send account email
2. Add New Action -> System -> Send email.
Unfortunately, which tokens you get to use depends on which action you are using, but I have not found any documentation that describes this.
Comment #32
cola CreditAttribution: cola commentedhi all
if you change on the role "Send email" to "Send account e-mail" then it works fine...
you have on the $param from htmlmail the $account... with this you can generate a onetime link like this...
$url_onetime = user_pass_reset_url($params['account']);
$username = $params['account']->name;
important, is better to generate a own template file with the name "htmlmail--user--register_no_approval_required.tpl.php"
regards
Comment #33
akalata CreditAttribution: akalata commentededit: Sorry, thought I had this working but was getting the core emails as well, which worked of course. :-/
Comment #34
futurmat CreditAttribution: futurmat commentedThe solution from #20 worked for me some time ago. Unfortunately recently it stopped working ... the url generated looks good, but if I follow the link I get the message that the on-time-login is expired. Any ideas what happened?
P.S. Password reset from the password reset form still works.
Comment #35
Horroshow CreditAttribution: Horroshow commentedComment #36
oana.hulpoi CreditAttribution: oana.hulpoi commented#6: 1289898-rules-restricted-user-tokens.patch queued for re-testing.
Comment #37
mortona2k CreditAttribution: mortona2k commented#20 works.. I'd still like to see the token work though.
If you're using logintoboggan, [user:validate-url] will provide you with an account validation link. I only would use this if the password is set during registration, otherwise it will log in, but not prompt the user to set their password.
Comment #38
stomerfull CreditAttribution: stomerfull commentedhello,
[user:validate-url] and [account:validate-url] is not interpreted in rule
i means that token is not remplaced by his value
is anyone have an idea for this ?
thanks
Comment #39
Nebel54I think there are two possible approaches:
Last week criz, dasjo and me discussed about the second approach, which would be great for a usecase like "Send a registration reminder with one-time-login when an account hasn't been activiated for two days".
So the attached patch addresses the second approach. It uses the rules_user_integration_access access callback which should be adequate for managing users.
Comment #40
fagoToo much indentation - check the coding style.
I'd append link to the label and maybe add a help text that says it provides the link back as variable so it can be used by .... (what would come here, a token in a e-mail message?)
It provides just the URL, right? So the type should be URI then.
Also, we need to add test coverage.
We should use the "official" spelling here, which should have URL in upper case.
Comment #41
Horroshow CreditAttribution: Horroshow commentedIt doesn't work for me. Should I change something else in the rules or the email template?
Comment #42
Horroshow CreditAttribution: Horroshow commentedAfter patching with #39, I added the "Generate one-time log in" action the rule "Create a new account for an anonymous order (HTML)". The one_time_login_link PHP variable became available. Then I added the variable like this to the Account Email (/admin/commerce/config/email):
The variable didn't print in the email and the site gave this error:
Notice : Undefined property: stdClass::$pass dans user_pass_reset_url() (line 2296 in /modules/user/user.module).
Notice : Undefined property: stdClass::$login dans user_pass_reset_url() (line 2296 in /modules/user/user.module).
PDOException : SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'name': INSERT INTO {users} (uid, created, data) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 9724 [:db_insert_placeholder_1] => 1380812977 [:db_insert_placeholder_2] => a:2:{s:7:"contact";i:0;s:18:"htmlmail_plaintext";i:0;} ) in drupal_write_record() (line 7043 in /includes/common.inc).
Comment #43
Nebel54When you want to send mails to new user accounts (e.g. On "New user created"-Conditions) the actions are executed BEFORE the new user has been saved and an before it got an user id.
Therefor you need to add an action "Save Entity" (of the new user account) with the option "Force saving immediately" selected. Then you can use the new Generate one-time log in action.
I'm going to add a new patch which address fago's remarks, but as far as i know there is no other solution than an "Save Entity"-Action before using this action for this problem.
Comment #44
Horroshow CreditAttribution: Horroshow commentedThere's already a Save Entity action (see below). For now I will delete the "Send mail with Variable" action and replace it with the "Send account e-mail" action from Drupal core. It's a plain text email but the One Time Login URL token is working.
Comment #45
davewilly CreditAttribution: davewilly commented#20 Worked for me using Drupal Commerce.
Enable PHP filter.
print user_pass_reset_url($account);
in emailWould still love a token!
Comment #46
dustinbrunson CreditAttribution: dustinbrunson commentedI was getting error with $account, but this worked
print user_pass_reset_url($user);
important to change to phpcode text format. thank you... Its awesome being a part of a community of people helping to make good things happen.
Comment #47
knalstaaf CreditAttribution: knalstaaf commentedThe patch in #39 is not working for my updated Commerce installation. The workaround in #20 does.
Comment #48
jsheffers CreditAttribution: jsheffers commented#46 Worked for me, changing $account to $user was the key.
Comment #49
kevster CreditAttribution: kevster commentedJust tried the patch in #20 but got access denied message after clicking link so didnt work for the commerce account email at /admin/commerce/config/email.
Will try the other solution as [user:one-time-login-url] token not printing at all for me and not available in the tokens list...
EDIT:
#46 worked for me for the commerce new order/new account email - many thx!
Comment #50
Exploratus CreditAttribution: Exploratus commented#46 worked for me, although I'd prefer a token solution. Also using Drupal Commerce. :)
Comment #51
Anonymous (not verified) CreditAttribution: Anonymous commentedFor anyone who might not know how or want to patch Rules, here is a workaround module:
Disappointing to see this issue unresolved after three years....
Comment #52
Horroshow CreditAttribution: Horroshow commentedI will try it as soon as I have a little more time and report here. Anyone tried pferlito's module?
Comment #53
tchopshop CreditAttribution: tchopshop commentedYes, I tried pferlito's module. It works great. Thank you pferlito!!!!
Edit: I started getting an Ajax error that often comes from file encoding or extra lines after closing php statement, which I don't see in this module, but it would stop when I disabled. However, I moved the .inc file to the .module file and deleted the .inc file and the error went away...
Comment #54
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commented+1 !! This is base core feature on a community website! Let visitors fill in a form, then use Rules to create a content + a user account and send them an email with a link for them to choose their password... I can't believe this is still not working with Rules on D7.32...
Thanks for the module although I find it heavy to have to install a module for that!
Let's bump this one to major!
Comment #55
yce CreditAttribution: yce commentedThanks pferlito!
It works great!
Comment #56
kopeboy CreditAttribution: kopeboy commentedPlease include this!!
Comment #57
BrightBold@cola's point in #32 solved the problem for me, thanks!
Comment #58
AaronBaumanDoes the root of this issue have anything to do with the fact that the password for the new account is always blank when created through rules?
Comment #59
Tharick CreditAttribution: Tharick commented#20 working perfectly :-)
Comment #60
Channel Islander CreditAttribution: Channel Islander commentedThe module from pferlito does not work for me on a fresh install of everything current.
The Rule appears to run and get he variable but the token name still prints out in the e-mail instead of the token value .... anyone have a tip, please and thank you?
Email sent:
Comment #61
nithinkolekar CreditAttribution: nithinkolekar commentedtesting this with rules 7.x-2.8+2-dev and drupal 7.34 and still [entity-created:one-time-login-url] is not replacing with actual link and replacing with blank text.
As mentioned in #43 and in http://drupal.stackexchange.com/questions/133827/rules-token-one-time-lo... , Save entity action must be applied with Force saving immediately: True
Temporary workaround:
When user entity is created by this way, it's status is set to "blocked" and applying Unblock a user on [entity-created] is sending core's Account activation mail(Notify user when account is activated should be checked for this).
But still Send mail is failing to replace the actual one-time-login-url.
complete rules export (this is for entityform submission):
Comment #62
maxplus CreditAttribution: maxplus commentedThanks,
I used #45 and it worked for me.
Comment #63
Miranda Jose CreditAttribution: Miranda Jose commented#39 worked for me.
Thanks for the patch
Comment #64
alduya CreditAttribution: alduya at 2DotsTwice bvba commentedI altered the patch of #39 so most of the comments of #40 are included.
Comment #66
nattyweb CreditAttribution: nattyweb commented#45 worked for me. Would be good if this patch (#64) was accepted so we could use tokens.
Comment #67
MrPeanut CreditAttribution: MrPeanut commentedPatch from #64 is working great for me.
Comment #68
bmango CreditAttribution: bmango commentedPatch from #64 worked for me. Many thanks!
Comment #69
bmango CreditAttribution: bmango commentedComment #70
TR CreditAttribution: TR commentedCan't be RTBC because the patch doesn't even apply anymore - see #64. It needs to be re-rolled and posted here, the testbot has to be able to apply it, and the tests have to run green with no added coding standards errors.
Also, back in #40 @fago said this needed tests, and tagged this issue as "Needs tests", but that hasn't been done yet.
Comment #71
bmango CreditAttribution: bmango commentedI have updated the patch in #64 for the latest 7.x-2.x
Comment #72
TR CreditAttribution: TR commentedThe patch introduced 25 new coding standards errors. See the PHP 7.2 test results (the testbot doesn't currently check coding standards in PHP 5.3 tests).
The big problem is your use of tabs, which are not allowed in Drupal code.
Can you fix those and post a new patch?
Comment #73
bmango CreditAttribution: bmango commentedThanks for the tip about the tabs. I have recreated the patch replacing the tabs with spaces and removing the extra empty line.
Comment #74
darrenwh CreditAttribution: darrenwh commentedUpdating this to needs review, please feel free to change to 'needs work' and add outstanding tasks if it needs to be returned to this status.
Comment #75
darrenwh CreditAttribution: darrenwh commentedHiding files
Comment #76
TR CreditAttribution: TR commentedChanging this to a feature request - it was originally a bug report about tokens not working, but has turned into a feature request for a new action to generate a one-time login URL.
Also, if this feature is put into D7 Rules, it should also be put into D8 Rules - I've added the appropriate issue tag for that.
Now who wants to write the tests?
Comment #77
TR CreditAttribution: TR commentedComment #78
dsdeiz CreditAttribution: dsdeiz at Skvare commentedYeah, here's one for D8.
Comment #79
TR CreditAttribution: TR commentedIt looks pretty good, but it needs test cases - we already have test cases for every Rules event, condition and actions; new events, conditions, and actions also need to provide tests.
For the tests, this needs:
Comment #80
dsdeiz CreditAttribution: dsdeiz at Skvare commentedComment #81
dsdeiz CreditAttribution: dsdeiz at Skvare commentedYeah, gave this a try although not really sure where to start from when testing the action. Tried to look for something similar like UserBlockTest.php or BanIpTest.php although they I can't seem to get an idea there.
Yeah, will probably wait for others to chime in. Or any directions I can look at would be nice to get it started.
Comment #82
TR CreditAttribution: TR commentedUserBlockTest looks like a good one to use. Your test will involve users, which need to be set up properly for Unit tests. Unit tests don't enable modules, and therefore don't create the default anonymous and authenticated users, among other things. So for user tests it's good to start by copying another test that uses users, like UserBlockTest. A lot of the setup work is done in the Rules test base, which UserBlockTest subclasses.
The changes you have to make to that test are:
If you don't have PHPUnit set up on your local development machine, feel free to use this issue for testing - post your patches as "Needs review" and they will be tested. If there's a fail you can't figure out just ask and I'll take a look at it.
Comment #83
dsdeiz CreditAttribution: dsdeiz at Skvare commentedSweet, thanks! Yeah, here's an initial attempt. Yeah, the ones I'm not sure are how to activate the user from
testUserCreateLoginUrlWithValidUser()
, check ifuser_pass_reset_url()
is called one time, and assert that the generated login URL is the correct.Yeah, tried to base it on UserBlockTest as well.
Really appreciate the directions!
Comment #84
dsdeiz CreditAttribution: dsdeiz at Skvare commentedYeah, tried copying the whole setup in UserBlockTest. I'm not entirely sure how to avoid copying the same things in UserBlockTest though. Error now is:
I think I need to test if
user_pass_reset_url()
is called and maybe if the return value is the same as well? Or perhaps only checking ifuser_pass_reset_url()
is called?Comment #85
Suresh Prabhu Parkala CreditAttribution: Suresh Prabhu Parkala at Specbee commentedRe-rolled patch. Please review.
Comment #86
TR CreditAttribution: TR commentedHere is a re-roll of #85 that applies to the current HEAD.
I have NOT reviewed this - I just re-rolled it to see if the added tests will pass. If they do, then we can move on from there. But we haven't had a patch that applies for almost a year now.
Comment #87
mrcharles CreditAttribution: mrcharles commentedHi. I've had great value out of the patch in #73 for years now.
It seems to not be compatible with the 7.x-2.14 release of August '23.
I wonder if anyone else is experiencing this and any help to fix the issue would be greatly received.
Many thanks in advance.
Comment #88
Nikolay ShapovalovThere is no closing quote in 86.
I update patch 86, I was not able to create interdiff between 86 - 88, having issue
Changes, add close quote:
I was searching for solution
But only I found approach used in SendAccountEmailTest, where dump function
_user_mail_notify
used.But I am not sure that this is the right approach.
And I don't understand what should be tested in the Unit test for this action.
Comment #90
Nikolay ShapovalovI was able to finish Unit Integration test, but this is my first Integration test, would love to get some feedback.