Зачем нужны статусы модерации юзера если есть роли?

Question

[jazzus]

Делаю модерацию пользователей. Впервые, поэтому смотрел примеры-рассуждения в сети. А там везде status 0/1. Ну я тоже сделал т.к. не стадо. Думаю 0 – заблокирован, 1 активен. Что может быть проще. В процессе чуть усложнил – сделал таблицу для статусов и модерации со связью ит.д. Сейчас дошел до реализации и думаю – не погорячился ли я? С того ли конца начал? Может вначале стоило подумать?)) У меня ведь уже реализованы роли доступа с пермишенами. И мне все равно нужно менять доступ. Т.е. создавать роль для, например неактивен или на модерации. Чтобы права изменить. И тогда смысл этих ролевых игр со статусами. Получается дублирование контента. Или не получается? И я не знаю то чего не знаю и статусы нужны. В общем, я в замешательстве) Буду благодарен за инфу. Кто имел опыт такой реализации. Как вы делаете это? Нужны ли статусы если роли есть и зачем.

Answer 1

[Decadal]

Статус пользователя это не то же самое что и пермишены. Это ограничения другого рода. Возможно, вы сделаете суперадмина а потом деактивируете его при помощи статуса. Несмотря на то что все пермиссии остались, зайти под ним никто не сможет. А потом надо будет что-то глянуть от суперадмина и вы консольной командой его включите обратно.
Тогда как пермиссии отображают обычный сценарий работы. Это разъяснения, кому, что и где можно делать. А раз так, иерархия таких прав может настраиваться долго и тщательным образом для каждого юзера.
И потом, если появились подозрения что пользователь мошенник, вы просто отключаете его профиль, проверяете, а потом снова включаете его. Деактивация при помощи пермиссий это болезненно.

Comments

[jazzus]

100% так правильно. Сейчас подумал. Действительно, как восстанавливать роли если их несколько. Вести логи по ролям что-ли. Можно сделать роль суперадмин, заблокированный, но если он еще был кем-то то будет развлечением это все собирать. Получается статусы только для глобального включения и отключения. Только насчет структуры не понятно.. В users статусы перенести или в отдельной таблице? У меня сейчас 2 модели UserModeration и Status
В UserModeration есть status_id связываются через hasOne (Laravel)
3 статуса модерации
Не активен
Активен
Модерация

Статус Модерация - чтобы пользователь мог залогиниться, но показывалась страничка с сообщением типа вы на модерации.

Сейчас думаю может статус “модерация” как раз сделать ролью. А status_id булеаном в таблицу users перенести, чтобы быстрее проверялось (без связи моделей) на активен/неактивен.

Answer 2

[vism]

Нужно думать сущностями, логическими блоками.

Пермишены и роли - это у вас разграничение того, чтоб может пользователь делать и куда он может ходить. Это как карточка доступа в офисе, в какие кабинеты она срабатывает и какие шкафчики открывает.

Блокировка
а) если это некая блокировка, которая не дает пользователю никуда ходить кроме столовой и коридоров - то это Роли и Пермишены. При том можно сделать проверку при получении ролей. Если блокирован - пермишены не грузим из БД, чтоб никуда не было доступа. А если допустим супер админ - даем все пермишены.
Но это говнокод.
Грамотно - если у вас стоит задача сделать блокировку, то сделать у ролей/пермишенов флаг activ(1/0). И если блокируется доступ управлять флагами. Вот и логично все. Можно закрывать доступ временно и частично к разделам.
б) Если блокировка это фейс контроль на входе, блокировка не доступа а именно самого юзера как сущности, это флаг а таблице который отрубает вобще возможность залогиниться.

Comments

[jazzus]

Честно говоря вообще не понял, как это работает.. В смысле у ролей/пермишенов active? Или вы имеете ввиду у пользователя active на роли? У меня сейчас флагами роли у пользователя устанавливаются. И флагами пермишены у роли. По идее логично. Добавили пермишены к ролям через manytomany. А потом только добавляем/удаляем роли у юзера. Так не правильно чтоли?

Что касается бана.
В итоге сделал isban (0/1) в users для проверки только на стадии авторизации. + сделал модерацию c ролью check для стадии проверки (права на показ профиля и страницы что идет проверка). Осталось сделать принудительный разлогин юзера при бане и лог модерации.

