User registration and account management are exclusively reserved for the Administrator role (Role 1). Administrators create accounts for all other users — whether internal staff (Presidency, Management, Customer Service) or external clients — assign roles, upload identity documents, and control account status throughout a user’s lifecycle. All remaining roles have limited self-service access to update their own profile details, but cannot create, deactivate, or delete other accounts.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/DanielRivera03/SistemaBancario/llms.txt
Use this file to discover all available pages before exploring further.
New User Registration Flow
Navigate to the Registration Route
The administrator navigates to the user registration interface via the query parameter:
Submit Basic Credentials
The admin provides the user’s core account data: first name, surname, unique user code (At this point the new user has
codigousuario), email address, password, and role assignment. These are saved via RegistroClientesAdministradores(), which calls SP RegistrarNuevosClientesAdministradores.habilitarsistema = 'no' and completoperfil = 'no' by default. The account is not yet usable.Complete the Full Profile
The administrator completes the user’s profile at the detail registration route, passing the unique code as a URL parameter:The method
RegistroNuevosDetallesPerfilUsuarios() calls SP RegistrarDetallesUsuarios_Clientes and stores the full personal and employment information (DUI, NIT, phone numbers, address, company, job title, birthdate, gender, marital status).Upload Identity Documents
Four document files are uploaded and saved to dedicated server directories. Each file is renamed using the pattern
The stored file names are recorded in the
<date>_<uniqid()>_<originalfilename> to avoid collisions.| Document | Server Path |
|---|---|
| DUI (front) | vista/images/fotoduifrontal/ |
| DUI (back) | vista/images/fotoduireverso/ |
| NIT | vista/images/fotonit/ |
| Signature | vista/images/fotofirmas/ |
detallesusuarios table via the same RegistrarDetallesUsuarios_Clientes stored procedure call.Account Status Management
Administrators can change any user’s account state at any time. All three operations respond with JSON for seamless AJAX handling on the front end.| Action | Model Method | Stored Procedure | Resulting estado_usuario |
|---|---|---|---|
| Deactivate | DesactivarUsuariosClientes() | DesactivarUsuarios_Clientes | inactivo |
| Block | BloquearUsuariosClientes() | BloquearUsuarios_Clientes | bloqueado |
| Reactivate | ReactivarUsuariosClientes() | ReactivarUsuarios_Clientes | activo |
Self-Service Profile Updates (All Roles)
All authenticated users, regardless of role, can update their own personal and employment details usingActualizacionDetallesPerfilUsuarios(), which calls SP ActualizarDetallesUsuarios.
Editable fields include:
- DUI number, NIT number
- Phone, cell phone, work phone
- Home address, company name, job title, work address
- Birthdate, gender, marital status
Gender-Based Localisation
When the user’sgenero field is "f" (female), marital status values are automatically converted to their feminine grammatical form before being stored. For example:
| Input (masculine) | Stored (feminine) |
|---|---|
Soltero | Soltera |
Casado | Casada |
Divorciado | Divorciada |
Viudo | Viuda |
usuarios Table — Key Fields
| Column | Type | Description |
|---|---|---|
idusuarios | int | Primary key |
nombres | varchar | First name(s) |
apellidos | varchar | Surname(s) |
codigousuario | varchar | Unique login code (unique constraint) |
contrasenia | varchar | Hashed password |
correo | varchar | Email address (unique constraint) |
fotoperfil | varchar | Profile photo filename |
idrol | int | Foreign key to roles table |
estado_usuario | varchar | activo, inactivo, or bloqueado |
completoperfil | enum | 'si' or 'no' — set automatically by trigger |
habilitarsistema | enum | 'si' or 'no' — controls platform access |
nuevousuario | enum | 'si' — flags that the user must change credentials on first login |
poseecuenta | enum | 'si' or 'no' — whether the client has a savings account |
poseecredito | enum | 'si' or 'no' — whether the client has an active credit |
Role Management (Administrator Only)
Administrators can create and maintain the platform’s role definitions through five dedicated routes and model methods.| Operation | Model Method | Description |
|---|---|---|
| Create role | RegistroNuevosRolesUsuarios() | Register a new user role with name and description |
| List all roles | ConsultarRolesUsuariosRegistrados() | Retrieve all defined roles |
| View single role | ConsultaRolesUsuariosEspecifica() | Fetch details of one specific role |
| Update role | ModificarRolesUsuarios() | Edit an existing role’s name or description |
| Delete role | EliminarRolesUsuarios() | Remove a role (ensure no users are assigned to it first) |
Newly registered users always start with
habilitarsistema = 'no' and completoperfil = 'no'. Once the administrator saves the full profile details (Step 3 above), the database trigger ComprobacionCompletarPerfilUsuarios fires automatically on the detallesusuarios table and sets completoperfil = 'si' on the parent usuarios row — no additional application call is needed. The administrator must still manually set habilitarsistema = 'si' to grant the user access to the platform.