Docs update

README.md

@@ -23,15 +23,16 @@ To install, configure and learn how to use Laratrust please go to the [Documenta
 - Objects ownership verification.
 - Multiple roles and permissions can be attached to users within teams.
 
-### Note
-This is a fork of Zizaco's [original code](https://github.com/Zizaco/entrust).
-
-Please note that this fork is not used on Zizaco's page at this time, nor is it maintained or contributed to by him.
-
 ## License
 
 Laratrust is open-sourced software licensed under the [MIT license](http://opensource.org/licenses/MIT).
 
 ## Contributing
 
 Please report any issue you find in the issues page. Pull requests are more than welcome.
+
+## Note
+
+This is a fork of Zizaco's [original code](https://github.com/Zizaco/entrust).
+
+Please note that this fork is not used on Zizaco's page at this time, nor is it maintained or contributed to by him.

docs/configuration/models/role.rst

@@ -19,7 +19,7 @@ The ``Role`` model has three main attributes:
 
 * ``name`` — Unique name for the Role, used for looking up role information in the application layer. For example: "admin", "owner", "employee".
 * ``display_name`` — Human readable name for the Role. Not necessarily unique and optional. For example: "User Administrator", "Project Owner", "Widget  Co. Employee".
-* ``description`` — A more detailed explanation of what the Role does. Also optional.
+* ``description`` — A more detailed explanation of what the Role does. Also, optional.
 
 Both ``display_name`` and ``description`` are optional; their fields are nullable in the database.
 

docs/configuration/models/team.rst

@@ -22,7 +22,7 @@ The ``Team`` model has three main attributes:
 
 * ``name`` — Unique name for the Team, used for looking up team information in the application layer. For example: "my-team", "my-company".
 * ``display_name`` — Human readable name for the Team. Not necessarily unique and optional. For example: "My Team", "My Company".
-* ``description`` — A more detailed explanation of what the Team does. Also optional.
+* ``description`` — A more detailed explanation of what the Team does. Also, optional.
 
 Both ``display_name`` and ``description`` are optional; their fields are nullable in the database.
 

docs/configuration/seeder.rst

@@ -1,13 +1,13 @@
 Seeder
 ======
 
-Laratrust comes with a database seeder, this seeder helps you filling the permissions for each role depending on the module, and creates one user for each role.
+Laratrust comes with a database seeder, this seeder helps you fill the permissions for each role depending on the module, and creates one user for each role.
 
 .. NOTE::
     Laratrust now accepts multiple user models so the seeder is going to work with the first user model inside the user_models array.
 
 .. NOTE::
-    Laratrust now accepts has a teams feature, the seeder doesn't support it.
+    Laratrust now has teams feature, the seeder doesn't support it.
 
 To generate the seeder you have to run::
 

docs/index.rst

@@ -14,7 +14,7 @@ Laratrust Docs
 Table of Contents:
 ==================
 .. NOTE::
-    Please read all the sections in order
+    Please read all the sections in order.
 
 .. toctree::
 

docs/upgrade.rst

@@ -6,7 +6,7 @@ Upgrade from 3.3 to 4.0
 
 In order to upgrade from Laratrust 3.3 to 4.0 you have to follow these steps:
 
-1. Change your ``composer.json`` to require the 4.0 version of laratrust::
+1. Change your ``composer.json`` to require the 4.0 version of Laratrust::
 
     "santigarcor/laratrust": "4.0.*"
 
@@ -23,7 +23,7 @@ In order to upgrade from Laratrust 3.3 to 4.0 you have to follow these steps:
     3.4. Update the ``config/laratrust.php`` file with your old values.
 
     .. NOTE::
-        Leave the ``use_teams`` key in false during the upgrade proccess.
+        Leave the ``use_teams`` key in false during the upgrade process.
 
 4. If you use any values of the ``config/laratrust.php`` in your application code, update those values with the new file structure.
 

docs/usage/concepts.rst

@@ -101,7 +101,7 @@ Removal
 User Permissions Assignment & Removal
 -------------------------------------
 
-You can attach single permissions to an user, so in order to do it you only have to make:
+You can attach single permissions to a user, so in order to do it you only have to make:
 
 Assignment
 ^^^^^^^^^^
@@ -166,7 +166,7 @@ Passing ``true`` as a second parameter instructs the method to require **all** o
    $user->can(['edit-user', 'create-post']);       // true
    $user->can(['edit-user', 'create-post'], true); // false, user does not have edit-user permission
 
-You can have as many \ ``Role``\s as you want for each ``User`` and vice versa. Also you can have as many direct \ ``Permissions``\s as you want for each ``User`` and vice versa.
+You can have as many \ ``Role``\s as you want for each ``User`` and vice versa. Also, you can have as many direct \ ``Permissions``\s as you want for each ``User`` and vice versa.
 
 The ``Laratrust`` class has shortcuts to both ``can()`` and ``hasRole()`` for the currently logged in user:
 
@@ -183,7 +183,7 @@ The ``Laratrust`` class has shortcuts to both ``can()`` and ``hasRole()`` for th
 .. WARNING::
    There aren't  ``Laratrust::hasPermission`` or ``Laratrust::isAbleTo`` facade methods, because you can use the ``Laratrust::can`` even when using the ``Authorizable`` trait.
 
-You can also use wildcards to check any matching permission by doing:
+You can also use wildcard to check any matching permission by doing:
 
 .. code-block:: php
 
@@ -196,7 +196,7 @@ You can also use wildcards to check any matching permission by doing:
 Magic can method
 ^^^^^^^^^^^^^^^^
 
-You can check if an user has some permissions by using the magic can method:
+You can check if a user has some permissions by using the magic can method:
 
 .. code-block:: php
 
@@ -337,7 +337,7 @@ If you want to retrieve the users that have some role you can use the query scop
    // This will return the users with 'admin' role.
    $users = User::whereRoleIs('admin')->get();
 
-Also if you want to retrieve the users that have some permission you can use the query scope ``wherePermissionIs``:
+Also, if you want to retrieve the users that have some permission you can use the query scope ``wherePermissionIs``:
 
 .. code-block:: php
 
@@ -374,12 +374,12 @@ If you want to change the foreign key name to check for, you can pass a second a
 Permissions, Roles & Ownership Checks
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If you want to check if an user can do something or has a role, and also is the owner of an object you can use the ``canAndOwns`` and ``hasRoleAndOwns`` methods:
+If you want to check if a user can do something or has a role, and also is the owner of an object you can use the ``canAndOwns`` and ``hasRoleAndOwns`` methods:
 
 Both methods accept three parameters:
 
 * ``permission`` or ``role`` are the permission or role to check (This can be an array of roles or permissions).
-* ``thing`` is the object used to check the ownership .
+* ``thing`` is the object used to check the ownership.
 * ``options`` is a set of options to change the method behavior (optional).
 
 The third parameter is an options array:
@@ -446,7 +446,7 @@ And then in your code you can simply do:
    
    $user = User::find(1);
    $theObject = new SomeOwnedObject;
-   $user->owns($theObject);            // This will return true or false depending of what the ownerKey method returns
+   $user->owns($theObject);            // This will return true or false depending on what the ownerKey method returns
 
 .. _teams-concepts:
 

docs/usage/soft_deleting.rst

@@ -1,7 +1,9 @@
 Soft Deleting
 =============
 
-The default migration takes advantage of ``onDelete('cascade')`` clauses within the pivot tables to remove relations when a parent record is deleted. If for some reason you can not use cascading deletes in your database, the LaratrustRole and LaratrustPermission classes, and the HasRole trait include event listeners to manually delete records in relevant pivot tables. In the interest of not accidentally deleting data, the event listeners will **not** delete pivot data if the model uses soft deleting. However, due to limitations in Laravel's event listeners, there is no way to distinguish between a call to ``delete()`` versus a call to ``forceDelete()``. For this reason, **before you force delete a model, you must manually delete any of the relationship data** (unless your pivot tables uses cascading deletes). For example:
+The default migration takes advantage of ``onDelete('cascade')`` clauses within the pivot tables to remove relations when a parent record is deleted. If for some reason you can not use cascading deletes in your database, the LaratrustRole and LaratrustPermission classes, and the HasRole trait include event listeners to manually delete records in relevant pivot tables.
+
+In the interest of not accidentally deleting data, the event listeners will **not** delete pivot data if the model uses soft deleting. However, due to limitations in Laravel's event listeners, there is no way to distinguish between a call to ``delete()`` versus a call to ``forceDelete()``. For this reason, **before you force delete a model, you must manually delete any of the relationship data** (unless your pivot tables uses cascading deletes). For example:
 
 .. code-block:: php