[vism]

варианты а или б - это виды блокировки которые отличаются по логике.

active у ролей/пермишенов в таблице их связки с юзером - для временного отключения роли для юзера, если нужен такой вариант по логике.

[jazzus]

vism, ааа.. кстати тоже вариант

[jazzus]

vism, и тоже простой - выключать через pivot и не нужно хранить логи. Если конечно я себе правильно представил

[jazzus]

Короче.. это просто офигительное решение. Именно так я себе его фантазировал, когда не знал, что мне нужно) Мы тут спорили ниочем. Статусы логи, доступы после бана.. Роли можно просто отключить)) Тугликами. Ппц.. Решение было перед глазами, что аж обидно) В общем большое спасибо! Я бы еще неизвестно сколько с восстановлением из логов возился. Что странно в интернете много чего читал, но нигде такого примера не было. Это ведь избавляет от гемороя с логами ролей, логик восстановления, версий, статистик, наглядности, удобочитаемости и т.д.

[vism]

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

Вобщем так себе решение на самом деле, в плане простоты реализации.
Я просто привел пример, как нужно думать, чтоб понять, что нужно реализовывать.

[vism]

Но намного проще чем логи и тому подобное)

[jazzus]

vism, В итоге сделал одну табличку для массового добавления/удаления ролей пользователя и смены статусов. В контроллере:

//Открепляем роли
        $detach = $user->roles()->detach();

        //Прикрепляем и деактивируем
        if ($role_id=$request->input('role_id')) {
            foreach ($role_id as $id) {
                     $user->roles()->attach($id);
                     $user->roles()->updateExistingPivot($id, ['active' => $false]);
            }
        }

        //Активируем
        if ($active_role_id=$request->input('active_role_id')) {
            foreach ($active_role_id as $id) {
                     $user->roles()->updateExistingPivot($id, ['active' => $true]);
            }
        }

В отношениях

public function activeRoles()
    {
      return $this->roles()->wherePivot('active',(new Role)->getStatusID('active'));
    }

Соответственно проверку доступов переделал под activeRoles. Тонкости не тестировал, но пока все работает.

[vism]

jazzus, Вы false true храните в отдельных переменных ? О_о

[jazzus]

vism, да))) я забыл что там булеан и получал ид по названию. В отдельном трейте.. Сейчас перепишу. Кстати то, что'active' true можно делать, а не 1 не знал. Прикольно)

[vism]

jazzus, На самом деле лучше хранить константами, как вам уже писали.
Model::ATTRIBUTE__VALUE
Role::ACTIVE__YES
Role::ACTIVE__NO

А вот это полная хрень.
Щас спасаю проект как-раз, где автор таким же макаром писал, в итоге так все заговнилось, что он запутался и кучу багов допустил, тупо из-за неверной семантики и таких конструкций.
(new Role)->getStatusID('active')

[vism]

Не надо привыкать быть рук***пом, у вас хорошие данные для становления хорошим разработчиком.
а то потом так вот будете делать...

[vism]

надо так

[jazzus]

vism, я не против констант. Как-то попробовал, не получилось и оставил это дело. Сейчас беру данные из массивов в моделях. Скорее всего отрефакторю, но это сложно и долго т.к. во всем приложении уже (new Role)->getStatusID('active')

[jazzus]

Еще непонятно как быть с массивами и условиями.
У меня есть часть данных в таком виде

if ($type == 'yes') return ['name' =>"Избранное", 'id'=>1, 'makeup'=>$makeup->color('green')];

Или это в константу можно отправить?

[vism]

jazzus, вот если бы делали константами, рефакторить было бы просто :)

Про массивы не понял, полный кусок кода предоставьте пожалуйста посмотрю.

Кстати, если у вас PhpStorm. Найдите в настройка[ code styling и установите setFrom->Psr

[vism]

vism, уже писал как-то, скопирую и вам)

1. Code formatting
All PHP code should be formatted with PSR standard. Each IDE provide such options.
In PhpStorm: Settings->Editor->Code Style->PHP->Set from->Predefined Style->Psr1/Psr2
https://www.php-fig.org/psr/psr-1/
https://www.php-fig.org/psr/psr-2/

2. Laravel ide-helper
Use ide helper. It is already in composer.
https://github.com/barryvdh/laravel-ide-helper

