Как решить, когда использовать роли пользователя или учетную запись типа пользователя?

Question

[uliyanovaanastasia]

В системе есть четыре типа пользователей:

1. Партнеры
   
2. Клиенты
   
3. Операторы
   
4. Администратор
   

Партнерами могут быть:

1. Врач
   
2. Медсестра
   
3. Массажист
   

Каждый имеет свой набор предлагаемых услуг.

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

Answer 1

[vitaly_74]

можно сделать один общий тип учетных записей например просто User
а вот уже самому юзеру давать роли врач. или врач И при этом администратор,
а можно группу ролей. принцип примерно тот же.

Comments

[uliyanovaanastasia]

Все-таки использовать подход через Роли/права? Или достаточно воспользоваться моделью наследования от User? В этом и сложность. А может быть что роль имеет под-роль

[Василий Банников]

uliyanovaanastasia, на самом деле подролей у вас нет. У вас нет просто "партнёр", но у вас есть пртнёр-врач и партнёр-массажист

[vitaly_74]

uliyanovaanastasia, наследованием лучше вообще не пользоваться. используйте принцип Роль/права. Если нужно, могу показать видео, в котором рассказывается почему наследованием в данном случае вообще не пользоваться

Answer 2

[Nik Faraday]

Вообще любой тип учётной записи и есть роль.

Тут нужно отталкиваться от того, как это видно в самой базе данных. В базу данных вы не сможете закинуть ФУНКЦИОНАЛ либо ВОЗМОЖНОСТИ какого-то типа юзера, у вас есть только юзер. Отсюда выходит, что в БД у вас будет только одна таблица, где будут храниться ЮЗЕРЫ. В этой таблице будет колонка с типом юзера.

После получения рекорда из БД на сервере, вы сможете уже ставить условия через тот же if, имеет ли данных юзер доступ к тому или иному функционалу.

Так же на клиентской части (На разметке) вы можете определять, какие части интерфейса выводить юзеру в зависимости от роли, или к каким страницам давать доступ через тот же if или switch

Comments

[uliyanovaanastasia]

Я хочу воспользоваться этим https://spatie.be/docs/laravel-permission/v5/basic...
Но не уверена. Одним полем не ограничусь - так как юзер может иметь несколько ролей одновременно. И опять - точно мне нужна модель роль-права?

[uliyanovaanastasia]

Можете обосновать это: "Вообще любой тип учётной записи и есть роль."?

[Nik Faraday]

uliyanovaanastasia, не знаком с пхп, по этому смотреть код не имеет смысла для меня. Тут используется общая концепция программирования.

Если юзер может иметь несколько ролей, тогда создайте таблицу с ролями и сделайте отношение многие ко многим (Один юзер может иметь много ролей. Одна роль может быть у многих юзеров) и просто при проверке уже используйте цикл, либо автоматизируйте.

Как автоматизировать? Лично я бы тут приклеил бы несколько методов, которые проверяли бы наличие какой-то роли в юзера среди массива роле и выдавали бы true/false, а далее, при проверке через if/else вызывал бы этот метод

[Nik Faraday]

@uliyanovaanastasia

Можете обосновать это: "Вообще любой тип учётной записи и есть роль."?

Сам по себе юзер это набор данных, которые хранятся в базе данных. Роль/Тип/Назначение/Предназначение/И т.д. для юзера это всего лишь некоторое значение в таблице БД, которое отличает одних юзеров от других.

В вашем понимании, тип учётной записи это юзеры, у которых просто отличаются права действия/доступа на сайте.

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

Answer 3

[Dark_Dante]

abstract class AbstractUser {}

class Partner extends AdstractUser {
       private UserType $type;
}

class Operator extends AbctractUser {}

class Client extends AbstractUser {}

class Administrator extends AbstractUser {}

enum UserType: string {

/**
* врач
*/
case DOCTOR = 'doctor';

/**
* Медсестра
*/
case NURSE = 'nurse';

/**
* Массажист
*/
case MASSEUR = 'masseur';
}

Вот как то так

Answer 4

[Дмитрий Б]

1. Отвязываемся от пользователя, оставляем там только поле type и варианты значений Admin, User
2. Под каждый тип пользователей создаем таблицу: partners, clients, operators
3. Определять является ли пользователь партнером, клиентом или оператором нужно по наличию записи в этих таблицах
4. Определять тип партнера можно добавив поле specialization_id в partners
5. Определять набор предоставляемых услуг партнером, можно добавив таблицу services и связав ее со specializations

Структура БД:
users - пользователи
- id
- type [admin, support, user]
clients - клиенты
- id
- user_id
- title
operators - операторы
- id
- user_id
- title
partners - партнеры
- id
- user_id
- specialization_id - специализация партнера
specializations - специализации (врач, медсестра, массажист)
- id
- title
services - предоставляемые услуги (массаж, обследование...)
- id
- title
specialization_services - связь между специализациями и услугами
- id
- specialization_id
- service_id

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