Извечный вопрос.
Всегда использовал конструкцию "и РольДоступна("ПолныеПрава"). Но тут возник спор с саповцами, что нарушаем саму парадигму разграничения прав(сам ни**я не понял).
В целом, правда похоже на костыль дополнительная проверка на полные права.

Допустим, надо всем ограничить доступ к справочнику, если нет прав "МожноРедактироватьЭтотСправочник". Как правильнее?

Если РольДоступна("МожноРедактироватьЭтотСправочник") или РольДоступна("ПолныеПрава")

или

Если ПравоДоступа("Изменение", Метаданные.Справочники.ЭтотСправочник)
?

Не понял, откуда здесь голосовалка?

ПравоДоступа позволяет рулить правами из одного окна с ролями, тогда как РольДоступна заставляет тебя носится по коду и искать вызовы функции.

имхо, РольДоступна только для совместимости со старыми конфами нужна.

(1) ну а как ты определишь предпочтения среди дочитавших до конца нулевой пост?

(4) а, понял. Я думал это что-то нажал и оно само(с).
А по вопросу, я бы хотел уяснить, как правильно, желательно со ссылками на одноэс. Понимаю, что "правильно" - понятие растяжимое и будет немного каша, но все же какое-то понятие хочется усвоить.

(0) А что тут не понятно? Пользователю может быть назначено несколько ролей и к конкретному объекту он может иметь конкретные права доступа на основании их. В зависимости от цели алгоритма можно требование наличие у пользователя конкретной роли (или совокупности их), но это нарушает сам принцип разграничения прав.

Ваш "саповец", в принципе, прав - вспомните об RLS.

(0) Зависит от задачи.

Право доступа у него может быть, а вот роли нет.
Что тогда? Давать доступ или нет?
Это две разные функции для разных задач.

ПравоДоступа - проверяем перед выполнением операции с БД, чтобы не получить ошибку.

РольДоступна - проверка по бизнес-процессу. У роли может вообще не быть галочек к объектам.

(7) "У роли может вообще не быть галочек к объектам" - эээ... то есть роль в качестве логического значения? Не эффективно, имхо, но имеет право быть.

(7) для таких кейсов придумали привилегированный режим\модуль.

(7) угумц.. утрированно - возможность и способ, что нужно проверять - зависит от контекста.

А как быть с РольДоступна("ПолныеПрава") - у него разве есть аналоги?

(9) причем тут привилегированный модель?

(8) кстати еще бывают роли на формы, команды, печать документов
это вообще не доступ к базе

написано же на ИТС про это

(0) Зависит от задачи. И это... Совет: не спорь с САПовцами. У них свои тараканы в голове.

переделайте пункты в голосовалке:
-Роль я дрожащая или
-право имею

https://its.1c.ru/db/v8std/content/2149184386/hdoc
Для проверки прав доступа в коде следует использовать метод ПравоДоступа.
Например, неправильно:

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

правильно:

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

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

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

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

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

Если Пользователи.РолиДоступны(...) Тогда ...

(17) По-моему самый исчерпывающий ответ.

(17) Огромное спасибо!
(18) во истину!

(17) @Либо аналогичная проверка с использованием БСП:@
За использование БСП нужно лицом к стенке и пулю в лоб...

(20) А как быть с типовыми? Отказаться от БСП и постоянно костылить своё?

(17) Не работает если нужно проверить наличие запрещающей роли у пользователя с полными правами

(22) Запрещающая роль?
А можете пример привести. Никогда не приходился стакливаться с выдачей роли, которая что-то бы запрещала.

(23) наверное что-то вроде

Если РольДоступна( ЗапретПродаж ) Тогда
   Отказ = Истина;
КонецЕсли;

(23) В ЗУП 3 запретить редактирование среднего заработка
(24) Вернет Ложь если доступны полные права

Читаем стандарты разработки

(26) Можно пример для ситуации в (22)?

(27) Не существует "запрещающих" ролей в 1с 8, а жаль

(28) Зато существует "запрещающая проверка" на наличие роли :-)

(29) Об этом все уже написано в (17)

(27)Значит неверная архитектура решения, если требуется применять методику, нерекомендованную вендором.

А когда темы в архив сдаются? почти 4 месяца теме...

из (17)
[не рекомендуется использовать ролевую настройку видимости в элементах форм]

так а нахрена они вообще сделали эту возможность?

(32) Рулить нужно доступностью, а не видимостью. Причин много.

(33) можно подробнее про причин много?

так зачем в платформе 1С дают возможно делать то, что не рекомендует делать таже 1С?

(34) Не слушай его. На ИТС в том пункте речь только о корневых подсистемах и начальной страницы. Про формы объектов там конечно же речи нет и видимость по ролям использовать можно и нужно.

(35) По тексту речь как раз о формах объектов:

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

(36) Этот пункт только про значительное количество ролей и про то, что вместо этого (в случае большого количества) надо использовать проверку кодом

(37) несколько десятков ролей наверное даже в самописках уже нормой считается. Поэтому, видимо, можно брать за правило этот пункт.

(38) Скорее не на абсолютное количество надо смотреть, а на их "качество": если это атомарные роли (где на каждый справочник или документ как минимум две роли - отдельно на просмотр и отдельно на добавление+изменение), тогда про видимость по ролям на формах объектов можно забыть

А если это "функциональные" роли (прям по должностям, например), тогда видимость по ролям хорошо заходит

видимость по ролям очень сложно отлаживать

поэтому видимость лучше в коде. кстате по этой же причине 1с рекомендует условное оформление в коде

(42) тьфу, еще и условное кодом делать...((
Эти рекомендации тоже с ИТС стандартов разработки?