Проверка прав доступа

Область применения: управляемое приложение, обычное приложение.

1. В случае большого количества ролей в конфигурации (от нескольких десятков) не рекомендуется использовать ролевую настройку видимости в элементах форм (просмотр и редактирование реквизитов по ролям, пользовательскую видимость полей формы по ролям, использование команд по ролям). Вместо этого следует придерживаться следующих подходов:

• при сильных различиях внешнего вида и функциональности формы в зависимости от наличия тех или иных ролей у пользователя – разрабатывать отдельные формы, специализированные под конкретный набор прав пользователя;
• при незначительных отличиях – выполнять проверку прав в коде. При этом следует иметь в виду, что программное управление видимостью может снизить скорость открытия формы, что нужно учитывать при выборе между предлагаемыми подходами.

Эти меры позволяют:

• существенно упростить работу из кода с элементами управления, которые пропадают из коллекции Элементы (код Элементы.ИмяЭлемента.ИмяСвойства становится нерабочим);
• повысить устойчивость кода к пересмотру состава ролей в конфигурации;
• организовать контроль использования ролей в конфигурации (в противном случае, выполнять анализ прав доступа по флажкам, назначенных для ролей в различных элементах произвольных форм конфигурации, крайне затруднительно).

2. Не рекомендуется использовать ролевую настройку видимости в командном интерфейсе конфигурации, командном интерфейсе основного раздела, а также рабочей области начальной страницы. Вместо этого следует использовать настройку прав на разделы командного интерфейса, общие формы и объекты, включенные в командный интерфейс или в рабочую область. Это позволяет повысить предсказуемость поведения управляемого интерфейса для пользователя, а также упростить расследование ошибок.

3. Для проверки прав доступа в коде следует использовать метод ПравоДоступа .
Например, неправильно:

Если РольДоступна(«ДобавлениеИзменениеСтранМира») Тогда .
Если РольДоступна(«ПросмотрОтчетаПопулярныеСтраны») Тогда .

Если ПравоДоступа(«Редактирование», Метаданные.Справочники.СтраныМира) Тогда .
Если ПравоДоступа(«Просмотр», Метаданные.Отчеты.ПопулярныеСтраны) Тогда .

Такой подход позволяет повысить устойчивость кода к пересмотру состава ролей в конфигурации.

4. В тех случаях, где роль не дает никаких прав на объекты метаданных, а служит только для определения того или иного дополнительного права, следует использовать метод РольДоступна . При использовании в конфигурации Библиотеки стандартных подсистем (БСП) следует использовать функцию РолиДоступны общего модуля Пользователи :
Например, без использования БСП:

Если РольДоступна(. ) Или Или ПривилегированныйРежим() Тогда .

Либо аналогичная проверка с использованием БСП:

Источник

Проверка наличия роли у пользователя

Проверка с помощью функции глобального контекста РольДоступна()

Если в программном коде необходимо проверить установлена ли какая-либо роль у текущего пользователя, то можно воспользоваться функцией глобального контекста РольДоступна( ), которая возвращает значение Истина, если указанная в скобках роль доступна и Ложь, если не доступна.

Однако, в конфигурациях на основе БСП при включении пользователя в предопределенную группу доступа Администраторы, пользователю назначаются только две роли: Полные права и Администрирование (в этом можно убедиться с помощью Конфигуратора: Администрирование — Пользователи — Пользователь — Прочие). Все остальные роли отключаются вне зависимости от того, включен ли пользователь в какие-либо еще группы доступа. Система считает, что другие роли этому пользователю не нужны. Поэтому функция РольДоступна() возвращает в этом случае Ложь, что не подходит для решения нашей задачи.

Проверка с помощью функций БСП

Проверить наличие роли можно также с помощью функций БСП: Пользователи.РолиДоступны() и УправлениеДоступом.ЕстьРоль(). Но данные функции для полноправного пользователя (с ролями Полные права или Администратор системы) вернут всегда Истину независимо от того, назначена ли данная роль пользователю или нет:

Можно было пойти по легкому пути, скопировать данные функции и убрать в них проверку на полноправного пользователя, но мы не ищем легких путей это бы нам не помогло, так как функция Пользователи.РолиДоступны() все равно используют функцию глобального контекста РольДоступна(), а функция УправлениеДоступом.ЕстьРоль() слишком громоздка (текст функции около 300 строк при этом текст основного запроса около 200 строк).

Таким образом, все перечисленные известные функции не подходят для решения нашей задачи.

Решение

Для решения этой задачи в любой конфигурации на базе БСП я использую свою функцию:

Буду признателен, если Вы будите делиться своим опытом решения данной задачи.

Источник

РольДоступна() УФ через профиль пользователя

А если я оставляю только:
Если ЭтоМенеджер() тогда

то пользователям с полными правами. реквизит блокируется тоже.

тогда эта функция вам не подойдет.
т.к. она начинается с

Т.е. если будет полноправный пользователь, хоть с «Менеджером», хоть без него , она все равно истину вернет.

Далее, у полноправных пользователей — все равно должна галка «менеджер» сниматься по идее.
А вспомогательные данные после добавления роли обновлял ?

какие еще способы могут быть, если роль на самом деле недоступна. вы двумя способами уже проверили, вам говорят что нет роли. Других способов нет и не нужно. Роль доступна сработает, исключительно если в конфигураторе стоит галка на роли. У вас что-то другое.

Изначально, откуда проблема взялась ? В рамках, так сказать, какого процесса вылезла проблема ? Давай всю предысторию

(2)Надо запретить менеджеру доступ к реквизита

Дописал в процедуру при открытии:

Вот в таком варианте ругается на нехватку прав.

