Closed (fixed)
Project:
Devel
Version:
7.x-1.x-dev
Component:
devel_generate
Priority:
Normal
Category:
Feature request
Assigned:
Issue tags:
Reporter:
Created:
9 Jan 2012 at 14:48 UTC
Updated:
4 Jan 2014 at 01:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
kurkuma commentedI have added a patch against version 7.x-1.2 of devel_generate. It works with the development version as well as the changes are compatible between both versions, at this point in time.
The patch adds a text field to set up a password string for all the automatically generated users. If it is left blank the default behaviour takes place.
Comment #2
kurkuma commentedThe patch file...
Comment #3
kurkuma commentedComment #5
kurkuma commentedThe patch was created from the sites root. May be an issue with the paths?
Comment #6
kurkuma commentedComment #8
salvisI'm not sure why your patch fails, but patches should always go against HEAD of the latest version.
This comment line is >80 chars.
If you want to fix this, then please fix it correctly.
Comments need to be on a line of their own, start with a capital letter and end with a dot. Even if this is not strictly followed elsewhere, we'd like new code to adhere to the coding standards.
Why "Reset"?
Please use is_set() rather than !is_null(), it's more efficient.
Comment #9
salvis@kurkuma: Please use the issues queue, not private messages.
As to your question about why D8: fixes and new features should always go to the newest version, so that an upgrade doesn't suddenly turn out to be a downgrade.
That said, you can try posting a patch prepared with 7.x-1.x-dev, because Devel for D7 and D8 are still pretty close.
Comment #10
mukesh.agarwal17 commented#2: devel_generate_generateduserspassword-1398664-1.patch queued for re-testing.
Comment #11
mukesh.agarwal17 commented#5: devel_generate_generateduserspassword-1398664-5.patch queued for re-testing.
Comment #13
warmth commentedAny news on this? I really need to assign passwords to my generated users. Is there any temp way of do it? Hashed passwords can't be inserted via MySQL so I have no idea what else to do.
Comment #14
salvisWe're waiting for a patch that passes and that takes the comments into account.
Comment #15
warmth commentedSo there is no temp solution?
Comment #16
salvisNot that I know of, but you're certainly welcome to propose one.
Comment #17
juampynr commentedHere is a patch for 8.x-1.x.
Comment #18
salvis@warmth: Please review and test!
Comment #19
warmth commentedI don't have any Drupal 8 installation now to test it, if you port it to D7 I could try it...
Comment #20
pcambratagging
Comment #21
Tomasrg commentedComment #22
Tomasrg commentedI applied the patch and tested creating 5 new users.
All the users created with the password filled on the text area.
Comment #23
juampynr commentedI need Moshe to chime in here.
Comment #24
moshe weitzman commentedLooks fine. Needs test coverage?
Comment #25
juampynr commentedCommitted. I would rather start taking potential testing cases from the doc me and @pcambra proposed for this weekend's event and convert them into issues.
Downgrading version field to 7.x-1.x to see if the patch at #2 still applies.
Comment #26
juampynr commentedJust saw it again and the paths of patch #2 are wrong. Waiting for @kurkuma to re-roll a new one.
Comment #27
kurkuma commentedA patch for 7.x-1.x
Comment #28
kurkuma commentedRegarding test coverage there is a funny event: the user is logged out "during" the submission of the form, so Drupal returns always a 403 error on generate users form submission. I have added the "administer users" permission to the user creation in the test method, and that should be enough. What am I missing? May be moving the user creation and login to the setUp?Edit: I was using kill_users so the user was deleted on submission of the form :p
Comment #29
kurkuma commented@juampy
Regarding your patch, in the version of devel for Drupal 7 the password gets scrambled in the final assignment to the user due to a double use of user_save. The effect of this is that the users can not log in as the password stored in Drupal is not the hash of the original password but seems to be the hash of the hash of the password. Is it the same in the module for Drupal 8?
Comment #30
kurkuma commentedComment #31
kurkuma commentedCould anyone test that the users created with password can actually log in in Drupal?
I have tested that with my patch in #27 but confirmation would be nice.
Comment #32
juampynr commented@kurkuma, for Drupal 8, I just verified that generated users can sign in with the given password.
Patch #27 works fine. Committed at 7.x-1.x at http://drupalcode.org/project/devel.git/commitdiff/1d4e2ef
Thanks!