User Management: Create, Edit, and Manage System Accounts

The Usuarios module provides full lifecycle management for UZDI system accounts: creating new users, editing existing ones, and browsing the complete user roster. Accounts created here determine who can log in to the platform and what they can access based on their assigned role (tppr_id) and UZDI zone (uzdi_id). The module is available at /app/usuarios and is restricted to Administrador (tppr_id >= 3) and Superadministrador roles — lower-privilege users will be redirected to the dashboard by the router guard.

User Table

On load, the table fetches the full user list from GET /api/v1/users. Each row displays:

Column	Description
Nombre	Full name (`nombres + apellidos`)
Login	Unique system login rendered in a monospaced pill
Correo	Institutional email address
Estado	Activity badge — all users returned by the API are shown as Activo (green)
Acciones	Edit button (pencil icon) to open the edit modal

Search and Pagination

The toolbar above the table contains a live search field. Typing filters rows in real time across three fields simultaneously:

// UsuariosView.vue — filtered computed property
const filtered = computed(() => {
  const q = search.value.toLowerCase()
  return rows.value.filter(r =>
    r.nombre.toLowerCase().includes(q) ||
    r.login.toLowerCase().includes(q)  ||
    r.correo.toLowerCase().includes(q)
  )
})

Results are paginated at 8 records per page. Use the Anterior / Siguiente buttons at the bottom of the table to navigate between pages. The current page resets to 1 automatically whenever the search query changes.

Searching by login is the fastest way to locate a specific account — login values are unique and short (e.g. ana.torres).

Creating a User

Open the creation modal

Click the Nuevo usuario button in the page header (top-right). A modal dialog titled “Nuevo usuario” will appear over the page.

Fill in the required fields

Complete the form. The modal exposes the following fields:

Field	Required	Notes
Nombres	✅	First and middle names
Apellidos	✅	Last names
Login	✅	Unique system identifier (e.g. `juan.perez`)
Correo electrónico	—	Valid email address; enforced as required by the backend DTO
Teléfono	—	e.g. `0999999999`
Contraseña	✅ (new only)	Minimum 8 characters. Only shown when creating a new account.

The backend CreateUserDto also accepts sexo, direccion, tppr_id, uzdi_id, and observaciones. These fields are not exposed in the modal form and can be set via a direct API call or a future admin interface.

Save the new account

Click Crear usuario. The form submits a POST to /api/v1/users. On success, the modal closes and the table reloads automatically. If an error occurs (e.g. duplicate login or unreachable backend), a red error banner appears at the top of the modal.

POST /api/v1/users
Content-Type: application/json

{
  "nombres": "Ana",
  "apellidos": "Torres",
  "login": "ana.torres",
  "correo": "[email protected]",
  "password": "SecurePass1",
  "tppr_id": 2,
  "uzdi_id": 5
}

The backend ValidationPipe enforces whitelist: true — any fields not declared in CreateUserDto are stripped silently. The frontend validates that nombres, apellidos, and login are non-empty before sending the request.

Editing a User

Click the pencil icon in the Actions column of any row to open the edit modal pre-filled with that user’s current data. The password field is hidden during edits — use the Perfil page to change passwords. Once changes are made, click Guardar cambios. This sends:

PATCH /api/v1/users/:id
Content-Type: application/json

{
  "nombres": "Ana Beatriz",
  "correo": "[email protected]"
}

Only the fields included in the request body are updated (partial update via UpdateUserDto, which extends PartialType(CreateUserDto)).

User Profile Page (`/app/perfil`)

Every logged-in user can view and update their own account at /app/perfil. This page is separate from the admin Usuarios module and is accessible to all roles.

Personal Information

The profile page opens in read-only mode by default, showing:

Full name (nombres + apellidos)
Correo electrónico
Teléfono
Login (display only, not editable)
Avatar circle with initials derived from nombres + apellidos

Click the Editar button to enter inline edit mode. The form fields for nombres, apellidos, correo, and teléfono become active. Save with the Guardar button, which sends a PATCH /api/v1/users/:id request and simultaneously updates the in-memory session state via setSession() so the topbar and avatar reflect changes immediately without a page reload.

Changing Your Password

The password change form sits below the personal information card and is always visible.

Enter your current password

Type your existing password in the Contraseña actual field. This is required even for administrators changing their own password.

Enter and confirm the new password

Type the new password (minimum 8 characters) and repeat it in the Confirmar nueva contraseña field. The form validates that both values match before submitting.

Submit

Click Actualizar contraseña. The request is sent to:

POST /api/v1/auth/change-password
Content-Type: application/json

{
  "userId": 42,
  "currentPassword": "OldPass123",
  "newPassword": "NewSecure456"
}

On success, all three fields are cleared and a green confirmation banner appears for 3 seconds. On failure, the error message from the backend (e.g. "Contraseña actual incorrecta") is displayed inline below the current password field.

User Entity Reference

The user record is stored in the seguridad.prsn table via TypeORM. Here are all mapped fields:

Entity Field	DB Column	Type	Notes
`id`	`prsn_id`	`int4` PK	Auto-generated primary key
`uzdi_id`	`uzdi_id`	`int4`	UZDI zone assignment (nullable)
`tppr_id`	`tppr_id`	`int4`	Role profile ID (nullable)
`nombres`	`prsnnmbr`	`varchar(31)`	Required
`apellidos`	`prsnapll`	`varchar(31)`	Required
`sexo`	`prsnsexo`	`char(1)`	`M`, `F`, or `O` (nullable)
`direccion`	`prsndire`	`varchar(255)`	Nullable
`telefono`	`prsntelf`	`varchar(63)`	Nullable
`correo`	`prsnmail`	`varchar(63)`	Nullable in entity; validated as required email in DTO
`login`	`prsnlogn`	`varchar(30)`	Unique
`password`	`prsnpass`	`varchar(63)`	Bcrypt hash, write-only
`observaciones`	`prsnobsr`	`varchar(255)`	Nullable

Error Handling

The usuarioService.getAll() method catches all API errors and returns an empty array rather than throwing, so the table renders an empty state instead of crashing the page:

// usuario.service.ts — graceful fallback
async getAll(): Promise<UsuarioRow[]> {
  try {
    const { data } = await api.get<UsuarioDto[]>('/users')
    return data.map(u => ({ ... }))
  } catch {
    return []   // backend unreachable → empty table, no crash
  }
}

Create and update operations (create, update) do not swallow errors — they propagate to the modal’s catch block, which displays a red inline banner:

“No se pudo guardar. Verifica que el backend esté corriendo.”

This pattern surfaces actionable feedback for save failures while keeping the read path resilient.

Using the Application

Reporting & Administration

User Table

Creating a User

Editing a User

User Profile Page (`/app/perfil`)

Personal Information

Changing Your Password

User Entity Reference

Error Handling

Build docs developers (and LLMs) love

Using the Application

Reporting & Administration

Documentation Index

​User Table

​Search and Pagination

​Creating a User

​Editing a User

​User Profile Page (/app/perfil)

​Personal Information

​Changing Your Password

​User Entity Reference

​Error Handling

Build docs developers (and LLMs) love

User Table

Search and Pagination

Creating a User

Editing a User

User Profile Page (`/app/perfil`)

Personal Information

Changing Your Password

User Entity Reference

Error Handling