确认学校角色方案¶
完成本页后，你可以把学校人员的长期职责整理成功能权限和数据范围方案，区分全校、年级、班级和科目职责，并判断是否需要建立自定义角色。
适用对象¶
- 负责整理学校岗位职责和系统权限需求的行政或教务人员。
- 准备配置教师角色、年级、班级或科目绑定的人员。
- 需要判断现有角色是否够用，以及是否需要自定义角色的人员。
所需权限¶
整理角色方案不需要登录 Examark，也不会修改系统数据。
后续核对当前学校角色时，账号需要实际能够进入 管理员设置 → 角色管理；后续配置教师时，还需要能够进入 管理员设置 → 教师管理 并执行相应操作。不要只根据账号名称判断具有这些权限。
前置条件¶
- 已确认本方案对应的学校和组织。
- 已列出需要配置的人员或岗位，但尚未根据岗位名称预设系统权限。
- 已确认哪些职责是长期学校工作，哪些只针对某一场考试。
- 已准备各人员长期负责的年级、班级或科目范围。
- 已阅读身份、角色、权限与数据范围。
进入路径¶
在用户手册导航中进入 管理员指南 → 确认学校角色方案。
本页是配置前的规划页面，不要求进入角色管理或教师管理，也不会要求保存系统设置。
操作步骤¶
1. 先写清楚实际工作¶
为每类人员列出需要完成的具体工作，不要先填写“管理员”“年级组长”“班主任”等角色名称。
建议先建立以下清单：
| 人员或岗位 | 需要完成的工作 | 长期职责或单场考试 | 涉及的数据范围 |
|---|---|---|---|
| 由学校填写 | 例如维护班级、查看成绩 | 长期或单场考试 | 全校、年级、班级或科目 |
同一个岗位有多项工作时分行记录，避免用一个名称代替全部权限结论。
2. 分开长期职责和考试协作¶
先判断每项工作属于哪一种配置：
| 工作性质 | 应记录到哪里 | 已确认边界 |
|---|---|---|
| 学校中的长期功能职责 | 组织角色方案 | 角色决定账号可以使用哪些功能 |
| 长期负责的组织数据 | 年级、班级或科目绑定方案 | 绑定决定功能作用于哪些组织数据 |
| 只负责某一场考试 | 考试协作方案 | 创建人、考官、试题编写人、扫描员和阅卷人只对目标考试生效 |
| 某场考试中的具体阅卷题目 | 阅卷任务 | 成为阅卷人不等于已经获得具体题目 |
学校中的长期角色不能代替考试协作关系。即使长期角色含有考试相关权限，账号没有被加入目标考试时，仍不能看到或进入该考试。
3. 为长期工作选择功能权限¶
在角色权限与数据范围参考的“当前可分配的功能权限”部分查找每项工作对应的已确认权限名称和编码，再填入方案表。
记录时遵循以下要求：
- 每项权限都应对应一项已经确认的实际工作。
- 不根据岗位名称自动增加权限。
- 涉及查看和维护时，分别核对对应权限，不把“可以查看”写成“可以维护”。
- 涉及菜单、按钮和数据时，分别记录后续需要验证的结果。
一个账号拥有多个组织角色时，各角色提供的功能权限按并集合并。因此，方案表需要查看该账号的全部角色，不能只检查其中一个。
4. 确定职责的数据范围层级¶
为每项长期职责记录需要覆盖的范围：
| 范围层级 | 方案中需要写清楚的内容 |
|---|---|
| 全校职责 | 哪项工作需要覆盖当前学校整体 |
| 年级职责 | 需要负责哪些具体年级 |
| 班级职责 | 需要负责哪些具体班级 |
| 科目职责 | 需要负责哪些具体科目 |
一个账号绑定多个班级、年级或科目时，各有效绑定覆盖的数据范围会按并集合并；不同层级的有效绑定也会一起合并。
合并后的范围可能大于单条记录
设计方案时必须汇总同一账号的全部有效绑定。不能因为某一条绑定范围较小，就忽略其他角色或绑定带来的功能和数据范围。
班主任、副班主任、任课教师和班级 AI 阅卷教师这四类班级角色中的“任教科目”均已确认不是必填项。本阶段不介绍 AI 教师或 AI 角色的实际行为。
5. 形成角色与绑定方案表¶
为每类人员填写一行或多行方案：
| 人员或岗位 | 实际工作 | 所需权限名称/编码 | 范围层级 | 具体范围 | 单场考试另行配置 | 后续验证项 |
|---|---|---|---|---|---|---|
| 由学校填写 | 已确认工作 | 从参考表选择 | 全校/年级/班级/科目 | 写明名称 | 是/否 | 菜单、按钮、数据 |
如果同一人员需要多个角色或多个绑定，应在表中全部列出，并增加一行“合并后结果”，写清最终功能和数据范围。
6. 判断是否需要自定义角色¶
本阶段使用的自定义角色类别包括 全校角色、年级角色、班级角色和科目角色。AI 类别不纳入本页。
按以下顺序判断：
- 下一步先查看当前学校已有角色的实际权限和状态。
- 检查已有角色是否覆盖方案中的功能权限。
- 检查角色类别与计划的数据范围是否一致。
- 汇总该人员全部角色和绑定后的结果。
- 只有当前已有角色仍不能满足已确认职责时，才把自定义角色列为候选。
不要因为岗位名称与现有角色名称不同就直接创建新角色。名称不同不能证明权限不同；名称相同也不能证明权限相同。
创建自定义角色前必须完成复核
自定义角色在新建时可以选择权限，但创建后暂时不能再次修改权限；名称、说明和状态可以修改，也可以删除。
因此，方案中仍有未确认权限时不要提前创建。先完成当前学校实际权限核对，再决定是否需要自定义角色。
7. 标记后续操作，不在本页直接配置¶
在方案表最后增加处理结论：
| 结论 | 后续处理 |
|---|---|
| 已有角色满足需求 | 记录角色名称，下一步核对其当前实际权限和状态 |
| 需要多个已有角色或绑定 | 列出全部配置，并计算合并后的范围 |
| 可能需要自定义角色 | 列出缺少的权限和类别，核对后再创建 |
| 仅属于单场考试 | 不加入长期角色方案，留到目标考试的协作配置 |
| 仍有事实或学校决策未确认 | 保留问题和负责人，不进入系统配置 |
本页不创建、修改、分配或删除任何角色和绑定。
角色变更的验证边界
已确认的规则是：修改用户已经分配的角色或绑定后立即生效，已登录用户刷新系统后可以看到调整结果。
这条规则不等于“修改角色定义中的权限后，所有已有用户也按相同方式生效”。后者尚未单独实测。后续如果修改角色定义，应使用目标账号刷新系统，并分别核对菜单、按钮和数据，不预先承诺生效时间。
完成标志¶
同时满足以下条件，表示学校角色方案已经确认：
- 每项权限都能对应到一项实际工作，而不是来自角色或岗位名称推测。
- 长期组织角色、数据绑定、考试协作和阅卷任务已经分开记录。
- 全校、年级、班级和科目职责均写明具体范围。
- 同一账号的多个角色和绑定已经计算合并后的结果。
- 已明确哪些需求可由现有角色满足，哪些需要下一步核对。
- 只有现有角色可能无法满足的已确认需求，才被列为自定义角色候选。
- 方案中没有包含 AI 教师或 AI 角色的行为假设。
下一步¶
进入查看当前学校的实际角色权限，逐项记录目标角色当前包含的权限和状态。方案表不能代替当前学校的实际权限核对。
如果需要重新核对基础组织数据，返回新建班级。