При настройке прав доступа для различных категорий пользователей в конфигурации «1С:Бухгалтерия предприятия 3.0» администраторы и разработчики часто сталкиваются с неочевидным поведением системы. Две наиболее популярные проблемы — это внезапное «исчезновение» доступных полей (например, поля Склад) в настройках отчетов у менеджеров и неработающий запрет на проведение документов, даже если соответствующие галочки в роли конфигуратора были сняты.
В этой статье мы подробно разберем механизмы платформы «1С:Предприятие 8.3», которые приводят к подобным ситуациям, выясним первопричину такого поведения системы и найдем практические, безопасные способы решения обеих проблем.
Рассмотрим ситуацию: бухгалтер открывает стандартный отчет «Продажи по контрагентам» и спокойно настраивает фильтрацию по складу, организации или менеджеру. Однако пользователь с правами «Менеджер по продажам» в этом же самом отчете видит гораздо меньше доступных полей, а поле Склад в списке доступных полей компоновки данных отсутствует вовсе. Почему так происходит?
Причина кроется в особенностях работы Системы компоновки данных (СКД), на базе которой строятся практически все современные отчеты в 1С. СКД тесно интегрирована с системой прав доступа платформы и работает по строгому принципу безопасности:
Чтение (Read) и Просмотр (View) на конкретный объект метаданных (например, справочник Склады или соответствующий регистр накопления), СКД автоматически исключает данный объект и все связанные с ним реквизиты из структуры доступных полей отчета. Пользователь даже не узнает о существовании этого поля в схеме компоновки.Выясним, как исправить эту проблему. Для того чтобы вернуть менеджеру возможность использовать поле Склад в отборах отчетов, необходимо предоставить ему права на чтение и просмотр справочника Склады. Напрямую изменять типовые роли в конфигураторе крайне не рекомендуется, так как это усложнит последующие обновления базы данных. Разберем правильный алгоритм действий через режим «1С:Предприятие».
Пошаговое решение:
Чтение данных складов или аналогичную роль, содержащую права на справочник Склады), и установим напротив нее флаг.После перезапуска сеанса пользователем СКД перестроится, обнаружит наличие прав на объект Справочник.Склады и автоматически выведет поле Склад в доступные поля отбора отчета.
Теперь проанализируем вторую, не менее распространенную проблему. Администратор решает ограничить менеджерам возможность проведения документа РеализацияТоваровУслуг. Для этого в конфигураторе он создает или изменяет роль (например, ПраваМенеджеров), где на вкладке «Права» для документа Реализация товаров и услуг снимает флаги с пунктов:
ПроведениеОтмена проведенияИнтерактивное проведениеИнтерактивная отмена проведенияОднако после сохранения конфигурации и запуска системы под учетной записью менеджера выясняется, что документ все равно отлично проводится. Функция проведения остается доступной.
Разберем причину этой проблемы. Она заключается в фундаментальном механизме работы платформы «1С:Предприятие 8.3» — принципе кумулятивности (объединения) ролей по логическому правилу «ИЛИ».
В системе 1С пользователю почти никогда не назначается всего одна роль. В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) права пользователя формируются динамически из десятков различных ролей, входящих в его профили групп доступа. Если пользователю назначено, к примеру, 15 ролей, то платформа проверяет права по следующему принципу: если действие разрешено хотя бы в одной из этих 15 ролей, то действие считается разрешенным для пользователя в целом.
Даже если в вашей кастомной роли ПраваМенеджеров проведение строго запрещено (сняты галочки), но пользователю одновременно назначена стандартная роль Добавление и изменение документов продаж или даже общая роль Базовые права, в которой проведение разрешено, то платформа проигнорирует ваш точечный запрет и позволит провести документ.
Чтобы запретить проведение документов стандартными средствами ролевой модели, вам придется найти абсолютно все роли, назначенные данному пользователю, и в каждой из них снять галочки проведения для документа РеализацияТоваровУслуг. На практике это практически невыполнимо, поскольку многие роли являются системными и их изменение нарушит логику работы других механизмов конфигурации.
Как же поступить в такой ситуации? Самым современным, надежным и безопасным способом решения данной задачи является использование расширений конфигурации. Этот механизм позволяет перехватить транзакцию записи или проведения документа на уровне кода и программно отменить ее для определенных пользователей, не затрагивая при этом типовые роли и не мешая будущим обновлениям программы.
Рассмотрим по шагам процесс создания такого ограничения:
ЗапретПроведенияМенеджерам), снимем у него флаги «Безопасный режим» и «Защита от опасных действий» (если это необходимо для выполнения кода БСП).РеализацияТоваровУслуг. Для этого в основной конфигурации найдем данный документ, нажмем по нему правой кнопкой мыши и выберем Добавить в расширение.РеализацияТоваровУслуг внутри нашего расширения. Нам нужно перехватить процедуру ПередЗаписью.Напишем программный код, который будет проверять режим записи документа (проведение) и доступность определенной роли у текущего пользователя. Если пользователь пытается провести документ, а у него нет на это прав, мы прервем операцию и выведем понятное предупреждение.
Посмотрим на пример реализации такого кода в модуле расширения:
&После("ПередЗаписью")
Процедура Расш1_ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// Проверяем, выполняется ли именно проведение документа
Если РежимЗаписи = РежимЗаписиДокумента.Проведение Тогда
// Метод РольДоступна() проверяет наличие конкретной роли у текущего пользователя.
// Допустим, мы создали в расширении роль "Расш1_РазрешеноПроводитьРеализации".
// Если этой роли у пользователя нет, мы блокируем проведение.
Если Не РольДоступна("Расш1_РазрешеноПроводитьРеализации") Тогда
Отказ = Истина; // Отменяем транзакцию записи и проведения
// Выводим информационное сообщение для пользователя
ПоказатьПредупреждение(, "Уважаемый пользователь! У вас нет прав на проведение документов реализации.
|Вы можете только сохранять их в качестве черновиков (записывать без проведения).");
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Проанализируем работу этого алгоритма подробнее. При попытке пользователя нажать на кнопку «Провести и закрыть» или «Провести» в документе реализации платформа инициирует событие записи. Программа заходит в созданный нами обработчик ПередЗаписью. Наша процедура срабатывает после основной («&После»), проверяет, равен ли параметр РежимЗаписи системному значению РежимЗаписиДокумента.Проведение.
Если условие выполняется, система проверяет, назначена ли пользователю специальная роль Расш1_РазрешеноПроводитьРеализации (которую мы предварительно создали в этом же расширении и выдали только руководителям или бухгалтерам). Если роль не обнаружена, переменной Отказ присваивается значение Истина. Платформа мгновенно прекращает транзакцию записи, документ не проводится, а менеджер получает понятное и вежливое уведомление на экране.
Этот способ обладает неоспоримыми преимуществами:
Таким образом, мы детально разобрали особенности функционирования подсистемы прав доступа 1С, выяснили причины возникновения сложностей с отборами СКД и проведением документов, а также изучили надежные методы их решения.