При администрировании и разработке в крупных корпоративных системах на базе 1С:ERP Управление предприятием 2.4 (а также КА 2.5 и УТ 11) специалисты часто сталкиваются со следующей проблемой: два пользователя имеют абсолютно одинаковый набор ролей в системе, но один из них может беспрепятственно проводить документы по выбранному складу, а у второго система выдает ошибку прав доступа.
В этой статье мы подробно разберем, почему возникает подобная ситуация, как быстро локализовать проблему с помощью отладки, в каких случаях виновата скрытая доработка (кастомный код), а как решить задачу разграничения прав по складам абсолютно типовыми средствами платформы 1С:Предприятие 8.3.
Рассмотрим ситуацию, описанную коллегами на форуме. Пользователь пытается провести документ, но получает ошибку. При этом роли у текущего сотрудника и у ответственного лица, указанного в карточке склада, полностью идентичны. Логично возникает вопрос: почему права ведут себя по-разному?
Для начала проанализируем поведение реквизита Ответственный в справочнике Склады в стандартной (коробочной) конфигурации 1С:ERP. В типовом решении этот реквизит выполняет исключительно информационную и представительную функцию:
ТекущийПользователь() = Склад.Ответственный.Поэтому, если ваша система физически блокирует проведение документа пользователем только из-за того, что он не указан в поле "Ответственный" карточки склада, — это 100% кастомная доработка. Чаще всего такие проверки внедряются через механизмы расширений конфигурации или подписки на события ПередЗаписью / ОбработкаПроведения.
Если вы столкнулись с подобным поведением системы, не спешите гадать по ролям. Проведем детальный анализ базы данных с помощью конфигуратора. Разберем по шагам, как локализовать место, где программа накладывает ограничение:
Если ошибка вызывается принудительно, в коде расширения вы, скорее всего, обнаружите конструкцию, аналогичную следующей:
// Пример кастомной проверки в расширении перед записью документа
&После("ПередЗаписью")
Процедура Инт_ПередЗаписьюПроверитьОтветственного(Отказ, РежимЗаписи, РежимПроведения)
Если РежимПроведения = РежимПроведенияДокумента.Проведение Тогда
// Проверяем наличие реквизита Склад в документе
Если ОбщегоНазначенияКлиентСервер.ЕстьРеквизитИлиСвойствоОбъекта(ЭтотОбъект, "Склад") Тогда
ТекущийСклад = ЭтотОбъект.Склад;
Если ЗначениеЗаполнено(ТекущийСклад) И ЗначениеЗаполнено(ТекущийСклад.Ответственный) Тогда
// Сравниваем авторизованного пользователя с ответственным на складе
Если ТекущийСклад.Ответственный <> ПараметрыСеанса.ТекущийПользователь Тогда
ТекстСообщения = "Ошибка! Проводить документы по складу '" + СокрЛП(ТекущийСклад) + "' может только ответственный: " + СокрЛП(ТекущийСклад.Responsibility);
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения, , , , Отказ);
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Если в ходе отладки вы обнаружили подобный код, то задача по разграничению прав действительно решена некорректным (нетиповым) путем. Это создает проблемы при обновлении конфигурации и путает пользователей. Но как реализовать это требование бизнеса правильно?
Для того чтобы решить задачу ограничения прав проведения документов по складам без написания кода и создания кастомных расширений, необходимо использовать встроенный штатный механизм платформы — RLS (Row-Level Security), или ограничение доступа на уровне записей.
Именно благодаря RLS у двух пользователей могут быть абсолютно одинаковые профили и роли, но разные права на фактические данные (в данном случае — на склады). Разберем по шагам, как настроить такое ограничение:
Для начала убедимся, что механизм RLS активирован в нашей информационной базе. Выполним следующие действия:
Важно: активация этого флага может временно замедлить работу системы в момент первого применения настроек, так как платформа начнет пересчитывать ограничения прав для всех таблиц базы данных.
Теперь создадим правила, по которым пользователи будут получать доступ только к разрешенным складам. Нам не нужно менять роли или профили пользователей. Мы разделим их на уровне групп доступа:
Для второго пользователя проделаем аналогичную операцию: создадим группу доступа "Кладовщики Склада №2", укажем тот же профиль "Кладовщик", добавим в участники второго пользователя, а в ограничениях доступа по складам выберем "Склад №2".
После настройки RLS система начнет автоматически фильтровать данные на уровне СУБД:
Недостаточно прав для выполнения операции или склад просто не будет доступен для выбора в форме документа.Таким образом, мы проанализировали проблему разграничения прав, выяснили причины странного поведения одинаковых ролей и научились решать бизнес-задачи наиболее эффективным, встроенным в 1С:ERP методом.