This file is the main entrypoint for your rules, it will instantiate Guard and assign the specified types.
The ability file is read top to bottom, the bottom rules take more precedence that the ones at the top.
Take the following example:
Remove all permissions, give them one by one.
Your logic will be more direct and easier to follow, this reduces confusion and potential bugs.
Blitz Guard will allow everything unless you state otherwise. No rules means that everything is allowed.
if guards look similar, take some code out of them
Guard will execute the guard condition if the rule matches the ability and resource. This means that you should, whenever possible, take as much logic out of the rule's guard.
These two methods will determine what a user can or cannot do in your application.
The action that the user can perform.
create, read, update, delete, manage
The subject of the action.
It's the condition for the rule to apply, args are passed down from a wrapped mutation or query or manually when calling Guard.can
async (args) => boolean
With each rule, you can define a reason for it.
While using Guard.can you will receive the result, true/false and the reason.