ClearQuest 下用户组设置策略思考
 

2009-11-27 作者:thehenry 来源:thehenry的blog

 

在CQ二次开发的过程中,可通过流程定制功能来实现不同企业的业务流程,通过用户组权限的设置来达到功能操作权限的控制、数据查看范围权限的控制,可见在CQ下用户组创建策略的重要。经过二次开发过程中的实践,针对自己的体会总结出一些设置策略。以下分为两部分,第一部分为问题需求,第二部分为实现思路。

说明:对于数据查看范围权限的理解建立在深入了解CQ Security Context机制的前提之上。本文中所述的ACL即指CQ的Security Context机制的应用。

问题需求:

假设一个需求变更工单管理系统,需求工单在流转过程中需要经过以下环节:

图一

并且该系统使用组织的架构分为四层:

图二

需求提交之后,将按照箭头的方向流转,下级部门需求流转到上级部门之后必须经过再次审批。开发商不需要进行审批处理。

数据查看权限范围要求箭头流转起始部门不可以看到目的部门的数据,如地市A不可以看到省业务部门的需求工单,省业务部门不可以看到省研发部门的需求工单。开发商属于特殊组织,允许看到所有需求工单,并且上级部门只有相关人员才能看到下级部门的数据,如省业务部门的提交人不可以看到地市A的记录,只有省业务部门的审批人才可以看到地市A的记录。如图三:

图三

实现思路:

我们将建立三种不同用途类型的组,分为组织架构类型的组、操作类型的组、数据创建类型的组,下面将依次说明各种组的作用及优点:

1、组织架构类型的组:

如图二,根据组织层次及工作方式我们定义以下组织架构类型的组,分别为:地市A、地市B、省业务部门提交人、省业务部门审批人、省研发部门提交人、省研发部门审批人、省研发部门分解人、开发商开发人、开发商关闭人。

2、操作类型的组:

如图一,提交操作在不同层级组织中均存在,所以需要3个操作,审批操作在省业务部门、省研发部门均存在,所以需要2个操作,因此将定义8个操作类型的组,分别为:提交人A、提交人B、提交人C、审批人A、审批人B、分解人、开发人、关闭人。每一个组对应一个唯一的操作(通过在CQ Designer开发时指定)。

操作类型的组通过这种方式设置之后,随时可在CQ 用户管理工具中改变操作类型组下的成员组来设置不同用户所拥有的操作功能权限,而且这种方式不需要从CQ Designer中进行,所以也就不需要升级产品库,以免中断用户使用系统。

3、数据创建类型的组:

如图三,数据查看权限要求是:地市公司A和地市公司B不可互相查看,省业务可看到本级及下级所有记录,省研发可以看到本级、省业务及下级所有记录,开发商可以看到所有部门的记录。针对这种要求,我们还需要创建如下三个组:省公司、省业务、省研发。通过Security Context的方式来配置ACL。

根据以上的策略,可随时通过在CQ 用户管理中来配置不同用户的组+ACL的配置满足各种安全控制的要求。假设我们需要满足如图四的安全控制:

图四

上图中U+数字编号代表用户,假设省业务部门、省研发部门的提交人也不可以看到地市的工单数据,并且满足前面的要求,跟按照如下方式配置组与组之间的关系

这样可随时在CQ用户管理中将某个用户加入到 省业务部门审批人组即可具有审批权限,移出该组将撤销审批权限,避免从CQ Designer中操作。

以下为用户与组的关系、ACL的组配置关系:

假设我们在ACL设置中,在创建记录时与组关联。按照Security Context的机制,判断一个用户是否可以查看记录权限的原则为:判断该记录的创建标记组在该用户归属的组列表中是否存在,如果存在则允许查看,否则禁止查看。例如:用户U2创建记录,创建标记组则为“省公司”,用户U3是省业务部门的提交人,用户归属的组列表中只有“省业务”,则不允许查看。而用户 U4则可以查看到U2创建的记录。根据这样的规则,则U1、U2可看到对方的数据。

如果还需要配置地市各分公司禁止互相查看数据,则需要如下配置:

则用户与组管理的配置列表如下图:

火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。

资源网站: UML软件工程组织