如何在BO的报表中过滤数据
我在做报表的过程中，遇见一个问题。
客户要求在浏览报表的时候，要求进行公司结构的数据过滤。
详细的说，就是集团A底下有公司A，公司B，公司C
在浏览报表的时候，集团A可以浏览全部的数据，各公司间只能看自己的相关数据
并且，在这个基础上，还有公司部门的结构。
比如，各个公司可能有自己的财务部门，人事部门等
集团A的财务，可以看所有的财务报表，就是说能看集团A+3个公司的财务报表，不能看人事的。
同样，集团A的人事也只能看所有的人事报表。
但是到了下面公司，各公司只能看本公司的相关报表。
比如，公司A的财务部门只能看本公司的财务，不能看其他公司的财务，也不能看本公司的人事。
而同时，财务报表可能含员工薪资，福利，资产等几个块的报表；
人事可能含人员花名册，人员培训情况等几个块的报表。
以上是大的结构上的需求。
小需求是，客户要求把BO报表集成到门户里。
先选择公司，再选择部门，最后选择报表。
比如，公司A的财务领导先选择公司A，然后选择财务，最后选择财务里的员工薪资报表。
要求，当用户跨权限浏览的时候，提示报错。报错后的处理，只要不给他看跨权限的数据，怎么处理都行，比如直接返回上一页，或者跳到出错页。
PS：各公司的一把手，有权利浏览本公司所有部门的所有报表
请问大家有什么好的设计方法
[最优解释]
没什么好办法，因为从数据上讲，universe是最小的授权单位。
一般的做法，有时是只授给用户report的权限，这样这个用户就只能刷新和查看这个预先设计好的report
或者建不同的universeA,universeB,universeC每个中只desinger中把filter的where 子句加上。
以前做过一个，是通过在数据库中设计不同的视图，把视图的权限授给不同的用户。比如在oracle中，建usera,userb,userc
在usera schema中建成 usera.view_data as select * from data where companyid='A'，相应B，C中也一样。
然后你可以设置connection让用户登录的时候输入oracle的账号。
[其他解释]
又错了
。。。。
select
decode('时间参数','',1,'时间字段') as 时间,
decode('地区参数','',1,'地区字段') as 地区,
decode('部门参数','',1,'时间字段') as 部门,
sum(度量) as 度量
from 表
where
... 其他条件
....
[其他解释]
自己顶自己
[其他解释]
第一种方法是可行的，但是会随着公司结构的膨胀而集聚膨胀
并且，目前的公司结构就很庞大了
第二种方法能说详细下吗？
因为用户登陆的是BO的系统，帐号都是BO里，好象跟数据库关系不大
[其他解释]
在你设置universe 的connection的时候，有一个选项就是可以让用户自己输入数据库的账号。
这样如果你能集成BO，WINDOWS，ORACLE/SQL SERVER的账号，比如全部都使用windows的账号进行验证。则可以方便的使用第三种。
第二种很简单。建三个universe, 记得是在class上还是在表上可以设置条件
[其他解释]
在数据库层面一般是通过给用户授权来解决的。
[其他解释]
BO 不是数据库，是数据仓库分析工具。有自己的分组授权对象和结构。一般是通过在BO中直接进行授权。只有楼主这种特殊需要才需要考虑不同的方案来实现。
[其他解释]
可以在一张报表中，查询两个UNIVERSE吗？
我是说，把UNIVERSE像表一样联结查询，然后把结果反映到一个报表上
[其他解释]
在一个REP报表文件中可以插入多个universe. 菜单，插入，表格，然后你选择 from different way就行了。
不同的universe没办法直接UNION，你需要先建一个filed link,然后只能做join,但由于companyid上不重复，一个是A，一个是B，所以join后会显示成两列，看看能不能通过公式把这两列合并起来。
[其他解释]
啊~~烦啊
让我再考虑考虑
我觉得这个问题是比较普遍的问题，希望能搞出个最佳解决方案
[其他解释]
如果数据库是SQL SERVER则建议用第三种方法。直接在数据侧把用户的widnows 账号加到sql server 的用户组中即可。这样就用一个universe实现了。
[其他解释]
哎……关键时候哪壶不开提哪壶啊
我们用的是ORACLE
[其他解释]
呵呵，我们也是oracle,所以用了方案二，5个universe ,4个是各分公司的，一个是可以看所有的
[其他解释]
来抢沙发了啊~~~~~~~~~~~~~
------其他解决方案--------------------
看来这种需求真的是很普遍。
最开始我们用BV做报表数据源的，结果就是因为这个不同层级的问题，改用了unv。
对于不同层级的人，BO的技术人员建议我们用filter,但是加filter是个痛苦的事情，我们用sdk接口去加
因为用户比较多，有的一个报表的filter要加到上千个，当一个报表的filter超过200个的时候，再加一个要3秒以上，越多越慢，后来到了10秒以上
到最后基本不可忍受。
后来我们就摒弃了这个方案，用参数+SQL来实现。
数据库是oracle.
我们是用水晶报表做rpt来连unv的
比如我们要区分总公司和分公司，unv的语法是这样的，当然实际情况比这个复杂的多
Select * from tbl where decode('参数','',1,{分公司字段})=decode('参数','',1,'参数')
参数应该是个prompt语法，我就不写了
如果输入参数为空（当然，也可以是个特殊值，比如000等），那么
decode('参数','',1,{分公司字段})=decode('参数','',1,'参数')
=>
1=1
显示数据全集
否则
{分公司字段}='参数'
仅显示输入参数，如本公司的数据
于是关键就落在前段上如何控制不同的用户必须输入自己所在级别的，现在我们是自己编程来控制这一端的
数据库里面建了一套人员层级表（对应BOE账号表，就是每个账号对应不同的人，以及他的层级信息，及权限级别等），
登陆时首先登陆到BOE中，登陆成功后从我们自己的库里取层级
然后根据报表参数，前端界面显示一个层级列表
分公司 下拉菜单
部门 下拉菜单
总公司的能看到所有的分公司和部门，某公司的只能看自己公司和部门，某部门的就只能看自己的部门
这样保证前台传进去的参数是有效的，当然，为了安全，用户提交后，需要绕到层级表里去检查权限的
获得这个参数后，通过opendoc把参数传给报表来呈现。
表述的不是很清楚好像~~
另外BOE的报表权限也比较抽象，虽然有SDK，但是也有些麻烦。
现在我们正在准备把这一层也接管过来。
纯用BO套件，有时候处理起来确实有点力不从心。
[其他解释]
补一下，所有的分公司数据，在一个unv中实现的。
[其他解释]
[其他解释]
