• Каким образом перебрать в таблице миллион записей?

    @terzi_eduard
    DB::table('users')->orderBy('id')->chunk(100, function($users) {
        // Process the records...
    
        return false;
    });
    Ответ написан
    Комментировать
  • Как регулировать уровни доступа к модулям Admin Architect - Laravel 5.2?

    @terzi_eduard
    День добрый!

    Сразу прошу прощения за долгое молчание.

    Постараюсь ответить на Ваши вопросы коротко, но содержательно.

    На данный момент управлять доступом можно 2-мя способами:

    Global permission
    файл `config/administrator.php` содержит ключ `permission`, где можно указать глобальные уровни доступа в админку в целом.

    'permission' => function ()
    {
    	return ($auth = auth('admin')->user()) && $auth->isSuperAdmin();
    },


    Action Service

    Каждому модулю (ресурсу) в Admin Architect-е соответствует дефолтный Action Service - класс отвечающий за выполнение CRUD задач. Action Service также служит для объявления групповых задач (bulk actions) и одиночных (single actions).

    Как Вы правильно заметили руты (routes) в Admin Architect-е достаточно абстрактные, поэтому есть определенные трудности с навешиванием Middleware для конкретного ресурса. Именно поэтому эта задача и легла на плечи Action Servic-а.

    Т.е. чтобы определить уровень доступа для конкретнго action-а в ресурсе - достаточно прописать `can` метод.

    public function canEdit(Authenticatable $who, $model)
    {
    	return $user->isSuperAdmin() && ! $model->isProtected();
    }


    так же для глобальной политики, можно использовать и сторонний сервис класс:

    public function canEdit(Authenticatable $user, $model)
    {
    	return (new ACLGate($user))->forEntity($model)->checkPermission('edit');
    }


    еще вариант: каждый Action Service созданный для ресурса можно унаследовать не от `Terranet\Administrator\Services\Actions`, а от своего, нокоего Proxy класса (`php artisan administrator:action `), с определенной логикой ACL, ну или можно попытаться полностью подменить `app('scaffold.actions')` - на свою реализацию.

    Итог
    Если у вас достаточно гибкая политика ACL - это довольно удобно, хоть и приходится немного дописать, в обычной ситуации можно описать достаточно общие правила примерно так (пример достаточно простой, но отражает суть подхода):

    public function __call($method, $args)
    {
    	if (in_array($method, ['canEdit', 'canActivate', 'canLock'])) {
    		list($user, $model) = each($args);
    		return $user->isSuperAdmin() && ! $model->isProtected();
    	}
    
    	return false;
    }


    Из плюсов данного подхода по отношению к middleware - для single-action методов (canEdit, canDelete, ваших собственных) позволяет управлять доступом на уровне конкретной записи, а не только ресурса в целом.
    К примеру, легко можно запретить удаление пользователя со статусом 'SuperAdmin'.

    Надеюсь писал не зря, и это кому-то пригодится!

    P.S. Конечно, представленные решения не идеальны, могут и должны быть улучшены, но они выполняют поставленную задачу. На досуге подумаю как можно улучшить данную модель. Если есть предложения - с удовольствием приму на рассмотрение.
    Ответ написан
    Комментировать