Добрый день, вопрос к гуру RLS, подскажите пожалуйста, можно ли только средствами данного механизма сделать такую штуку. Чтобы отдельные пользователи могли просматривать элемент справочника "Контрагенты" в форме списка, но не могли при этом выбирать его в заказах, видеть в задачах и т.д. Я почитал о RLS, но насколько я понял, можно только дать права на чтение, удаление, добавление, изменение. Т.е. если я не дам право на чтение, то пользователь и в списке видеть этого клиента не будет. Как лучше решить эту проблему? Подпилить форму выбора из этого справочника и остальные места где нужно ограничение?
По теме из базы знаний
Найденные решения
RLS накладывает дополнительные условия на работу с ТАБЛИЦАМИ. Соответственно и прикручивается к таблицам, а не к сущностям (типа "Контрагенты").
Вполне можно разрешить видеть контрагента в списке (таблица контрагентов), но запретить видеть и создавать заказы по этому контрагенту (таблица заказов). Про таблицы регистров тоже не забыть.
Срабатывают ограничения в момент соответствующего обращения к табице (попытка чтения, попытка записи). То есть выбрать контрагента в заказе пользователь сможет (если есть права на чтение таблицы контрагентов), но при попытке записи такого заказа получит исключение (если запрещено писать заказы с этим контрагентом).
Все очень просто и железобетонно. Если нужно что-то сверх этого - RLS уже ничем не поможет.
Вполне можно разрешить видеть контрагента в списке (таблица контрагентов), но запретить видеть и создавать заказы по этому контрагенту (таблица заказов). Про таблицы регистров тоже не забыть.
Срабатывают ограничения в момент соответствующего обращения к табице (попытка чтения, попытка записи). То есть выбрать контрагента в заказе пользователь сможет (если есть права на чтение таблицы контрагентов), но при попытке записи такого заказа получит исключение (если запрещено писать заказы с этим контрагентом).
Все очень просто и железобетонно. Если нужно что-то сверх этого - RLS уже ничем не поможет.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
RLS накладывает дополнительные условия на работу с ТАБЛИЦАМИ. Соответственно и прикручивается к таблицам, а не к сущностям (типа "Контрагенты").
Вполне можно разрешить видеть контрагента в списке (таблица контрагентов), но запретить видеть и создавать заказы по этому контрагенту (таблица заказов). Про таблицы регистров тоже не забыть.
Срабатывают ограничения в момент соответствующего обращения к табице (попытка чтения, попытка записи). То есть выбрать контрагента в заказе пользователь сможет (если есть права на чтение таблицы контрагентов), но при попытке записи такого заказа получит исключение (если запрещено писать заказы с этим контрагентом).
Все очень просто и железобетонно. Если нужно что-то сверх этого - RLS уже ничем не поможет.
Вполне можно разрешить видеть контрагента в списке (таблица контрагентов), но запретить видеть и создавать заказы по этому контрагенту (таблица заказов). Про таблицы регистров тоже не забыть.
Срабатывают ограничения в момент соответствующего обращения к табице (попытка чтения, попытка записи). То есть выбрать контрагента в заказе пользователь сможет (если есть права на чтение таблицы контрагентов), но при попытке записи такого заказа получит исключение (если запрещено писать заказы с этим контрагентом).
Все очень просто и железобетонно. Если нужно что-то сверх этого - RLS уже ничем не поможет.
(2) Подскажите пожалуйста, создал роль, в ней добавил рлс правило на изменение документ "ЗаказКлиента", для теста написал небольшой запрос, я так понимаю теперь у меня запрет на проведение любого заказа, так как условие всегда истинно, но почему-то у пользователя, которому присвоена эта роль нет ограничений, заказы проводятся( что я сделал не так?
Прикрепленные файлы:
(4) У вас стоит условие, что если контрагент в списке контрагентов, то менять можно. Вот программа и дает менять.
Простой вариант реализации: заведите параметр сеанса "Текущий пользователь" и при старте системы устанавливайте его.
Заведите регистр сведений "Пользователь - Контрагент" , в роли пропишите , что если контрагент есть для этого пользователя в регистре сведений, то можно писать, если нет, то нет.
Простой вариант реализации: заведите параметр сеанса "Текущий пользователь" и при старте системы устанавливайте его.
Заведите регистр сведений "Пользователь - Контрагент" , в роли пропишите , что если контрагент есть для этого пользователя в регистре сведений, то можно писать, если нет, то нет.
(5) Я переписывал условие и таким образом:
Это ничего не дало. А по поводу параметров сеанса и рс, не могу добавить их т.к. конфигурация стоит на поддержке, а расширение не позволяет менять структуру метаданных (
ЗаказКлиента ГДЕ НЕ ЗаказКлиента.Контрагент В
(ВЫБРАТЬ
СписокКонтрагентов.Ссылка
ИЗ
Справочник.Контрагенты КАК СписокКонтрагентов)Это ничего не дало. А по поводу параметров сеанса и рс, не могу добавить их т.к. конфигурация стоит на поддержке, а расширение не позволяет менять структуру метаданных (
(8)
Нет. RLS - это "уточнение" работы ролей (конкретизация, как роль будет работать на уровне записей таблицы). При "сложении" ролей в 1С пользователь получает "наибольшие" права.
Я думал рлс работает поверх ролей, т.е. перекрывает их, это не так?
Нет. RLS - это "уточнение" работы ролей (конкретизация, как роль будет работать на уровне записей таблицы). При "сложении" ролей в 1С пользователь получает "наибольшие" права.
(11) Просто для информации.
В подсистеме БСП "Управление доступом" реализован очень гибкий и интересный подход. Чтобы избежать перекрытия ролей и при этом дать максимально гибкие возможности настройки прав доступа используется правило - для каждого объекта, на каждый вид доступа к этому объекту (чтение/изменение) создается ОТДЕЛЬНАЯ роль. Получается много-много ролей. Но в каждой - только одно ограничение. Поэтому "перекрытие" разных ролей на одной таблице исключается в принципе.
А чтобы с этим было удобно работать, уже в рамках подсистемы реализованы т.н. "профили доступа", которые объединяют эти микро-роли в какие-то осмысленные логические единицы, по которым уже можно удобно выдавать доступ пользователям (в пользовательской части пользователя включают в какую-то группу доступа, ассоциированную с профилем, а БСП при этом сама автоматически накидывает пользователю все нужные микро-роли).
В подсистеме БСП "Управление доступом" реализован очень гибкий и интересный подход. Чтобы избежать перекрытия ролей и при этом дать максимально гибкие возможности настройки прав доступа используется правило - для каждого объекта, на каждый вид доступа к этому объекту (чтение/изменение) создается ОТДЕЛЬНАЯ роль. Получается много-много ролей. Но в каждой - только одно ограничение. Поэтому "перекрытие" разных ролей на одной таблице исключается в принципе.
А чтобы с этим было удобно работать, уже в рамках подсистемы реализованы т.н. "профили доступа", которые объединяют эти микро-роли в какие-то осмысленные логические единицы, по которым уже можно удобно выдавать доступ пользователям (в пользовательской части пользователя включают в какую-то группу доступа, ассоциированную с профилем, а БСП при этом сама автоматически накидывает пользователю все нужные микро-роли).
(12) не понимаю. В метаданных предусмотрено на каждый вид документа 27 прав. Роль в 1с предусматривает хранение всех установленных/не установленных прав доступа на все объекты метаданных. Как минимум в метаданных в результате 80% предусмотренного для метаданных пространства не используется (1 право из 5 укрупненных(чтение, запись, проведение, удаление, отмена проведения), в худшем 1/27). Сколько процентов от размера cf составляют роли?
(13)
Без понятия. Я не смотрел на формат сохранения ролей в метаданных. Но даже если ваше предположение верно и в случае микророли она занимает неоправданно много места (в чем я очень сильно сомневаюсь - лично я могу придумать массу вариантов оптимизированного хранения ролей в случае их частичного наполнения. Модель хранения метаданных скорее документная, чем реляционная), то я не вижу в этом большой проблемы. Во всяком случае на практике это никогда проблемой не становилось.
Сколько процентов от размера cf составляют роли?
Без понятия. Я не смотрел на формат сохранения ролей в метаданных. Но даже если ваше предположение верно и в случае микророли она занимает неоправданно много места (в чем я очень сильно сомневаюсь - лично я могу придумать массу вариантов оптимизированного хранения ролей в случае их частичного наполнения. Модель хранения метаданных скорее документная, чем реляционная), то я не вижу в этом большой проблемы. Во всяком случае на практике это никогда проблемой не становилось.
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот