Skip to content

One React Aria version in both harnesses, and a magic-link acceptance test (#132, phase 5) - #137

Draft
sneridagh wants to merge 3 commits into
issue-132-phase-4from
issue-132-phase-5
Draft

sneridagh wants to merge 3 commits into
issue-132-phase-4from
issue-132-phase-5

Conversation

@sneridagh

@sneridagh sneridagh commented Oct 4, 2026 •

Copy link
Copy Markdown
Member

Fifth phase of #132, stacked on #136. 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.

Two things:

What changes

Both harnesses override the React Aria libraries to the ranges in Aurora's core/catalog.json. Volto's own catalogue has the same ranges.

Library Range Resolved in both
react-aria-components ^1.17.0 1.21.1
react-aria ^3.48.0 3.52.1
react-stately ^3.46.0 3.50.0
@react-aria/utils ^3.34.0 3.34.1
@react-spectrum/utils ^3.13.0 3.13.1
@internationalized/date ^3.12.1 3.12.4
  • Volto harness: pnpm.overrides in frontend/package.json.
  • Aurora harness: overrides in frontend/aurora/pnpm-workspace.yaml.

Why the lockfiles changed too

The ranges already matched, but the two lockfiles had been resolved at different times. Volto had react-aria-components 1.20.0, react-aria 3.51.0 and react-stately 3.49.0; Aurora had the versions above.

Volto's lockfile was moved to Aurora's versions by pinning them for one install and then restoring the ranges. Its diff touches only these libraries and their @internationalized/number. A plain pnpm update of the six would also have re-resolved unrelated packages: webpack plugins, and Volto's react-is-19 alias.

Each lockfile has exactly one version of each library, and the transitive @internationalized/* and @react-types/shared match too.

AGENTS.md gains the rule: keep the two override lists the same, and both lockfiles resolving the same versions.

Magic-link acceptance test

frontend/aurora/acceptance/tests/magic-link.spec.ts:

  1. Asks for a link from Aurora's login page, for an address nobody has used.
  2. Reads the email the site sent, and checks the link points at Aurora's own origin and /login-identity. This shows the backend built it through the virtual-host URL.
  3. Signs in with it: home, with Aurora's session cookie.
  4. Opens it again without a session: "That sign-in link is no longer valid."

The test adds the email provider for its own run and removes it afterwards. Beside Dex, that provider would stop /login going straight to Dex in the sole-provider test.

Where the mail comes from

The harness's acceptance server now runs the add-on's own layer, pas.plugins.identity.testing.ACCEPTANCE_TESTING, instead of Volto's VOLTO_ROBOT_TESTING. The layer already installs collective.MockMailHost and configures a sender, so every message the site sends is kept, not sent. The test reads the last one through the server's Robot Framework remote library (get_the_last_sent_email, over XML-RPC).

Option Outcome
Volto's robot layer, as before Its mock MailHost holds no messages on this server, and the backend tried real SMTP
Products.PrintingMailHost Writes each message to the log. A test could only read it by scraping the backend's output
Mailpit Works, but is one more service; the first commit of this PR used it
The add-on's own layer, with collective.MockMailHost Kept: no extra service, and the mail is readable over the remote library

One backend change: the layer's Zope root had no virtual host monster, which the Aurora add-on's VirtualHostBase URLs need. testing.py now installs it, as Volto's robot fixture does. The backend suite passes: 3837 tests.

All five acceptance tests pass locally. Not run in CI yet.

Checks

Check Result
Tests Core 282, Volto 664, Aurora add-on 26: unchanged
make -C frontend lint, make aurora-lint, both typechecks Pass
Volto pnpm build, make aurora-build, Storybook Pass

Override react-aria-components, react-aria, react-stately,
@react-aria/utils, @react-spectrum/utils and @internationalized/date to
the ranges of Aurora's core/catalog.json, in the Volto harness
(pnpm.overrides) and the Aurora one (pnpm-workspace.yaml overrides).
Both lockfiles now resolve the same versions: react-aria-components
1.21.1, react-aria 3.52.1, react-stately 3.50.0. Volto's lockfile only
changes for those libraries.

A stopgap until Volto's and Aurora's @plone/components agree on one
version by themselves.

Refs #132
A Playwright test sends a magic link from Aurora's login page, reads it
from Mailpit, and signs in with it, then checks that the same link is
refused the second time. The link has to point at Aurora's own address:
the backend builds it through the virtual-host URL.

The acceptance site has no mail server and no sender address, so the
test gives it both, and adds the email provider only for its own run:
beside Dex it would stop /login going straight to Dex in the other
tests. Mailpit starts with `make acceptance-mail-start`, and in CI.

Refs #132
@sneridagh sneridagh changed the title One React Aria version in both frontend harnesses (#132, phase 5) One React Aria version in both harnesses, and a magic-link acceptance test (#132, phase 5) Oct 4, 2026
The harness's acceptance server now runs the add-on's own
pas.plugins.identity.testing.ACCEPTANCE_TESTING layer instead of
Volto's robot layer. It already installs collective.MockMailHost and
configures a sender, so the test reads the link through the server's
Robot Framework remote library, and no mail service or registry
patching is needed.

The layer's Zope root lacked the virtual host monster, which the
Aurora add-on's VirtualHostBase URLs need; the layer now installs it,
the way Volto's robot fixture does.

Products.PrintingMailHost was considered: it writes mail to the log,
which a test could read only by scraping the backend's output.

Refs #132

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant