Modelos de Datos (Eloquent)

Este documento condensa los conocimientos y entidades de la capa de datos (app/Models) del sistema GDU, describiendo la responsabilidad primordial de cada Modelo y sus relaciones principales.

🏢 Arquitectura Institucional y Acceso

1. Dependencia
   • Entidad que representa a las áreas operativas, oficinas o secretarías de la Institución.
   • Se relaciona fuertemente con los Expedientes actuando como creador y como poseedor (holder). Puede agrupar a múltiples usuarios y participar de los "pases paralelos" mediante tablas pivote.
2. User
   • Representa al usuario físico/agente que opera el sistema. Utiliza características de Spatie/Permissions (Roles), autenticación de Jetstream, y se encuentra asignado en "caliente" a una dependencia (dependenciaActiva) en la que opera temporalmente.

📁 Núcleo Documental (Expedientes)

1. Expediente
   • Es el corazón y objeto transaccional principal del sistema. Funciona como un agrupador legal de los sucesos.
   • Tiene dos relaciones temporarles críticas: dependencia_id (la originaria que lo creó) y holder_id (El tenedor actual en el flujo lógico, quien lo tiene en "posesión").
2. TipoExpediente
   • Modelo de configuración y lectura. Define de forma maestra la taxonomía (Ej: Acción de Pago, Licitación, Expediente Estándar), sus colores de interfaz, e íconos.
3. ExpedienteManifest
   • Entidad puramente técnica. Modela la cadena de bloques (Blockchain interno) del expediente. Guarda instantáneas versionadas (version, manifest_hash, prev_manifest_hash, state_hash) garantizando integridad legal de manera inmutable tras cada movimiento.
4. DependenciaExpediente
   • Modelo que actúa netamente como Clase Pivote (Pivot) con atributos adicionales (activo, expira) para sostener de forma estructurada el compartir simultáneos paralelo los expedientes.

📑 Solicitudes 

1. Solicitud
   • Predecesora del Expediente. Es el formulario interactivo provisto en la mesa de entrada o self-service. Contiene los datos crudos provistos por el "Causante". Una vez aprobada se convierte en Expediente Oficial mediante la rutina de caratular.

📑Comunicaciones

1. Ccoo
   • Modela una "Comunicación Oficial". Es una entidad de envío de oficios, resoluciones o mensajes entre una dependencia_origen y una dependencia_destino.

📎 Archivos y Adjuntos (Ecosistema Múltiple)

El sistema segrega fuertemente los subidos acorde al ámbito donde se agregaron:

1. Archivoe
   • Archivos y fojas PDF vinculadas directamente a un Expediente Oficializado. Está versionado (hash), auditado, y permite adjuntar firmas.
2. Archivot
   • Archivos transitorios vinculados inicialmente a una Solicitud que aún no es Expediente.
3. ArchivoCcoo
   • Disposición de almacenamiento enfocada a las Comunicaciones Oficiales (Ccoo).
4. Firma
   • Entidad complementaria al Archivoe. Captura los metadatos específicos leídos en un PDF (Nombre del certificado, fecha de validación legal del PKI, validez criptográfica) en un registro verificable.
5. (Nota: File es una clase obsoleta o fallida marcada en el código para deprendimiento futuro)

📡 Herramientas de Sistema

1. Log
   • Modela la traza silenciosa de auditoría interna. Almacena la Acción, qué Usuario/Dependencia interactuó, sobre qué entidad (Solicitud/Expediente) y anexa factores forenses básicos de HTTP (IP, User Agent).
2. Email
   • Réplica de correos institucionales inyectados. Guarda destinatario, remitente y el cuerpo limpio que luego se utiliza interactivamente con el controlador de Inteligencia Artificial de las bandejas integradas.