多个项目中的ClearQuest用户权限设定

由于ClearQuest的一个Schema Repository可以对应多个User Database的模式，所以，在实际使用过程中，一般都是共享同一个Schema Repository、多个开发项目对应都有各自的User Database的模式（为了表述方便，以下简称为“一对多模式”），本文将结合一些使用经验，对该模式下的用户权限设定进行探讨。

    “一对多模式”相对于普通的“一对一模式”（即对每个项目建立一个Schema Repository和一个Database）来说，具有以下几个优点：

1、对于Schema的修改，可以同时反映到各个User Database中；

2、账号管理统一，不需要对每个人重复设定账号和权限；

 

当然，“一对多模式”带来的是，由于多个项目混合在一起，用户权限和流程设置变得更复杂了。而一般来说，即使不同的开发项目，流程也是基本类似的，比如缺陷跟踪管理。但是在用户权限设置方面，却是有几个问题需要解决。

 

以A项目和B项目共用一个Schema、Record Type是Defect为例：

1、A项目和B项目的使用者账号都统一在一个User Administration中管理；

2、A项目中的成员只能登陆A项目的Database，B项目的成员不仅能登陆B项目，还能登陆A项目；

3、A项目中，在Action权限方面，A项目中的成员都有Submit权限，但只有项目经理才有Delete权限；而属于B项目成员的用户即使登陆了，也是只能查看，不能做任何操作；

4、B项目中，在Action权限方面，同样的，B项目中的成员都有Submit权限，但只有项目经理才有Delete权限；

5、Fields在不同的状态时，不同的用户具有不同的权限；

 

上述要求无法在设计Schema的过程中，简单的直接指定某个User Groups具有某个Action就可以了，并且随着使用时间的增长，会有越来越多的项目需要在ClearQuest中进行管理，而我们同样希望能实现上述的功能。我们实现的方法是：将User Groups跟User Database关联起来，在二者之间建立一种特定的关系，而这种特定关系，就是跟User Database的名称Logical Database name相关！

首先，在设计Schema时，对于权限方面，采用脚本动态读取权限的设置。

其次，在建立User Groups，组名的格式要求为：<Database name>_PM，<Database name>_Test，<Database name>_Dev……等

 

还是以Defect中的Delete Action权限为例子吧。

1、在设计时，Delete的Access Control设置为Basic Script，内容为：

       defect_AccessControl = ActionAccessControl(CurrDbName&"_PM","0","0")。

 

CurrDBName函数用来返回登陆的Database名称，ActionAccessControl中的第一个参数为具有该操作权限的组的名称，另外两个参数用来判断提交者和所有者是否具有权限。

2、为A项目和B项目分别建立User Database，Logical Database name分别命名为：apro和bpro，关联到Schema上；若今后有新增项目，可以再建立新的User Database。

3、用户管理里面，对A项目建立两个组：apro_PM和apro_Test，将项目经理的账号加到apro_PM组里面，其余成员的账号加到apro_Test里面。同样的对于B项目也建立两个组：bpro_PM和bpro_Test，加入相应的账号。

4、对于apro_PM和apro_Test，设置Subscribe Database为apro；对于bpro_PM和bpro_Test，则同时可以访问apro和bpro。

上述操作实现了对Delete Action的特殊权限要求。至于对于Fields的权限要求，则可以在此基础上进行调整，但基本的原理也同样是根据数据库名称来做权限的判断。