DOORS的访问控制怎么去细化，以及因为访问控制导致字段无法编辑又该怎么处理，核心并不是简单地把用户设成只读或者可编辑就结束了，而是要把项目、文件夹、模块、对象、属性定义，还有属性值，这几个层级的权限分开来看。DOORS中常见的访问权限，包括了Read、Modify、Create、Delete，还有Admin这几类，这里面，Modify才是允许去编辑已有数据的，就比如说去修改对象，或者是对象上的属性值。

　　一、DOORS访问控制怎么细化

　　在对DOORS的权限进行细化的时候，不能就光在项目那一层，给一个统一的授权就完事了。需求的模块，一般是会牵扯到不同的角色的，就比如需求工程师、开发、测试、质量、供应商，还有评审的这些人员，他们在同一个模块里面，能动手操作的范围，那是不一样的。权限要是设计得太粗了，是会把那些关键字段给错改了的；可要是权限设计得太碎了，又会让平常正常的编辑流程，动不动就给卡住。

　　1、先把权限的层级给分清楚

　　这个权限，是能从项目、文件夹、模块、对象，还有属性这么几个不同的层级去瞧的。项目跟文件夹的权限，它管的是“能不能瞧得见”；模块的权限，管的是“能不能打开和编辑这个模块”；对象和属性的权限呢，管的则是“能不能去改某一条需求，或者是某一个字段”。要是只给了模块一个可读的权限，那用户是能瞧见里面的东西，可这不代表他就一定能去编辑那些个字段。

　　2、按角色去把能访问的范围给配上

　　在跟【Access】有关的设置里面，照着不同的角色，去把读、改、建、删，还有管理的这些权限给分下去。

　　写需求的那个人，他一般是要能去改对象，还有那些常用的属性的；评审的人，可能就只需要一个读的权限，外加一个能写评论的权限；而管配置的那个管理员，他才适合去拿更高一层的管理权限。可别把Admin这个权限，当成普普通通的编辑权限来使，Admin它是更偏向权限和管理这些操作的，给出去的太多了，是会多出来不少那种误操作的风险的。

　　3、对那些敏感的字段，要单独去管

　　像是状态、ASIL等级、验证的结论、基线的标记，还有变更的状态，这一类的字段，是不太建议让所有人都能去改动的。是可以把那些普通做描述的字段，跟那些关键流程里面的字段，给分开来管的，让多数人能去编辑需求的内容，但就是不能随随便便地去改掉审批的状态，或者是安全的等级。

　　二、DOORS访问控制导致字段无法编辑怎么办

　　碰上字段没法编辑的时候，不要光去瞧这个用户他到底是不是模块的成员。在DOORS里面，能不能去编辑属性的值，一般它是同时被模块打开的那个方式、对象的权限、属性值的权限，还有属性定义的权限，这几样一块儿给管着的。要去编辑对象的属性值，那得对这个对象，还有这个属性值，都有Modify的权限才行的，而且同时，模块还得是用那种独占编辑的方式给打开的。

　　1、去检查一下模块打开的那个方式

　　先去确认一下，这个模块它是不是用Exclusive Edit的那种方式打开的。要是在只读的模式下面，就算这个用户他自己本身是有修改权限的，那也是有可能没法去编辑字段的。碰到好几个人同时用一个模块的时候，也得去确认一下，当前是不是被别人给占用了，还是说，自己就只是用一个只读的方式进到里面去的。

　　2、去检查一下对象和属性的权限

　　在对象的属性里面，去查查看，当前的这一个用户，或者是他所在的那个用户组，对这个对象，是不是有Modify的权限。有些时候，模块那一层看着好像是可以编辑的，可偏偏有某些对象，它继承了不一样的权限，再或者是，有些个字段的属性值，被单独给限制住了，弄到最后，就会出现那种“别的字段都能改，就独独某一个字段改不了”的情况。瞅见这种样子，是要分开去查对象的权限，还有属性值的权限的，不要就只一个劲儿地去改模块的权限。

　　3、去检查一下属性定义的权限

　　要是碰上了没法去改字段的定义、枚举的那些值、默认的值，或者是访问的控制这种情况，那就得去瞧属性定义它本身的权限了。去编辑属性的定义，那是得对这个属性的定义，还有它所在的模块，都有Modify的权限的；要是想要去改掉属性定义，或者是属性值的那些访问的权限，那还得要拿着对应的Admin权限才行的。

　　三、DOORS权限调整后怎么避免反复出问题

　　权限这个东西，最怕的就是临时抱佛脚地去处理。今天给这个人开一个权限，明天再给另一个人补一个权限，时间一长，这个模块里面，就会多出来一大堆的例外，到了后面，谁到底能改什么字段，这事儿就很难再解释清楚了。

　　1、要优先去使用用户的组

　　别直接就给单个的人，去放一大堆的权限。一个更稳当的搞法，是按着角色去建组，就比方说，需求编辑的组、评审的组、测试的组，还有只读的组，然后再把一个个的用户，给加到对应的那个组里面去。等到人员有调动的时候，就只去调整组里面的成员就行了，用不着一个模块挨着一个模块地去改权限。

　　2、把特殊的例外给减下来

　　那些特殊的对象，还有特殊的字段，是可以单独去设权限的，可是这个数量，一定得给管住了。这种例外越是多，后头排查起来就越是费劲。要是某一类的字段，经查需要那种特殊的控制，那最好就是给它形成一套统一的规矩，而不是每次，都靠管理员在那儿临时地去做判断。

　　3、调整完了以后，去做一次验证

　　在权限的修改全都弄完了以后，拿一个普通的账号去把模块打开，实地去测一下，到底能不能查看、能不能编辑、能不能创建对象、能不能去改那个目标里的字段。光去看管理员账号的结果，那是一点意思都没有的，因为管理员，他是常常能绕开那些，普通用户会碰上的麻烦的。

　　总结

　　DOORS的访问控制怎么去细化，因为访问控制弄得字段没法编辑了又要怎么办，是可以照着“先得把权限的层级给理清楚，再按着角色去放权，末了再去检查模块打开的方式、对象的权限、属性值的权限，还有属性定义的权限”这么样一个思路去办的。字段编辑不了，它不一定就是账号没有权限，也有可能是模块给设成只读了、对象的权限被盖掉了、属性值受到了限制，再或者是属性定义的权限不太够。把用户的组、关键字段的那些权限，还有验证的记录，都给归置利索了，那DOORS的权限维护起来，就会变得更稳当一些。