Authorization

When Lamotivo is accessed only by you or your development team, you may need no additional authorization. However, if you provide access to Lamotivo to a large team of users, you may wish to authorize certain requests.

Policies

To limit which users may view, create, update, or delete resources, Lamotivo leverages Laravel's authorization policies.

When manipulating a resource within Lamotivo, Lamotivo will automatically attempt to find a corresponding policy for the model. Typically, these policies will be registered in your application's AuthServiceProvider. If Lamotivo detects a policy has been registered for the model, it will automatically check that policy's relevant authorization methods before performing their respective actions, such as:

• viewAny
• view
• create
• update
• delete
• restore
• forceDelete

Let's see an example:

<?php

namespace App\Policies;

use App\User;
use App\Post;
use Illuminate\Auth\Access\HandlesAuthorization;

class PostPolicy
{
    use HandlesAuthorization;

    /**
     * Determine whether the user can update the post.
     *
     * @param  \App\User  $user
     * @param  \App\Post  $post
     * @return mixed
     */
    public function update(User $user, Post $post)
    {
        return $user->type == 'editor';
    }
}

:::warning Undefined Policy Methods

If a policy exists but is missing a method for a particular action, the user will not be allowed to perform that action. So, if you have defined a policy, don't forget to define all of its relevant authorization methods.

::

Hiding Entire Resources

If you would like to hide an entire Lamotivo resource from a subset of your dashboard's users, you may define a viewAny method on the model's policy class. If no viewAny method is defined for a given policy, Lamotivo will assume that the user can view the resource:

<?php

namespace App\Policies;

use App\User;
use App\Post;
use Illuminate\Auth\Access\HandlesAuthorization;

class PostPolicy
{
    use HandlesAuthorization;

    /**
     * Determine whether the user can view any posts.
     *
     * @param  \App\User  $user
     * @return mixed
     */
    public function viewAny(User $user)
    {
        return in_array('view-posts', $user->permissions);
    }
}

Fields

Sometimes you may want to hide certain fields from a group of users. You may easily accomplish this by chaining the canSee method onto your field definition. The canSee method accepts a Closure which should return true or false:

use Anyspin\Lamotivo\Fields\ID;
use Anyspin\Lamotivo\Fields\Text;

/**
 * Get the fields displayed by the resource.
 *
 * @param  \Illuminate\Http\Request  $request
 * @return array
 */
public function fields(Request $request)
{
    return [
        ID::make(),

        Text::make('name')
            ->canSee(function () {
                return lm()->user()->can('viewProfile', $this);
            }),
    ];
}

In the example above, we are using Laravel's Authorizable trait's can method on our User model to determine if the authorized user is authorized for the viewProfile action. However, since proxying to authorization policy methods is a common use-case for canSee, you may use the canSeeWhen method to achieve the same behavior. The canSeeWhen method has the same method signature as the Illuminate\Foundation\Auth\Access\Authorizable trait's can method:

Text::make('name')
    ->canSeeWhen('viewProfile', $this),

It is worth noting that the canSee and canSeeWhen methods must be the last chaining methods on field's definition. You should apply other field's customization before them.

Models Filtering

To filter models from the resource database query, you may override the getNewQuery method on your resource:

public static function getNewQuery()
{
    return parent::getNewQuery()
        ->where('user_id', lm()->user()->id);
}