At the risk of making sweeping generalizations, the people who build permission systems tend to be very different from the people who sit at a desk and set permissions for people.<p>Those who build permission systems commonly think very deeply about the process and can hold tremendously complex permission systems in their head. The people who are tasked with setting permissions in the real world tend to view anything else as a more important part of their job to think about and tend to default to either granting permissions broadly so they aren't bothered again or granting permissions minimally so they aren't blamed for things.<p>A small number of well designed and well named roles is unfortunately commonly better in practice than a highly powerful and flexible fully configurable turing complete granular permissions management system.
The reasoning about only allowing additive permission is something I've had pretty strong opinions, and it's nice to see that other people agree with this. Permissions gets incredibly complicated very fast even in the best case, and any additional complexity can easily confuse users.<p>Their use case feels a bit too micro-managed for my taste, but that is certainly a matter of opinion. And if their customers demand this, it's hard to convince them otherwise. My preference is to handle certain more subtle cases like their "only DNA design team can edit sequences, but Research team can edit metadata" as a convention, not a hard rule enforced by the application. And if you have a good history of changes, it still allows for transparency about who edited what.
Interesting article and really close to what we’ll need to do at my company soon!<p>I wonder if there are any open-source projects that operate in this realm and provide an off the shelf solution to this.<p>I’m thinking that it could be something like a small server to store the policies and a few libs in various languages to interpret them.<p>This could or could not be tied to a user management system.