Skip to main content
The administrador app owns the three models that form the administrative backbone of SIGEP: Evento, ConfiguracionSistema, and AuditoriaLog. Every other app references administrador.Evento as a foreign key for anything event-scoped.

Evento

Represents a single academic event. All other scoped data — ponencias, projects, rubrics, spaces, and inscriptions — references an Evento via a foreign key.

Fields

titulo
string
required
Event title. Max 200 characters.
descripcion
string
required
Full event description. Stored as TextField with no length limit.
fecha
date
required
Event date. Stored as DateField.
lugar
string
required
Venue or location name. Max 150 characters.
cupo
integer
required
Maximum attendance capacity. PositiveIntegerField. Defaults to 0 (unlimited / not yet set).
estado
string
required
Publication state. Defaults to BORRADOR. See choices below.
ValueDisplay label
BORRADORBorrador
PUBLICADOPublicado
CERRADOCerrado
creado_por
ForeignKey → Usuario
The user who created the event. Nullable — set to null when the user is deleted (SET_NULL).
creado_en
datetime
Set automatically on creation (auto_now_add).
actualizado_en
datetime
Updated automatically on every save (auto_now).
Only events with estado = PUBLICADO are visible to speakers and participants. The puede_editar() method on Ponencia and ProyectoParticipante checks this value to gate document uploads.

ConfiguracionSistema

A simple key/value store for platform-wide settings. Use it to hold values that administrators need to change at runtime without a code deployment — for example, registration deadlines, feature flags, or external service URLs.

Fields

clave
string
required
Unique setting key. Max 100 characters. Uniqueness is enforced at the database level.
valor
string
required
Setting value. Max 255 characters. All values are stored as plain strings; cast in application code as needed.
actualizado_en
datetime
Updated automatically on every save (auto_now).
actualizado_por
ForeignKey → Usuario
The user who last changed this setting. Nullable — set to null when the user is deleted (SET_NULL).

AuditoriaLog

An append-only audit table. Every significant action in the platform — including all authentication events — writes a row here. Rows are never updated in place.

Fields

usuario
ForeignKey → Usuario
The authenticated user who performed the action. Nullable — null for anonymous or failed-login events.
accion
string
required
Human-readable action label. Max 255 characters. For auth events the format is AUTENTICACION | LOGIN_EXITOSO, AUTENTICACION | LOGOUT, or AUTENTICACION | LOGIN_FALLIDO | usuario=<identifier>.
modulo
string
App or subsystem that generated the log entry. Max 80 characters. Indexed. Example: AUTENTICACION.
accion_tipo
string
Short action type code. Max 80 characters. Indexed. Example: LOGIN, LOGOUT, LOGIN_FALLIDO.
entidad
string
Name of the affected model or entity. Max 120 characters. Example: Sesion, Evento.
objeto_id
string
Primary key of the affected object as a string. Max 60 characters. May be empty for non-object actions.
resultado
string
required
Outcome of the action. Indexed. Defaults to EXITOSO.
ValueDisplay label
EXITOSOExitoso
FALLIDOFallido
ADVERTENCIAAdvertencia
detalles
object
Arbitrary JSON payload with additional context. Defaults to an empty dict. For auth events, contains path and, for failed logins, identidad.
fecha
datetime
Set automatically on creation (auto_now_add). Indexed descending.
ip_origen
string
Client IP address. Respects the X-Forwarded-For header. Nullable.
user_agent
string
Raw User-Agent string from the request. Truncated to 2000 characters for auth events. Nullable.

Automatic authentication logging

You do not need to write audit entries for authentication events manually. The administrador app connects three Django signals at import time:
Signalaccion_tiporesultado
user_logged_inLOGINEXITOSO
user_logged_outLOGOUTEXITOSO
user_login_failedLOGIN_FALLIDOFALLIDO
Because AuditoriaLog rows are created inside signal handlers that swallow exceptions, a database error during logging will not surface to the user and will not roll back the authentication action. Monitor your database logs separately if audit completeness is critical.

Build docs developers (and LLMs) love