Внутренние роли пользователя в соц. сети.

Всё про контроль доступа пользователей: фильтры, RBAC, проверки
Ответить
Аватара пользователя
zhe17065564
Сообщения: 49
Зарегистрирован: 2016.06.09, 10:46
Откуда: Украина
Контактная информация:

Внутренние роли пользователя в соц. сети.

Сообщение zhe17065564 » 2017.12.04, 21:07

Здравствуйте. Опишу суть вкратце, по крайней мере постараюсь. В соц. сети есть 4 базовые роли в RBAC:
1.Admin. 2.Moderator. 3. User. 4.Company.
Связь, если простой пользователь сотрудник, то его профиль , а если регистратор компании - то профиль компании(отдельно).
Profile<- User ->Company
У сотрудника с таблицы User есть отдельно профиль(тоже таблица), в котором он заполняет поле, что он работает в такой то компании, а она это потом подтверждает(связь ManyToMany): таблица verify( id, user_id, company_id, status) - отсылка к тому, что у человека ведь за карьеру может быть нe одна компания, в которой он работал. Вариант пока набросок - я иду к тому, чтобы его упростить. Так вот в чем вопрос - как добавить внутренние роли под сотрудников компании? Мне надо создать дополнительные роли и права для сотрудников компании -1. регистратор может все действия скажем -он уже есть по умолчанию, как создатель компании. -2. модератор занимается контентом компании. -3. обычные сотрудники только просмотр информации о своей компании.
Насколько логически я рассуждаю:
1.водить сотрудников как дополнительную сущность, наследоваться от IdentityInterface в коде модели и уже там определять базовые роли через константы, а регистратор компании уже вместе со статусом верификации может ещё менять роль своего сотрудника с базовой до модератора например, чтобы тот мог в выделенной области заполнять контент компании
2.или же вместо верификации держать статус и роль в компании того, кто прислал заявку на подтверждение оставляя связь ManyToMany, не вводя новую сущность, а усложняя текущую.
Плюсы последнего варианта: сотрудник может быть модератором у любой компании, которая его верифицировала и меняет ему роль под себя(больше гибкости)
Минусы последнего варианта:
-дублирование в базе.(не знаю насколько это критично в данной ситуации или может быть по-другому никак)
-числится активным сотрудником у всех компаний, кто его верифицировал
Как решение: добавить статус работает/работал и тогда уже по нему отлавливать и не выводить в структуре компании среди сотрудников

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

Ответить