feat: el donante sigue sus donaciones (Mis donaciones + seguimiento) y previsión por centro#201
Merged
Merged
Conversation
GetIntakeDeepLink generaba …/e/{slug}/donar-acopio?resourceId=…, una ruta web
inexistente (404). Se apunta a /pre-registro, que ya resuelve el pre-registro
de entrega con resourceId preseleccionado. Actualizados ejemplo del DTO y los
tests unitario y e2e.
Closes #187
…opio - Donante: nueva página pública /e/[slug]/donacion/[code] y endpoint GET /emergencies/:emergencyId/donation-intakes/by-code/:code (sin login, sin PII de terceros, con throttle) para seguir por el comprobante el estado y recorrido de la donación. El QR del comprobante ahora codifica la URL de seguimiento (#168). - Acopio: nuevo endpoint GET /resources/:resourceId/donation-intakes/incoming-summary (auth, intake:read) y panel "Por entrar (previsión)" en /recepcion con el material pre-registrado pendiente agregado por línea, para planificar (#200). Closes #168 Closes #200
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…anel Cada punto que gestiona el operador es ahora un "Centro de recepción" con su propia previsión de entrante y sus entregas pendientes, en lugar de un agregado único de todos los puntos. La entrada del hub de coordinación pasa a llamarse "Centro de recepción" y el enlace de volver apunta al panel de coordinación, para que la recepción deje de ser una URL suelta.
…aforma (#168) El donante autenticado ve sus donaciones desde su cuenta, sin depender de guardar el código del comprobante: - API: GET /me/donation-intakes devuelve las entregas del usuario (por donorUserId) en todas las emergencias, de más reciente a más antigua, sin PII de terceros. Use-case GetMyDonationIntakes + repos (in-memory y drizzle). - El pre-registro reenvía ahora la sesión (guard JWT opcional del endpoint), de modo que una entrega hecha con la cuenta queda enlazada al usuario; el pre-registro anónimo sigue funcionando (solo código/QR). - Web: página /mis-donaciones (acceso desde el panel) que lista las donaciones y enlaza a su página de seguimiento. La búsqueda de donaciones por código o email sigue siendo exclusiva de los gestores y operadores (intake:read), sin cambios.
…a tiene (#168) Perfil de usuario: - Nuevo campo `phone` (migración 0035), expuesto en /auth/me y persistido por los repos (drizzle + in-memory). Nullable, sin romper cuentas existentes. Donante logueado: - El pre-registro toma nombre y email (y teléfono si lo tiene) de su cuenta, en solo lectura, y reenvía la sesión para enlazar la donación a su usuario. Donante sin cuenta: - Si deja un email, se crea un perfil SIN contraseña (EnsureDonorAccount) y la donación queda enlazada, de modo que la verá en "Mis donaciones" cuando active su cuenta. Queda un hueco (SetPasswordInviter, implementación no-op) para el email de "crea tu contraseña": el envío NO se implementa en esta PR. La búsqueda de donaciones por código o email sigue siendo exclusiva de operadores (intake:read).
# Conflicts: # apps/web/src/app/e/[slug]/pre-registro/pre-registro-form.tsx # apps/web/src/app/panel/page.tsx
This was referenced Jun 29, 2026
3 tasks
vgpastor
pushed a commit
that referenced
this pull request
Jun 29, 2026
…nel) (#213) ## Resumen Cierra el hueco de #205: el usuario puede fijar su teléfono al registrarse y editarlo desde el panel. - **API:** `phone` opcional en `RegisterDto`; nuevo use-case `UpdateProfile`; `PATCH /auth/me` (autenticado, devuelve perfil actualizado). - **Web:** nueva página `/panel/mi-perfil` con formulario de nombre + teléfono; acceso desde el panel de inicio. - Sin migración de BD — la columna `phone` ya existía desde PR #201. - `packages/api-client/src/schema.ts` regenerado con el nuevo endpoint. ## Validación - [x] Pasé el gate que toca para esta zona del repo — api: build, eslint, prettier, test; web: build, lint; api-client: build. En verde. - [ ] Verifiqué el comportamiento manualmente — pendiente de preview: registro con phone → /panel/mi-perfil → editar → /auth/me devuelve phone actualizado. - [x] Actualicé docs, migraciones o cliente API si correspondía — schema.ts regenerado; sin migraciones. ## Cierre - Closes #205
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resumen
Cierra el círculo del flujo de donación por los dos lados: el donante sigue sus donaciones y el acopio prevé lo que va a entrar. Reconcilia además la ruta del QR/deep-link.
Donante — trazabilidad (#168):
/e-independiente/mis-donaciones(acceso desde el panel) que lista las donaciones del usuario autenticado en todas las emergencias y enlaza a su seguimiento. APIGET /me/donation-intakes(pordonorUserId, sin PII de terceros). El pre-registro ahora reenvía la sesión (guard JWT opcional), de modo que una entrega hecha con la cuenta queda enlazada al usuario; el pre-registro anónimo sigue funcionando (solo código/QR).GET /emergencies/:id/donation-intakes/by-code/:code(sin login, throttle, sin PII) + página/e/[slug]/donacion/[code]con estado, punto y línea de tiempo. El QR del comprobante codifica la URL de seguimiento.intake:read), sin cambios.Acopio — previsión de entrante (#200):
GET /resources/:id/donation-intakes/incoming-summary(auth,intake:read): agrega las líneas de los pre-registros pendientes por (nombre + categoría + unidad + presentación)./e/[slug]/recepcionse reorganiza por centro: cada punto del operador es un bloque "Centro de recepción" con su previsión y sus pendientes (en vez de un agregado único), integrado bajo el hub de coordinación. No duplica Registro de entradas (donaciones recibidas) en un punto #9 (lo que ya entró y suma a stock); esto es lo pendiente/esperado.Fix de ruta (#187): el deep-link/QR apuntaba a
/donar-acopio(404); lo reapunto a/pre-registro?resourceId=(página existente) en vez de duplicarla. Cumple los dos criterios de aceptación de la issue.Backend hexagonal (use-cases framework-free con tests in-memory:
GetMyDonationIntakes,GetDonationIntakeTracking,GetIncomingSummaryByResource). Cliente tipado regenerado. Sin migraciones (reutilizadonation_intakes/resource_items;donor_user_idya es nullable).Validación
build(nest/tsc),eslint --max-warnings=0,prettier --checken verde; web:build,linten verde;@reliefhub/api-clientbuild. (Los testsjestde la API requieren Postgres/Redis delglobal-setup, no disponibles en esta sesión; los nuevos specs son unitarios —use-case con repositorio in-memory— y los ejecuta CI.)/mis-donaciones→ seguimiento; y panel de previsión por centro con un grantintake:read.packages/api-client/src/schema.tsregenerado (3 endpoints nuevos); sin migraciones.Cierre
/e/{slug}/donar-acopiopara el deep link/QR de pre-registro por acopio #187