How to set up row-level data security in BO XI r2

Question

I need to get Data/Row level security into my BO XI r2 report.
A logged in user should be able to view info on pertaining to him without refreshing it.
how do i incorporate this feature into my report?
its possible to do this by setting a filter using the currentuser() function.
however it requires a refresh of the report.
hence the new user shall be able to view the data of the previous user. i need to enforce more security on the data. How do i do this???

Answer 1

Hi Anamika, here is a sample of what the cv_security view might look like:
create or replace view cv_security
as
select distinct sec."gid", sec."uid", sec."from", sec."to"
from
-- All users where NO LIMITS APPLY (sg.group = 1)
(select distinct
sg.group_id as "gid",
sg.user as "uid",
'----' as "from",
'ZZZZ' as "to"
from dual sr, sec_groups sg, sec_users su
where su.user(+) = sg.user
and su.status = 1
and sg.coding = 'GL'
and sg.group = 1
union all
--All users with specified sec_ranges
select distinct
sg.group_id as "gid",
sg.user as "uid",
case when sr.from is NULL
then ' '
else sr.from
end as "from",
case when sr.to is NULL
then ' '
else sr.to
end as "to"
from sec_ranges sr, sec_groups sg. sec_users su
where su.user(+) = sg.user
and su.status = 1
and sg.coding = 'GL'
and sg.group_id(+) = sr.group_id) sec
grant select on cv_security to ROLENAME
Notes about cv_security:
1) For those users with NO LIMITS APPLY (i.e. Admin staff) hard code an absolute range of RC codes from '----' to 'ZZZZ' to ensure you trap all possible alpha-numeric values.
2) For those users with NO LIMITS APPLY (i.e. Admin staff) substitute the sec_ranges table with dual
3) su.status = 1 to a filter to report on only active users
4) sg.coding = 'GL' is assessing the General Ledger coding dimension of the multi-dimensioned security matrix of our Financial system (this may not apply to you)
Responses to your questions:
Q- Does it involve self join between view cv_secured_detail? A- Yes, the 1:N cardinality is a self join between view cv_secured_detail and itself.
Q- What is the difference between steps 3) and a) below it. A- Step 3a) is simply the act of importing the cv_secured_detail Oracle View as a BO Universe Class, with it's columns known to the BO Universe as Objects
Q- Can the tables from which report data is fetched be included in the Universe? or should they be part of cv_secured_detail view.
A- I'm not sure if I understand your question, but I might phrase it another way - Once you create the cv_secured_detail view, and the Universe from this view, with the user = 'BOUSER' limiter. The universe is then used to design the CR, by virtue of it belonging to the CMS Repository, you as the report designer have to log into the CMS repository using your LDAP credentials, if a match is found against the cv_security view your data is automatically row-level secured. In outher words, whatever is declared in the view, is in the universe, and is ultimately available to the report.
Does this help?
Bill.