20.09.2014
В языке запросов существует директива «Разрешенные». Она предназначена для отсеивания платформой записей, на которые у пользователя нет прав, при настройке ограничения на уровне записей базы данных.
Казалось бы, в запросах лучше всегда использовать данную директиву. Буду утверждать, что это не так. Так же, буду утверждать, что по возможности, стоит избегать её использования, вот почему.
Допустим, мы делаем отчет по взаиморасчетам физических лиц. У пользователя есть права на одну организацию, а в базе данных находится более одной организации и в базе данных включено ограничение на уровне записей. Так же, в базе данных есть регистр «Взаиморасчеты» с измерениями «Организация» и «Физлицо». Если в системе будет запрос
«Выбрать
Организация,
ФизЛицо
Из РегистрНакопления.Взаиморасчеты
и он будет выполняться от имени пользователя с разрешением на одну организацию, то запрос не выполниться, при наличии записей других организаций в этом регистре. Случиться ошибка, а описание ошибки будет «У пользователя не достаточно прав для выполнения запроса!» и это действительно так, платформа не обманывает, поскольку у него нет прав на записи других организаций в этом регистре.
Что же делать в этом случае, использовать директиву «Разрешенные»? На мой взгляд не стоит. Необходимо всего лишь установить отбор по организации и пользователь сможет сформировать отчет. Запрос для отчета с компоновкой данных будет выглядеть так
«Выбрать
Организация,
ФизЛицо
{Выбрать
Организация
,ФизЛицо}
Из РегистрНакопления.Взаиморасчеты
{Где
Организация
,ФизЛицо}
Если пользователь будет выполнять запрос к таблице без отбора, то отчет не сформируется, и пользователь не узнает данных по другим организациям, а если он поставит отбор по своей организации, то сформирует с корректными данными.
Вы можете снова спросить – «Почему же не стоит применять директиву Разрешенные», это сразу накладывает отбор, убережет пользователя от не нужных ему сообщений!
На этот вопрос ответ будет такой – как в этом случае пользователь узнает, что в отчет попали все нужные данные. Допустим, ранее, этот пользователь работал под полными правами и ошибся и выбрал в документе физлицо из другой организации. Так же может быть ситуация, данные загружались – и в документы организации записалось подразделение другой организации (в ЗУП на них тоже накладываются ограничения по владельцу). В этом случае директива «Разрешенные» отсечет запрещенные данные без каких-либо сообщений пользователю, и он не узнает, что в отчет попало не все, что должно попасть.
Поэтому – не стоит повально вписывать данную директиву в запросы типовых конфигураций считая это ошибкой. Очень не рекомендуется это делать в запросах регламентированной отчетности. Так же не стоит это делать в других отчетах и документах, где нужна точность информации.
А как же все-таки избежать ошибки «падения» программы при не хватке прав?
Да очень просто, необходимо использовать команду «Попытка», вот пример:
Попытка
Запрос.Выполнить();
Исключение
Сообщить(ОписаниеОшибки());
КонецПопытки;
В отчетах с использованием СКД программный код исполнения отчета необходимо написать вручную, так же через попытку.
В результате, пользователь не получит не корректных данных и получит вменяемое сообщение об ошибке.
Можно ознакомиться с нюансами настройки RLS в обособленных подразделениях в нашей статье.
Если вы не нашли у нас необходимые вам доработки, то мы можем предложить индивидуальное сотрудничество.
Мы работаем исключительно посредством удаленного доступа.
Связаться с нами можно через диалог обратной связи, ICQ, skype или по телефону.
Рабочие дни: 10:00-16:00
+7 (916) 020-33-02
21.09.2014
Разграничение прав доступа для пользователей ЗУП на уровне записей по обособленным подразделениям для ЗУП 2.520.09.2014
Использование директивы «Разрешенные».06.04.2014
Установка IIS для 1С Предприятия 8.3 в картинках на платформе WINDOWS 8.121.02.2014
Унифицированная печатная форма Т-6а (альтернативная), Зарплата и Управление Персоналом 2.520.02.2014
Унифицированная печатная форма Т-6 (альтернативная), Зарплата и Управление Персоналом 2.501.12.2013
Отчет "История основного начисления", Зарплата и Управление Персоналом 2.505.11.2013
День рождения нашего сайта!
Комментарии к этой записи в блоге