禅道开源版 22.5：让 @ 通知、外部协作与用例同步更可靠

2026-08-24 34 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

禅道开源版 22.5 的变化集中在日常协作中最容易产生摩擦的几个环节：编辑器内 @人员 后发送消息通知、改进测试用例版本同步提示，以及允许外部人员成为协作对象成员。这些功能看似细小，却直接影响消息能否触达、测试资产是否被误操作，以及跨组织协作能否顺畅落地。

@ 不再只是文本，而是明确的通知动作

在缺少通知联动时，用户即使在需求、任务或缺陷描述中写下某个人的名字，对方也未必会及时看到。22.5 为编辑器中的 @人员 增加消息通知后，提及动作开始具备更明确的协作含义：内容负责人与相关干系人不必完全依赖主动刷新页面或线下转告。

这个变化适合以下场景：

  • 产品经理在需求变更说明中提醒研发负责人确认影响范围；
  • 测试人员在缺陷记录中通知开发人员补充复现信息；
  • 项目负责人更新任务备注后，直接提醒需要参与决策的成员；
  • 评审过程中只通知真正相关的人，减少无差别群发消息。

团队仍需约定 @ 的使用边界。若每次编辑都提及大量成员，通知很快会变成噪声。更可执行的规则是：只有需要对方确认、处理或决策时才使用 @，纯信息同步则交给订阅、看板或例会。

升级后建议验证完整链路，而不只是确认编辑器能选中用户：

  1. 在实际业务对象的编辑器中 @ 一名普通内部用户；
  2. 保存内容，检查被提及者是否收到站内消息；
  3. 验证消息是否能定位到正确的需求、任务或缺陷；
  4. 分别检查有权限和无权限访问该对象的用户；
  5. 连续编辑同一内容，观察是否产生不必要的重复提醒。

用例版本同步提示降低误操作风险

测试用例与用例库之间的版本同步通常不是单纯的文本复制。同步方向、目标版本和覆盖范围一旦理解错误，可能导致团队把旧内容当作最新基线，或者覆盖已经调整过的执行用例。

22.5 优化了测试用例和用例库用例版本同步时的操作提示，重点价值在于让操作者在提交前更清楚地判断“从哪里同步到哪里”以及“操作会影响哪些内容”。对于测试资产较多的团队，提示文案的清晰程度会直接影响变更安全性。

上线后可以选取一条非关键用例做回归：

  • 在用例库中创建一个可辨识的新版本，例如修改前置条件；
  • 进入对应测试用例的版本同步流程；
  • 检查页面是否清楚显示来源、目标和可能产生的影响；
  • 完成同步后核对步骤、预期结果及版本记录；
  • 再测试取消操作，确认不会留下半完成状态。

生产环境不宜用核心回归用例做首次验证。先在测试环境或独立测试项目中走完同步流程，再让测试负责人确认新提示与团队现行规则一致。

外部人员可以进入真实协作链路

过去对外部人员成为成员的限制，会让供应商、客户代表或外包团队难以被设置到实际需要协作的对象中。22.5 放开这一限制：开启“列出外部用户”后，外部人员可以正常设置到需要协作的对象中。

这里需要区分两个动作：列出外部用户解决的是“能否选择”，权限配置解决的是“选择后能看到和修改什么”。升级后不要因为成员选择范围扩大，就默认外部用户应该拥有与内部成员相同的访问能力。

建议按最小权限原则建立外部协作角色：

  • 只开放参与项目所需的产品、项目和执行范围；
  • 限制敏感需求、内部成本、人员信息等数据的访问；
  • 明确外部成员能否创建、编辑、指派或关闭对象；
  • 项目结束后及时移除成员关系并复核账号状态；
  • 使用独立外部测试账号验证实际页面，而不是只检查管理员配置。

可以这样实践：升级前备份与升级后验收

来源摘要没有给出特定部署方式或升级命令。下面是一份可改造的 Docker 部署备份脚本，假设数据库运行在名为 zentao-db 的 MySQL 容器中，禅道附件存放在宿主机 /srv/zentao/data。运行前需要修改容器名、数据库账号和数据目录，使其与实际环境一致。

#!/usr/bin/env bash
set -euo pipefail

BACKUP_ROOT="${BACKUP_ROOT:-/srv/backup/zentao}"
DATA_DIR="${DATA_DIR:-/srv/zentao/data}"
DB_CONTAINER="${DB_CONTAINER:-zentao-db}"
DB_NAME="${DB_NAME:-zentao}"
DB_USER="${DB_USER:-root}"
DB_PASSWORD="${DB_PASSWORD:?Set DB_PASSWORD before running}"
STAMP="$(date +%Y%m%d-%H%M%S)"
TARGET="${BACKUP_ROOT}/${STAMP}"

mkdir -p "${TARGET}"

docker exec \
  -e MYSQL_PWD="${DB_PASSWORD}" \
  "${DB_CONTAINER}" \
  mysqldump --single-transaction --default-character-set=utf8mb4 \
  -u "${DB_USER}" "${DB_NAME}" > "${TARGET}/zentao.sql"

tar -C "$(dirname "${DATA_DIR}")" \
  -czf "${TARGET}/zentao-data.tar.gz" \
  "$(basename "${DATA_DIR}")"

sha256sum "${TARGET}/zentao.sql" \
  "${TARGET}/zentao-data.tar.gz" > "${TARGET}/SHA256SUMS"

printf 'Backup completed: %s\n' "${TARGET}"

执行方式如下：

chmod +x backup-zentao.sh
DB_PASSWORD='replace-with-real-password' ./backup-zentao.sh

备份完成不代表备份可用。至少要在隔离环境中完成一次恢复演练，并核对数据库、附件和历史记录。正式升级后，再按下面的验收清单逐项确认：

[ ] 内部用户可以在编辑器中被 @ 并收到消息
[ ] 通知能够跳转到正确对象，且不会绕过访问权限
[ ] 用例与用例库版本同步提示清楚展示操作方向和影响
[ ] 同步完成后的步骤、预期结果和版本记录正确
[ ] 开启列出外部用户后，可以选择指定外部成员
[ ] 外部成员只能访问获准的产品、项目和业务对象
[ ] 项目结束后的外部成员移除流程可执行
[ ] 数据库与附件备份已经通过恢复验证

升级决策：小功能也要按权限变更处理

22.5 的三个重点改进都在减少协作阻力，但它们也扩大了消息触达和成员选择的范围。升级评估不能只看页面是否可用，还要同时检查通知频率、对象访问权限、外部账号生命周期和测试用例版本治理。

更稳妥的落地顺序是：先备份并在测试环境升级，再用内部账号验证 @ 通知和用例同步，随后使用权限受限的外部账号测试成员选择与数据边界。确认审计、撤销和账号回收流程都能执行后，再推广到生产团队。

# 全栈 # 工程效能 # 开源 # 开源中国

相关推荐