DOORS的权限如果只靠口头约定，最容易在评审、外包协作、基线冻结时出问题。正确做法是先用用户与组把人分清，再用文件夹与模块的Access权限把范围圈住，最后用一套复核与留痕方式让权限变更可追溯。下面按分配流程与外包只读落地步骤写清可执行路径。

　　一、DOORS权限怎么分配

　　DOORS权限分配建议按由粗到细的顺序做，先把用户放进正确的组，再把组赋权到文件夹与模块，必要时再下沉到对象级别。这样做的好处是后续换人不需要重配权限，只要调整组成员即可。

　　1、先确认你是否具备管理用户与组的权限

　　用具备数据库管理员权限的账号登录，在Database Explorer里点击【Tools】→【Manage Users】打开用户管理界面，先确认你能看到Users与Groups两个页签，避免后续创建用户或组时发现按钮不可用。

　　2、先建立组再加人，避免单用户逐条授权

　　在【Manage Users】的Groups页签点击【New】创建组，组名建议按组织与用途命名，例如DEV_ReadWrite、QA_ReadOnly、PM_Review，把组作为权限载体，后续所有模块只给组授权，不对单个用户散配。

　　3、把用户加入组并控制多组叠加带来的权限膨胀

　　在Users页签创建或编辑用户后，把用户加入目标组；同一用户在多个组里权限会叠加，外包账号尤其要避免同时属于只读组与内部开发组，否则最终会拿到更高权限。

　　4、用文件夹权限先圈定访问范围

　　在Database Explorer里对目标文件夹右键点击【Properties】进入Access相关页签，给目标组添加条目并设置R或RC或RCM等权限，先把外包或非相关团队挡在文件夹层面，减少误进误改风险。

　　5、在模块层再细化权限，确保不同模块口径一致

　　对具体模块右键点击【Properties】进入Access页签，把组权限设为你希望的最小集，例如外包组只给R，开发组给RCM，管理员组给更高权限；同时检查默认条目与继承条目，避免模块继承了上层的多余权限。

　　6、需要对象级控制时再做传播，不要一上来就拆到对象

　　只有在同一模块内确实存在敏感对象需要锁定时，才在模块里按对象设置更细的权限，并用【Propagate】把对象权限传播到子层级；否则优先用模块级权限解决，维护成本更低。

　　二、DOORS权限怎么让外包账号只读访问

　　外包只读的核心不是把模块切成只读模式，而是让外包账号在权限模型里永远拿不到Create和Modify。你需要同时把外包账号的组归属和模块Access两端钉死，才能避免权限叠加或继承导致的穿透。

　　1、创建外包只读组并固定命名规则

　　在Database Explorer点击【Tools】→【Manage Users】进入Groups页签，点击【New】创建组，组名建议明确用途，例如OUT_ReadOnly，后续所有外包账号只允许加入该组或其他只读组。

　　2、创建外包账号并仅加入只读组

　　在Users页签点击【New】创建账号，设置登录名与有效期等信息后，在组成员配置处只勾选OUT_ReadOnly，创建完成后再打开账号信息复核一次，确保没有被默认加入其他组。

　　3、先在外包可见的根文件夹上设置只读并去掉新增权限

　　在Database Explorer对外包可见的顶层文件夹右键点击【Properties】，在Access页签为OUT_ReadOnly新增一条权限并只勾选R，确认未勾选C与M与D；同时检查默认条目，避免Everyone Else或默认组存在RCM导致外包通过继承获得写权限。

　　4、在每个对外模块上补一层只读，避免文件夹权限被绕过

　　对需要外包查看的模块逐个右键点击【Properties】，在Access页签对OUT_ReadOnly设置为R，并确认模块没有对象级的特例权限授予外包组，确保外包在模块内也无法创建对象或修改属性。

　　5、用外包账号做两分钟验收，验证能看能检索但不能改

　　用外包账号登录后，打开目标模块，尝试点击【Edit】相关功能、尝试新建对象、尝试修改某个对象属性并保存，预期结果应为无法保存或提示权限不足；同时确认外包仍可用过滤与视图查看内容，避免只读做过头导致无法浏览。

　　6、把外包只读变更写入记录并加一个回滚入口

　　在外包账号开通当天保存一份权限变更记录，包含外包组名、授权的文件夹与模块清单、负责人；需要回滚时只要在【Manage Users】把账号从OUT_ReadOnly禁用或移除即可，不要临时改模块权限去封堵。

　　三、DOORS权限复核与审计留痕

　　权限配完如果不做留痕，最容易在复评时解释不清，也容易在人员变动后慢慢漂移。建议把复核节奏、变更记录、基线冻结三件事固定下来，让权限管理变成流程而不是临时操作。

　　1、建立权限清单并与模块目录一一对应

　　用一张清单列出文件夹与模块路径、Owner组、外包组权限值、内部组权限值，每次新增模块先把清单补齐再放开访问，避免模块越建越多但权限口径越来越乱。

　　2、把权限变更纳入审批并记录生效时间点

　　任何权限调整都要求提交变更说明，写清原因、影响范围、实施人、回滚方式，实施后在清单里记录生效日期，复评抽样时能直接说明何时开通、何时收紧。

　　3、基线前做权限快速复核，基线后冻结访问口径

　　在创建基线前先抽查外包可见模块是否仍为R，确认没有临时放开的RCM残留；基线创建后对外包只读组保持不变，避免同一基线版本在不同时间被外包看到不同内容。

　　4、定期做一次组成员审计，清理叠加权限隐患

　　每月或每里程碑在【Tools】→【Manage Users】里导出或人工核对外包账号组归属，重点检查是否被误加到内部组，发现后先移除组再复测权限，优先消除叠加带来的写权限风险。

　　5、把常见误配点写成检查项，减少重复踩坑

　　重点检查默认组与Everyone Else是否有过高权限，检查模块是否继承了上层不该继承的权限，检查是否存在对象级特例权限把只读组抬升到可写，这三类问题最容易导致外包只读失效。

　　6、交付给外包时同步告知只读边界与请求通道

　　在外包交付说明里写清外包账号只读范围与不可操作项，外包若需修改应走需求变更或评审流程提交，由内部账号执行变更，避免外包以为系统故障而反复尝试修改。

　　总结

　　DOORS权限分配要先用组把角色固化，再把组权限下发到文件夹与模块，必要时才下沉到对象级。外包只读要同时控制组归属与Access权限，做到只有R没有C与M，并用外包账号现场验收验证不可写。最后用权限清单、变更记录、组成员审计与基线前复核把口径长期守住，外包访问就能稳定可控。