Поможет ли RLS?

[Prophetic]

Добрый день всем.

Возникла задача ограничить доступ определенной группы пользователей к определенным складам при создании Заказа на продажу.
Т.е. сделать так, чтобы определенные склады нельзя было выбрать в lookup форме при создании нового заказа.
Однако, в Отчеты-Запросы-В наличии на складах нужно эти склады видеть.

[Zodiak]

если выпадающих списков, которые надо фильтровать, не много (1-2-3), то проще перекрыть соответствующие lookup'ы и наложить фильтр там

[glibs]

Поможет отфильтровать список складов в такой постановке задачи. Но, возможно, что где-то такое решение вылезет боком.

В ряде версий и СП невидимое в лукапе из-за RLS значение можно ввести вручную, если вы его знаете, и система не ругается.

[DSPIC]

Цитата:

Сообщение от glibs

Поможет отфильтровать список складов в такой постановке задачи. Но, возможно, что где-то такое решение вылезет боком..

И пользователи этой группы запрещенных складов ни в одном лукапе не увидят во всей системе...

Цитата:

Сообщение от glibs

...
В ряде версий и СП невидимое в лукапе из-за RLS значение можно ввести вручную, если вы его знаете, и система не ругается.

Пусть A - таблица-источник, по которой делается лукап, на неё натроен RLS, т.е. записи видим не все.
Пусть Б - таблица-приемник, куда вбивается значение из лукапа, на неё RLS не настроен.
Вполне предсказуемо, что в таблицу Б мы можем ручками вбить запрещенное значение (только такое поведение я и встречал). С другой стороны, система должна запрещать вручную вбивать значение, отсутствующее в лукапе. Т.е. для надежности - впервую очередь RLS должен быть настроен на таблицу Б (но таких таблиц, где м.б. ссылка на А в системе м.б. много...).
Glibs, а в каких версиях система не дает ручками вбить в таблицу Б?
В 3-ке и 4-ке дает...

Ест

[glibs]

Цитата:

Сообщение от DSPIC

И пользователи этой группы запрещенных складов ни в одном лукапе не увидят во всей системе...

Да, я именно это имел в виду. Возможно, что где-то такое поведение может быть нежелательным. Например, при построении расширенного фильтра по тому же запросу по остаткам (где будут видны все склады).

Цитата:

Сообщение от DSPIC

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

Не разделяю вашу т.з. насчет "Вполне предсказуемо". Точнее разделяю как вредный тестировщик, имеющий некоторый дар от природы предсказывать места, где разработчик мог зарыть багу.

Цитата:

Сообщение от DSPIC

...
а в каких версиях система не дает ручками вбить в таблицу Б?
В 3-ке и 4-ке дает...
...

Тут, скорее, речь должна идти о версии ядра (Ax32.exe).

Только что проверил 3.0 сп6 с ядром от KR3. Эффект воспроизводится.
5.0 сп2 hotfix rollup 3. Эффект воспроизводится.

Вообще, насколько я помню историю RLS, то в 2.5 был партнерский модуль, и не помню точно, не было ли путей его обойти.

В 3.0 появился в базовой поставке, но работал нестабильно (с критическим количеством багов) до сп3. Позже в каком-то из последних СП таки встроили RLS и в validateField() в ядре где-то. Писали где-то, но не могу найти, что в 4.0 это сломали, и проверка поля опять перестала работать. Не помню, проверял или нет. В 5.0 вроде починили. С какого СП — не помню. Может кто сможет дополнить чего в истории.

[sukhanchik]

Цитата:

Сообщение от glibs

Вообще, насколько я помню историю RLS, то в 2.5 был партнерский модуль, и не помню точно, не было ли путей его обойти.

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

Цитата:

Сообщение от glibs

В 3.0 появился в базовой поставке, но работал нестабильно (с критическим количеством багов) до сп3.

Сделанный RLS (и это важно) работал именно в ядре. Т.е. уже никакой фильтр по пустому значению не мог его сломать. Равно как и вводить запрещенное значение.

[Logger]

Если не ошибаюсь, glibs имел в виду следующую особенность поведения системы :
Если в вашем примере настроен RLS на табличку Б то для одних билдов система просто накладывала дополнительный фильтр на табличку Б при просмотре, не запрещая создавать руками значения противоречащие RLS (т.е. RLS действовал исключительно как фильтр при просмотре), а в других билдах - запрещала. Т.е. RLS действовал не только как фильтр, но и накладывал ограничения на значения в поле. Т.е. RLS влиял на валидацию значений.

На каком варианте в итоге остановились - не помню. Можно протестировать по последнему билду.

[glibs]

Цитата:

Сообщение от Logger

...
Если не ошибаюсь, glibs имел в виду
...

Если я правильно смог понять текст сообщения, то glibs имел в виду другое .

Уточню на примере, чтобы не возникало ни у кого разночтений.

Я тестировал на таблицах LedgerTable и LedgerBudget. На плане счетов настроил RLS как !ХХХ, где "ХХХ" — некий счет ГК. Натравил этот RLS на пользователя через группы. Убедился, что в плане счетов счет "ХХХ" не отображается. Убедился, что в лукапе счетов ГК в бюджетных проводках счет "ХХХ" не отображается. При создании бюджетной проводки ввел значение "ХХХ" в соответствующее поле и попытался его покинуть, на что получил сообщение что значение "ХХХ" отсутствует в таблице План счетов.

Вообще было очень прискорбно, когда такого эффекта удалось добиться для 3.0, но он был потерян в 4.0. Есть гипотеза, что в 3.0 этот функционал сделали после того, как разработчики ядра 4.0 отделились вместе с наследием для разработки новой версии. Мне все кажется, что в 3.0 такое поведение появилось с сп5.

Что касается описанного вами случая... IMHO сейчас эффект корректный. Если бы я настроил RLS на таблицу бюджетных проводок по счету ГК, то создать я строчку могу, а вот когда открою форму снова, то уже не увижу созданную мною же запись. Не вижу ничего некорректного в том, что проверка значения поля делается по RLS на справочнике, а не по фильтру на транзакционной таблице. Первое, IMHO, логичнее. Если нужно запретить и видеть и создавать записи по значению справочника в транзакционной таблице — фильтр настраивается два раза: и на справочнике, и на транзакционной таблице. А именно ввод значения — справочник. В результате можно выбирать между первым, вторым и первым и вторым одновременно.

Обратил внимание, что настройка RLS в 5.0 у меня не заработала, пока я входил в группу "Admin". На более ранних версиях я такого не замечал.

[Prophetic]

Принял решение поступить по совету glibs: в моём простом случае фильтр решил проблему.
Благодарю всех откликнувшихся.