Use this file to discover all available pages before exploring further.
Banco Alimentos enforces a two-layer access control model. At the coarse level, Spring Security’s SecurityConfig gates entire URL prefixes by role — for example, /api/donaciones/** is only reachable by users who hold ROLE_USER_DEPOSITO. At the fine-grained level, individual controller methods are annotated with @PreAuthorize("hasAuthority('PERMISSION_NAME')"), meaning a user must also possess the specific permission for the operation they are attempting. Roles and their associated permissions are seeded into the database on every application startup by DataInitializer.
Warehouse operations. Manages the full donation lifecycle: registering donor companies, recording donations and their line items, tracking products, generating remittances and delivery notes, issuing invoices, and reviewing donation audit history.
USER_TESORERIA
Treasury & billing. Focused on financial oversight: can view institutions and is the only role that can modify payment statuses (ESTADO_PAGO_MODIFICAR).
USER_INSTITUCIONAL
Institution management. Creates, views, updates, and removes beneficiary institutions, and can review institution audit history.
When a user authenticates, CredentialsEntity.getAuthorities() builds the full authority set that Spring Security uses for every access decision. For each role the user holds, two kinds of authorities are added:
A role authority prefixed with ROLE_ — e.g. ROLE_USER_DEPOSITO. Used by hasRole(...) checks in SecurityConfig.
One permission authority for every PermitEntity associated with that role — e.g. DONACION_CREAR. Used by @PreAuthorize("hasAuthority('...')") on individual endpoints.
On every application startup, DataInitializer wipes and re-seeds the credentials, roles, and permissions tables. Three users are always available for development:
Username
Password
Role
deposito
deposito123
USER_DEPOSITO
tesoreria
tesoreria123
USER_TESORERIA
institucional
institucional123
USER_INSTITUCIONAL
Because DataInitializer calls credentialsRepository.deleteAll() on startup and application.yaml sets ddl-auto: create-drop, all data is reset every time the application restarts. Do not use this configuration in a production environment.
The /api/instituciones/** path is configured in SecurityConfig as authenticated() rather than locked to a single role. This means any user with a valid JWT — regardless of their role — can reach the endpoint at the HTTP routing level. Fine-grained permission checks (@PreAuthorize) on individual controller methods then enforce the exact INSTITUCION_* permission required for each operation.
When a controller method is annotated with @PreAuthorize, Spring evaluates the authority set that was populated by JwtAuthenticationFilter at request time:
// Example: only a user whose role carries DONACION_CREAR can call this method@PreAuthorize("hasAuthority('DONACION_CREAR')")@PostMappingpublic ResponseEntity<DonacionResponse> create(@RequestBody DonacionRequest request) { ... }
If the authenticated user does not hold the required authority, Spring Security returns 403 Forbidden before the method body executes.
To extend the system with a new role, add a value to the Roles enum, assign the desired PermitEntity entries to a new RoleEntity in DataInitializer, and create a CredentialsEntity linked to that role. The authority derivation in CredentialsEntity.getAuthorities() handles everything else automatically.