The fact that its intuitive doesn't take away how powerful it is to handle very complex and frequently used permission scenarios in different types of projects .
Why Almost everything we do in computing these days needs permissions . There are hundreds of permission/access control systems and methods, many of them are not intuitive .
I wanted to create a system that would cover most popular use cases, where you can get started in minutes, whether you are a novice or very experienced programmer, yet still powerful enough to handle complex permissions .
I took inspiration from the linux permission system e.g rwxr--r-x, but took it some steps further and made it more intuitive
I wanted to be able to handle permissions/access control in a SaaS (or any application), with multiple access levels and users
I wanted to be able to control access for actions including Create, Read, Update, Delete, Execute (remember CRUDE - more on this later), I wanted to be able to control how much of each of those actions can be carried out by each user, and how frequently within a specific period of time they can carry out those actions .
I wanted to create a permission/access control system with no dependencies, except the go standard library
I wanted to enjoy writing and reading permissions/access control
I wanted to be able to write extremely complex permissions/access control for a user/org/entity on a single line
I did not want to have to write complex DB queries to verify permission and resource usage, which can get very tedious as an application gets more complex.
Features Ability to set create, read, update , delete, execute (CRUDE) operations permissions Ability to control start and end time for permissions Ability to set quota limit (Quota is how many of a certain resource can exist at any given time) Ability to set batch limit Ability to set time based limits (all time , per minute, per hour, per day, per week, per fortnight, per month, per quarter, per year, custom time duration [in progress] ) Ability to verify permission against usage (you would need to store usage in your preferred DB ) Ability to verify permissions based on entity i.e (user, role, group, domain, organisation) Ability to set entity permission order (the flow/order in which the permission should be checked e.g org->domain->group->role->user)