Hi there, I’m trying to implement row level security. Until now, I had used it like this: I add one row condition to a user, then another one, and so on; and it work fine if what you want is that all the conditions are applied to the user.
What I want now is to add 2 row level conditions from different tables to a user, and I want the report to bring me the information if it satisfy one condition or another, not both.
For example, I have the following objects: Lines, Regions, and Cicles. The 3 are in different tables. I want that this user can get all the information of the Lines which are in Region “1” or in Cicle “25”.
How can I do this, because if I put both restrictions of Region=“1” and Cicle=“25” as row level conditions, but that will only bring me the Lines which satisfy both conditions.
Hope somebody can help me with this , thanks a lot.
You can do or. Just create the intial join tablea.a1=x. Then edit the join and paste the or statement in. tablea1=x or tablea2=y. You will have to do a table force on ever object in the unv so that table1 and table2 come into each query.
Ok, I have a possible solution but I still have some doubts.
I need this condition only for an especific user, so I will add the joins to all my contexts, then force a “where” with the “or” condition on every query of this user.
My doubt know is: how can I force that on every query of the user, it appears the “where” condition I want?
Hope you understand what I just said. Thank you very much.
It’s a lot of work to set up and maintain, but you can do this kind of thing in Designer.
The basic idea is that you have a table of BO logins and the data that they can access in the database, and then build logic into the universe which compares the user’s login to what’s in the row.
Eg, you have a table with BO username and country.
You build self-joins into the universe which checks which countries the user can see using something like ‘table.Country in (select country from userlist where user = @BOUSER)’
It can be a lot of work to put the joins in initially, the lookup table needs maintaining, and this can slow your queries down. But it’s one option of doing what you want to.