3. Logic duplication
If you copy code and don't change logic - you should move this code to another method and use that method instead. NO code and logic dublication
KISS(Keep it simple, stupid)
DRY(don't repeat youself)

4. Use constants anywhere you can.
Model naming: {COLUMN_NAME}__{VALUE_DESCRIPTION}
Not model static things naming: {TYPE}__{VALUE_DESCRIPTION}
Reason: If we change value, sometimes it can be found through code and changed everywhere. But sometimes it can cause a lot of hours of refacotring and a lot of errors if developer hurry.
Constants - zero time to change and zero errors.
Examples:
------------
so no
$this->user->status == 'Past Due'
should be
$this->user->status == User::STATUS__PAST_DUE
-----------
No
in_array(request()->route()->getName(), array('creditcard','creditcardpost','plan','plandowngrade','plandowngradepost','planupgrade','planupgradepost')
This should also be constans.
-----------
BusinessConnection::with('reviews')->where('business_id', $this->business->id)->where('type_id', 3)->first();
Here type_id should be also constant!

[jazzus]

vism,

public function getDataTypes($type)
  {
      if ($type == 'user') return ['name' =>"Пользовательский", 'id'=>4];

      $makeup = new Makeup;
      if ($type == 'yes') return ['name' =>"Избранное", 'id'=>1, 'makeup_id'=>$makeup->color('green')];
      if ($type == 'see') return ['name' =>"Просмотрено", 'id'=>2, 'makeup_id'=>$makeup->color('blue')];
      if ($type == 'not') return ['name' =>"Не показывать", 'id'=>3, 'makeup_id'=>$makeup->color('red')];
  }

Метод возвращает массив данных для дефолта+ инфа из него растягивается на запчасти (ид, цвет навзание). И данный мой велосипед едет в нескольких моделях по такому же шаблону. Вообще не представляю, как это заменить на константы. Не люблю рефакторить такие вещи)

[jazzus]

С другой стороны массив можно оставить, а данные вставить константами

[jazzus]

vism, User::STATUS__PAST_DUE выглядит конечно круче чем (New User)->status(‘value’). + сразу видно, что константа, а не просто метод. Я видел другие варианты написания. Т.е. вы так и пишете User::STATUS__PAST_DUE? А в blade шаблонах как?

[jazzus]

Кстати, если у вас PhpStorm. Найдите в настройка[ code styling и установите setFrom->Psr

У меня Атом. стоит какой-то плагин для php стиля) по-крайней мере визуально выглядит красиво)

[vism]

jazzus, {{ \App\Models\User::STATUS__PAST_DUE }}

public function getDataTypes($type)
  {
      if ($type == 'user') return ['name' =>"Пользовательский", 'id'=>4];

      $makeup = new Makeup;
      if ($type == 'yes') return ['name' =>"Избранное", 'id'=>1, 'makeup_id'=>$makeup->color('green')];
      if ($type == 'see') return ['name' =>"Просмотрено", 'id'=>2, 'makeup_id'=>$makeup->color('blue')];
      if ($type == 'not') return ['name' =>"Не показывать", 'id'=>3, 'makeup_id'=>$makeup->color('red')];
  }

Id это поле модели? Тогда так

const TYPE_ID__USER = 4;
const TYPE_ID__FAVORITE = 1;
const TYPE_ID__SEEN = 2;
const TYPE_ID__HIDDEN = 3;

public function getNameByType($typeId)
  {
    $name = '';
        switch($typeId){
            case self::TYPE_ID__USER:
                $name = 'Пользовательский';
            break; 
            case self::TYPE_ID__FAVORITE :
                $name = 'Избранное';
            break; 
            case self::TYPE_ID__SEEN :
                $name = 'Просмотрено';
            break; 
            case self::TYPE_ID__HIDDEN :
                $name = 'Не показывать';
            break; 
        }
    return $name;
}

ну и для make up такой же метод

[jazzus]

vism, Спасибо! Буду разбирать. Нашел также такой способ:

define(
      'DOSSIER',
      [
          "Anderson" => ["name" => "Thomas", "born" => "1962-03-11"],
          "Reeves"   => ["name" => "Keanu",  "born" => "1962-09-02"],
      ]);

Так правильно делать?

[jazzus]

vism,

ну и для make up такой же метод

