Offer the claim at sign-up and after sign-in #388

New issue

Closed

opened 2026-10-11 16:27:41 +00:00 by root · 11 comments

root commented

2026-10-11 16:27:41 +00:00

(Migrated from gitlab.core-project.space)

Imported from GitHub amaurycoudr/chess-project#388, opened by @amaurycoudr on 2026-10-11 16:27 UTC.

Parent

#365

What to build

A Player signing up in a browser whose Guest owns Games sees a choice on the form, ticked by default, to add them to the new Account, naming how many. A Player signing in to an existing Account in such a browser gets a dialog: "Add N games to your account?", with "Add them" and "Not now". Either way the Games then show in "My games" on every browser of the Account. The e2e spec walks both paths and a second device.

Sign-up view: when the status is unclaimed with at least one Game, the form shows the choice. After sign-up succeeds with it ticked, the view claims through #387's mutation. Unticked claims nothing. A failed claim leaves the Account signed in, shows a toast and leaves the banner on "My games". The sign-up procedure itself is not changed.
Sign-in view: after sign-in succeeds with the status unclaimed and at least one Game, the dialog asks. "Not now" changes nothing, and the dialog shows again at the next sign-in. A failed claim shows a toast and leaves the banner on "My games".
No Guest, or a Guest with no Games: no choice on sign-up and no dialog on sign-in.
Every new string goes in the Paraglide catalogue in English and French (ADR 0025).
e2e, one new spec, using the suite's Room helpers and the Accounts v1 helpers for signing up and in:
- two Players play a Game and one resigns; the Guest who resigned signs up with the choice left ticked and sees the Game in "My games"; a fresh browser context signs in to that Account and sees it too;
- a Player with an Account made through the UI in another context plays as a Guest, signs in, confirms the dialog, and sees the Game in "My games".

Seam: The front views (sign-up and sign-in views) and e2e

Acceptance criteria

With an unclaimed Guest that owns Games, the sign-up form shows the choice, ticked, naming the count. Signing up with it ticked claims, and "My games" lists the Games.
Signing up with the choice unticked claims nothing, and the banner stays on "My games".
A claim that fails after sign-up leaves the Player signed in, shows a toast, and leaves the banner.
After sign-in with such a Guest, the dialog names the count. "Add them" claims and tells how many were added. "Not now" moves nothing, leaves the banner, and the dialog shows again at the next sign-in.
A claim that fails from the dialog shows a toast and leaves the banner.
With no Guest, or a Guest owning zero Games, neither the choice nor the dialog shows.
Every new string exists in English and French.
The e2e spec's two tests pass, each asserting in every browser it uses.

> _Imported from GitHub [amaurycoudr/chess-project#388](https://github.com/amaurycoudr/chess-project/issues/388), opened by [@amaurycoudr](https://github.com/amaurycoudr) on 2026-10-11 16:27 UTC._  --- ## Parent #365 ## What to build A **Player** signing up in a browser whose **Guest** owns **Games** sees a choice on the form, ticked by default, to add them to the new **Account**, naming how many. A **Player** signing in to an existing **Account** in such a browser gets a dialog: "Add N games to your account?", with "Add them" and "Not now". Either way the **Games** then show in "My games" on every browser of the **Account**. The e2e spec walks both paths and a second device. - Sign-up view: when the status is `unclaimed` with at least one **Game**, the form shows the choice. After sign-up succeeds with it ticked, the view claims through #387's mutation. Unticked claims nothing. A failed claim leaves the **Account** signed in, shows a toast and leaves the banner on "My games". The sign-up procedure itself is not changed. - Sign-in view: after sign-in succeeds with the status `unclaimed` and at least one **Game**, the dialog asks. "Not now" changes nothing, and the dialog shows again at the next sign-in. A failed claim shows a toast and leaves the banner on "My games". - No **Guest**, or a **Guest** with no **Games**: no choice on sign-up and no dialog on sign-in. - Every new string goes in the Paraglide catalogue in English and French (ADR 0025). - e2e, one new spec, using the suite's **Room** helpers and the Accounts v1 helpers for signing up and in: - two **Players** play a **Game** and one resigns; the **Guest** who resigned signs up with the choice left ticked and sees the **Game** in "My games"; a fresh browser context signs in to that **Account** and sees it too; - a **Player** with an **Account** made through the UI in another context plays as a **Guest**, signs in, confirms the dialog, and sees the **Game** in "My games". Seam: The front views (sign-up and sign-in views) and e2e ## Acceptance criteria - [ ] With an unclaimed **Guest** that owns **Games**, the sign-up form shows the choice, ticked, naming the count. Signing up with it ticked claims, and "My games" lists the **Games**. - [ ] Signing up with the choice unticked claims nothing, and the banner stays on "My games". - [ ] A claim that fails after sign-up leaves the **Player** signed in, shows a toast, and leaves the banner. - [ ] After sign-in with such a **Guest**, the dialog names the count. "Add them" claims and tells how many were added. "Not now" moves nothing, leaves the banner, and the dialog shows again at the next sign-in. - [ ] A claim that fails from the dialog shows a toast and leaves the banner. - [ ] With no **Guest**, or a **Guest** owning zero **Games**, neither the choice nor the dialog shows. - [ ] Every new string exists in English and French. - [ ] The e2e spec's two tests pass, each asserting in every browser it uses.

root commented

2026-10-11 16:27:41 +00:00

(Migrated from gitlab.core-project.space)

GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links).

Parent (sub-issue of): #365
Blocked by: #387
Blocking: #389

> _GitHub issue relations, imported as "related" links (GitLab CE has no sub-issues or blocking links)._  - Parent (sub-issue of): #365 - Blocked by: #387 - Blocking: #389

root commented

2026-10-13 08:39:51 +00:00

(Migrated from gitlab.core-project.space)

mentioned in issue #389