Подсистема прав доступа (анализ ролей, отладка RLS, Eng код, обычные и управляемые формы) [infostart.ru]

Складчина: Подсистема прав доступа (анализ ролей, отладка RLS, Eng код, обычные и управляемые формы) [infostart.ru]

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

Спойлер: про проблемы

1. Нельзя прочитать RLS, т.е. внедренец ставя ограничение на роль – вообще без понятия о том, что там эта роль реально ограничивает и по каким правилам. Например, есть некая роль:

1. Роли, при наличии БСП, хоть и являются «универсальными», однако, они все равно не перекрывают все потребности. А особую сложность в понимании несут роли, которые дают доступ к разным объектам. Т.е. надо четко уметь отделить некое право, и посмотреть – какие роли его дают. В идеале – одна роль, дает одно право.
2. В конфигурациях бывают баги, а бывают тонкости, про которые далеко не все знают, например, одна роль на чтение может иметь РЛС на некий справочник, а совсем левая роль на изменение (от другой подсистемы), может к этому справочнику давать безусловное чтение. Баг это, или фича, не важно, но такое есть, и хорошо бы такое отлавливать.
3. Отдельное счастье – отладка RLS, что сейчас в принципе невозможно, так как язык RLS – он не тот же самый язык 1С (BSL), и просто написать – не всегда получится.
4. Любое изменение роли – требует лезть в конфигуратор. Любое добавление – роли, надо идти в конфигуратор, надо тестировать под пользователем, открывать все параметры сеансов, смотреть что где, в общем трешь.
5. И когда выходит обновление конфы – надо перепроверять, не обновились ли шаблоны, и если они обновились, то тогда надо вот в те новые 10 ролей идти, и перекидывать шаблоны, обновлять каждую роль.
6. История изменения ролей. Кто, когда, зачем и на кой черт попросил что-то поправить. Т.е. т.к. роли добавляет программист, то он берет все входные данные и группирует их, а потом идет делает новые роли, или модификацию предыдущих, и вот потом разобраться – зачем была та или иная модификация, или же – какая модификация была на какую-то там дату – это не реально, разве что в задачниках, но и там надо каждый чих отслеживать, и как-то группировать, чтобы найти.
7. Ну и мой самый любимый прикол – это когда тебе попадается в руки УТ10, УТП и им подобные, где уже никто ничего не понимает, что творится в ролях, никакого анализа адекватного нету, и пользователей просто создают «по аналогии», так как там изначально всего десяток ролей.
8. И куча всякого другого…

Итого, была поставлена задача по написанию принципиально нового подхода к разработке ролей:

1. Это будет внешняя подсистема, отсутствие которой никак не скажется на конфигурацию. Т.е. модульность.
2. Подсистема должна быть универсальной, и не привязываться, практически ни к каким модулям конфигурации или ее объектам.
3. Основные функции системы – анализ ролей, отладка правил, создание новых ролей, хранение истории изменения ролей и т.д.

И такая подсистема была создана.

Вся суть работы с подсистемой - описывается в пару шагов:

1. Подключение расширения к конфигурации

2. Загрузка ролей из XML

3. Создание новых ролей

4. Авто генерация нового расширения с новыми ролями

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

Код:

https://infostart.ru/public/1222978/