员工 — 审核 + 批准 / 拒绝 补装 申请
成员在 #Request Regear 上提交 补装;一切提交都会落到 #Review Requests,由员工分流处理。本页端到端走一遍审核队列。
权限
你需要 审核 补装 申请 权限(在"编辑身份组 → 权限"的 补装 区块下),才能看到此频道并对申请采取操作。多数公会会把它给到 补装 员工 / 补装 经理 / 经理 这几种身份组预设。完整表格见 权限参考。
审核队列
从侧边栏的 补装 团队 区块打开 #Review Requests。
页面顶部:
- 标签页 —
待处理/已批准/已拒绝。待处理是工作队列;另外两个是审计视图。 - 工具栏(在 待处理 标签页上):
- 全选 复选框 — 用于多选批量操作。
- 类型 筛选 —
全部/死亡/超额补装。 - 战场职位 筛选 — 收窄到某个 战场职位 的申请(CTA 中某一职位占主导时很好用)。
- 搜索 — 接受受害者名字或
#event_id(带#前缀的 9 位 Albion 事件 ID，例如#475568182)。事件 ID 与 Albion 死亡信息流及事件链接 URL 中使用的数字相同，当成员在 Discord 发来击杀链接问"这条过了吗？"时，复制末尾那串数字、加上#前缀粘贴，队列就会只显示该行。相同的#event_id搜索在 #截单任务 上同样可用，让你能从审核队列一路追溯到打包侧。
队列中每张卡片是一条申请:
- 顶行 — 成员名 + 角色 + 战场职位 徽标(截图中是
Outcomers/FreezDawnera/Riderr)。 - 中部 — 死亡事件链接(eventID)+ 3×4 装备网格,展示损失物品及每个槽位的验证徽标:
- 🟢 通过 — 槽位在期望的 tier 上与职位 套装配置 匹配。
- 🟡 低于T阶 — 物品 tier 低于职位要求。
- 🔵 高于T阶 — 物品 tier 更高。
- 🔴 无效 — 物品根本不在该职位的 套装配置 里。
- 底行 — 操作按钮 + 元信息(UTC 死亡时间戳 + 名望)。
每条申请上的三个操作
✅ 批准
批准这条申请。后续行为取决于公会的 补装 模式:
- 物品模式 — 申请进入
已批准状态;绿色按钮显示为 创建截单任务(单条 + 批量)。点击即可把申请打包进#Cut-off Tasks的一项打包任务。见 物品模式 — 截单 + 储物柜。 - Silver 模式 — 申请进入
已批准状态;绿色按钮显示为 结算(单条 + 批量)。点击会把 silver 计入该成员的 银库 钱包。见 Silver 模式 — 从 银库 发放。
同一个 批准 操作,第二步的按钮不同,由公会配置决定。批准与"钱 / 物真正流转"之间留出空档是有意为之 — 见下方 两步式生命周期。
❌ 拒绝
直接拒绝这条申请。会弹出原因输入框 — 写明原因(例如"战场职位 错了 — 本场 CTA 没分配此职位"),确认。成员会在 #My Requests 看到被拒及原因。
一经拒绝,该申请就是 终态 — 不会再回到队列。如果成员有异议,他们可以用更正的信息提交一条新申请。
📁 归档
把申请从待处理队列移除,既不批也不拒 — 移到 已归档 视图。适合处理重复提交、已不再可执行的旧申请,或一切你想隐藏但又不想下结论的情形。
验证策略的闸门
验证器对 低于T阶 / 高于T阶 / 无效 问题怎么处置,由公会的 补装 策略(设置 → 补装 策略)决定。三个策略槽,各自独立设为:
- 自动拒绝 — 提交时即被拒;永远不进入此队列。
- 允许 — 申请走到员工面前,问题会标注但不会挡成员的"提交"按钮。
- 由员工决定(默认) — 申请进入队列;员工看到问题后逐条裁定。
如果公会对"无效"槽采用"由员工决定",你就会看到带 🔴 徽标的申请仍然需要你判断。每个槽位的提示信息能帮你在 批准(放行)、拒绝(驳回)和 批准时覆写(例如批准时改为另一个与装备匹配的 战场职位)之间做选择。
批准时覆写 战场职位
点击申请卡片顶部的 战场职位 徽标,可针对该条申请 更换 战场职位。这会用新职位的 套装配置 重新跑一次验证 — 用于以下场景:
- 成员在提交时点错了 战场职位。
- 损失装备实际上对应的是另一种职位的 套装配置(例如 Holy Healer 跑了 Lifecurse)。
- 你想套用另一个 silver 上限(在 战场职位 — 按实际封顶 模式下,所选职位的上限决定结算时的额度)。
覆写会记录在审计日志中以保持透明。
多选批量操作
勾选 全选 复选框(或勾选每张卡片的勾选框)→ 工具栏会显示批量的 批准 / 拒绝 / 归档 按钮。
- 批量批准 — 在一次调用中批准 N 条申请。每条仍会按各自模式跑逻辑 — 物品模式会为每条申请创建独立的截单任务(不会合并);silver 模式则把 N 笔结算一笔接一笔执行,但作为单一批量操作完成。
- 批量拒绝 — 弹出原因输入框;所选全部沿用同一原因。适合处理明显违规("这些都没过 战场职位 检查")。
- 批量归档 — 把所选全部移出待处理。不会弹原因。
两步式生命周期
为什么"批准"与"发放"是两次点击:
- silver 是真实货币。 批准 = "这条申请有效";结算 = "动 silver"。Stripe / payroll / PayPal 都把这两步分开。
- 反悔窗口。 如果你在批准与付款之间发现错误,直接拒绝该行,钱还没动。无需补偿性流水。
- 批量发薪。 员工可以攒一周的"已批准"在固定的发薪日一起付 — 一条审计日志、一次 Discord 通知。
- 模式无关的待处理。 待处理申请不关心公会当前是哪种模式。如果公会从物品切到 silver,待处理申请不需要迁移 — 等到被批准时再认领新模式。
物品模式下"打包"这一步更直观:批准 → 申请排队 → 合并进截单任务 → 打包者干活。截单任务才是真正的交接 — 批准只是放行灯。
成员会看到什么
一旦你对申请采取行动,成员在 #My Requests(他们的个人进度页)上会同步看到:
- 已批准 → 进度条推进到 5 步中的第 2 步。
- 已拒绝 → 该行变红,附上你的原因。
- 已归档 → 从他们的待处理视图中消失。
之后进度条会随着截单任务 / 结算 的进展继续走完。成员侧完整细节见 成员 — 提交 补装。
相关页面
- 补装流程总览 — 模式 + 分叉总览
- 成员 — 提交 补装 — 上游提交流程
- 物品模式 — 截单 + 储物柜 — 物品模式下批准之后的事
- Silver 模式 — 从 银库 发放 — silver 模式下批准之后的事
- 设置 — 补装 策略 — 验证策略 + 模式选择
- 成员 补装 报表 — 按成员的审计视图