It's currently possible for a site to deny anonymous users the ability to create accounts via the site-wide registration form but still see those same anonymous users create accounts via the checkout form. In some cases, this may be desired behavior, but in others it might be a surprise, which is unintended / unwanted.

There is some ambiguity here in that the settings form appears absolute but is not documented as required to be enforced by every third-party module that might create accounts. Thus, a compromise solution would be to at least:

  1. Signal in a checkout flow's configuration interface when its "Create a new account for an anonymous order" checkbox overrides the account settings form to permit account creation upon checkout completion.
  2. Signal the same in the "Login or continue as guest" checkout pane settings form.
  3. Signal the same in the "Guest registration after checkout" checkout pane settings form.

Issue fork commerce-3613532

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

rszrama created an issue. See original summary.

velmir_taky made their first commit to this issue’s fork.

velmir_taky opened merge request !726

velmir_taky’s picture

velmir_taky commented
Issue summary: View changes
Status: Active » Needs review

Added the signal in all three spots. Since it's the same check and message each time, I pulled it into a RegistrationConflictWarningTrait: it reads user.settings register and, when that's set to administrators-only, returns a messages--warning element linking to the account settings form.

- Checkout flow config: shown next to "Create a new account for an anonymous order", with #states so it only appears while that checkbox is on.
- Login pane: same, tied to "Allow registration".
- Guest registration after checkout pane: shown in its settings form (the pane being enabled is the toggle here).

config.factory is injected via create() (property injection, no constructor change, so no BC break; PluginBase's DependencySerializationTrait handles the service on serialize).

Covered by CheckoutFlowTest::testRegistrationConflictWarning — no warning while visitors can register, warning on all three once registration is admins-only.

The phpunit failure is ProductLayoutBuilderIntegrationTest::testProductWithoutVariationsDoesNotCrash (JSWebAssert:117, line 235 — a Views-wizard AJAX wait), unrelated to this MR: commerce_checkout isn't even installed in that test, and the new testRegistrationConflictWarning plus all checkout tests pass. Same failure is red on the pristine 3.x scheduled pipeline (#905996) on core 11.4.4, so it's a pre-existing core-compat issue in that test, not something this change introduced.

velmir_taky’s picture

velmir_taky commented
Related issues: +#3614106: ProductLayoutBuilderIntegrationTest::testProductWithoutVariationsDoesNotCrash fails on Drupal 11.4 (Views UI wizard AJAX)