ivansosabz/legajos-de-funcionarios

1. Purpose and Runtime

This is a server-rendered Django system for managing public-employee personnel files (“legajos”): employee records, associated documents, evaluations, and labor events. It runs on Python/Django through the development entry point manage.py; deployment adapters are legajosdefuncionarios/wsgi.py and legajosdefuncionarios/asgi.py.

2. Project Composition and Routing

The Django project package centralizes settings and top-level URL composition:

• legajosdefuncionarios/settings.py

• legajosdefuncionarios/urls.py

• legajosdefuncionarios/views.py

Feature apps expose their own URL/view boundaries, then render HTML templates rather than providing a separate API. Request flow is: browser → project/app URL routing → view → form/model persistence → template response.

3. Employee Records as the Core Domain

funcionarios is the central personnel-record app and likely the parent entity for the other business domains. It owns employee persistence, input validation, CRUD request handling, and views/templates:

• funcionarios/models.py

• funcionarios/forms.py

• funcionarios/views.py

Its schema originates in funcionarios/migrations/0001_initial.py. Other modules’ migration names explicitly reference funcionario, indicating that evaluations, documents, and events are associated with an employee record.

4. Personnel File Documents

documentos manages digitized documents connected to personnel files, including a separate document-type management area. The app has model/form/view layers and templates for document CRUD and type CRUD:

• documentos/models.py

• documentos/views.py

• templates/documentos/tipos/index.html

Document state evolved through documentos/migrations/0002_alter_documentofuncionario_estado.py, making document status a meaningful lifecycle boundary. Storage implementation is not evident from the supplied tree; do not assume local media, object storage, or external document services.

5. Evaluations and Employment Events

Two independent employee-associated domains capture time-based HR history:

• Performance/employee evaluations: evaluaciones/models.py, evaluaciones/forms.py, evaluaciones/views.py

• Labor events: eventoslaborales/models.py, eventoslaborales/forms.py, eventoslaborales/views.py

Both follow server-side CRUD flows with list/create/edit/delete templates. Event migrations show employee linkage and end-date handling are part of the modeled lifecycle: eventoslaborales/migrations/0002_rename_funcionario_eventolaboral_id_funcionario_and_more.py and eventoslaborales/migrations/0003_alter_eventolaboral_fecha_fin.py.

6. Identity and Access Boundary

usuarios isolates user/account concerns from personnel records:

• usuarios/models.py

• usuarios/forms.py

• usuarios/views.py

It has its own routing and a login template at templates/usuarios/login.html. The README claims role-based access control, but the available tree alone does not establish the exact authorization model, permissions, or whether Django’s built-in auth is extended.

7. Persistence, UI, and External Dependencies

Django migrations are the database contract across each domain app; development uses SQLite and production is intended to use PostgreSQL per README. Dependencies are declared in requirements.txt. The presentation layer is Django templates organized by app, composed through templates/layouts/base.html, with static CSS/JavaScript under static/. Bootstrap 5 is the stated UI framework. No queue, cache, API gateway, cloud provider, or third-party SaaS integration is evidenced in the repository tree.