rasulboboev111-dotcom/docuflowversion2

Purpose and Runtime

DocuFlow is a Django-based electronic document-management system for creating, editing, approving, signing, archiving, and verifying documents. It runs as a server-rendered web application with HTMX/Alpine-enhanced UI, PostgreSQL persistence, MinIO/S3 file storage, and OnlyOffice browser editing.

Primary Django entry points are manage.py, config/settings.py, config/urls.py, and deployment composition in docker-compose.yml / Dockerfile.

Application Routing and UI Boundary

The Django project routes requests into three domain apps: core administration and audit, document workflow, and reference registries. Server views render templates; HTMX partial templates support live filtering/table refreshes rather than a separate SPA API.

Key paths: config/urls.py, core/urls.py, documents/urls.py, registry/urls.py, templates/base.html.

Identity, Roles, and Audit

core owns users, role/permission evolution, administrative user management, dashboards, reporting, monitoring, and audit visibility. Role-based access is a control boundary for document actions and registry/audit access; signals likely record cross-cutting lifecycle events.

Key paths: core/models.py, core/views.py, core/signals.py, templates/core/audit_list.html.

Document Domain and Approval Workflow

documents is the system’s central domain. Its models define documents, templates/registries, version history, status, priority, sender, UUID, and content hash evolution. Views and forms handle create/edit/detail/list/archive flows, while services centralize document processing.

The intended control flow is a five-stage approval sequence: Равзанаи ягона → Муҳандис → Мудир → Муовин → Директор. Approval state gates progression and finalization.

Key paths: documents/models.py, documents/views.py, documents/services.py, templates/documents/document_detail.html.

File Storage, Integrity, and Archive

Document binaries are stored externally in MinIO via its S3-compatible interface, while PostgreSQL stores document metadata and workflow state. UUID and hash migrations indicate durable document identity and integrity verification. Archive presentation is a first-class lifecycle state, not merely deleted content.

Key paths: documents/models.py, documents/migrations/0004_document_uuid.py, documents/migrations/0006_add_document_hash.py, templates/documents/archive_list.html.

OnlyOffice Editing and Visual Signing

OnlyOffice integration is isolated in document-specific views and local editor configuration. Browser editing/preview flows bridge Django document records to an OnlyOffice Document Server. Signing produces role-specific visual marks: QR codes for the Director and stamps for other approvers; static OnlyOffice QR plugin assets support editor-side functionality.

Key paths: documents/views_onlyoffice.py, config/onlyoffice_local.json, static/onlyoffice/plugins/qr_code/plugin.js, templates/documents/sign_document.html.

Registry Subsystem

registry is a separate reference-data domain, currently centered on mobile-phone records and import/list/edit UI. It is permission-controlled independently enough to have dedicated migration changes and routes, and can support document-related lookup/registry workflows without coupling its models into document views.

Key paths: registry/models.py, registry/views.py, registry/urls.py, templates/registry/phone_list.html.

Infrastructure and Operations

Docker Compose coordinates the application and its required service dependencies, notably PostgreSQL, MinIO, and OnlyOffice. Django provides ASGI and WSGI entry points for production server selection. Seed commands provide initial users and documents for bootstrap environments.

Key paths: docker-compose.yml, config/asgi.py, config/wsgi.py, core/management/commands/seed_users.py, documents/management/commands/seed_docs.py.