Внимание! Тема закрыта. Добавлять сообщения в закрытую тему запрещено.
Всем здравствуйте. Как в роли можно можо поставит ограничение на видимость некоторых реквизитов справочника, документа или рег сведений?
Слышал о RSL. в типовой конфе увидел такой запрос для ограничения доступа к данным для прочих полей :
интерсует параметр #ТекущаяТаблица = # это параметр RSL ?? тоесть текущая таблица(док или спр), &ТекущийПользователь - откуда этот параметр подставляется? через код??
Слышал о RSL. в типовой конфе увидел такой запрос для ограничения доступа к данным для прочих полей :
Контрагенты ИЗ #ТекущаяТаблица КАК Контрагенты
ГДЕ Контрагенты.ОсновнойМенеджерПокупателя = &ТекущийПользователь интерсует параметр #ТекущаяТаблица = # это параметр RSL ?? тоесть текущая таблица(док или спр), &ТекущийПользователь - откуда этот параметр подставляется? через код??
По теме из базы знаний
- Ограничение доступа к отдельным записям (пример)
- Групповая замена/добавление ограничений доступа RLS
- Ограничение доступа на уровне записей по кассам
- Возможности типовых шаблонов ограничения доступа на уровне записей (RLS)
- RLS добавление ограничения доступа к данным по произвольному справочнику через штатные механизмы
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) Ягг, какой запрос написать, чтобы он скажем реквизит организация скрывал в спр. сотрудники. Там дан вот такой приер
тоесть все зависит от настроек пользователя - какие назначены в РегистрСведений.НастройкиПользователей??
ТекущаяТаблица ИЗ #ТекущаяТаблица КАК ТекущаяТаблица
ГДЕ
(ТекущаяТаблица.Организация В
(
ВЫБРАТЬ
Выразить(НастройкиПользователей.Значение как Справочник.Организации) как Организация
ИЗ
РегистрСведений.НастройкиПользователей КАК НастройкиПользователей
ГДЕ
НастройкиПользователей.Пользователь = &ТекущийПользователь
И НастройкиПользователей.Настройка = Значение(ПланВидовХарактеристик.НастройкиПользователей.ОсновнаяОрганизация)
)
) Показатьтоесть все зависит от настроек пользователя - какие назначены в РегистрСведений.НастройкиПользователей??
(4) Manticor,
нет, боюсь что так не получится. В 8.1. "видимость" устанавливается на всю запись "целиком". Вот на "чтение", "изменение", "удаление" и "добавление" можно ставить условия на доступ к отдельным реквизитам. Но это не интерактивный доступ через формы - это сказывается при записи или чтении через запрос. К примеру если нет доступа к какому-то одному реквизиту ссылки на "чтение" то при отображении вся ссылка читаться не будет.
Вывод - если нужно кому-то скрывать, а кому-то видить реквизит, это нужно в 8.1. явно прописывать в форме (кажется так).
К сведению в 8.2. для этого используют "функциональные опции" (хотя там кажется и по реквизитам можно RLS использовать - но не эффективно)
Что касается регистра "Настройки пользователя" - это частный случай. Важно что в подобных запросах можно использовтаь "Параметры Сеанса" - от этого и надо плясать :)
Сожалею, что кажется ввел в заблуждение, но вопрос был все же по RLS (на него и отвечал :) ).
нет, боюсь что так не получится. В 8.1. "видимость" устанавливается на всю запись "целиком". Вот на "чтение", "изменение", "удаление" и "добавление" можно ставить условия на доступ к отдельным реквизитам. Но это не интерактивный доступ через формы - это сказывается при записи или чтении через запрос. К примеру если нет доступа к какому-то одному реквизиту ссылки на "чтение" то при отображении вся ссылка читаться не будет.
Вывод - если нужно кому-то скрывать, а кому-то видить реквизит, это нужно в 8.1. явно прописывать в форме (кажется так).
К сведению в 8.2. для этого используют "функциональные опции" (хотя там кажется и по реквизитам можно RLS использовать - но не эффективно)
Что касается регистра "Настройки пользователя" - это частный случай. Важно что в подобных запросах можно использовтаь "Параметры Сеанса" - от этого и надо плясать :)
Сожалею, что кажется ввел в заблуждение, но вопрос был все же по RLS (на него и отвечал :) ).
(5) Ягг,
тут Ягг фишка такая:
есть ряд документов и справочников, ну и регистров расчета по з\п, которые должны читать и видеть определенный круг пользователй и не должны видеть все остальные.
Если я убираю полностью все права(чтение, изменение просмотр редактирование интерактивные вещи) у роли которая использует эти данные будь это спр или рег сведений то возникают ситуации когда в каком-либо документе косвенным образом эти данные используются.
Возникла идея следующая: права не убирать, а сделать какие то ограничения.
Самое первое что приходит на ум это убрать элементы или сам объект визуально иначе скрыть.
А теперь суть вопроса)) с RSL сталкиваюсь впервые, вижу что к примеру на элемент организация накладывается условие.
Может можно что то аналогичное под мою проблему. Работаю в 8.2
тут Ягг фишка такая:
есть ряд документов и справочников, ну и регистров расчета по з\п, которые должны читать и видеть определенный круг пользователй и не должны видеть все остальные.
Если я убираю полностью все права(чтение, изменение просмотр редактирование интерактивные вещи) у роли которая использует эти данные будь это спр или рег сведений то возникают ситуации когда в каком-либо документе косвенным образом эти данные используются.
Возникла идея следующая: права не убирать, а сделать какие то ограничения.
Самое первое что приходит на ум это убрать элементы или сам объект визуально иначе скрыть.
А теперь суть вопроса)) с RSL сталкиваюсь впервые, вижу что к примеру на элемент организация накладывается условие.
Может можно что то аналогичное под мою проблему. Работаю в 8.2
(6) Manticor,
Вообще, насколько я понимаю, для интерактивной работы (т.е. что бы пользователь "видел") важны права "просмотр" и т.д. А вот права "Чтение", "Изменение" - это права важны для самой программы. Например, если в своей работе как-то модуль обращается (програмно) к спарвочнику, на справочник должно быть право "чтение", но не обязательно просмотр. В этом случае, когда нет "просмотра", программа будет работать нормально (у пользователя), а вот пользователь не сможет видеть элемент (в формах).
Кроме того, у 8.2 есть возможность устанавливать права на просмотр (и реадктирование) отдельных реквизитов.
Т.е. вывод - если данные используются "косвено", но пользователь их видеть не должен - ставим право на "Чтение" (или изменение, добавление - смотря как косвенно используются), но снимаем право на "просмотр". (Тут даже не в RLS дело - можно обычными ролями обойтись. RLS нужно если блокируем доступ не ко всему справочнику, а только к некоторым из его записей).
Нужно учесть, что роли складываются по принципу ИЛИ - если хоть в одной из ролей (а у пользователя может быть несколько ролей) действие разрешено, то пользователю действие разрешено.
Что касается видимости, то в случае управляемых форм на 8.2. удобно не заморачиваться с ролями (тем более если речь идет только о видимости), а использовать функциональные опции (я не помню работают ли функциональные опции в обычных формах) - но это уже другая тема :)
Вообще, насколько я понимаю, для интерактивной работы (т.е. что бы пользователь "видел") важны права "просмотр" и т.д. А вот права "Чтение", "Изменение" - это права важны для самой программы. Например, если в своей работе как-то модуль обращается (програмно) к спарвочнику, на справочник должно быть право "чтение", но не обязательно просмотр. В этом случае, когда нет "просмотра", программа будет работать нормально (у пользователя), а вот пользователь не сможет видеть элемент (в формах).
Кроме того, у 8.2 есть возможность устанавливать права на просмотр (и реадктирование) отдельных реквизитов.
Т.е. вывод - если данные используются "косвено", но пользователь их видеть не должен - ставим право на "Чтение" (или изменение, добавление - смотря как косвенно используются), но снимаем право на "просмотр". (Тут даже не в RLS дело - можно обычными ролями обойтись. RLS нужно если блокируем доступ не ко всему справочнику, а только к некоторым из его записей).
Нужно учесть, что роли складываются по принципу ИЛИ - если хоть в одной из ролей (а у пользователя может быть несколько ролей) действие разрешено, то пользователю действие разрешено.
Что касается видимости, то в случае управляемых форм на 8.2. удобно не заморачиваться с ролями (тем более если речь идет только о видимости), а использовать функциональные опции (я не помню работают ли функциональные опции в обычных формах) - но это уже другая тема :)
(7) Ягг, прланируется 3 роли,в одной из ролей - да, там будет не видно ничего, вклчая и сам справочник - т.е толькопросмотр. А вот отстальные роли предусматривают именно частичное скрытие реквизитов. Так например 2 роль дает возможность просмотра паспортных данных в спр Сотрудники, фио, семейное положение, но ограничивают просмотр военной службы, данные которой береутя из рег свед. воинский учет, также требуется скрыть поле ИНН, сраховой номер- в общем по некоторым реквизитам. Получается RSL.
(8) Manticor, дело конечно хозяйское :) , но как справедливо замечено в (9) RLS - это все таки доступ прежде всего к записям (т.е. к строкам таблиц), а не к отдельным полям (как там обстоит дело с отдельными полями уже обсуждали). Так что думаю, тут надо все таки прежде всего использовтаь функциональные опции, а RLS как ббы вторично (для подстраховки в запросах и т.д.)
(10)Ягг, попробовал с функциональными опциями. Этот механизм не подходит, поскольку там нет привязки к конкретной роли, да и признак ее использования довольно мутен (хранится в контстанте которая сязана с документом).
Далее поэксперементировал с ревизитами объекта - теми данными которые используются напрямую - НЕ косвенно, например СтраховойНомерПФР из спр физлица. Делал так:
Хочу сделать роль, в которой не будет виден например реквизит у спр ФизЛица СтраховойНомерПФР. создаем эту роль, далее идем на спр физлица, ставим все галочки- тоесть чтение, добвление просморт и тд.
Переходим на реквизит СтраховойНомерПФР - все галочки с него убираем просмотр и редактирование. По логике вещей теперь пользователь которому присвоена эта роль может заходить в спр физЛица и видеть все кроме реквизита СтраховойНомерПФР. Однако этого не происходит, данный рекизит остается видимым. Так и должно быть??
Также если. мы встанем на роли- все роли и выберем кокой-либо объект например спр сотрудники и встанем на него - то увидим, что на доступ к этому справочнику имеют лишь некотрые роли, но если мы перейдем на реквизиты или таб.части или станд реквизиты, то увидим, что почему то досуп на все имеют все роли!!
более того если мы втнем снова на сам объект и переснимем все галки со все роли, то даже после этой операции у всех ролей будет право на дооступ к реквизитам и тч и прочему. Помогает только если вставать на каждую роль в окне все роли и перещелкивать КАЖДУЮ роль по галке все
роли- только тогда убираются галки и с остальных реквизитов. Платформа версии 1С:Предприятие 8.2 (8.2.15.310), конфигурация УПП 1.3..
Выше давали ссылки на примеры с использованием ограничения доступа RLS. Попробовал следующее:
встал на роли/все ограничения доступа, добавил объект СПР.Физлица, роль, котрой данное ограничене будет присвоено, право выставил ЧТЕНИЕ, поле СтраховойНомерПФР, ограничение доступа прописал так:
ТекущаяТаблица ГДЕ ТекущаяТаблица.СтраховойНомерПФР = &ТекущийПользователь. В итоге сам спр открывается но на фомру элемента не пускает : у пользователя не достаточно прав на исполнение операции над БД. Поправил код на <> &ТекущийПользователь - пускает но реквизит виден.
А еще надо как то косвенные сделать котрые из регистров читаются....
Далее поэксперементировал с ревизитами объекта - теми данными которые используются напрямую - НЕ косвенно, например СтраховойНомерПФР из спр физлица. Делал так:
Хочу сделать роль, в которой не будет виден например реквизит у спр ФизЛица СтраховойНомерПФР. создаем эту роль, далее идем на спр физлица, ставим все галочки- тоесть чтение, добвление просморт и тд.
Переходим на реквизит СтраховойНомерПФР - все галочки с него убираем просмотр и редактирование. По логике вещей теперь пользователь которому присвоена эта роль может заходить в спр физЛица и видеть все кроме реквизита СтраховойНомерПФР. Однако этого не происходит, данный рекизит остается видимым. Так и должно быть??
Также если. мы встанем на роли- все роли и выберем кокой-либо объект например спр сотрудники и встанем на него - то увидим, что на доступ к этому справочнику имеют лишь некотрые роли, но если мы перейдем на реквизиты или таб.части или станд реквизиты, то увидим, что почему то досуп на все имеют все роли!!
более того если мы втнем снова на сам объект и переснимем все галки со все роли, то даже после этой операции у всех ролей будет право на дооступ к реквизитам и тч и прочему. Помогает только если вставать на каждую роль в окне все роли и перещелкивать КАЖДУЮ роль по галке все
роли- только тогда убираются галки и с остальных реквизитов. Платформа версии 1С:Предприятие 8.2 (8.2.15.310), конфигурация УПП 1.3..
Выше давали ссылки на примеры с использованием ограничения доступа RLS. Попробовал следующее:
встал на роли/все ограничения доступа, добавил объект СПР.Физлица, роль, котрой данное ограничене будет присвоено, право выставил ЧТЕНИЕ, поле СтраховойНомерПФР, ограничение доступа прописал так:
ТекущаяТаблица ГДЕ ТекущаяТаблица.СтраховойНомерПФР = &ТекущийПользователь. В итоге сам спр открывается но на фомру элемента не пускает : у пользователя не достаточно прав на исполнение операции над БД. Поправил код на <> &ТекущийПользователь - пускает но реквизит виден.
А еще надо как то косвенные сделать котрые из регистров читаются....
(11) Manticor,
про механизм функциональных опций. Привязок к ролям там кончено нет, но есть привязка с справочникам. Можнопривязать к тому же справочнику "Пользователей". Привязка делается через Параметры функциональных опций (посмотртие в литературе).
По правам: я честно говоря не очень понял (что-то туплю с утра :)). Но по идеи (повторюсь) запись видима (в общем случае) если видны все ее реквизиты или доступна если доступны все (это к сообщению о недосттке прав).
А то что видно лишнее - возможно у пользователя несколько ролей и права сложились по ИЛИ.
про механизм функциональных опций. Привязок к ролям там кончено нет, но есть привязка с справочникам. Можнопривязать к тому же справочнику "Пользователей". Привязка делается через Параметры функциональных опций (посмотртие в литературе).
По правам: я честно говоря не очень понял (что-то туплю с утра :)). Но по идеи (повторюсь) запись видима (в общем случае) если видны все ее реквизиты или доступна если доступны все (это к сообщению о недосттке прав).
А то что видно лишнее - возможно у пользователя несколько ролей и права сложились по ИЛИ.
(12) тут выше давали ссылку
Там вроде нашли решение так:
Два списка полей - который ограничиваем и который не ограничиваем в настройке "Ограничения доступа к данным".
Например:
[1C]
ГоловнойКонтрагент, ЮрФизЛицо | Контрагенты ГДЕ ЛОЖЬ
Ссылка, ПометкаУдаления | <Пусто>
[/1C]
не понятно где такие поля? что тут за условие вообще. тоесть нужен рабочий пример этого RLS ограничения.
Там вроде нашли решение так:
Два списка полей - который ограничиваем и который не ограничиваем в настройке "Ограничения доступа к данным".
Например:
[1C]
ГоловнойКонтрагент, ЮрФизЛицо | Контрагенты ГДЕ ЛОЖЬ
Ссылка, ПометкаУдаления | <Пусто>
[/1C]
не понятно где такие поля? что тут за условие вообще. тоесть нужен рабочий пример этого RLS ограничения.
в 8.1 в запросах RLS доступны переменные, определенные в параметрах сеанса. Обычно используется из параметров текущий пользователь, а дольше уже соединениями со справочниками определяют заданные в режиме предприятия права. В типовых конфигурациях (ЗУП, УПП) очень много примеров по RLS. Берите, смотрите. Не очень удобно, что там создаются универсальные шаблоны (очень громоздкие и сложно читаемые), но расковырять их можно. Можно даже частями в консоли запросов, заменив
Контрагенты ИЗ #ТекущаяТаблица КАК Контрагенты
например, на
Контрагенты ИЗ Справочник.Контрагенты КАК Контрагенты
ГДЕ Контрагенты.ОсновнойМенеджерПокупателя = &ТекущийПользователь
Контрагенты ИЗ #ТекущаяТаблица КАК Контрагенты
например, на
Контрагенты ИЗ Справочник.Контрагенты КАК Контрагенты
ГДЕ Контрагенты.ОсновнойМенеджерПокупателя = &ТекущийПользователь
(15) vitek1, чем больше прокачиваюсь- тем больше понимаю- скорее всего так задачу не реализовать. Вот если был хотя бы тонкий клиент(а я на толстом) то моэно еще было хотя бы реквизиты например у спр спрятать в роли да и как быть с косвеными - тоже вопрос. Но увы клиент толстый....
(19) catena, у меня не управляемы формы. И поддержк 8.2 отключена, да платформа 8.2 это ничего абсолютно не меняет.
(18) pathort, это все применимо если реквизиты находятся непосредственно в данных в справочнике или доке. Но большинство параметров - косвенно читаются, тоесть к ним как к полям (объектам ) даже через RLS не обратиться(отсутствуют как объекты). тоесть либо работать с самим объектом в целом - например спр Сотрудники и также применять RLS либо никак наверно
(18) pathort, это все применимо если реквизиты находятся непосредственно в данных в справочнике или доке. Но большинство параметров - косвенно читаются, тоесть к ним как к полям (объектам ) даже через RLS не обратиться(отсутствуют как объекты). тоесть либо работать с самим объектом в целом - например спр Сотрудники и также применять RLS либо никак наверно
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот