anlinew

nice！

kylin已经接入 权限这部分比较麻烦 权限最终实际上是资源的访问控制，之所以要结合，无非是因为用户在原有系统，而资源在cboard，因此就有两个方式： 1、已有系统的人员角色（需要报表这部分的）进cboard，如果你的系统支持类似cas之类的鉴权体系，直接使用Cboard的cas client机制配置一下即可，这样原有系统的user及其角色（可选、需改造cborad）在sso进入cboard的同时就会在cboard中产生，然后对这些角色进行赋权即可，也可以给这些人赋予cboard里的角色 2、将cboard里的资源注册到原有系统作为原有系统的外部资源进行管理，在原有系统对这部分资源进行鉴权时，调用cboard的鉴权服务 我们目前用方案1

这种过滤不是用户可选择的，是数据集级的，建议： 1、登陆用户参数可接受传输的参数（运行时上下文，比如用户名、角色、组织 loginname 、rule、org等），运行时参数可通过session上下文自定义扩展就更好了 2、数据集配置时的过滤里可以增加默认过滤条件  在这里配置，支持当前登录用户等运行时参数选项 

通过将数据集里的维度与用户运行时参数匹配来实现灵活的数据隔离机制 这里的最近xxx的时间维条件是系统级运行时参数 当前用户、角色、部门、组织、租户等信息则是应用级运行时参数，属于企业级应用运行时常见的上下文信息

理解 希望所谓“公司的政策”别影响了这个好项目的发展

单使用用户也可以变通做到数据权限控制，只是可能不够优雅 需要为每个需要做数据权限控制的模型增加一个xxbyuserpower的模型，即根据将数据权限模型按照用户展开并形成关系表，将原业务模型与这个权限模型进行关联，比如原来的订单模型 order ，如果要控制某人能看某部门的订单，则建立人与部门的权限关系，然后与订单表通过部门关联形成order_byuserpower的模型即可，供参考