Как-то они похоже выглядят. Будет правильно их пытаться автоматизировать? Я не очень люблю дублировать похожие схемы, т.к. однажды зависал на рефакторинге такого с ошибками.
Можно ли в массив это все дело перевести? ТАм где переменная name. Например:

public function getNameByType($typeId)
  {
    $data = '';
        switch($typeId){
            case self::TYPE_ID__USER:
                $data = ['name' =>Пользовательский', 'makeup_id' => Makeup::ID__GREEN];
            break; 
        }
    return $data;
}

Получается по TYPE_ID__USER получаю массив данных, чтобы из него вытащить нужную инфу. Или все же метод продублировать полностью для makeup_id?

[vism]

jazzus, скорее тогда создайте статичный метод, который возвращает массив, основанный на константах

public static function getDataTypes() {
    return [
        self::TYPE_ID__USER => ['name' =>Пользовательский', 'makeup_id' => Makeup::ID__GREEN],
    ];
}

А для получения конукетного дата тайп - метод

public static function getDataTypeById($typeId){
    return self::getDataTypes()[$typeId]
}

//и в коде будет красота и простота рефакторинга

Model::getDataTypeById(Model::TYPE_ID__USER)

А учитывая кол-во данных, не лучше ли в БД это все запихнуть?
И доставать через relations?

[jazzus]

vism, Большое спасибо за объяснения и примеры! Реально спасибо мой код стал другим. В итоге все заменил на константы. Выглядит круто, чувствую себя программистом)) Если бы знал, что константы работают, как Model::CONSTANT я бы сразу делал нормально

[jazzus]

vism, в принципе я сделал также

if ($typeId == self::TYPE_ID__FAVORITE) return ['name' =>"Избранное", 'makeup_id'=>Makeup::ID__GREEN];

ну и получение один в один

[vism]

jazzus, Здорово. Из вас выйдет хороший разработчик я думаю.
Если вы фрилансите сразу, как модно сейчас. Лучше на пару лет сходите в офис поработать, в какую нибудь крупную фирму, где пилят свой сервис (не веб студия)
Потом конкуренции вам не будет.

[jazzus]

vism, я для себя все это изучаю. Хотелось понять, самому делать какие-то проекты и т.д. Типа хобби) Но мне на самом деле пока и так информации и какого-то опыта достаточно (я совсем с нуля здесь)

Answer 3

[Максим Тимофеев]

Думаю что при наличии ролей, отдельно хранить признак модерации не нужно, так как может быть роль "новый юзер", "юзер", "админ", "забаненный юзер" и т.д. Это позволяет оставить один механизм фильтрации доступа на базе ролей и не лепить сверху еще проверку статуса, да и с точки зрения оптимального хранения в БД, раз уж есть RBAC, зачем еще 1 столбец в таблице юзер или даже отдельная таблица?
Я думаю это рудимент пришедший с доООПшных систем. Многие просто так привыкли и тянут за собой это. Или же RBAC часто ставится не сразу и получается вначале система с контролем доступа по статусу, а потом сверху прикручивают rbac, а статус оставляют.

Comments

[Decadal]

ну да а что делать с direct пермишенами? а что делать с мультиролями? Вот вы кинули пользователя в группу забаненных а он был еще и оператором, и модератором контента, и юридическим сотрудником? Или удалять все эти роли а потом снова восстанавливать, или сохранять весь этот клубок и писать везде if ($user->hasGroup(Group::BLOCKED) { //cancel request }

[Максим Тимофеев]

Decadal, При блокировке, подразумевается блокировка. Так что, да, снимать все роли и давать роль "блокирован". Можно даже не делать такую роль, а просто снимать все роли.

Но я не утверждаю, что статус никогда не нужен. Наверняка есть случаи, где он оправдан. Но это редкие случаи. Чаще это рудимент (при условии наличия полноценного rbac).

[Decadal]

При блокировке, подразумевается блокировка.

да, и ничего более. А говорить что разрушить систему ролей это блокировка - не совсем правильный ход на мой взгляд. Я могу быть заблокированным админом. Не могу? В организации где у человека семь ролей, пять одобренных личных пермиссий разными начальниками отделов, просто непозволительно каждый раз грохать пермиссии

[Максим Тимофеев]

Decadal,

Я могу быть заблокированным админом. Не могу?

Если в ТЗ такое подразумевается? То можно ввести статусы, это частный случай или же ввести роль "блокированный админ". Как я уже говорил, вариантов где то что предлагаю не удобно - можно много придумать. Но только они или теоретические или крайне редкие случаи. Нет 1 метода на все случаи.

просто непозволительно каждый раз грохать пермиссии

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

Ради редкого случая восстановления ролей, не стоит иметь частую логику проверки статуса.

[jazzus]

Максим Тимофеев, блин.. везде есть недостатки/преимущества. В вашем варианте нужно будет логировать сброшенные роли. Но это на самом деле не сложно сделать и восстановить их 5 секунд. Записал в лог ид ролей/ юзера и восстановил через attach. Со статусами наглядней (можно видеть заблокированных с ролями), но придется писать параллельные доступы на статусы, а я очень не люблю любое дублирование кода-логики. Однажды намучался с рефакторингом одного и тогоже. Хотя наверное там есть простой путь через мидделварь

[Decadal]

Максим Тимофеев, а зачем частая проверка статуса? В авторизационном контроллере. При логине. И все.

[Максим Тимофеев]

Decadal, то есть меня заблокировали, но пока я не разлогинюсь и не войду снова, я могу делать что хочу. Так? А что делать в случае с REST где авторизация идет путем передачи пары логин пароль в каждом запросе?
Нет, это чаще рудимент, кроме редких случаев.

[Максим Тимофеев]

jazzus,

блин.. везде есть недостатки/преимущества

так и есть и выбрать путь, можете только Вы глядя на конкретное ТЗ. И не слушайте тех кто его не видел. Слушайте факты, но думайте и принимайте решения сами. Потому что так правильно в конкретной ситуации, а не потому что какой-то Максим Тимофеев или Decadal посоветовали.

[jazzus]

Максим Тимофеев, фактов у меня пока не особо много, все впервые узнаю) И про мультироли и про разлогиниться.
Что касается вариантов.. если сделать сводную таблицу для логов-ролей типа модель OldRole или BlackUser и туда записывать id roleй и юзера через многие ко многим. Как считаете это норм? В правильном направлении думаю? По идее я могу легко скидывать/прикреплять роли туда-сюда, а также получать все эти роли в случае восстановления и также брать статистику по заблокированным пользователям (например кто из заблокированных к каким ролям относится). Типа $user->oldroles() или role with blackusers

[Максим Тимофеев]

jazzus, Я вижу эту таблицу так:
id | user_id | moder_id | date | reason | back
итого есть юзер кто блокировал, кого блокировали, дата, причина и строка с json конфигом для восстановления. При чем можно туда писать логи всех изменений, не только банов
При такой структуре удобно выводить историю по пользователю, историю по модератору и вытягивать последние изменения.

[jazzus]

Максим Тимофеев, у меня сейчас один в один такая таблица только вместо back- status_id. и reason- comment Про json хранение логов.. Несколько раз уже где-то читал на тостере, но вообще не представляю что-это и как использовать. Буду гуглить))

[Максим Тимофеев]

jazzus, В последних версиях mySql есть тип данных JSON. Но даже без этого можно хранить json в обычном varchar или text. Если Вы вообще не знаете, что такое json - срочно разбираться.

[jazzus]

Максим Тимофеев, что такое json я знаю т.к. передаю из laravel в vue. Не понятно как его использовать для других целей. Например для логов. Файл сохраняется, но как, куда, откуда. Пример бы поюзать стаью видео. я по модерации почти ничего не нашел. Все регистрациями авторизациями завалено. Если начну сам сочинять напишу велосипед, который потом 100% переделывать.

[Максим Тимофеев]

jazzus,

использовать для других целей. Например для логов

в данном случае для хранения конфига, например:

{
roles: {'admin','moder'}
}

Файл сохраняется

какой файл?

[jazzus]

Максим Тимофеев, я про json файлы читал. Говорю, что не представляю пока как это работает, но по ссылкам их у себя открывал. Там также, как у вас в коде. Если с таблицей. Получается: cохраняем в таблицу, в некое поле формата json через контроллер таким образом
$data['back'] = response()->json($roles);
А когда нужно будет восстановить делаем обратное преобразование (decode или encode короче я этгго не делал)) делаем foreach и на каждую итерацию цикла делаем attach, чтобы вернуть роль. Пока такой вариант фантазирую)