Add checkout settings to allow more flexibility with anonymous orders and user accounts

I use the MR not patch 20. it applied cleanly, but I got the same error as in #24

Did a manual copy/paste reroll of the patch from what I think was the lastest changes in the MR.

Did get this on drush updb:

>  [notice] Update started: commerce_checkout_post_update_2
>  [notice] commerce_checkout.settings does not exist in extension storage
>  [notice] Update completed: commerce_checkout_post_update_2

Just need some clear direction here from commerce maintainers as to what is preferred in regards to settings.

drr... discarded changes to the removed file...

I was the one suggesting a separate config object in comment #9, but now I'm having second thoughts about this suggestion... I don't think it's a good idea to spread out checkout configuration in 2 different places. The checkout flow is a natural fit for this even though I get that it'd be annoying to have to configure on simple sites 2 different checkout flows for the same thing even though the value is likely going to be similar.

@rszrama: thoughts on this?

First stab at a reroll back to checkout flow. :)

Made some changes to the patch from #32, renamed "guest_order_convert" to "guest_order_assign" and also tweaked the setting description which previously sounded weird. Also the event subscriber logic used to call the user_password() function which no longer exist with D10.

Haven't tried re-running the tests locally but see how this goes :).

Thanks! I was just sitting down to sift through this, I will wait for the test results! :)

Looks like we left the guest_new_account_notify setting out of the event subscriber:

	+    $checkout_flow = $order->get('checkout_flow')->entity;
+    assert($checkout_flow instanceof CheckoutFlowInterface);
+    $checkout_flow_plugin = $checkout_flow->getPlugin();
+    $configuration = $checkout_flow_plugin->getConfiguration();
+    $guest_new_account = $configuration['guest_new_account'] ?? FALSE;
+    $guest_order_assign = $configuration['guest_order_assign'] ?? FALSE;
+    if (!$guest_new_account && !$guest_order_assign) {
+      return;
+    }

I see this is left our as well:
https://git.drupalcode.org/project/commerce/-/merge_requests/38/diffs?co...

I have some deprecations locally in testing, but here's the added line.

@tonytheferg: but why changing this? This change is not necessary?

It was initially changed by matt:
https://git.drupalcode.org/project/commerce/-/merge_requests/38/diffs?co...

Then reverted back:
https://git.drupalcode.org/project/commerce/-/merge_requests/38/diffs?co...

Matt's PR is 2 years old :), the code has changed since...

Good point. 😆

Tests are green now, I wonder if we should "block" the user by default or at least check the user settings so that we know whether or not the registration requires admin approval.

Woot!

I wonder if we should "block" the user by default or at least check the user settings so that we know whether or not the registration requires admin approval.

The default behavior in 7 AFAIK is that a customer is an unblocked authenticated user.

For reference, the completion register pane also logs in the new user right away and we aren't doing this here.

For reference, the completion register pane also logs in the new user right away and we aren't doing this here.

Now this would be helpful. In 7 I constantly saw page not founds after order completion because users are clicking the order link in the completion message not reading that the have to log in to view their order.

I had to try to reword the completion message to make it as clear as possible:

Thank you for your order!

Your order number is [commerce-order:order-number]. You must log in → to view your orders. If this is your first order with us, you will receive an email with log in instructions. Please check your inbox, and spam/junk folder as we handle all order notifications and account information through email.

Once you have logged in, you can view the status of your order by clicking on the "Orders" tab. For any questions regarding your order, please don't hesitate to contact us → .

Thank you again for your business.

#41 looks great

@tonytheferg: I guess the main difference with the completion register checkout pane is that the customer registered on purpose.
With this patch, the user account is created and there is no communication about it... So I guess we should leave the patch as is.

The "guest_new_account_notify" setting is now hidden until the "guest_new_account" checkbox is checked, using #states, like the following:

 '#states' => [
        'visible' => [
          ':input[name="configuration[guest_new_account]"]' => ['checked' => TRUE],
        ],
      ],

went ahead and committed the patch!

🎉

🥳 nice

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

mglaman → closed merge request !38