禅道开源版 22.5 带来了一组围绕协作效率和操作清晰度的改进。编辑器中 @ 人员后，相关人员可以收到消息通知；测试用例与用例库用例进行版本同步时，系统补充了更明确的操作提示；外部人员也可以在开启相关设置后，被加入需要协作的对象中。
这些变化看起来分散，实际都指向同一个问题：项目协作中的信息是否能及时到达，操作是否能被准确理解，以及不同身份的人员能否顺利参与工作流。
@人员不再只是文本标记
在需求、任务、Bug 或讨论中，@某位成员通常意味着“请关注这条内容”或“需要你参与处理”。如果 @ 只会在正文里留下一个用户名，而不会触发提醒，协作者仍然需要主动刷新页面、查看列表，甚至依赖口头沟通才能发现自己的待办。
22.5 为编辑器中的 @ 人员增加消息通知，使提及动作和消息提醒建立了直接联系。对评审、问题确认、风险升级等场景来说，被提及的人可以更早看到上下文并作出响应。
实践中需要注意几个边界：
- @ 人员应尽量对应明确的行动，例如确认、评审、修复或提供信息。
- 一条内容不宜无差别 @ 大量人员，否则通知会变成噪声。
- 被提及人员的权限和对象可见范围仍然需要符合项目配置。
- 如果业务系统自行实现类似能力，应避免在同一事件上重复发送通知。
测试用例同步提示更加清晰
测试用例与用例库之间的版本同步涉及内容覆盖、历史版本和后续维护。如果系统只提供一个含义模糊的按钮，用户很难判断同步方向、是否会覆盖已有内容，以及同步完成后应该在哪里查看结果。
本次版本优化了同步操作提示，重点是让用户在执行动作前获得更清楚的反馈。清晰的提示至少应该回答三个问题：
- 数据从哪里同步到哪里？
- 目标对象中已有内容会如何处理？
- 同步完成后，用户如何确认结果？
这类提示并不是简单增加几句说明。对于测试管理工具而言，提示文本应该和实际操作结果保持一致，尤其要明确版本关系、覆盖风险和可回退能力。
外部人员可以参与更多协作对象
过去，外部人员被设置为项目或协作对象成员时可能受到限制。22.5 放开了相关限制：开启“列出外部用户”后，外部人员可以正常设置到需要协作的对象中。
这更适合客户、供应商、外包团队和跨组织项目等场景。外部人员能够被加入后，项目管理员可以把协作关系配置在禅道中，而不必通过额外表格或即时通信工具维护一份平行名单。
开放外部人员参与协作时，权限边界仍然是重点。建议按对象和角色分别检查：
- 外部人员是否只能访问必要的项目、产品或迭代。
- 是否能查看内部备注、敏感附件和不应公开的讨论内容。
- 是否需要限制创建、编辑、关闭或导出操作。
- 人员离开合作关系后，账号和成员关系是否能及时回收。
可以这样设计 @通知流程
下面是一个与版本能力相匹配的简化实践示例。假设系统提供“创建评论”和“发送消息通知”两个接口，接口路径与字段仅用于说明集成思路，实际接入时应替换为部署环境中的 API。
编辑器提交内容时，可以先解析 @ 用户，再创建评论，最后为有效的被提及用户发送通知：
#!/usr/bin/env bash
set -euo pipefail
BASE_URL="https://zentao.example.test/api"
TOKEN="replace-with-your-token"
OBJECT_TYPE="task"
OBJECT_ID="123"
MENTIONED_USER_IDS="18,27"
CONTENT='请 @18 和 @27 确认接口返回字段。'
curl --fail-with-body -X POST "$BASE_URL/comments" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d "{
\"objectType\": \"$OBJECT_TYPE\",
\"objectId\": $OBJECT_ID,
\"content\": $(printf '%s' "$CONTENT" | jq -Rs .),
\"mentionedUserIds\": [18, 27]
}"
服务端处理时，可以采用“评论落库成功后再创建通知”的顺序，避免用户收到指向不存在内容的消息。一个最小的伪代码示例如下：
def create_comment(command, current_user):
# 假设 command 已经过身份认证、权限校验和内容解析
comment = comment_repo.create(
object_type=command.object_type,
object_id=command.object_id,
author_id=current_user.id,
content=command.content,
)
user_ids = filter_visible_users(
mentioned_user_ids=command.mentioned_user_ids,
object_type=command.object_type,
object_id=command.object_id,
)
notification_repo.create_many(
user_ids=user_ids,
event="user_mentioned",
resource_id=comment.id,
deduplicate_key=f"mention:{comment.id}",
)
return comment
这个流程体现了三个实用原则：先保存业务事实，再发送提醒；发送前校验对象可见性；通过幂等键避免重试造成重复通知。若通知量较大，还可以把通知投递放入异步队列，但要保留失败重试和投递状态。
升级与使用建议
禅道开源版 22.5 适合关注协作通知、测试用例维护和外部成员管理的团队升级验证。上线前可以用一组小范围场景确认行为：
- 在需求、任务或 Bug 编辑器中 @ 一名项目成员，检查消息是否及时生成。
- 用测试用例和用例库分别验证版本同步提示，确认用户能理解同步方向和影响。
- 开启列出外部用户，使用测试账号将外部人员加入指定协作对象。
- 复核外部账号的项目权限、数据可见范围和离职回收流程。
- 检查已有通知规则，避免原有提醒与新通知重复触发。
本次发布没有只关注单个功能入口，而是同时改善了“提醒谁”“同步什么”和“谁可以参与协作”这几个日常操作。升级时应把功能验证和权限审计放在一起进行，这样才能让新的协作能力真正服务于项目流程，而不是增加新的管理风险。