При администрировании современных конфигураций на платформе «1С:Предприятие 8.3», разработанных на базе Библиотеки стандартных подсистем (БСП), часто возникает специфическая задача. Нам необходимо предоставить пользователю доступ в информационную базу так, чтобы при запуске тонкого или толстого клиента он видел абсолютно пустой интерфейс (чистый рабочий стол) без стандартных разделов («Продажи», «Покупки», «Банк и касса», «Склад» и т. д.). На этом «пустом холсте» мы планируем вывести только одну специализированную подсистему с ограниченным набором объектов, созданную специально для этой роли (например, для курьера, оператора ввода данных или внешнего аудитора).
В этой статье мы подробно разберем, как решить эту задачу, проанализируем списки стандартных ролей, выясним причины возможных ошибок при запуске системы и рассмотрим альтернативные, более надежные способы реализации такого механизма с помощью расширений конфигурации.
На первый взгляд задача кажется тривиальной: достаточно создать новую роль, дать ей права на запуск клиента, назначить пользователю и отключить видимость стандартных подсистем. Однако на практике разработчики сталкиваются с лавиной ошибок вида «Недостаточно прав доступа» на самом этапе инициализации программы. Выясним причину этого поведения.
Современная конфигурация «1С:Бухгалтерия предприятия 3.0» (БП 3.0) при запуске выполняет сотни служебных операций. Платформа и механизмы БСП обращаются к различным константам, параметрам сеанса, служебным регистрам сведений, справочникам классификаторов и системным механизмам. Если у пользователя нет прав на чтение этих объектов, сеанс аварийно завершается, даже не успев отрисовать главное окно программы. Поэтому для успешного входа требуется строго определенный «технологический минимум» ролей.
Рассмотрим минимальный набор стандартных ролей, который позволяет успешно запустить клиентское приложение в БП 3.0 и получить пустой рабочий стол без лишних разделов. На основе практического опыта администраторов и разработчиков, для простого открытия программы в режиме предприятия достаточно предоставить следующий базовый пакет прав:
Этого набора ролей достаточно исключительно для самого факта успешной авторизации. Однако, как показывает практика реальной эксплуатации, как только пользователь попытается совершить минимальные действия в своей кастомной подсистеме, система начнет выдавать ошибки. Для стабильной работы интерфейса и базовых механизмов платформы этот список необходимо расширить.
Проанализируем расширенный список ролей, гарантирующий бесконфликтную работу клиентского приложения:
Если пользователю в дальнейшем потребуется работать хотя бы с базовыми справочниками, вам также придется точечно добавить роли на просмотр контрагентов, договоров, номенклатуры, физических лиц и складов. Полный список таких прав собирается индивидуально под бизнес-требования конкретной должности.
Обратим особое внимание на главный недостаток ручного формирования профиля из десятков мелких базовых ролей. Этот подход обладает высокой чувствительностью к обновлениям конфигурации.
Фирма «1С» регулярно выпускает обновления для «Бухгалтерии предприятия». С каждым новым релизом в систему добавляются новые служебные регистры, константы контроля, новые интеграции (например, с государственными информационными системами маркировки, прослеживаемости товаров и т. д.). Очень часто разработчики жестко зашивают обращение к этим новым объектам в модули управляемого приложения при начале работы системы.
После очередного обновления ваш филигранно настроенный профиль «Только вход» перестанет работать. Пользователь получит ошибку прав доступа при входе, и вам как администратору придется в экстренном порядке запускать конфигуратор, включать отладку и искать, чтение какого нового служебного регистра теперь требуется добавить в профиль. Это создает серьезные риски простоя бизнес-процессов.
Для обхода проблемы с обновлениями современные разработчики используют более изящное архитектурное решение. Вместо того чтобы собирать «куцый» профиль из сотен ролей, мы идем от обратного. Рассмотрим этот алгоритм по шагам:
Мы назначаем нашему ограниченному пользователю стандартный поставляемый профиль «Только просмотр». Этот профиль поддерживается самой фирмой «1С» в актуальном состоянии. В него гарантированно входят абсолютно все служебные права, необходимые для успешного и беспроблемного запуска системы после любых обновлений конфигурации.
Создаем небольшое расширение конфигурации, которое не влияет на поддержку основной базы данных. В этом расширении мы создаем собственную уникальную роль (например, Роль_ТолькоСвояПодсистема), которую также назначаем нашему пользователю.
В расширении мы перехватываем процедуру запуска управляемого приложения. Нам нужно написать программный код, который анализирует роли текущего пользователя. Если система обнаруживает у пользователя нашу специфическую роль, она динамически «на лету» скрывает все стандартные разделы командного интерфейса конфигурации.
Проанализируем пример кода, который можно разместить в модуле управляемого приложения расширения (в обработчике события ПриНачалеРаботыСистемы):
&НаКлиенте
Процедура Расш1_ПриНачалеРаботыСистемыПеред(Отказ)
// Проверяем наличие нашей ограничивающей роли у текущего пользователя
Если РольДоступна("Роль_ТолькоСвояПодсистема") Тогда
// Отключаем видимость стандартных разделов интерфейса
Для Каждого Подсистема Из Метаданные.Подсистемы Цикл
// Разрешаем видеть только нашу специализированную подсистему
Если Подсистема.Имя <> "НашаСпециализированнаяПодсистема" Тогда
// Программное управление видимостью элементов интерфейса
// (в зависимости от конкретной реализации структуры интерфейса БСП)
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецПроцедуры
Используя этот подход, мы получаем колоссальное преимущество: под капотом у пользователя работают все легитимные стандартные права (он успешно проходит все проверки при старте системы), но визуально его рабочий стол остается абсолютно чистым, за исключением одной разрешенной нами подсистемы. При этом любые обновления конфигурации проходят абсолютно бесшовно.
В Библиотеке стандартных подсистем предусмотрены специальные штатные точки интеграции, позволяющие управлять командным интерфейсом программы без жестких ограничений на уровне СУБД.
Разберем, как использовать общий модуль ОбщегоНазначенияПереопределяемый. В нем присутствует специализированная процедура, в которой мы можем переопределить состав доступных пользователю разделов панели разделов. Нам достаточно вставить проверку прав пользователя и программно очистить массив доступных подсистем, оставив только нашу целевую подсистему.
Этот способ является наиболее «чистым» с точки зрения методологии разработки в экосистеме 1С, так как мы используем штатный программный интерфейс (API), заложенный создателями БСП специально для этих целей.
Мы рассмотрели различные варианты реализации профиля «Только вход» в 1С:Бухгалтерия 3.0. Если вам необходимо быстро решить задачу стандартными средствами в пользовательском режиме (без программирования), вы можете воспользоваться списком ролей из Способа 1. Однако помните о рисках последующих обновлений.
Если же вы нацелены на создание отказоустойчивой системы, которая не потребует вашего вмешательства при каждом релизе «1С», настоятельно рекомендуем использовать Способ 2 (с расширением) или Способ 3 (через переопределяемые модули). Это сбережет ваше время и обеспечит стабильную работу пользователей.