Каталог решений - Подсистема прав доступа (анализ ролей, отладка RLS, английский код, обычные и управляемые формы)

Немного про проблемы, которые мы хотели решить этой подсистемой

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

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

Глядя на нее в конфигураторе — можно прочитать текст ограничения, и понять, как оно сработает.

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

Принятое решение

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

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

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

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

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

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

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

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

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

Как это все выглядит?

1. Подключается новое расширение, возьмем для примера УТ11:

1. Параметры, пока оставим их, но суть в том, что можно создавать свои параметры сеанса.
2. Пользователи – это просто сам справочник пользователей, из основной конфигурации.
3. Профили доступа – этот справочник, по сути, аналогичен типовым из БСП, там просто есть таблица с ролями, и это позволяет комбинировать роли для конкретного пользователя, например.
4. Роли доступа — это справочник самих ролей, вот прям ролей, которые есть в конфигурации.
5. Шаблоны – это шаблоны ролей. У 1С в конфигурации нет единого объекта шаблонов ролей, а на каждую роль – идет свое, однако, в нашем случае – это единый общий справочник.
6. Отчет, который позволяет проанализировать роли.
7. Загрузка данных ролей из XML.
8. Конвертация шаблонов в код BSL.
9. Генерация и подключения расширения с новыми ролями.
10. Используется для обычных форм, это просто обработка с теми же 3 кнопками, что и выше.

2. Идем в опцию загрузки ролей "Загрузка данных ролей из XML" , и загружаем роли:

При открытии — программа определит текущее подключение и заполнит настройки:

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

При загрузке, если что-то пойдет не так, то программа покажет лог. Status отличный от нуля — значит произошла ошибка.

Если есть ранее выгруженная конфигурация в XML файлы (это можно сделать  зайдя в конфигуратор, и выбрав меню "Конфигурация — Выгрузить конфигурацию в файлы", или же есть конфигурация в исходниках формата EDT, то можно выбрать третий пункт — "XML файлы конфигурации" и указать путь к верхней папке, т.е. внутри этот папки должна быть папка Roles, по сути, только она и нужна, остальные папки не сканируются.