update inbox list

vendor/spatie/laravel-permission/docs/best-practices/_index.md

@@ -0,0 +1,4 @@
+---
+title: Best Practices
+weight: 2
+---

vendor/spatie/laravel-permission/docs/best-practices/performance.md

@@ -0,0 +1,23 @@
+---
+title: Performance Tips
+weight: 10
+---
+
+Often we think in terms of "roles have permissions" so we lookup a Role, and call `$role->givePermissionTo()` 
+to indicate what users with that role are allowed to do. This is perfectly fine!
+
+And yet, in some situations, particularly if your app is deleting and adding new permissions frequently,
+you may find that things are more performant if you lookup the permission and assign it to the role, like: 
+`$permission->assignRole($role)`.
+The end result is the same, but sometimes it runs quite a lot faster.
+
+Also, because of the way this package enforces some protections for you, on large databases you may find
+that instead of creating permissions with `Permission::create([attributes])` it might be faster to
+`$permission = Permission::make([attributes]); $permission->saveOrFail();`
+
+On small apps, most of the above will be moot, and unnecessary.
+
+As always, if you choose to bypass the provided object methods for adding/removing/syncing roles and permissions 
+by manipulating Role and Permission objects directly in the database,
+you will need to manually reset the cache with the PermissionRegistrar's method for that,
+as described in the Cache section of the docs.

vendor/spatie/laravel-permission/docs/best-practices/roles-vs-permissions.md

@@ -0,0 +1,11 @@
+---
+title: Roles vs Permissions
+weight: 1
+---
+
+It is generally best to code your app around `permissions` only. That way you can always use the native Laravel `@can` and `can()` directives everywhere in your app.
+
+Roles can still be used to group permissions for easy assignment, and you can still use the role-based helper methods if truly necessary. But most app-related logic can usually be best controlled using the `can` methods, which allows Laravel's Gate layer to do all the heavy lifting.
+
+eg: `users` have `roles`, and `roles` have `permissions`, and your app always checks for `permissions`, not `roles`.
+

vendor/spatie/laravel-permission/docs/best-practices/using-policies.md

@@ -0,0 +1,12 @@
+---
+title: Model Policies
+weight: 2
+---
+
+The best way to incorporate access control for application features is with [Laravel's Model Policies](https://laravel.com/docs/authorization#creating-policies).
+
+Using Policies allows you to simplify things by abstracting your "control" rules into one place, where your application logic can be combined with your permission rules.
+
+Jeffrey Way explains the concept simply in the [Laravel 6 Authorization Filters](https://laracasts.com/series/laravel-6-from-scratch/episodes/51) and [policies](https://laracasts.com/series/laravel-6-from-scratch/episodes/63) videos and in other related lessons in that chapter. He also mentions how to set up a super-admin, both in a model policy and globally in your application.
+
+You can find an example of implementing a model policy with this Laravel Permissions package in this demo app: https://github.com/drbyte/spatie-permissions-demo/blob/master/app/Policies/PostPolicy.php