Input forms that need validation will have AJAX requests
performed to get validation decisions live.
All but a few important and common form fields perform
generic validation; these will need a back-end handler
in the future in order to have them validated through AJAX requests.
Information is conveyed on focus and blur for both
errors and successes.
In particular, implement a validation API for registration,
where a client makes AJAX calls to the endpoints requesting
validation decisions on each input. Responses are strings
dependent on the type of validation error; if no error,
then empty string to indicate OK.
The function `create_account_with_params` calls `_do_create_account`,
which exhibits some discrepant behavior with throwing errors when handling
duplicate email and/or username.
A duplicate email raises a `ValidationError` (rather than the expected
`AccountValidationError`) from the first part of `_do_create_account`,
when errors from `form` (the `AccountCreationForm`) are raised.
A duplicate username raises the expected `AccountValidationError`, but
from a later part of `_do_create_account`. As a result, registering with
both duplicate username and email raises a `ValidationError` for email only.
The user message for username is “An account with the Public Username
'{username}' already exists.” which differs from that of email, “It
looks like {email} belongs to an existing account. Try again with a
different email." The latter is more consistent with other user messages.
PSA was monolothic, now split, with new features, like
a DB-backed partial pipeline. FB OAuth2 version also upped.
Partial pipelines don't get cleared except when necessary.
They persist for special cases like change of browser while
still mid-pipeline (i.e. email validation step).
Refactor, cleanup, and update of a lot of small things as well.
PLEASE NOTE the new `social_auth_partial` table.
Defaulting to a plaintext response makes no sense for an endpoint that is intended to be used by machines for testing. The endpoint now returns JSON only unless a redirect action is triggered.
In PR #15030, we missed adding the override of the initial account activation from address using the ACTIVATION_EMAIL_FROM_ADDRESS SiteConfiguration setting. We had only added the override when a subsequent activation email was sent.
ENT-318
