Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Дмитрий, чтобы пользоваться одним методом, где доступен заказ, чтобы изменять потом в одном месте, а не в нескольких.
Но я Вас услышал, возможно, вы и правы. Попробую переделать, если это возможно, т. к. не хочется писать каждый раз:

in_array($order->status, [Order::NEW, Order::WORK]);

И еще понял, параметры, похоже, не нужно передавать в полиси, можно же их вытащить из request()

Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Дмитрий, в общем, получилось так (сложно):

public function authorize()
    {
        return $this->user()->can('update', [
            $this->order,
            [
                'user_id' => $this->user_id,
                'table_id' => $this->table_id,
                'total_person' => $this->total_person,
                'status' => $this->status,
            ]
        ]);
    }

    public function update(User $user, Order $order, array $params = [])
    {
        if ($user->isEmployee()) {
            # employee нельзя обновлять заказ другого пользователя
            # employee должен назначить заказ сначала на себя
            if ($user->id !== $order->user_id && $user->id != $params['user_id']) {
                return false;
            }
        }

        if ($user->isAdmin()) {
            # admin может изменять заказы только у себя или у employee
            if (!$order->user?->isEmployee() || $user->id !== $order->user_id) {
                return false;
            }
        }

        if (isset($params['table_id']) || isset($params['user_id']) || isset($params['total_person'])) {
            return $order->canUpdate();
        }

        if (isset($params['status'])) {
            return $order->canUpdate('status');
        }
    }

Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Дмитрий, спасибо большое.
Главное - правильно составить вопрос, у меня не получилось, к сожалению.

Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Дмитрий, этот кейс, получается, не обыграть в policy, к сожалению

$this->user()->id != $this->user_id // это входной параметр на изменение

Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Дмитрий, очень интересные практики подсказали.
Попробую вынести в полиси.
Я просто полиси пользуюсь только для роутинга, видимо - нужно расширить представление

Route::controller(\App\Http\Controllers\Admin\EmployeeController::class)->prefix('/employees')->group(function() {
                Route::get('/', 'getAll')->can('getEmployees', 'project');

                Route::get('/{user}', 'show')->can('getEmployee', 'project');
                Route::delete('/{user}', 'destroy')->can('deleteEmployee', 'project');
            });

Не твой заказ - иди нахрен.

Тут немного сложнее логика.
Если ты Админ, то изменять заказ возможно.
А для обычного сотрудника можно еще и изменять поле user_id - это назначить на себя.

Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Очень интересно, благодарю.

if ($this->user()->isEmployee()) {
            # employee нельзя обновлять заказ другого пользователя
            # employee должен назначить заказ сначала на себя, чтобы потом обновлять
            if ($this->user()->id !== $this->order->user_id && $this->user()->id != $this->user_id) {
                return false;
            }
        }

Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Дмитрий, не очень понял, что и где?
Вызов метод модели в реквесте?

Как ограничить или оптимизировать доступ к валидации параметров на laravel в request?

Дмитрий, модель

Можно ли без pivot модели влиять на возвращаемые значения полей?

Дмитрий, спасибо большое

Можно ли без pivot модели влиять на возвращаемые значения полей?

Дмитрий, а relation останется без изменений, если создать pivot model?

// order model
    public function dishes()
    {
        # Требует название таблицы dishe_order, поэтому прописываем явно
        # Добавление в ответ полей из связанной таблицы order_dishe
        return $this->belongsToMany(Dishe::class, 'order_dishe')
            ->withPivot(['id', 'price', 'quantity', 'comment', 'paid_back_at'])
            ->orderByPivot('id', 'desc')
            ->withTimestamps();
    }

Можно ли без pivot модели влиять на возвращаемые значения полей?

Дмитрий, под костылями имел ввиду преобразования вручную, например в resource

Как проверить history в react-router-dom (v5) на пустоту?

Артем, очень подробно, спасибо большое!!!

Как проверить history в react-router-dom (v5) на пустоту?

спасибо большое!
Но length, как я понял не сбрасывается при обновлении страницы, верно?
Если только самый-самый первый раз зашел? (у меня оно при полном обновлении страницы равно 50+)

Как проверить history в react-router-dom (v5) на пустоту?

szQocks, обновил, что нужен v5

Как на laravel проверить, что тебе пришло null?

Через замыкание видел - да, благодарю.
Без него, получается, никак?

Как правильно спроектировать тарифные планы?

maksam07, потому что связь многие ко многим, и в таблице должен быть один активный тариф.

И есть кейс, например, идёт переход на один тариф, он действует до конца года, но через месяц я решаю перейти на другой, первый я отключаю - active = 0, перехожу на другой.
Но в течение этого года я могу вернуться на первый тариф и он будет действовать до конца года.

Как правильно спроектировать тарифные планы?

maksam07,

1. Отключать тариф по крону в 00 00 00 у всех, у кого valid_till просрочился
2. Отключать тариф только при: переходе на другой или продление нового

Под отключением я подразумеваю active = 0.
А если active = 1, а valid_till просрочена, тариф в этом случае носит только информативный характер (для админки).
Такого кейса не может быть в том, что предлагает мой ментор.
Но чтобы отобразить на фронте, что тариф закончился, приходится возвращать последний активный тариф.

Как правильно спроектировать тарифные планы?

maksam07, он не совсем работает.
в первом варианте (от ментора), достаточно проверить active - это будет говорить о том, что тариф и просрочен в том числе или, наоборот, не просрочен.
Но есть микро-проблема, о которой я писал выше.
Плюс, я не могу вернуть на фронт текущий тариф (уже просроченный), не на что опереться.
Приходится извращаться и возвращать отдельным полем, если не подключен тариф, то возвращаем последний отключенный:

public function lastTariff() {
        return $this->hasOne(ProjectTariff::class)->NotActive()->orderBy('id', 'desc');
    }

А в моем случае проверяется два поля - active и valid_till.
Например, у нас есть админка и публичная часть.
В админке я владельцу возвращаю его просроченный тариф, т. к. active = 1 (в случае 1 варианта, мне уже не вернуть последний тариф без дополнительных манипуляций - а-ля - получить последний активный тариф).
А в публичной части для всех пользователей закрываю доступ, т. к. valid_till просрочена.

public function scopeActiveNow($query) {
        return $query
            ->where('active', 1)
            ->where('valid_from', '<=', now())
            ->where('valid_till', '>=', now());
    }

Как правильно спроектировать тарифные планы?

maksam07, все верно
в 23:59:59 текущего дня тариф отключился (точнее дата valid_till истекла).
а в 00:00:00 следующего дня крон пошел отключать, но не факт, что он очень быстро отработает.

И этот промежуток как раз и будет интервалом без тарифа.

Как правильно спроектировать тарифные планы?

maksam07, он топит за то, что за активность тарифа должно отвечать одно поле в таблице - active.
В моем же кейсе (второй вариант) - это будут 2 поля как минимум - valid_till и active.
То есть, пока я не переведу тариф в active = 0 - он считается действующим, хоть и просроченным в определенный момент (просрочку проверять отдельным методом просто).