This seems like it would be… challenging to store in the DB ![]()
The where syntax could be useful for properties directly attached to the resource (like status and shipped_at), but it would get complicated for properties of related resources. For instance, in a region-based sales system “recently shipped orders in the current user’s district”.
Right here is one of the pain points of trying to design a “generic” authorization system: the result may be a system whose configuration grows in complexity without bound. To balance that, consider establishing a set of “application personas” (see also the “user persona” practice in design); each “application persona” is a detailed description of a system built using RBAC. The example in your organizations branch is a good start at one.
One other thing to consider: designing good data structures is about “what questions should this make easy to ask?”. Consuming the access control (hooking into controllers, or similar mechanism) is important to prototype early.


















