Skip to main content

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.

CashMan H.A. organizes every authenticated user into one of five roles. Each role maps to a dedicated portal with its own dashboard, navigation, and permitted operations. Role assignment is managed by an Administrator at registration time and is stored as an integer ID in both the database and the active PHP session. Every protected route in cGestionesCashman.php checks $_SESSION['id_rol'] before rendering any view, ensuring users can never access functionality outside their assigned role.

​
Role Overview

Role IDName (ES / EN)DescriptionDashboard Route
1Administrador / AdministratorFull system control: user registration, role management, product management, savings account operations, all reports and queries. Generates initial credential PDFs for every new user.?cashmanhagestion=inicioadministradores
2Presidencia / PresidencyFinal credit approval authority, executive dashboards, product catalog editing, and high-level transaction reports.?cashmanhagestion=iniciopresidencia
3Gerencia / ManagementFirst-level credit review and recommendation, transaction management, and management-level operational reports.?cashmanhagestion=iniciogerencia
4Atención al Cliente / Customer ServiceProcesses savings account deposits, withdrawals, and openings; assists clients with queries; handles support tickets.?cashmanhagestion=inicioatencionclientes
5Clientes / ClientSelf-service portal: view credit status, make loan installment payments, transfer funds between savings accounts, send messages, and download statements and payment receipts.?cashmanhagestion=inicioclientes
Additional roles can be registered in the database, but doing so requires significant code-level changes throughout both controllers and all associated views to wire up the new role’s portal and permissions.

​
Access Control Mechanism

Role enforcement is applied inline within every case block of cGestionesCashman.php. Before any model call or view include is executed, the controller compares $_SESSION['id_rol'] against the expected integer for that route. If the check fails, the user is immediately redirected to the system redirection handler: 
// cGestionesCashman.php — role check pattern applied to every protected route
case "inicioadministradores":
    if ($_SESSION['id_rol'] == 1) {
        // fetch dashboard data and render admin portal
        require("../vista/Administradores/inicio-administradores.php");
    } else {
        // wrong role — redirect to the system's role-based redirect resolver
        header('location:cGestionesCashman.php?cashmanhagestion=redirecciones-sistema-cashmanha');
    }
    break;

case "iniciopresidencia":
    if ($_SESSION['id_rol'] == 2) {
        require("../vista/Presidencia/inicio-presidencia.php");
    } else {
        header('location:cGestionesCashman.php?cashmanhagestion=redirecciones-sistema-cashmanha');
    }
    break;
The redirecciones-sistema-cashmanha case acts as a central routing fallback that inspects the session role and forwards the user to their correct home dashboard, preventing any cross-role view exposure.
There is no middleware layer or route-group guard. Access control is entirely the responsibility of the developer maintaining each case block. If you add new routes, you must manually include the $_SESSION['id_rol'] check.

​
Session Variables

When a user successfully authenticates through cIniciosSesionesUsuarios.php?cashmanha=validar-sesiones, the following session keys are populated from the database record returned by the IniciarSesion stored procedure:
Session KeySource ColumnDescription
$_SESSION['id_usuario']idusuariosUnique numeric user ID
$_SESSION['nombre_usuario']nombresUser’s first name(s)
$_SESSION['apellido_usuario']apellidosUser’s last name(s)
$_SESSION['usuario_unico']codigousuarioUnique username / login handle
$_SESSION['id_rol']idrolInteger role ID (1–5) used for all access checks
$_SESSION['correo_usuario']correoEmail address (used for SMTP notifications)
$_SESSION['foto_perfil']fotoperfilProfile photo filename
$_SESSION['estado_usuario']estado_usuarioAccount status flag
$_SESSION['comprobar_iniciosesion_primeravez']nuevousuarioFirst-login flag — triggers mandatory credential setup
$_SESSION['habilitar_sistema']habilitarsistemaWhether the user’s associated credit has been approved
$_SESSION['comprobacioncuenta_ahorros']poseecuentaWhether the user holds a savings account
$_SESSION['comprobacioncreditos_clientes']poseecreditoWhether the user has an active credit on record
These values are set in a single block immediately after a successful credential match: 
// cIniciosSesionesUsuarios.php — session population on login
$_SESSION['id_usuario']                        = $IniciarSesionUsuarios['idusuarios'];
$_SESSION['nombre_usuario']                    = $IniciarSesionUsuarios['nombres'];
$_SESSION['apellido_usuario']                  = $IniciarSesionUsuarios['apellidos'];
$_SESSION['usuario_unico']                     = $IniciarSesionUsuarios['codigousuario'];
$_SESSION['id_rol']                            = $IniciarSesionUsuarios['idrol'];
$_SESSION['correo_usuario']                    = $IniciarSesionUsuarios['correo'];
$_SESSION['foto_perfil']                       = $IniciarSesionUsuarios['fotoperfil'];
$_SESSION['estado_usuario']                    = $IniciarSesionUsuarios['estado_usuario'];
$_SESSION['comprobar_iniciosesion_primeravez'] = $IniciarSesionUsuarios['nuevousuario'];
$_SESSION['habilitar_sistema']                 = $IniciarSesionUsuarios['habilitarsistema'];
$_SESSION['comprobacioncuenta_ahorros']        = $IniciarSesionUsuarios['poseecuenta'];
$_SESSION['comprobacioncreditos_clientes']     = $IniciarSesionUsuarios['poseecredito'];

​
First-Login Credential Setup

The comprobar_iniciosesion_primeravez flag (sourced from the nuevousuario column) identifies users who are logging in for the first time. When this flag is set, the system enforces a mandatory credential-change flow before granting full portal access.
When an Administrator registers a new user, the system generates a PDF containing the user’s initial login credentials. Those credentials are considered temporary. The first-login flag ensures that every new user — whether administrative staff or a client — must immediately set a personal password (and optionally a new unique username, depending on their role) before they can access their portal. This prevents any user from operating under the default credentials distributed at registration.
Similarly, habilitar_sistema controls whether Client-role users can access the full self-service portal. If a client’s associated credit application has not yet been approved, certain functions remain locked until the approval workflow completes.

Build docs developers (and LLMs) love

Get started for freeTalk to us