RBAC without magic: 58 atomic permissions in production
In PDP, we built RBAC not around the principle of “admins can do everything,” but through 58 atomic permissions using the `{entity}_{can_view|can_create|can_edit|can_delete}` scheme. Access is restricted by role and by specific objects.
In PDP, we built RBAC where it’s not “admins can do everything,” but 58 atomic permissions using the {entity}_{can_view|can_create|can_edit|can_delete} scheme. Yes, it’s almost like LEGO for access control — except if you assemble it wrong, someone may suddenly see deals that aren’t theirs 🙃
The main point: access is restricted not only by role, but also at the level of individual objects. A user sees only the houses and spaces they’re linked to. So a foreman doesn’t get into deals, and a sales manager doesn’t get into inspectors’ notes.
The most “fun” layer is multi-role overlap: the same person can be an inspector, the person responsible for an issue, and an observer at the same time. At that point it’s no longer “assign a role and forget about it,” but proper engineering. Against the backdrop of the fine-grained access control trend, this is no longer an option, but the baseline for enterprise systems.