32.9　定义评审工作流

未登录的用户只属于Anonymous Users，登录用户则同时拥有Anonymous Users和Registered Users的权限。对于管理员则还拥有Administrators用户组权限。

查看全局（伪项目"—All Projects—"）的初始权限设置，会看到如表32-2一样的授权表格。

对此表格中的授权解读如下：

对于匿名用户：根据第4条授权策略，匿名用户能够读取任意版本库。

对于注册用户：根据第5条授权策略，注册用户具有比第四条授权高一个等级的权限，即注册用户除了具有读取版本库权限外，还可以向版本库的refs/for/＜branch-name＞引用推送，产生评审任务的权限。

之所以这种可写的权限也放在"Read Access"类别中，是因为Git的写操作必须建立在拥有读权限之上，因此Gerrit将其与读取都放在"Read Access"归类之下，只不过高一个级别。

对于注册用户：根据第2条授权策略，在向服务器推送提交的时候，忽略对提交中Author字段的邮件地址检查。这个在之前已经讨论过。

对于注册用户：根据第1条授权策略，注册用户具有代码审核的一般权限，即能够将评审任务设置为“+1”级别（看起来不错，但需要通过他人认可），或者将评审任务标记为“-1”（评审任务没有通过不能提交）。

对于管理员：根据第3条策略，管理员能够读取任意版本库。

上面的授权策略仅仅对评审流程进行了部分设置。如：提交能够进入评审流程，因为登录用户（注册用户）可以将提交以评审任务的方式上传；注册用户可以将评审任务标记为“+1：看起来不错，但需其他人认可”。但是没有人有权限可以将评审任务提交逐一合并到正式的版本库中，即没人能够对评审任务做最终的确认及提交，因此评审流程是不完整的。

有两种方法可以实现对评审最终确认的授权，一种是赋予特定用户Verified类别中的"+1:Verified"的授权，另外一个方法是赋予特定用户Code Review类别中更高级别的授权："+2:Looks good to me,approved"。要想实现对经过确认的评审任务的提交，还需要赋予特定用户Submit类别中的"+1:Submit"授权。

下面的示例中，创建两个新的用户组Reviewer和Verifier，并为其赋予相应的授权。

这样，就为Gerrit所有的项目设定了可用的评审工作流。