A hybrid Odoo 16 + Django platform managing Indigenous student scholarships, enrollment, billing and document handling. Two stacks on one Postgres database, with documents in S3 behind short-lived presigned download URLs.
Avataq is a hybrid Odoo 16 + Django platform for managing Indigenous student scholarships, enrollment and document handling. Odoo holds the business logic — students, schools, sessions, scholar years, enrollment records, computing sheets for billing, reconciliation. A separate Django application serves the document explorer side: read-only access to uploaded scholarship documents with sixty-second presigned S3 download URLs, gated by role.
We built it end-to-end. Two applications sharing a single PostgreSQL database and communicating via REST. Documents live in AWS S3 under deterministic keys (`{status_no}/{scholar_year}/{slug}.{ext}`) so the key encodes context. Credentials live in `ir.config_parameter`, not in code. An `AvataqDocumentS3Sync` abstract mixin gives any Odoo model uploading capability for free; an `index_document` endpoint on the Django side upserts the index from an `X-API-Key`-gated POST.
Splitting the document explorer out of Odoo wasn't accidental. Odoo is great at modelling the business — students, sessions, computing sheets, reconciliation. It's less great at being a fast, focused viewer for thousands of binary records with per-role access. So the explorer lives in Django, reads the same database, asks S3 for short-lived presigned URLs, and never holds the documents in memory.
We've been on this platform since early 2023. The cadence is steady — new flows as the scholarship workflows expand, document-flow refinements as the cohort grows, S3 backups running nightly.
Main Odoo addon — students, inscriptions, sessions, schools, computing sheets, reconciliation, mail templates, S3 document upload, Django sync.
Public portal and website templates.
Auth and signup customisation.
Scheduled S3 database backups.
Read-only viewer over the same Postgres. Permission-gated by `documents.can_view_documents`. Mints presigned S3 URLs on demand.
Abstract Odoo mixin — drop the inherit, get S3 upload + Django index notification for free. Used across three uploader models.
Odoo POSTs document metadata to Django `/api/index/` after every successful upload, gated by `X-API-Key`. Django upserts the index row; never writes back.
docker-compose for db / odoo / django; shared `avataq_env` conda env across both stacks; one `deploy.sh` for production rollouts.
Splitting the document explorer out of Odoo wasn't accidental. Odoo is great at modelling the business; less great at being a fast, focused binary viewer with per-role access. So the explorer lives in Django, reads the same Postgres, asks S3 for short-lived presigned URLs, and never holds the documents in memory.
Three Odoo models needed S3 upload behaviour with the same conventions. We wrote `AvataqDocumentS3Sync` as an abstract mixin — drop the inherit, get key generation, S3 upload and Django-side index notification for free. New uploaders are a one-line inherit.
Everything sensitive lives in `ir.config_parameter`: the S3 bucket, region, access key, secret key, Django API URL and API key. No deploy-time substitution, no committed secrets, no surprise when an environment is missing a key.
Uploaded documents go straight to S3 with a deterministic key. Odoo never holds them after the upload finishes. Authenticated Django users get a sixty-second presigned URL when they request a download — long enough to click, short enough to never get shared usefully.
Three Odoo models needed identical S3-upload behaviour. We wrote one abstract mixin: the inheritor declares its files, the mixin handles key generation, S3 upload, and a POST to the Django `/api/index/` endpoint with `X-API-Key`. New uploaders cost a one-line inherit.
Odoo is the writer; Django is the indexer. After every successful S3 upload, Odoo POSTs metadata (student_reference, scholar_year, s3_key, filename) to Django's `/api/index/` endpoint, gated by an `X-API-Key` header. Django upserts a `DocumentIndex` row. The Django side never writes to S3 or to Odoo's tables.
Document downloads go through Django, which mints a 60-second presigned S3 URL on demand. Long enough to click, short enough that a shared URL is dead by the time it could be misused. No long-lived public links.
Object keys encode their context: `{status_no}/{scholar_year}/{slug}.{ext}`. Two operations come for free: per-cohort listing is just an S3 prefix scan, and migrating documents between environments is a key-renaming exercise rather than a metadata join.