Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#48 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
playwright, typescript
Área
authentication, testing-qa

Línea de trabajo

Empieza ejecutando el servidor de desarrollo desde esta rama o desde main después de la fusión, y sigue después los dos escenarios de inicio de sesión de GitHub descritos en el issue. Usa las pantallas existentes para reclamar una cuenta de PR #46 y, si es necesario, prepara dos registros people/*.toml para el caso con varios candidatos. Se considera terminado cuando los detalles del candidato único y el valor matchedVia sean correctos, y seleccionar una tarjeta con varios candidatos reclame únicamente a esa persona.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
1
Forks
1
Merge medio
1 d 20 h
PR fusionados (30 d)
25

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de CodeForPhilly/codeforphilly-ng

Todos los issues de CodeForPhilly/codeforphilly-ng

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.