RLS и ручная настройка ограничений

[Arahnid]

Настраиваю руками видимость на форме в DS в методе executeQuery

    if (t == 0)
    {
        qbds1.clearRange(fieldNum(,));
        qbdsrange1 = qbds1.addRange(fieldNum(,));
        qbdsrange1.value(sysQuery::value(curExt()));
        qbdsrange1.status(1);

    }

Но если пользователь войдет и руками через Найти укажет * по полю, то фильтр слетает.
Если настраивается RLS, то все хорошо. Вопрос, как сделать так, чтобы фильтр по полю не слетал?
Способ запретить функцию Найти не выход.

[BOAL]

А чем РЛС не выход?
Если речь о штучной форме, то нужно
1 проверять и перекрывать рандж на нужный
или
2 сделать еще другое поле на таблице и по нему рандж скрытый, чтоб его нельзя было выбрать в фильтре и он всегда работал все равно, а поле скрыть.
Но это все же изврат, тк РЛС есть.

[Arahnid]

Да, пасибо. Ожидаемый ответ, но хотелось еще мнение услышать.

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

[Logger]

Цитата:

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

А чем РЛС не выход?
Если речь о штучной форме, то нужно
1 проверять и перекрывать рандж на нужный
или
2 сделать еще другое поле на таблице и по нему рандж скрытый, чтоб его нельзя было выбрать в фильтре и он всегда работал все равно, а поле скрыть.
Но это все же изврат, тк РЛС есть.

если речь о 3-ке, то единственный гарантированный способ - это в методе Executequery перед super() чистить все Range() по данному полю и устанавливать свой. Тогда комар носа не подточит и фильтр нельзя обойти. Иначе есть обходные пути из-за дырок в ядре, например сделать на поле команду "Фильтр" через правую кнопку мыши - это гарантированно ставит range по полю несмотря на все запреты. А этот range уже можно подредактировать как нам надо и тем самым все-таки увидеть запрещенные записи. С ExecuteQuery такой номер не прокатывает.

[Arahnid]

Ясно, тогда останавливаюсь пока на запрете поиска по нужному полю и тогда фильтр в Executequery снять нельзя с этого поля.

[Logger]

Цитата:

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

Ясно, тогда останавливаюсь пока на запрете поиска по нужному полю и тогда фильтр в Executequery снять нельзя с этого поля.

Зачем ?
Может людям искать надо.
Поставьте код на ExecuteQuery и все будет нормально.

[S.Kuskov]

Можно программно (например в том же ExecuteQuery) присоеденить к таблице источника данных exists join'ом ту же самую таблицу. И все системные ограничения вешать уже на добавленную таблицу, а пользователи пусть себе фильтруют основную (больше, чем позволит exist join, они всё равно не увидят)

[Raven Melancholic]

Пожалейте хоть админа и консультантов, которым настраивать все эти доступы/видимости.
Что за версия?
Если DAX2009?, то там есть возможность в RLS добавлять некоторые функции. Если до 2009, то на форуме есть проект, позволяющий реализовывать RLS для подчиненных датасорсов.

Цитата:

там много групп прав и итак висит кучка ограничений на видимость

Не верю, что все эти группы нельзя классифицировать (учти, что я работаю на клиенте и приходилось реализовывать совершенно бредовые требования по видимости). Так что, приведи пример, в котором RLS не хватает.