Я как раз пытаюсь реализовать контроль прав по похожему алгоритму. К схеме поясню:

События - стандартные и нестандартные события объектов и ГМ (класс Перехватчик).
Обработчики - процедуры, которые выполняются при возникновении события, возвращают 0/1 или/и выполняют дополнительные действия (класс ВыполняемыйМодуль).

Все действия, включая создание обработчиков, производятся из режима 1С:Предприятие. Конфигуратор не задействуется.
Количество обработчиков к одному событию неограничено.
Главное правило при формировании конечного мнения об открытии/запрете доступа (на основании совокупности обработчиков, наборов обработчиков, групп пользователей - которая формируется для пользователя при возникновении события) - что не запрещено, то разрешено. То есть если при открытии документа 5 обработчиков разрешили доступ (вернули 1), а один запретил (вернул 0), то открытие документа запрещается. Если ни один из обработчиков не возразил, или если для данного события пользователю не назначено обработчиков - то доступ разрешается.
Если обработчиков для события несколько, то они выполняются в определенном порядке, который можно изменять. Каждый обработчик независим сам по себе, но они могут обмениваться некими данными через глобальную структуру (скажем один обработчик при открытии документа сохранил значение реквизита "Контрагент" в структуре, затем другой обработчик при записи документа сравнил сохраненное значение с текущим). Обработчики также могут изменять представление (реквизиты) формы.

Скатовскую схему не пробовал, честно говоря и не видел даже. надо глянуть...

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

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

да тут вообще шальные мысли...  

Самая общая схема реализации ролей что в голову пришла:

1) Есть глПользователь - он же пользователь (фактически логин/пароль).
к пользователю привязываем некий объект РОЛИ, который определяет все роли, назначенные глПользователь. (параметры сеанса, фактически).

2) Каждая роль - это типа вектор доступа к объектам (доки, справочники и пр).
В общем случае Роль - вещь параметрическая. (то есть Кладовщик - склада, ГлБух - Организации, Сотрудник - отдела).

3) Есть Объекты (доки, спр и т.д.) которые тоже параметрические.
Для каждого Объекта определен список доступов к нему (запись, чтение и пр.)
Для каждого Объекта в разрезе доступов к инфо задаются его список параметров:
   а) влияющие на доступ,
   б) зависящие от доступа.
(К примеру журнал доков организации А, (организация А - влияющая на доступ (разрешить/запретить)), выводить только доки сотрудников отдела Б (значение отбора - зависящее от доступа).

4) Есть матрица отношения Роли(Параметры) и Объектов(Параметры)  в конечном итоге и определяющая возможность доступа.

При реализации этой схемы написание конфы с ролями идет комфортно. Объекты пишутся так, как будто доступ к объектам полный. Я как разработчег в этот момент вообще о доступах не парюсь. Т.е. конструкций типа:

Если глПользователь.Кладовщик  <> 1 Тогда
   СтатусВозврата(0);
   Возврат;
КонецЕсли;
Если глДоступныеСклады.НайтиЗначение(Склад) = 0 Тогда
   СтатусВозврата(0);
   Возврат;
КонецЕсли;
 

не пишу.

При таком подходе доступ к объекту и параметры будут проставлены автоматически, согласно правилам из матрицы отношений Ролей и Объектов. Но это коммунизм.

Если вынести из кода хотя бы ту часть стандартных доступов к объектам 1с что там уже реализована платформой, уже б стало намного проще писать поведение объектов. Котлеты и не котлеты уже б разделились...

Пока в коде все в куче и роли и не роли и это не камильфо никак.

Фактически контекстный фильтр на доступ к событиям объекта?
Объекты оставляем как есть, или если пишем с нуля то как будто бы доступ к данным событиям объекта полный?
Все конструкции типа:

Процедура ПриОткрытии()
    Если А=Б Тогда
	 СтатусВозврата(0); Возврат;
   КонецЕсли;
КонецПроцедуры
 

в отдельный модуль?

Дело.

(все таки идея прорваться к доступам 77 будоражит мозг)

Если накладывать идею ролей на конфу в виде прописания всего поведения в модулях объектов, то это таким тонким слоем размазывается по объектам конфы, что введение одной доп роли это гимор.

maljaev писал(а) 11. Сентября 2009 :: 11:24:

Ну в плане "прав на просмотр" то таки-да, без глобального изменения конфы не обойтись. Но IMHO это справедливо не только для 7.7 а и для 8.х. (да я думаю не только для 1С а и для любой системы) Более того "права на изменение", которые в 7.7 легко реализуются с помощью "Перехватчика", в 8.x, опять-же IMHO, реализовать не получится ....

PS - Все измышления о возможности/невозможности рассматриваются в плане присоединения к готовой (типовой) конфигурации без ее изменения

Вообще подобный механизм можно реализовать только одним надежным путем: перехватить запрос 1С на доступ к Record (Row) - строке таблицы данных, и далее в зависимости от условий либо дать доступ либо не дать.