А через РольДоступна() делать не хочу, т.к. менеджеров много и эта галочка постоянно слетает.

Чет с условием как-то неправильно.

Когда у пользователя полные права, то все остальные роли снимаются.

А в функции ЕСТЬРОЛЬ — первым делом проверяются полные права, если они полные — то возвращается истина, если нет — тогда уже проверка на роль. Причем это дело в привелигированном режиме происходит, т.е. должно работать по любому.
должно остаться только проверка на менеджера.

А уверен, что ошибка именно при вызове этофункции общего модуля ? Отладчиком если пройтись, на какой строке гасится ?

А если я оставляю только:
Если ЭтоМенеджер() тогда

то пользователям с полными правами. реквизит блокируется тоже.

тогда эта функция вам не подойдет.
т.к. она начинается с

Т.е. если будет полноправный пользователь, хоть с «Менеджером», хоть без него , она все равно истину вернет.

Далее, у полноправных пользователей — все равно должна галка «менеджер» сниматься по идее.
А вспомогательные данные после добавления роли обновлял ?

Источник

Проверка прав доступа

Область применения: управляемое приложение, обычное приложение.

1. В случае большого количества ролей в конфигурации (от нескольких десятков) не рекомендуется использовать ролевую настройку видимости в элементах форм (просмотр и редактирование реквизитов по ролям, пользовательскую видимость полей формы по ролям, использование команд по ролям). Вместо этого следует придерживаться следующих подходов:

• при сильных различиях внешнего вида и функциональности формы в зависимости от наличия тех или иных ролей у пользователя – разрабатывать отдельные формы, специализированные под конкретный набор прав пользователя;
• при незначительных отличиях – выполнять проверку прав в коде. При этом следует иметь в виду, что программное управление видимостью может снизить скорость открытия формы, что нужно учитывать при выборе между предлагаемыми подходами.

Эти меры позволяют:

• существенно упростить работу из кода с элементами управления, которые пропадают из коллекции Элементы (код Элементы.ИмяЭлемента.ИмяСвойства становится нерабочим);
• повысить устойчивость кода к пересмотру состава ролей в конфигурации;
• организовать контроль использования ролей в конфигурации (в противном случае, выполнять анализ прав доступа по флажкам, назначенных для ролей в различных элементах произвольных форм конфигурации, крайне затруднительно).

2. Не рекомендуется использовать ролевую настройку видимости в командном интерфейсе конфигурации, командном интерфейсе основного раздела, а также рабочей области начальной страницы. Вместо этого следует использовать настройку прав на разделы командного интерфейса, общие формы и объекты, включенные в командный интерфейс или в рабочую область. Это позволяет повысить предсказуемость поведения управляемого интерфейса для пользователя, а также упростить расследование ошибок.

3. Для проверки прав доступа в коде следует использовать метод ПравоДоступа .
Например, неправильно:

Если РольДоступна(«ДобавлениеИзменениеСтранМира») Тогда .
Если РольДоступна(«ПросмотрОтчетаПопулярныеСтраны») Тогда .

Если ПравоДоступа(«Редактирование», Метаданные.Справочники.СтраныМира) Тогда .
Если ПравоДоступа(«Просмотр», Метаданные.Отчеты.ПопулярныеСтраны) Тогда .

Такой подход позволяет повысить устойчивость кода к пересмотру состава ролей в конфигурации.

4. В тех случаях, где роль не дает никаких прав на объекты метаданных, а служит только для определения того или иного дополнительного права, следует использовать метод РольДоступна . При использовании в конфигурации Библиотеки стандартных подсистем (БСП) следует использовать функцию РолиДоступны общего модуля Пользователи :
Например, без использования БСП:

Если РольДоступна(. ) Или Или ПривилегированныйРежим() Тогда .

Либо аналогичная проверка с использованием БСП:

Источник

Поведение функции РольДоступна()

Уважаемые специалисты, подскажите пожалуйста, как обойти эту проблему:

в конфигурацию добавил новую роль «_ИзменениеДопДанных» и для проверки этой роли применяю оператор РольДоступна( «_ИзменениеДопДанных» ), но вижу, что возвращается ложь, как у пользователя с полными правами, так и у урезанного, но эта роль привязана не к нему, а к его группе. То есть есть некий профиль _Пользователь, который привязан к группе доступа _Пользователь, в которую входит группа пользователей _Опт, а в этой группе _Опт есть пользователь Иванов, и вот у Иванова РольДоступна( «_ИзменениеДопДанных» ) возвращает Ложь.

Прошу прощения, что не сказал, что речь идет о БСП (УТ11). В конфигураторе ничего не назначал, обновление вспомогательных данных (ИнструментыРазработчикаОбновлениеВспомогательныхДанных) делал.

(5) а ПравоДоступа() будет работать для сложной схемы Роль-Профиль-ГруппаДоступа-ГруппаПользователей-Пользователь?

(7) Если зайти в справочник пользователей, с включенной опцией использовать группы, то всех пользователей можно раскидать по группам. При этом присваивать группы доступа можно не пользователям поименно, а их группам (открыть группу пользователя, перейти на закладку «права доступа».

А проверяю я права в совсем другом месте — некая обработка при открытии в зависимости от ролей пользователя показывает или скрывает кнопки на своей форме. Я начал делать проверку прав с помощью РольДоступна() и увидел, что она работает не так, как ожидалось.

(10) автор дикой схемы — фирма 1С. Я в ней ничего не менял, я ей только пользуюсь.

Я нашел — в модуле УправлениеДоступом есть функция ЕстьРоль() и она делает то, что мне нужно.

Учебники по новым конфигурациям (УТ11, БП3, ERP) — должны содержать на заглавной странице — «Забудьте все, что вы учили ранее».

Источник