Add checkAbility method to Field classes for streamlined permission checks

[savosik]

Feature Description

I propose adding a checkAbility method to all Field classes in MoonShine. This method would provide a convenient way to check permissions directly on fields, integrating smoothly with Laravel's authorization system and MoonShine's resource structure.

Use Case

When defining fields in a resource, developers often need to check if a user has permission to view or interact with a specific field. Currently, this requires using the canSee method with a closure that performs a manual check. A dedicated checkAbility method would simplify this process and make the code more readable and maintainable.

Proposed Implementation

Add a checkAbility method to the base Field class:

public function checkAbility(string $ability): self
{
    return $this->canSee(function () use ($ability) {
        $user = auth()->user();
        $resource = moonshineRequest()->getResource();
        $item = $resource ? $resource->getItem() : null;
        $model = $item ?? ($resource ? $resource->getModel() : null);

        if (!$user || !$resource) {
            return false;
        }

        if (Gate::getPolicyFor($model) && method_exists(Gate::getPolicyFor($model), $ability)) {
            return Gate::forUser($user)->allows($ability, [$resource, $item]);
        }

        return true;
    });
}

Example Usage

This would allow for more intuitive and concise field definitions in resources:

public function fields(): array
{
    return [
        Text::make('Name')
            ->sortable()
            ->checkAbility('view'),
        Number::make('Price')
            ->sortable()
            ->checkAbility('managePrice'),
        CommonFields::active()
            ->sortable()
            ->checkAbility('update'),
    ];
}

Benefits

• Improved readability and maintainability of resource definitions.
• Consistent approach to permission checks across all fields.
• Tighter integration between MoonShine fields and Laravel's authorization system.
• Reduces boilerplate code in resource classes.

[lee-to]

I like your idea, but the thing is that in version 3 the Field themselves will not know about Laravel and therefore they will not have access to the Gate inside, in order not to complicate it can be done through a macro, the fields now have a Macroable trait! What do you think about this? You could even organize a package

But in general we can implement it abstractly in version 3.

In general, we need to think about this, but the idea is excellent.