В общем есть вебморда, куда нужно сделать доступ для своих и доступ для клиентов. Свои будут работать с заказами клиентов, а те в свою очередь видеть весь ход работы.
Проблема вот в чем: групп будет 3 - админ, свои (обзовем это сотрудниками) и клиенты и еще нужно подразделять сотрудников на некие группы, скажем так группа поддержки клиентов, группа дизайнер, группа программист. И для этих групп уже давать через вебморду права на доступ к определенной части. Например, группа поддержки имеет доступ к заявкам от клиентов, дизайнер и программист к проектам, еще кто-то к счетам. В общем разделение идет по обязанностям. Но суть не в этом, а в том, как расположить эти группы в базе. Есть несколько вариантов:
1) Таблица group - где храним три группы: админ, сотрудник, клиент - это три основных группы. В этой же таблице делать и группы для сотрудников. Получается:
- Админ
- Сотрудники
- Клиенты
- Поддержка
- Дизайнер
- Программист
2) В таблице group хранить лишь группы сотрудников
- Поддержка
- Дизайнер
- Программист
а такие группы как админ, сотрудник, клиент не делать физическими, а сделать например у каждого пользователя поле type_user: 1,2,3 где цифра это админ, сотрудник, клиент.
Проблема в том, что нужно создавать группы лишь для тех кто является сотрудником. Получается путаница, так как сотрудник сама является группой, еще вместе с этими группами будет в одном списке и админ, клиент.... что не вяжется между собой. Буду рад ответам!
я сделал так, есть действия, роли и пользователи. каждая роль содержит свой набор действий. каждый пользователь может обладать любым набором ролей. так же каждый пользователь может напрямую обладать разрешением или запретом на какое-то действие, то есть поверх того что ему по ролям дается. но это не обязательно. в инициализации проги составляется список действий которые доступны пользователю исходя из установленных связей. еще есть две дубовые роли, это гости и зарегистрированные пользователи. и есть специальный повсеместно доступный метод проверки доступа к действию. в методах требующих разрешения прописывается условие с проверкой, если действия нет в списке, то отдыхаем. так же эту проверку можно производить чтобы решить показывать ему элементы интерфейса вызывающие действия или нет. вкратце так
А в чем собственно проблема, чтобы сделать не 3 группы, а необходимое количество? Это вы программистов и дизайнеров запихали в одну группу сотрудники, но ведь можно вообще не делать группу сотрудники. Просто у вас будет 5 (или другое необходимое количество групп), и каждая из них будет иметь доступ в свой раздел.
Ну и где-нибудь в конфиге/модели можно хранить массив, в котором перечислены все ID групп, которые относятся к "сотрудникам". Это можно сделать, если есть такая необходимость.
Средний