Petro123 EstetsОчень смелое заявление защита на уровне БД от пользователей и администраторов ;)))
на всякий случай:
- предоставление доступа к определённой БД - sp_grantdbaccess..........
- предоставление доступа к определённым объектам в БД - grant..........

Это можно назвать "раздачей прав", но не как не "защитой на уровне БД". Не могу ничего сказать о ORACLE и DB2, но SYBASE и MS (судя по sp_*) не позволяют защитить данные на сервере от прямого вмешательства или хищения.

Petro123 EstetsНа самом деле есть пять сотрудников отдела, которые имеют одни и те же права и обязанности, но 1-ый может еще и подписывать счета,
каким образом это реализовано в коробочном продукте у Вас ?
Давайте ближе к практике, иначе не будем флеймить.

Согласен, хотя ничего "принципиально нового" сказать не могу. Возмите описание допусков любой БД, или описание любой массовой "учетной системы", например Axapt-ы. Есть пользователи - роли - "объекты контроля доступа"

Для Axapt-ы "объекты контроля доступа" это "Функциональные ключи" которые привязываются к объектам БД, пунктам меню, элементам интерфейса и служат для отключения/скрытия функционала в зависимости от текущей настройки.

Для нашей системы "объекты контроля доступа" это:

1) документы и из состояния/статусы. Т.е. может может ли данный пользователь(роль) видеть документы данного типа в данном состоянии.

2) Формы. Может ли данный пользователь(роль) видеть данную форму документа, или данный список.

3) Методы. Может ли данный пользователь(роль) выпольнить данное действие с документом, например подтвердить, отменить или добавить документ данного типа.

От этого зависит:
1) интерфейс - пользователь не увидит пункт меню вызывающий "Список входящих счетов" если у него нет доступа к этому списку.
2) получение данных - хп которая лежит под списком входящих счетов не
вернет на клиента счета находящиеся в состоянии "оплата произведена", если у пользователя нет допуска до документов в состоянии "оплата произведена"

3) обработка данных - пользователь не увидит в контекстном меню пункт "удалить счет", если у него нет доступа к методу "удалить счет", документа "Входящий счет". При чем контроль осуществляется как со стороны интерфейса, так и со стороны ХП отвечающей за удаление счета, если пользователь все таки вызовет данную процедуру из ISQL то получит соответствующее сообщение.

Petro123- мне нужна методология разработки Рабочих мест или АРМ.
Могу сказать из собственного опыта внедрения продуктов, разбиение на АРМ-ы или Роли "теоретически" провести нельзя, продукт должен быть внедрен, а потом уже исходя из статистики, опыта и предложений происходит конфигурация АРМ/РОЛЕЙ/ДОПУСКОВ. Предварительную конфигурацию можно проводить исходя из требований заказчика и здравого смысла.

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

наутилусхм.. а давайте может определимся с понятием рабочее место????!
Вам же выше писали, что РМ=Роль... и в моём понимании точно так же.
зачем перелогиниваться?? пользователю??... у него есть набор ролей и соответсвенно разрешённых действий.

Если быть более точным "РМ"= совокупность ролей необходимая для осуществления служебных обязанностей

Petro123 Estets
Если быть более точным "РМ"= совокупность ролей необходимая для осуществления служебных обязанностей
наконец пришли к консенсусу.
Не совсем так, под термином "совокупность" имелось ввиду, что не потимально приравнивать "роль" к "рабочему месту", проще приравнивать "роль" к некому "направлению деятельности" или области служебных обязанностей. Не знаю как более точно это выразить, покажу на примере.

Если "Роль" = "Рабочее место", что судя по всему более соответствует вашему предложению, то справедливо что 1 пользователь = 1 роль. И есть роли:
Директор, кладовшик, старший смены и пр.

В случае если "Роль" = "направлению деятельности" то 1 пользователь = 1РОЛЬ + 2РОЛЬ + 3РОЛЬ, и есть роли типа:

"Права для всех" - включает в себя просмотр общих справочников типа валюты, курсы валют, пункты меню такие как "смена пароля" и прочие в зависимости от специфики данные и действия доступные всем.

"Работа с контрагентами" включает в себя списки юридических и физических лиц, с возможностью добавления и изменения, банки, счета, адреса, отчеты и прочее все что необходимо для внесения и изменения информации по контрагентам.

"Работа с проводками" - включает себя журналы проводок, планы счетов, всякие там оборотно-сальдовые ведомости и пр.

К чему это все, в результате мы получаем что РМ кладовшика состоит из ролей
"Базоыве права для всех" + "Складские документы"+"Работа с контагентами", а РМ старшего кладовщика это те же роли плюс роль "Работа с проводками" и "Экспорт во внешние системы".

Petro123Т.к. совокупность ролей в БД SQL Server раньше не было.
Совокупность ролей это список ролей принадлежащих данному пользователю.

softwarerСобственно, вопрос об иерархической организации ролей поднимался не так давно, и если мне не изменяет память, в Вашем присутствии. И тогда в очередной раз констатировали, что "роль может включать в себя другие роли" - вполне достаточно, никаких дополнительных сущностей не нужно.
ИМХО конечно, но я с этим не согласен, не могу представить себе задачу, когда бы потребывалось группы ролей, суб-роли и прочая иерархия.
Перед глазами пример АБС где достаточно большой набор "опций" к которым дается доступ и около 1000 пользователей, и каждому допуска даются индивидуально. Т.е. никакие группы и роли не используются вообще. Хотя это специфический пример.

В нашей программе около 3500 объектов к которым регулируется допуск разбито на 12 "простых ролей" , этого оказалось достаточно без дополнительной иерархии, правда пользователей всего 30. Получается матрица 12x30 которой и оперирует администратор системы.

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

Petro123Первое, в отличии от второго гибче, но и недостатки есть (дороже, надо писать РМ администратора ролей/РМ, или писать фреймворк как iscrafm )
Думаю зависит от программы, на 1-ю версию нашей программы было потрачено около 3-х человеко-лет. И соответсвенно написание динамической кодфигурации РМ в зависимости от настройки занявшей 1-2 человеко-месяца было не критичной задачей.

Petro123
1. Нужно написать и спроектировать программу или форму где "вася-охранник
может поставить галочку". Т.е. спроектировать ЕЩЁ ОДНО РМ-конфигуратор_РМ.
И это правильно

Petro1232. Что вы будете делать если нужно объеденить клиентские формы в одну для A+B-сотрудника. Например, вывести график "Динамика продаж" в углу формы сотрудника АРМ "Оператор-бухгалтер"?
Сразу делается объединенная форма, а видимость "Динамика продаж в углу" зависит от прав пользователя.

Petro123GRANT SELECT ON Таблица_Динамика_продаж TO Роль_Оператор_ввода
Несколько вырожденный случай, но кто мешает вам показывать пункт меню "Динамика продаж", в зависимости от того есть ли у пользователя право на SELECT на "Таблица_Динамика_продаж". Вот вам и кастомизация клиентской части в зависимости от настроек, не требующая дополнительных затрат на "конфигуратор" ;)

Petro123
Интересно кто у Вас в коробочном продукте отвечает за эту "настройку".
Конечно, можно и внедрение забубенить за отдельные деньги и командировочные.
Для любой достаточно сложной системы начиная от 1с и кончая SAP R/3 нужен администратор и человек занимающийся внедрением. Хотя и то и другое - коробочный продукт.