Проблема с ролями на крупных проектах
Меня зовут Алексей Куверзанов. Я тимлид группы разработки. В 1С я всего-навсего пять лет. За это время я успел поучаствовать где-то в трех проектах – крупных внедрениях. Это были и строительная компания, и атомная электростанция ближнего зарубежья, и крупная нефтянка. И все эти проекты объединяла одна боль: всегда были проблемы с ролями.
Казалось бы, что сложного? В 1С уже есть роли. Они созданы на каждый документ, все классно. Но как только мы касаемся конфигурации чуть больше, чем «1С:Управление нашей фирмой», возникают такие неприятные ошибки, как нарушения прав доступа.
Начал я разбираться с этим на примере 1С:ERP УХ. На изображении видно, что роль на добавление и изменение авансовых отчетов добавлена, но документ не может даже открыться, не говоря о том, чтобы записаться, провестись или что-то изменить. И это проблема не одного документа – она встречается повсеместно.
Каким образом можно решить эту проблему? Какие вообще есть варианты? Я видел три: страдать аналитику, разработчику или стажеру. Либо всем вместе.
Один из распространенных способов – разбить типовых пользователей на группы по функциональности и на каждую группу навесить набор прав. Так права раздаются быстрее. Мы знаем, в какую функциональную группу входит человек, и включаем его в соответствующую группу пользователей. Это такие папочки в списке. Если добавили новый объект и забыли навесить на него права, это уже вопрос к разработчикам.
Но проблема в том, что у типовых ролей групп доступа нет достаточного функционала, который заявлен.
Как появилась идея автоматизации
Разгар первого проекта, на который я пришел. Аналитики загружены, их не хватает. Команде разработки, так как она побольше, падает задача: за роли отвечаем мы. Выделяют двух разработчиков. На тот момент я тоже был разработчиком и, к несчастью, оказался одним из них.
База грузилась и перезапускалась 20–30 минут. Захожу, открываю ТЗ: надо добавить роли. Добавляю роли, запускаю – а у меня даже «1С:Предприятие» не может запуститься с базовыми правами.
Я посидел так пару дней и понял: так дело не пойдет. Мы вдвоем эти 20–30 групп пользователей будем делать полгода-год, бесконечное множество, и это просто насилие над всеми. И тут сработал такой эффект: я же разраб, как я могу сидеть и тупо тыкать? Я решил написать обработину, потому что посчитал, что это выйдет сильно быстрее, чем страдать. И интереснее.
Мы написали обработину полного цикла, которая помогает решить эту проблему. И самая лучшая новость – ее можно забрать бесплатно.
Обработка помогает анализировать уже созданные профили, создавать новые и добавлять необходимые роли в связанные объекты. Чаще всего проблема не в том, чтобы открыть документ, а в том, что нет прав на связанные объекты. Дальше обработка генерирует код для программного обновления профилей и обновляет регистр, где хранится весь этот кеш.
У нас все было построено так: мы создавали свои поставляемые роли, запихивали их в Конфигуратор как типовую поставку, и там нужно было обновление. Оно в обработке тоже есть.
Настройка и анализ объектов
Интерфейс я сделал максимально понятным, потому что мы разрабы и не хотели этим заниматься. В итоге все-таки передали обработку аналитикам, потому что здесь, кажется, справится даже пользователь.
На первом шаге есть несколько галочек, пугалочек и вкладок. Первая – «Включить связанные объекты метаданных». Эта галочка позволяет на следующем шаге расставить минимальные необходимые роли на связанные объекты.
У нас в компании было принято правило, что это чтение. Но в выпадающем списке можно выбрать изменение, добавление и все остальное – как кому нравится.
Другая галочка называется «Анализировать роли по профилю». Мы можем выбрать нужный профиль, обработка проставит все объекты метаданных, которые есть в этом профиле, и его можно будет проанализировать и дополнить базовыми ролями.
Таким образом можно взять базовый типовой профиль группы доступа и дополнить его базовыми правами так, чтобы он взлетел, а не пилить свой с нуля. При выборе чтения и команды «Проставить метаданные по профилю групп доступа» просто проставятся все нужные галочки.
На втором шаге мы попадаем в новое меню. На первой вкладке – «Основные объекты». Сюда попадают объекты, которые мы протыкали на первом шаге, и показываются все роли, которые так или иначе связаны с этим объектом. Здесь мы интерактивно сами выбираем роль, которая нам подходит. В помощь – галочки, которые показывают, что дает та или иная роль, если по названию это непонятно.
На следующем изображении показана вторая вкладка – «Связанные объекты». Туда затягиваются все связанные объекты по всей имеющейся вложенности. Условно, у нас есть «Заказ клиента», внутри – номенклатура. Мы получаем номенклатуру, а вместе с ней – все, что есть в номенклатуре. Все это тоже попадает в связанные объекты.
Здесь есть волшебная кнопка «Проставить минимальные роли». Она сама анализирует объекты по определенным критериям и расставляет минимальные роли на каждый связанный объект. На первом этапе мы выбрали чтение. Если бы выбрали изменение, обработка проставила бы роли на изменение.
Зеленым подсвечивается, если все получилось и все проставлено. Снизу появляется ошибка, если минимальная роль не найдена. По опыту, это уведомление, конечно, нужно, но такие ошибки не мешали запускать документы, и анализировать их приходилось редко.
На третьем шаге можно выбрать профиль группы доступа, создать новый или выбрать нужный и добавить роли в этот профиль. В этот момент все выбранные роли передаются в профиль группы доступа.
Важная поправка: обработка не учитывает видимость подсистем – в какой подсистеме находится документ. Здесь есть небольшая недоработка: это нужно сделать вручную.
Не учитывается RLS. Думаю, мы это доработаем.
И обработка долго думает на большом количестве документов, потому что перелопачивает все метаданные конфигурации. Чем больше конфигурация, тем дольше она думает. Цикл в цикле тоже никто не отменял.
По поводу подсистем есть еще одна классная, достаточно стандартная и общеизвестная обработка – «Анализ прав доступа». Благодаря ей можно выбрать роль, которая подходит для видимости подсистемы. Ставим галочку «Просмотр», выбираем нужную подсистему, в которой находится документ (можно посмотреть под администратором), и смотрим какая роль подходит для этого больше всего.
По опыту на больших проектах подсистемы выдавались избыточно. Поэтому мы либо создавали похожую роль с отключением подсистем, либо просто добавляли видимость какой-то конкретной подсистемы. То есть роли мы все-таки добавляли.
Перенос профиля между базами
Итак, мы добавили в профиль группы доступа все роли. Что делать дальше? Профиль создан, теперь его нужно как-то перенести из тестовой базы в другую тестовую, потом в препрод, в прод. Обработка этот момент тоже учитывает. Мы не любим ничего делать руками, хотим, чтобы все было автоматически.
На четвертом шаге встроена типовая обработка, которая формирует профиль группы доступа в виде кода. Выбираем профиль, который заполняли на третьем шаге, либо другой, если это нужно, и нажимаем кнопку «Сформировать».
Получается такая процедура. Она формируется, конечно, в режиме «1С:Предприятие», но я решил показать ее сразу в Конфигураторе.
Как видно на изображении, в ней указываются папка, идентификатор, наименование, а дальше – добавление профилей.
На пятом шаге мы обновляем настройки профилей. Нажимаем одну волшебную кнопку, затем перезапускаемся – и профили групп доступа уже появляются в системе.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
