1. Цель публикации
Цель данной статьи ознакомиться с особенностями работы системы ограничения доступа на уровне записей (RLS) в конфигурации УНФ.
Эта система, на уровне организаций, была добавлена в УНФ , начиная с версий конфигурации 1.6.13, в январе 2018 года. УНФ развивается настолько быстро, что статьи на тему RLS успевают устаревать за короткое время. Так, предыдущая публикация на эту тему: //infostart.ru/public/829474/ датируется весной 2018 года и касается версии 1.6.5, когда системы RLS в УНФ ещё не было. На момент написания этой статьи, ноябрь 2018, она уже есть и в неё также добавлены ограничения по контрагентам для подсистем "Продажи" и "Закупки" с той целью, чтобы менеджеры видели только своих клиентов, и лидам для подсистемы "CRM".
Ладно бы только статьи устаревали, но быстрое развитие влечёт за собой и не всегда корректную работу программы. Из-за этого в среде 1С бытует мнение, и не без оснований, о том, что не стоит торопиться устанавливать самые последние версии платформы и конфигураций.
Конечные покупатели УНФ также осведомлены о наличии этой системы, благо вебинаров и прочих материалов в сети достаточно, и хотят воспользоваться её возможностями. Так и я, до поры, отметил для себя наличие этой системы по информационным материалам. А когда обратился клиент с просьбой организовать разграничение доступа по организациям, с удивлением, вскоре сменившимся любопытством, обнаружил, что работает эта система, мягко говоря, не совсем так, как следует. И это привело меня к идее создания расширения, устраняющего выявленные недостатки, которое и представлено ниже.
2. Описание проблемы
О каких недостатках речь? Это не критичные моменты, к чести разработчиков. Они возникли, по всей видимости, как следствие быстрого развития УНФ. Так, в журналах документов ограничение доступа по организациям работает идеально во всех разделах программы. Если их вывести на начальную страницу, то всё работает замечательно. Проблема обнаруживается при попытке пользователя, у которого установлены ограничения, зайти в документы разделов через основное панель разделов – Закупки, Продажи, Производство, Деньги и Работы. Принцип, декларируемый 1С как «система автоматически учитывает при построении интерфейса права пользователя. Например, из командного интерфейса исключаются команды для доступа к объектам, которые пользователю недоступны», работает. Если не дать пользователю доступ к разделу, то этого раздела в интерфейсе пользователя не будет. На систему RLS, ограничивающую доступ к некоторым данным, данное правило не распространяется.
Проблема была выявлена на базе клиента в конфигурации 1.6.15.39, а затем сделан контрольный пример в последней конфигурации серии 1.6.15 – 1.6.15.63.
3. Контрольный пример
Создал три организации - Компания А, Компания Б, Компания В, а также оставил организацию «Наша фирма» как предопределённый элемент. Далее создал три товара, из которых 2 производятся по спецификациям из материалов (Товар 1 – в Компании А, Товар 2 – в Компании Б) и один для торговли – Товар 3. По Компании А создана цепочка документов: Заказ покупателя на Товар 1 – Заказ на производство – Заказ поставщику – Приходная накладная – Производство – Расходная накладная. По компании Б - аналогичная цепочка, с той разницей, что Товар 2 производится из 2х материалов, поэтому заказов поставщику понадобилось два. По Компании В проходит только Приходная накладная на товар 3, который реализуется Расходной накладной. В последнем случае – чистый «рынок», никаких заказов и планов. По организациям приняты на работу сотрудники и созданы соответствующие им пользователи:
Компания А: Заведующий складом А, Менеджер А, рабочий А
Компания Б: Заведующий складом Б, Менеджер Б, рабочий Б
Компания В: Заведующий складом В.
В центральном офисе («Наша фирма») – Администратор.
Права заведующих складов А и Б аналогичны:
Для подсистемы Закупки Зав складами предоставлен доступ ко всем организациям, другие подсистемы доступны только по своей компании.
Менеджерам права заданы по-разному, для А – все организации запрещены, одна разрешена.
Для Б – наоборот, все организации разрешены и запрещены все, кроме одной.
Как реагирует стандартная версия УНФ? В журналах документов , повторюсь, всё в порядке.
Также нет проблем с ограничениями доступа из раздела «Главное». А при попытке зайти в документы раздела «Продажи» получается следующее:
Полагаю, это не совсем то, что требуется в описанной выше ситуации.
Аналогичная картинка в разделе «Производство»:
И во всех других разделах.
При этом у менеджеров ограничение в 1.6.15.39 также не работает, а в 1.6.15.63 уже работает. Но только для менеджеров. То есть, что-то разработчики доделали, но не до конца.
На этом основании можно утверждать, что представленный здесь продукт пригоден для всех версий серии 1.6.15, а также для более ранних конфигураций, где предусмотрена система RLS.
4. Решение
С расширением все ограничения отрабатывают так, как их представляет себе пользователь:
Для ограничений, заданных другим способом, также всё в порядке.
При попытке выбрать другую компанию в конфигурации с расширением возникает некритическая ошибка. Привожу её для специалистов, чтобы было понятно, каким образом это реализовано:
Ограничения доступа остаются прежними.
Расширение ограничивает доступ к записям во всех разделах программы. А также учитывает ту ситуацию, что касса для организаций может быть одна. Если задать ограничения по кассе и внести кассу в соответствующий справочник, то стандартная конфигурация отработает и сама. Но пользователь может этого и не сделать. И ещё много чего может не сделать или сделать такого, что не укладывается в логику разработчиков. И стандартный вариант работать перестаёт.
Для специалистов скажу, что, поскольку работа расширения начинается в процедуре После, то, даже в случае, если разработчики УНФ решат исправить ситуацию, расширение не слетит и ничего не изменит, просто начнёт работать стандартный вариант.
Всё вышеизложенное касается только ограничения доступа по организациям.
Надеюсь, данное расширение положительно повлияет на Ваше отношение к отличной конфигурации - УНФ.
Всем удачи и позитива!