Enterprise · Enterprise operations
Trident Ops Portal
A permissions model complex enough that it had to be built test-first.
- Role
- Backend engineer
- Duration
- 9 months
- Team
- 3 from our side
- Sector
- Enterprise operations
The situation
A project and operations platform where what you can see and do depends on your role, your customer, and the specific project — three dimensions that interact rather than nest.
We owned the Django and DRF layer: the data model, the permission logic, and the API the React front end consumes.
The problem
Permission rules of this shape are where enterprise platforms quietly break. A change to one role leaks access to another, and nobody notices until a customer sees a project that was never theirs.
Manual QA cannot cover the combinations. The matrix of role × customer × project is far too large to click through before every release.
What we built
- 01
The permission model as data
Customer, permission, and role-permission as first-class models rather than conditionals scattered through views. One place to read, one place to change.
- 02
Unit coverage on every model and endpoint
Written alongside the logic, not after it. Each role-permission pairing has a test that asserts both what it grants and what it must refuse.
- 03
A DRF layer with permissions at the edge
Authorization decided in one enforcement point, so a new endpoint inherits the rules instead of reimplementing them.
- 04
Boto3 integrations for the operational side
Document storage and asynchronous jobs on AWS, wired so a failed integration degrades one feature rather than the portal.
The outcome
Unit coverage on every model and endpoint, so permission changes ship without regression across roles.
Changing what a role can do became a normal pull request with a test proving nothing else moved — rather than a release everyone held their breath through.