I am sure this has been discussed but I couldn't fine references.
I've also searched google and this issue queue and the documentation and kind of found that doing this is not possible, my question is why?
I am about to write my own create new user action, but I wondered if there are strong reasons not to work on this as a patch to rules.
First, I understand some security implications on allowing the password to be set from some variable of the rules, however, this should be allowed for any of us to use it (if you want, with the proper permission).
So, this is my scenario:
I have a content profile (another of your great modules) for a specific user role. On this special case I will have A LOT of users of this specific role and some administrator, and this role has specific profile fields that are needed. I wanted to give the admins the option to create the user from the content profile instead of the other way around. This is because of many reasons, first, it's more user friendly, second, the username cannot be anything, instead is a fixed generated code composed of two fields from the content profile.
I managed to do almost everything, configured node_autonodetitle to create the fixed code for the content profile, configure a rule to create a user from that new content profile node and change the author of the node to the newly created user. All good so far, however, I want to set its password manually, not have it automatically generated.
Even more, I also want to send the normal drupal notifiy email, which is not available as an argument either. I know I could create a notification within rules but it would be better to use the already localized core notification.
So, why not allow to set the password on the rules and why not allow to have the notify account checkbox as well?
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 1216328-13.patch | 1.84 KB | shubham.prakash |
| #11 | 1216328-entity-api-get-set-user-password-11.patch | 1.83 KB | chris matthews |
| #8 | 1216328-entity-api-get-set-user-password.patch | 1.84 KB | davidwhthomas |
| #7 | 1216328-07-user_pass_property.patch | 1.12 KB | mitchell |
Comments
Comment #1
itangalo commentedChanging status of this issue.
@hanoii: Features like this could also go into Rules Bonus Pack -- some kind of greenhouse for new Rules features. Feel free to change the project in this issue to move it over.
Comment #2
hanoiihmm, ok, not a bad idea.. let's see if there's any feedback from Rules dev, otherwise, will definitely move it there and maybe contribute to that bonus pack
Comment #3
hanoiiComment #4
mitchell commentedMarked #991244: How to send a password to a user where it is reseted by admin ? as a duplicate.
Comment #5
mitchell commentedUnless there's an action with everything you want, you can use 'set a data value' for each of the fields you wish to set. The values will be available on the entity which is created.
The only one missing is setting a password, so moving to set that up. #1540180: Add a property for user's default theme will give you an idea on what a patch might look like.
Comment #6
fagoWE cannot support a password property, as the password property does not support proper read/write - e.g. setting a password stores the hash and reading it afterwards gives you the hash. Thus, maybe the hashed password would qualify as property, but that won't help you much I guess.
Thus, I'd suggest doing a separate action for setting a password.
Comment #7
mitchell commented> but that won't help you much I guess
It will. With the patch below, I can copy the password from one user to another. So, a generated user's password can be prepared, but it's still limited.
To complete the picture, Rules would need actions for Drupal's supported hash functions and access to the salt; or potentially even cooler than actions, Rules could lookup the value on another entity, which wraps the hash function as a computed property.
Comment #8
davidwhthomas commented@mitchell, thanks for the patch
A client requested to allow batch updating user passwords.
I used VBO with "Modify entity values" operation on a user entity view to batch set the user password.
The only problem with the above patch is it stored the password using
entity_property_verbatim_setwhich results in the plain text password stored in the database.I modified the patch to use
entity_metadata_user_set_propertiesinstead, where the password is hashed, (if not already). Note: There may be a better way to test if password is already hashed, but currently does a quick strpos check for "$S$" I'm open to suggestions on an approach to work better with other password hashing algorithmsThe net result is that I can now easily batch set user passwords using VBO with the "Modify entity values" operation selecting the "Password" user property and the value gets hashed and stored in the database.
Yay!
Cheers,
DT
P.S Entity API rocks :)
@fago, patch against latest -dev attached if you're still interested in this user password as entity property approach?
Comment #9
kriboogh commentedI need this password property too.
BTW, maybe an idea to think about: it would be nice if we could add (existing, but not provided) properties through some sort of hook(s). That way a module developer can decide wether or not he needs a particular property. He could then for example implement this hook and add password as a property to user wrappers. Just a though. Another example, I found myself lacking for example the 'format' property for taxonomy_terms entity wrappers.
Comment #10
zatox commented#8: 1216328-entity-api-get-set-user-password.patch queued for re-testing.
Comment #11
chris matthews commentedThe 6 year old patch in #8 to callbacks.inc and user.info.inc applied cleanly to the latest entity 7.x-1.x-dev, but had 1 whitespace error so new patch attached.
Comment #13
shubham.prakash commentedThis patch should apply cleanly.
Comment #14
shubham.prakash commented