Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Browser-validate the account-claim flow end-to-end

Aperta
  • Qualcosa non va?
#48 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
playwright, typescript
Ambito
authentication, testing-qa

Direzione di ricerca

Inizia eseguendo il server di sviluppo da questo branch o da main dopo il merge, quindi segui i due scenari di accesso a GitHub descritti nell’issue. Usa le schermate esistenti per il claiming dell’account di PR #46 e, se necessario, prepara due record people/*.toml per il caso con più candidati. Il lavoro è completato quando i dettagli del candidato singolo e il valore matchedVia sono corretti e la selezione di una scheda con più candidati reclama solo quella persona.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

The account-claim plan (PR #46) covers all paths via unit + integration tests against the in-process Fastify instance. Two validation criteria depend on the running browser experience and were not flipped at merge:

  • OAuth callback with candidates → claim screen renders the candidate(s) with the right info
  • Multi-candidate picker works; selecting one claims it; others remain unclaimed

The implementation is complete; this is purely a manual / playwright verification gap. The parent-repo dev server was busy during the implementation window so I couldn't drive a real GitHub OAuth flow through the new screens without disrupting other agents.

Verification

Run dev in this branch (or a checked-out post-merge main) and:

  1. Sign in via GitHub against a laddr-era email that matches a single legacy Person. Confirm the claim screen renders one card with matchedVia: email, fullName, slug, and member count.
  2. Repeat against a GH identity whose gh.login and email both match different legacy Persons (multi-candidate). Confirm the picker shows both cards; select one; confirm only that Person gets the GH identity and the other stays unclaimed.

Notes: a quick way to seed the multi-candidate path locally is to add two people/*.toml records with distinct slugs and email-match one to your real primary GH email, and have the GH login field equal the other slug.

Lingua principale
TypeScript
Stelle
1
Fork
1
Merge medio
11m
PR unite (30g)
22

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di CodeForPhilly/codeforphilly-ng

Tutte le issue di CodeForPhilly/codeforphilly-ng

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.