Привет всем!

Есть 2 признака, по которым нужно защищать данные. Например, пользователю долступны записи по следующим правилам:

код БД 1 регион *
код БД 2 регион 10

Когда я создаю переменные (КодБД_ОграничениеПрав и Регион_ОграничениеПрав) и ограничиваю признаки в отчете BEx, в этих переменных приписываются значения для сравнения:
КодБД_ОграничениеПрав = код БД 1 и 2
Регион_ОграничениеПрав = *

Таким образом получается, что я выберу коды БД 1 и 2, и на все эти записи действует ограничение Регион=*.

А нужно все записи, где код БД = 1, и все записи код БД=2 и регион=10

Все это из-за того, что переменные по правам создаются и используются отдельно друг от друга

Выход вижу один - создать признак, который содержит конкатенацию этих двух и его уже проверять.

не спеши

нота 557924 описывает один из методом решения

Я так понимаю систему защиты:
есть отдельно модуль, который следит за выбираемыми данными. Он работает независимо от BEx. Если выбираются неавторизованные данные, то он зарубает вообще выборку всех данных. Нота - именно для этого модуля.

второй модуль (вторая часть работы) - это в BEx. Там нужно прописать такие ограничения, чтобы первый модуль не зарубил выборку. И здесь как раз и используются соответствующие переменные. Нота помогает использовать ексит и заполнить эти переменные.

Но проблема в том, что используется 2 ОТДЕЛЬНЫЕ переменные - код БД и регион, тогда как нужны связанные переменные Код БД - Регион.

А в EXTIT-e АБАП-ом прописать ограничения не прокатит? То есть дать юзеру возможность выбота только кода БД, а в регион потом соответствующие значения напихать ?

Не в том проблема...
Например, заполнил я все как надо в ексите.

Затем в Бексе в запрос вставляю ограничение:
по коду БД - переменная КодБД_ОграничениеПрав = 1, 2
по региону - переменная Регион_ОграничениеПрав = *, 10

система будет думать, что по региону вообще нет ограничений, число 10 она упускает... Да и число 10 связано с кодом БД 2, а не 1.

Я просто перефразирую вопрос: какие должны быть ограничения для переменных, чтобы юзер видел все записи, для которых
код БД = 1, а также все записи, для которых
код БД = 2 и регион 10?

Все равно получается, что нужно сливать оба показателя в один...

А насколько критично security, то есть, если пользователь случайно увидит другие записи, например с кодом БД 2 и регионом 1 ?

Совсем критично - он будет получать не свои данные, отчетность полетит... А за ней и моя голова %(

Если я правильно понимаю, то комбинации, которые должен видеть пользователь, определяются его должностью, или отношением к какому-либо структурному подразделению. Тогда имеет смысл добавить признак "Структурное подразделение", по которому раздавть полномочия, а заполнять его при загрузке данных в куб, как раз по тем правилам, которые Вы указали

Тогда подразделение тянет за собой иерархию подчиненности. А эта иерархия еще не устаканилась - кто то должен ее вести...

В общем, получается все равно - нужно какой то один признак замутить, и на его основе отслеживать права...