activar usuario#96
Open
IsaacAburto1548 wants to merge 3 commits into
Open
Conversation
Ahora, al darle al botón de eliminar y seleccionar "Desactivar (Soft Delete)" en el sistema de gestión de usuarios, pedirá de forma obligatoria el motivo (ej. "ya no pertenece a la iglesia"). El motivo aparecerá visualmente bajo la etiqueta "Inactivo" en la lista de usuarios. Aparecerá un nuevo botón verde (✓) para los usuarios inactivos que permite reactivarlos instantáneamente.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds User Inactivation Reason
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/app/gestion-usuarios/gestion-usuarios.tsx (1)
191-203: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winHide the soft-delete choice for inactive users.
For
estado === 0, the delete button says “Eliminar permanentemente”, buthandleEliminarstill offers “Desactivar (Soft Delete)”. Passestadointo the handler and disable the deny option for inactive users.Proposed fix
- const handleEliminar = (id: number, nombre: string) => { + const handleEliminar = (id: number, nombre: string, estado: number) => { + const esInactivo = estado === 0; Swal.fire({ - title: 'Eliminar Usuario', - text: `¿Qué deseas hacer con el usuario ${nombre}?`, + title: esInactivo ? 'Eliminar Usuario Permanentemente' : 'Eliminar Usuario', + text: esInactivo + ? `¿Deseas eliminar permanentemente al usuario ${nombre}?` + : `¿Qué deseas hacer con el usuario ${nombre}?`, icon: 'warning', showCancelButton: true, - showDenyButton: true, + showDenyButton: !esInactivo,- onClick={() => handleEliminar(u.id, u.nombreCompleto)} + onClick={() => handleEliminar(u.id, u.nombreCompleto, u.estado)}- onClick={() => handleEliminar(u.id, u.nombreCompleto)} + onClick={() => handleEliminar(u.id, u.nombreCompleto, u.estado)}Also applies to: 523-527, 561-564
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/app/gestion-usuarios/gestion-usuarios.tsx` around lines 191 - 203, The delete flow in handleEliminar still shows the “Desactivar (Soft Delete)” deny option for inactive users, which should be hidden when estado === 0. Update handleEliminar to accept estado alongside id and nombre, then use that value to conditionally disable or omit showDenyButton and denyButtonText for inactive users while keeping the permanent delete path. Also update the call sites that trigger handleEliminar so they pass estado from the user row, including the related delete buttons mentioned in the other affected sections.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Line 8: The build script currently couples schema mutation with application
build by running prisma db push before next build; remove prisma db push from
the build entry so the build is isolated from live database access and schema
changes. Update the package.json build script only, keeping next build
--turbopack as the build command, and move any schema update behavior to a
separate migration/deploy workflow.
In `@src/app/api/usuarios/`[id]/route.ts:
- Around line 129-137: The update response in the usuario route is leaking
sensitive fields because prisma.usuario.update() returns the full Usuario
record, including passwordHash. Fix the handler in the update flow by using a
select on prisma.usuario.update() or by mapping the returned usuario before
NextResponse.json so the payload excludes passwordHash. Keep the change
localized to the usuario update endpoint and ensure the returned data object is
safe for the browser.
- Around line 120-127: The user update handler in route.ts is still allowing
inactive users to be saved without a valid reason. Update the main request body
handling around request.json() and dataToUpdate so that estado: 0 is rejected
unless motivoInactivo is present and non-blank, and keep the existing nulling
behavior when estado === 1. Also align the DELETE soft-delete path in this same
route so it enforces the same inactivation-reason contract instead of writing
only estado: 0.
In `@src/app/gestion-usuarios/gestion-usuarios.tsx`:
- Around line 515-529: The icon-only action buttons in gestion-usuarios need
accessible names beyond title or visible icon text. Update the button elements
that call handleReactivar and handleEliminar to include an aria-label that
describes the specific user action using u.nombreCompleto and the current state,
and apply the same fix to the matching action buttons elsewhere in this
component. Ensure the aria-label clearly matches each button’s purpose so
assistive tech announces the action unambiguously.
- Around line 227-240: The inactive-reason validator in gestion-usuarios.tsx
only rejects empty values, so whitespace-only input still gets submitted as
motivoInactivo. Update the inputValidator used with the motivo prompt to trim
the value before checking it, and keep the existing flow around motivo and the
fetch PUT request in GestionUsuarios so only a non-empty, non-whitespace reason
can proceed.
---
Outside diff comments:
In `@src/app/gestion-usuarios/gestion-usuarios.tsx`:
- Around line 191-203: The delete flow in handleEliminar still shows the
“Desactivar (Soft Delete)” deny option for inactive users, which should be
hidden when estado === 0. Update handleEliminar to accept estado alongside id
and nombre, then use that value to conditionally disable or omit showDenyButton
and denyButtonText for inactive users while keeping the permanent delete path.
Also update the call sites that trigger handleEliminar so they pass estado from
the user row, including the related delete buttons mentioned in the other
affected sections.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 92199545-9cdc-4f50-a450-b4d516002b35
📒 Files selected for processing (6)
package.jsonprisma/schema.prismasrc/app/api/usuarios/[id]/route.tssrc/app/gestion-usuarios/gestion-usuarios.tsxsrc/dao/usuario.dao.tssrc/models/Usuario.ts
| "postinstall": "prisma generate", | ||
| "dev": "next dev --turbopack", | ||
| "build": "next build --turbopack", | ||
| "build": "prisma db push && next build --turbopack", |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Remove prisma db push from the build script.
next build should not require live DB access or mutate schema state; run schema changes in a dedicated migration/deploy step instead.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@package.json` at line 8, The build script currently couples schema mutation
with application build by running prisma db push before next build; remove
prisma db push from the build entry so the build is isolated from live database
access and schema changes. Update the package.json build script only, keeping
next build --turbopack as the build command, and move any schema update behavior
to a separate migration/deploy workflow.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/app/api/usuarios/[id]/route.ts (1)
135-149: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick winBlock self-deactivation in the new
PUTflow.Line 47 already prevents deleting your own account, but the current UI uses
PUT /api/usuarios/:idfor soft-delete/reactivation (src/app/gestion-usuarios/gestion-usuarios.tsx:220-286). As written, an admin can deactivate themself here and lock themselves out.Suggested change
const body = await request.json(); const { estado, motivoInactivo } = body; + if (caller.id === id && estado === 0) { + return NextResponse.json( + { success: false, message: "No puedes desactivar tu propia cuenta" }, + { status: 400 } + ); + } + const dataToUpdate: any = {};🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/app/api/usuarios/`[id]/route.ts around lines 135 - 149, The PUT handler in `route.ts` allows soft-deleting a user via `estado = 0` without checking whether the target user is the same as the authenticated admin, so add a self-deactivation guard in this update flow. Update the logic around `body`, `estado`, and `dataToUpdate` to reject requests where the route user id matches the current session user before applying the state change, and return a 400/403 response with an appropriate message. Make sure the check is applied in the same `PUT /api/usuarios/:id` path used by `gestion-usuarios.tsx` so admins cannot deactivate themselves.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/app/api/usuarios/`[id]/route.ts:
- Around line 72-89: `update`/`PUT` in `route.ts` is trusting `estado` and
`motivoInactivo` without type checks, so invalid payloads can reach `trim()` or
be persisted. In the handler that reads `request.json()` and later calls
`prisma.usuario.update`, validate that `motivoInactivo` is a string before
trimming it, and reject non-string values with a 400. Also validate `estado`
against the supported values before using it or storing it, and return a clear
400 for unsupported or non-numeric states.
- Around line 159-176: In the PUT handler that uses prisma.usuario.update and
returns the selected usuario fields, handle the stale-id case explicitly instead
of letting it fall into the generic 500 path. Catch Prisma P2025 around the
update in this route or verify the user exists before calling update, and return
the same 404 response/message used by the DELETE flow ("Usuario no encontrado").
---
Outside diff comments:
In `@src/app/api/usuarios/`[id]/route.ts:
- Around line 135-149: The PUT handler in `route.ts` allows soft-deleting a user
via `estado = 0` without checking whether the target user is the same as the
authenticated admin, so add a self-deactivation guard in this update flow.
Update the logic around `body`, `estado`, and `dataToUpdate` to reject requests
where the route user id matches the current session user before applying the
state change, and return a 400/403 response with an appropriate message. Make
sure the check is applied in the same `PUT /api/usuarios/:id` path used by
`gestion-usuarios.tsx` so admins cannot deactivate themselves.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: debd4f3e-fe26-4fa5-a122-039ba46067d9
📒 Files selected for processing (2)
src/app/api/usuarios/[id]/route.tssrc/app/gestion-usuarios/gestion-usuarios.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- src/app/gestion-usuarios/gestion-usuarios.tsx
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
1 participant
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.
Ahora, al darle al botón de eliminar y seleccionar "Desactivar (Soft Delete)" en el sistema de gestión de usuarios, pedirá de forma obligatoria el motivo (ej. "ya no pertenece a la iglesia"). El motivo aparecerá visualmente bajo la etiqueta "Inactivo" en la lista de usuarios. Aparecerá un nuevo botón verde (✓) para los usuarios inactivos que permite reactivarlos instantáneamente.
Summary by CodeRabbit