Aurora: email confirmation and the profile gate (#132, phase 7)

[sneridagh]

Seventh phase of #132, stacked on #138. Draft: please don't merge. Each phase gets its own PR, built on the previous one, and none is merged until the whole series has been reviewed.

The sign-in follow-ups from the plan: email confirmation and the required-profile gate. The first-login route is left out: Volto offers it to sites that route to it, but nothing in either add-on does, and the gate covers the same need. concepts/frontends.md says so.

Email confirmation

• ConfirmEmailCard in core. Volto's ConfirmEmail mixed its Redux logic with its markup. The markup is now core's card, which takes a status (loading, nothing, asking, done), the addresses, and an onConfirm.
• Volto. Volto's page keeps its Redux state and renders the card. Its 10 existing tests pass unchanged, mounting the whole container. The card has 8 tests of its own in core.
• Aurora's /confirm-email. Under publicui's layout. The loader reads @my-profile as the user; the action POSTs the answer to @confirm-email.

The profile gate

Decided with you before building it: Aurora holds the user at an explanation page, /complete-profile, rather than dropping them on the edit form.

	Volto	Aurora
Held at	The profile's edit form	/complete-profile: core's new CompleteProfileCard names the missing fields by their form labels and links to /@@edit<profile>
Told why	A toast	On that page. Aurora's toast region is mounted only in the contents layout, and the edit form is @plone/cmsui's
Profile asked for	Expanded onto the content request	A rootLoaderData utility asks @my-profile for signed-in requests: one request per signed-in page. Aurora's content expansions are hard-coded, so an add-on cannot add one
Runs	appExtras, on every route	A component in the authenticatedTools slot, on every page with the site's header. It renders nothing

What Aurora reuses. The decision (lib/gate.ts) is core's rule with Aurora's stops. It uses core's EXEMPT_PATHS, awaitingConfirmation, onProfile, rememberReturn, takeReturn and handedOverReturn. A profile waiting only for an address confirmation goes to /confirm-email from anywhere but there, as in Volto.

Where the user ends up. The gate remembers where the user was going and resumes there once the profile is complete. Saving the edit form lands on the profile's own page, which has the header, and the gate lets the user go there.

Upstream. Two Aurora hooks would let this match Volto: add-on content expansions, and an app-wide toast region. Worth raising upstream.

Acceptance tests

profile-gate.spec.ts. It requires description through pas.plugins.identity.required_profile_fields for this file only, and clears it on the Dex user's profile first, so reruns start held. The steps:

1. Sign in with Dex: held at /complete-profile, told "Please fill in … before you can continue.", with the edit link at /@@edit/….
2. Open /search: held again.
3. Fill the field in as an administrator, then open /: sent on to /search.

Seen failing with the gate component unregistered. All nine acceptance tests pass locally, twice in a row. Not run in CI yet.

The email confirmation has no acceptance test: it needs a first sign-in bringing several verified addresses, and Dex brings one.

Translations

The moved messages kept their de, es and pt_BR translations. One new message, "Your profile is complete.", was translated here: "Ihr Profil ist vollständig." / "Tu perfil está completo." / "Seu perfil está completo." Worth a native speaker's look.

Checks

Check	Result
Tests	Core 324 (+8 ConfirmEmailCard, +4 CompleteProfileCard), Volto 634 unchanged, Aurora add-on 37 (+6 lib/gate)
make -C frontend lint, make aurora-lint, both typechecks	Pass
ci-i18n, both harnesses	Pass
Storybook; Volto pnpm build; make aurora-build	Pass
make docs-build; Vale	Pass; 0 errors