Ubercart's setting 'Login users when new customer accounts are created at checkout.' should respect core's "Require e-mail..."

But maybe Ubercart should use Drupal core's settings to determine if logging in after a new account has been created?

Yes, I'd say that if "Require e-mail verification when a visitor creates an account" is enabled then Ubercart should not allow "Login users when new customer accounts are created at checkout" to take action.

I disagree. New accounts are only created for anonymous customers. Making this change would *require* anonymous customers to set up a full Drupal account and verify the account before they had access to content they had purchased. Which defeats the whole notion of anonymous checkout. An Ubercart site can always disable anonymous checkout to force all customers to be authenticated users. In that case the "Require e-mail verification" setting in Drupal does work. But anonymous customers should not be required to verify e-mail under any circumstances. So I see this as a deliberate feature.

I'm leaving this open for further discussion, but moving it to a feature request and moving the version to 7.x-3.x as this should be addressed in the current version first.

My suggestion is just that Ubercart should require these two settings to be in synch with each other. I don't see why that's so ridiculous that a user created in checkout is treated the same as a user created by registering, but I've also only worked on a few e-commerce sites.

I also think this is a feature and not a bug. If you sell content such as roles or files, you probably want those users to get access to the content immediately; but you might also want to verify accounts if the user is registering without payment.

As I said above, if you configure your store so that only authenticated users may purchase, then you can force all your customers validate their e-mail addresses (or not) by using the normal "Require e-mail verification" checkbox. Conversely, if you allow anonymous users to make purchases, if they enter an incorrect e-mail address you still make the sale but the anonymous user will neither receive an order confirmation nor password for future login. By definition this is the same as an e-mail verification and applies whether or not the "Require verification" box is checked. In essence, anonymous customers are *always* subject to e-mail verification.

The "Login new users" box is unchecked by default, so in order you use this feature you have to explicitly enable it. And it's just that - a feature. No one is required to use it, but it does give the site administrator the option to automatically log on anonymous customers when a purchase is complete, as a way to give them immediate access to any non-physical purchase.

This is a fundamentally different use case than normal site registration, so it makes sense to me that Ubercart can override normal site sign-up in the narrow case where the site owner wants to allow anonymous checkout and also has non-physical products (downloads, site access) to sell. The anonymous user has to actually pay to get these things, which is as good or better protection against bots and spam than a simple e-mail address verification.

I didn't say your suggestion was ridiculous @greggles. If I thought it was ridiculous I would have just terminated the issue with extreme prejudice. You know I would have. I just tried to explain my thinking that in order to have anonymous checkout (which is pretty much a requirement for any e-commerce solution) you can't require your anonymous customers to first set up an account then wait for a confirmation e-mail, then click on the verification link, all before allowing them to make a purchase. Or worse, first accept their payment *then* tell them they have to go through some procedure to sign up on the site and verify their e-mail before they can download their purchase. That seems like extortion. I'm putting my thoughts out here and inviting you to point out the flaws in my logic - is there something I haven't considered which makes this an unreasonable position?

I consider this won't fix for the same reasons as TR. A contrib module could always keep these two settings in sync, if someone is convinced that's the right thing to do.