Mineral tracker
A Django system for mineral stock and transport, built around four roles that each see a different slice of the same data.
- Role
- Engineering
- Built with
- Django, Python, PostgreSQL, django-allauth
A management system for mineral stock and its movement, what is held, what is moving, and who signed for it.
The records in these screenshots are sample data, entered to exercise the dashboards. They are not real trading figures.
Roles are the design
The system defines four roles, administrator, operations manager, financial manager and store keeper, and they are the organising idea rather than a permissions afterthought. Each role opens onto a different part of the same records, which is what separates a tool that a warehouse actually uses from a CRUD interface with everything visible to everyone.
Login is required globally: anonymous requests redirect to the sign-in page rather than falling
through to a public view, so there is no route that quietly leaks a record. Sign-in runs through
django-allauth, with Google as an option, because the alternative is asking a store keeper to
remember one more password.
What that separation looks like in practice: the financial manager opens onto money, and the store keeper opens onto stock. Neither screen is a filtered version of the other.
Tax is computed rather than typed: the rate is a setting, and the dashboard derives government tax and net profit from the inflows and outflows already recorded, so the figure cannot drift from the payments it is drawn from.
Notes
- Postgres first, reading
DATABASE_URL, with a SQLite fallback so the project runs from a clean clone. - A
setup_rolesmanagement command creates the role groups, so the permission model is reproducible rather than clicked together in the admin once and forgotten. - No GDAL anywhere, a deliberate choice, and anyone who has tried to deploy a Django app with a geospatial dependency on a small host will know why.