There is no control over the password assigned to the generated users. That makes impossible to use the automatically generated users in external tools, like jmeter.
Add a field to customise the password assigned to all generated users.

Comments

kurkuma’s picture

Status: Active » Patch (to be ported)

I 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.

kurkuma’s picture

The patch file...

kurkuma’s picture

Status: Patch (to be ported) » Needs review

Status: Needs review » Needs work

The last submitted patch, devel_generate_generateduserspassword-1398664-1.patch, failed testing.

kurkuma’s picture

The patch was created from the sites root. May be an issue with the paths?

kurkuma’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, devel_generate_generateduserspassword-1398664-5.patch, failed testing.

salvis’s picture

Version: 7.x-1.2 » 8.x-1.x-dev

I'm not sure why your patch fails, but patches should always go against HEAD of the latest version.

+++ b/devel_generate.inc
@@ -11,8 +11,10 @@
+ * @param $pass
+ *  A string to be used as common password for all generated users. Defaults to NULL.

This comment line is >80 chars.

+++ b/devel_generate.inc
@@ -45,7 +47,7 @@ function devel_create_users($num, $kill, $age = 0, $roles = array()) {
-        'pass'    => NULL, // No password avoids user_hash_password() which is expensive.
+        'pass'    => NULL, //No password avoids user_hash_password() which is expensive.

If you want to fix this, then please fix it correctly.

+++ b/devel_generate.inc
@@ -99,6 +101,11 @@ function devel_create_users($num, $kill, $age = 0, $roles = array()) {
+        // Assign password, if set
+        if (!is_null($pass)) {
+          $account->pass = $pass; // Reset the password to an unencripted string
+        }

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.

salvis’s picture

@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.

mukesh.agarwal17’s picture

Status: Needs work » Needs review
mukesh.agarwal17’s picture

Status: Needs review » Needs work

The last submitted patch, devel_generate_generateduserspassword-1398664-5.patch, failed testing.

warmth’s picture

Any 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.

salvis’s picture

We're waiting for a patch that passes and that takes the comments into account.

warmth’s picture

So there is no temp solution?

salvis’s picture

Not that I know of, but you're certainly welcome to propose one.

juampynr’s picture

Status: Needs work » Needs review
StatusFileSize
new3.92 KB

Here is a patch for 8.x-1.x.

salvis’s picture

@warmth: Please review and test!

warmth’s picture

I don't have any Drupal 8 installation now to test it, if you port it to D7 I could try it...

pcambra’s picture

Issue tags: +develcontribute

tagging

Tomasrg’s picture

Assigned: Unassigned » Tomasrg
Tomasrg’s picture

Assigned: Tomasrg » Unassigned
Status: Needs review » Reviewed & tested by the community

I applied the patch and tested creating 5 new users.
All the users created with the password filled on the text area.

juampynr’s picture

Assigned: Unassigned » moshe weitzman

I need Moshe to chime in here.

moshe weitzman’s picture

Looks fine. Needs test coverage?

juampynr’s picture

Version: 8.x-1.x-dev » 7.x-1.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Committed. 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.

juampynr’s picture

Just saw it again and the paths of patch #2 are wrong. Waiting for @kurkuma to re-roll a new one.

kurkuma’s picture

A patch for 7.x-1.x

kurkuma’s picture

Status: Needs review » Patch (to be ported)

Regarding 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

kurkuma’s picture

@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?

kurkuma’s picture

Status: Patch (to be ported) » Needs review
kurkuma’s picture

Could 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.

juampynr’s picture

Status: Patch (to be ported) » Fixed

@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!

Automatically closed -- issue fixed for 2 weeks with no activity.