pangbianlaogu 2012-11-26
在某人的前东家那里, 在企业级别协作平台中, 文档是是管理在内容容器中, 这个内容容器可以是community 和project, 类似于Jive 的管理方式。
1.容器以及容器的描述信息可以对容器外用户搜索开放,以方便用户发现更多的容器;
2.容器中的内容希望对容器外的用户搜索封闭,以保护容器中的文档信息不会被较低权限的人所看到。
比如我们有如下组织的内容容器
-CompanyA(community)
--DepartmentRD(community)
---DepartmentDev(community)
----FrontEndTeam(community)
----Projectwebcomponent1.0
----ProjectApplloFrontEnd(project)
---ServerTeam(community)
----ProjectApplloServerEnd(project)
----ProjectSearchEngineRefactor(project)
---DepartmentTesting(community)
----ProjectApplloTesting(project)
---ArchitectureTeam(community)
--DepartmentSales(community)
-CompanyB(community)
这里我们假设A 公司有研发经理他是需要能够查看整个RD 社区下的内容, 又有Appllo 开发参与了项目Appllo 需要能够查看 Project Appllo Front End, Project Appllo Server End 和 Project Appllo Testing的内容。在内容创建的时候, 比如我们在Project web component 1.0 下新建一个文档, 那么它在容器管理中的路径应该是 Company A/Department RD/Department Dev/Front End Team/Project web component 1.0, 在文档创建索引的时候, 就带上Path 这个属性, 并且对path 进行索引。 当搜索要求到来的时候,业务调用方需要告诉搜索引擎当前用户所能看到的容器权限。 那么上文提到的研发经理, 那么他能够看到path Company A/Department RD 下的所有文档, 那么我们在搜索query中附加条件是 path:"epartment RD", Appllo 开发人员, , 我们在搜索query 中的附加条件是 path:"Project Appllo Front End" OR path:"Project Appllo Server End" OR path:"Project Appllo Testing"
1.需要业务系统管理整个容器权限
2.用户登录以后获取用户在整个系统中的权限树并存储在缓存中
3.用户在添加文档的时候,系统往搜索引擎中推入文档数据不需要考虑用户的权限,只需要保存文档本身的信息,包括文档在系统中的目录结构
4.用户在搜索的时候,需要附加用户可见的所有子节点目录,如果某节点下的所有子节点用户都可见,那么只需要给出这个当前节点。举例:
假如有用户他有对以下容器的读权限 Company A/Department RD/Department Dev/Front End Team/Project web component 1.0 和Company A/Department RD/Department Dev/Project Appllo Front End, 那么我们只需要给搜索引擎 Company A/Department RD/Department Dev/Front End Team 就好了5. 通过一定规则保证容器名(容器ID)之间不会出现重复。
1. 用户在应用系统中的角色权限发生变化, 我们不需要对已经生成的文档进行重新索引
2.应用系统中的容器隶属关系发生变化,比如我们这个时候CompanyA把CompanyB收购过来了,那么我们需要对相关变化的容器中的文档进行全部重新索引,也就是需要把CompanyB的内容容器中的文档进行索引重建。
另外一部分,则需要先做聚类、分类处理,将聚合出的分类结果存入ES集群的聚类索引中。数据处理层的聚合结果存入ES中的指定索引,同时将每个聚合主题相关的数据存入每个document下面的某个field下。