Нужно думать не о ролях а о привилегиях. Право на чтение таблицы или таблиц (SELECT) право на редактирование (UPDATE) право на удаление (DELETE). А роли это уже косметика которая иерархично выстраивает привилегии.
Исходя из выданных привилегий сами решаете что есть админ т.к. ими же (привилегиями) можете проверять экклюзивный доступ требующий привилегии ADMIN_ACCESS например. Таким образом админ тот у кого есть ADMIN_ACCESS привилегия.
Проще говоря есть некий код, который по логину-пароль возвращает интерфейс IUser у которого есть дочерний объект-интерфейс IRights у которого есть функция HavePrivilege(PriviligeID, ISecurityContext) где PriviligeID некое числовое или строковое обозначение привилегии (которая захардкожена в коде и используется где нужно),
ISecurityContext - интерфейс на список данных доступ к которым проверяется, это может быть что угодно:
- имя таблицы
- имя компонента
и .т.д.
Допустим Вы проектируете форму кредитных заявок, есть 2 роли:
- администратор, который видит все заявки в системе, от всех операторов и может их удалять.
- операционист, который их создает, редактирует и видит только те заявки, которые создал сам.
Система прав:
Есть понятие привилегии, если говорить в рамках операций с БД, то привилегии могут быть:
- с указанием таблиц к которым разрешено обращаться.
- с указанием признака супер-привилегии, такая привилегия тупо имеет доступ ко всем таблицам.
- с указанием пред.установленного фильтра, например запрос данных из таблицы сформируется с привязкой к текущему авторизованному пользователю, и юзер увидит только те записи которые создал он сам.
Собственно у вас 2 формы:
- 1. Форма с таблицей заявок.
- 2. Форма заявки.
Логика такая:
Открывается форма-список заявлений, проверяется разрешение TABLE_READ, если его нет - отлуп с сообщением "У вас нет прав на просмотр этих данных". Юзер видит пустой грид и кнопку закрыть.
Если TABLE_READ есть, и среди указанных там таблиц НЕТ "CreditRequests", то тот же отлуп с сообщением.
Если TABLE_READ есть к этой таблице или это супер-привилегия чтения всех таблиц, то смотрим на фильтр, и применяем его к формируемому SELECT. Что такое фильтр?
В таблице CreditRequests есть поле OperID которая указывает на IUser.ID т.е. связывает запись с её создателем, таким образом через привилегию открытия таблицы с указанием фильтра, вы покажете юзеру только записи которые делал он сам.
Дальше открывается БД, с формированием выборки и отображением в грид.
Дальше на форме лежит какой-нибудь ActionList , где на вставку, редактирование и удаление записей идет проверка TABLE_EDIT, TABLE_DELETE схожим образом, т.е. если IUser.IRights отвечает что тип нет такого или нет для запрашиваемого объекта то отлуп с сообщением о нехватке прав.
Таким образом администратор будет видеть все заявки и сможет смотреть в любые таблицы, т.к. имеет все привилегии без ограничений.
Оператор будет видеть только таблицу заявок кредитов, видеть только свои заявки и только их он может редактировать и удалять.
Эта система прав сложна и обычно глубоко интегрируется в частности в компоненты отображения т.к. например оператор видит колонки (поля) записи таблицы, а администратор должен видеть и иметь возможность фильтровать данные в разрезе операторов которые заявки плодят, т.е. есть колонка которая из БД поднимает ФИО того кто заявку создал + можно сформировать лог изменений по заявке (кто и когда чего наизменял), сюда же встраивается механизм верификации т.е. оператор создал, админ принял/отказал, оператору вернулась заявка на доработку.
А то и ещё глубже идет разграничение, например разрешается редактировать только некоторые компоненты на форме (например ставить отметки/галочки или писать примечания).
