Skip to content

Add guest to full account migration - #326

Merged
DennisBauer merged 6 commits into
mainfrom
feat/guest-account-migration
Aug 3, 2026
Merged

Add guest to full account migration#326
DennisBauer merged 6 commits into
mainfrom
feat/guest-account-migration

Conversation

@DennisBauer

Copy link
Copy Markdown
Contributor

No description provided.

migrateToRegistered only asks the server to mail a confirmation link;
the account stays anonymous, and the session stays valid, until that
link is redeemed. Migrating up front would strand the account on a
mistyped address, since a guest has no password to recover with.

refreshAccount reads GET /api/auth/account back into SessionStorage so
a migration confirmed on another device becomes visible here. Its
pendingEmail carries a pending address change for a registered user and
a pending migration for an anonymous one, so callers read it together
with userType.

Also drops loginAnonymous: it posted to /api/auth/login-anonymous,
which no version of the server has ever served.
Adds the upgrade screen and the ways into it. The form takes an email
and a password and switches to a "check your inbox" phase; the account
is untouched while that link is outstanding, so a typo costs one
re-submit and the app keeps working throughout.

The profile section shows the unconfirmed state as a callout rather
than a row, because that in-between is easy to forget and is exactly
when signing out still destroys everything. A guest signing out is
therefore always asked to confirm, not only when writes are queued.

pendingEmail is only read as a migration for anonymous users; for a
registered one the same field means a pending address change.
Redeeming a link under an anonymous session can only be that account's
upgrade: a guest has no address to change and no registration to
confirm. The server keeps its sessions alive across that migration on
purpose, so this path must not go through the session invalidator the
email-change flow needs, and the screen offers a way back into the app
instead of a sign-in.

A link opened with an account already on the device confirms on a
logged-in twin route, inside the app shell and on top of Home. The shell
picks its navigation graph from the current route's type, so the plain
key would flip to the logged-out graph, which has no entry for the Home
underneath it. Leaving the screen now uncovers the app again instead of
stranding a live session on Welcome.
The notice already promised an account could be created later, without
saying where. Points at the profile entry that now exists, and says
plainly that nothing is lost by taking it.
The refresh that replaces the cached guest with the registered user was
fire-and-forget. When it failed the app kept treating a migrated
account as a guest: the profile offered the upgrade again and sign-out
still warned that the groups would be lost.

A redeemed token under an anonymous session is proof the migration
happened, so the account type is now corrected locally when the server
copy cannot be fetched. The address catches up on the next refresh.
Ending the session instead would undo what this flow guarantees.

The existing test passed for the wrong reason: it left the fake's
refreshAccount at its failing default, so it never covered the success
path it claimed to.
They are stateless, so the getters allocated a new UiText on each
access. Matches the sibling account screens.
@DennisBauer DennisBauer added the feature New feature or request label Aug 3, 2026
@DennisBauer
DennisBauer merged commit 5581fde into main Aug 3, 2026
3 checks passed
@DennisBauer
DennisBauer deleted the feat/guest-account-migration branch August 3, 2026 17:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant