Update Docs

Author: santigarcor

docs/conf.py

@@ -57,9 +57,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = u'3.1.0'
+version = u'3.2.0'
 # The full version, including alpha/beta/rc tags.
-release = u'3.1.0'
+release = u'3.2.0'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

docs/configuration/after_installation.rst

@@ -6,6 +6,8 @@ Configuration Files
 
 Laratrust now allows mutliple user models, so in order to configure it correctly, you must change the values inside the ``config/laratrust.php`` file.
 
+.. _multiple-user-models:
+
 Multiple User Models
 --------------------
 

docs/upgrade.rst

@@ -1,22 +1,28 @@
-Upgrade from 3.0 to 3.1
+Upgrade from 3.1 to 3.2
 =======================
 
-In order to upgrade from Laratrust 3.0 to 3.1 you have to follow these steps:
+In order to upgrade from Laratrust 3.1 to 3.2 you have to follow these steps:
 
-1. Change your ``composer.json`` to require the 3.1 version of laratrust::
+1. Change your ``composer.json`` to require the 3.2 version of laratrust::
     
-    "santigarcor/laratrust": "3.1.*"
+    "santigarcor/laratrust": "3.2.*"
 
 2. Run ``composer update`` to update the source code.
 
-3. Add in your ``config/laratrust.php`` file this line::
+3. Add in your ``config/laratrust.php`` file this block:
 
-    'permission_user_table' => 'permission_user',
+   .. code-block:: php
 
-4. Run ``php artisan laratrust:upgrade`` to create the migration with the database upgrade.
+        'user_models' => [
+            'users' => 'App\User',
+        ],
 
-5. Run ``php artisan migrate`` to apply the migration created in the previous step.
+   And configure it with you user models information according to the new :ref:`multiple-user-models` explanation.
 
-6. If you use the ``savePermissions`` method in your code, change it to ``syncPermissions``.
+4. Run ``php artisan laratrust:add-trait`` to add the ``LaratrustUserTrait`` to the user models.
 
-Now you can use the 3.1 version without any problem.
+5. Run ``php artisan laratrust:upgrade`` to create the migration with the database upgrade.
+
+6. Run ``php artisan migrate`` to apply the migration created in the previous step.
+
+Now you can use the 3.2 version without any problem.

docs/usage/concepts.rst

@@ -139,22 +139,19 @@ Now we can check for roles and permissions simply by doing:
    $user->hasRole('admin');   // true
    $user->can('edit-user');   // false
    $user->can('create-post'); // true
-   $user->hasPermission('create-post'); // true
-   $user->isAbleTo('create-post'); // true
 
 .. NOTE::
-   The ``can``, ``hasPermission`` and ``isAbleTo`` methods have the same objective, to check user's permissions.
+   If you want, you can use the ``hasPermission`` and ``isAbleTo`` methods instead of the ``can`` method.
 
-   Inside Laratrust code the ``hasPermission`` method is used intead of the ``can`` method, so if you want to use the Authorizable trait you can use it without any problem (if you didn't use the Laratrust can method). To use the Authorizable trait check :ref:`troubleshooting`.
+.. NOTE::
+   If you want to use the Authorizable trait alongside Laratrust please check :ref:`troubleshooting`.
 
-Both ``hasRole()``, ``can()``, ``hasPermission()``, ``isAbleTo()`` can receive an array of roles & permissions to check:
+Both ``hasRole()`` and ``can()`` can receive an array of roles & permissions to check:
 
 .. code-block:: php
 
    $user->hasRole(['owner', 'admin']);       // true
    $user->can(['edit-user', 'create-post']); // true
-   $user->hasPermission(['edit-user', 'create-post']); // true
-   $user->isAbleTo(['edit-user', 'create-post']); // true
 
 By default, if any of the roles or permissions are present for a user then the method will return true.
 Passing ``true`` as a second parameter instructs the method to require **all** of the items:
@@ -165,8 +162,6 @@ Passing ``true`` as a second parameter instructs the method to require **all** o
    $user->hasRole(['owner', 'admin'], true);       // false, user does not have admin role
    $user->can(['edit-user', 'create-post']);       // true
    $user->can(['edit-user', 'create-post'], true); // false, user does not have edit-user permission
-   $user->hasPermission(['edit-user', 'create-post'], true); // false, user does not have edit-user permission
-   $user->isAbleTo(['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.
 
@@ -180,7 +175,10 @@ The ``Laratrust`` class has shortcuts to both ``can()`` and ``hasRole()`` for th
    // is identical to
 
    Auth::user()->hasRole('role-name');
-   Auth::user()->can('permission-name');
+   Auth::user()->hasPermission('permission-name');
+
+.. 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 placeholders (wildcards) to check any matching permission by doing: