Ubercart generated passwords for anonymous users are only one character.

Strange -- I'm hoping to give this module some love on Tuesday and will followup here.

How are you seeing that the passwords are being generated with a single character in length? Since the passwords are MD5 hashed in the database, you can't read them directly.

UC_Eco looks like it's got a lot of different miscellaneous tweaks that could be hard to track. Regarding user creation order, it looks like uc_eco works by populating the default part of the Ubercart order that UC core uses to create new accounts, which in my experience *is* compatible with uc_signup. You might try making the weight of uc_eco higher than uc_signup, so that it creates the new user account before uc_signup_order() is invoked. That way, uc_signup will see that the user exists and simply assign the signup to the existing account.

Also, do you have "Login users when new customer accounts are created at checkout." checked at http://localhost/dev/contrib/cod/admin/store/settings/checkout/edit/basic ?

You're right that if uc_signup creates accounts when hook_order case 'submit' is invoked, then the combination of Paypal WPS, uc_eco, and uc_signup *and* signing up the same user who is using the uc_econ account form won't work *if* uc_eco places it's new user form before the order is previewed. If taht is the case, my suggestion is to not use that part of the module if you must use PayPal with the above configuration.

At this point, definitely don't run beta5 -- run the dev instead.

I'm also getting passwords of one character, as seen in the customer email, + like the original poster, this is the email from Drupal ("administrator created an account for you.."). I got the same result with and without "Login users when new customer accounts are created at checkout" and incidentally, with it checked, they still were not logged in.

I am not using uc_eco. I am using uc_free_order, although my tests are not using that, I am testing with test gateway. Using dev version from Aug 1, no other patches applied, Ubercart 6.x-2.3, Drupal 6.17.

This has been resolved for me when reinstalling uc_signup latest dev fresh on a copy of the site that never had any older versions.

I spoke too soon. When my signups weren't being created (uc_signup's weight not -1 issue), like the above poster described, I was seeing Ubercart's email, which does have a good password. After I fixed the db weight and have signups being created, I'm getting what looks like a drupal site registration email, with the one character password.

I get these using test gateway. Also testing with PayPal WPPro + PayPal Express, but the PayPal sandbox doesn't include emails that aren't PayPal specific.

Marking as needs review. Thanks for the thorough investigative work here!

Working with test gateway, thank you brentratliff!

It seems that even if the ubercart checkout setting to send account details is checked, it is not used in place of the required Drupal new user setting, which seems fine, although your Drupal message might need to be written for a wider use than ubercart's, if we could use it.

I meant to add.. the patch applied with "Hunk #1 succeeded at 656 with fuzz 2 (offset 6 lines)."

Maybe related to the difference where this is generated from, is in the thank you section of the uc_order-customer.tpl it includes username + password if new user, but that is left out of the invoice emails my testing is getting.

patch from #23 (on otherwise unpatched dev) working, Nice work! Sends email from ubercart store setting address, and still fixes one character password issue.

A new issue is these signups are not entered as "count_towards_limit" in signup_log table to be counted as "Signup slots used".

I have an existing issue that previously only my PayPal signups did this #902482: Successful PayPal orders not counted as Signup slots used but my test gateway signups did count towards slots used, now after this patch, the test gateway signups also are not counted as "Signup slots used".

@brentratliff are you seeing this too?

My other point about the uc_order-customer.tpl - the conditional is
if (isset($_SESSION['new_user']))
then it includes username + new password - I'm not sure why or how to get this to show. This is minor, but the "count_towards_limit" in signup_log table is very important for this site's workflow.

@brentratliff I'm grateful you're working on this.

the new username + new password I am referring to is not from the checkout message settings, it's the invoice, uc_order-customer.tpl, using variables rather than tokens - by default it uses $new_username + $new_password but the conditional if (isset($_SESSION['new_user'])) is not being met.

Yes, orders are attached to username, and all is right with order, user account and signup being connected (except the "count_towards_limit" in signup_log table). Getting this in the invoice is not a high priority unless it's a clue towards something else. My priority need is "count_towards_limit".

Apologies, my error!
#23 usersave.patch is working for me and not causing any issues, it was me missing a configuration setting installing signup_status amidst testing. "count_towards_limit" is working!

My secondary issue of new username + new password not outputting to the invoice is still not working but not related, as it doesn't work in all conditions.

usersave.patch from #23 still applies cleanly to the new dev version from Sep 15 - I still get the one character password without the patch.

I suspect others get this, but it's not reported since it doesn't break anything - the one character password works. I hadn't found other issues this also addresses that you referred to in #23.

I've tested the patch on #23 and it seems to be working for me. I am using FreeOrder as my payment method and Loggintoboggan also.

When signing up a new user and not putting in a username or password, the user receives an email with a 'confirmation' link.

More feedback:

It would be nice if the order completion page said something about sending the email. Currently it displays (extra breaks removed):

"Your order is complete! Your order number is 47.
Thank you for shopping at [site name]. Your current order has been attached to the account we found matching your e-mail address.
Login to view your current order status and order history. Remember to login when you make your next purchase for a faster checkout experience!
Return to the front page."

I'd suggest something like:
"Thank you for shopping at [site name].
Your order is complete! An email has been sent to the email address provided, confirming your order. Your order number is 47.
[if new user] [bold] An account has been created for you and an email has been sent with a confirmation link, use that to log in, review your order and browse the site further. [bold]
[If not new user] Login to view your current order status and your order history.

Remember to login when you make your next purchase for a [bold]faster[bold] checkout experience!

Return to the front page to browse the site further."

@brentratliff: You raise valid issues about using drupal_execute() vs user_save(), particularly that the right kind of email is are sent for new accounts.

We actually switched from using user_save() to drupal_execute in order to simplify form validation of required fields in #547242: Users can checkout without entering required profile fields. I think your patch in #16 is closer to the correct solution, but I'm open to why user_save() could be a better approach taking into account the validation issue. Otherwise I think we could preserve drupal_execute and add a few lines of code to make sure the right type of email is sent.

@brentratliff thanks for telling me where i can edit the messages. I've been to that page but hadn't scrolled down to see all the goodies it can fiddle with (i.e. say "our little slice of the interwebs" a couple of times).

I changed language and the formatting of the code comments slightly to make them coding standards compliant, tested and committed.

Thanks, brentratliff!

http://drupal.org/cvs?commit=445276