Navicat Team项目权限不随账号自动迁移，需管理员在成员离职前手动转移所有权；API可批量处理，但不继承连接密码与SSH路径，导出文件无法反向导入Team环境。
Navicat Team 项目权限不随账号自动迁移
离职交接不是“导出再导入”那么简单。navicat team 的项目归属绑定的是组织（organization）内的成员身份，而非个人账号本身；一旦成员从组织中移除，其创建的项目不会自动转给他人，也不会保留在原组织——除非提前做权限委托。
常见错误现象：403 Forbidden 访问原项目、Project not found 提示、协作成员突然无法编辑 SQL 查询或数据模型。
- 必须由组织管理员在成员离职前，手动将项目所有权转移给其他在职成员
- 转移操作只能在
Team Settings > Projects页面完成，不能通过导出.nsq或.nmodel文件实现等效替代 - 被转移的项目会保留全部历史版本、评论、执行记录，但原创建者的头像和署名信息仍保留在审计日志中
如何用 API 批量处理跨组织项目移交（非 GUI 场景）
当涉及多个项目、多个离职成员时，人工点选效率低且易漏。Navicat Team 提供了 REST API 支持批量变更项目所有者，但需注意认证方式和路径细节。
使用场景：HR 批量同步离职名单后，运维需在 24 小时内完成 50+ 个项目权限重置。
- 调用
PUT /api/v1/projects/{project_id}，body 中指定"owner_id": "new_member_uuid" - 认证必须用组织级
API Token（在Team Settings > API Tokens创建），不能用个人账号密码或 Session Cookie -
project_id是 UUID 格式，不是项目名或数据库名，需先调用GET /api/v1/projects拉取列表解析 - API 不校验新 owner 是否属于同一组织——如果填错
owner_id，会导致项目“悬空”，后续需联系 Navicat 官方支持恢复
交接后 SQL 查询与数据源连接是否自动继承？
不继承。项目所有权转移只改变访问控制权，所有底层配置维持原样，包括连接信息、密码存储方式、SSH 隧道设置等。
容易踩的坑：Connection refused 报错常被误认为权限问题，实际是接手人本地未保存对应数据库密码，或 SSH 私钥不在默认路径。
- Navicat Team 不同步客户端本地的
saved passwords，仅同步连接定义（host/port/database），密码字段为空或占位符 - 若原连接启用了
SSH Tunnel，且私钥路径写的是绝对路径（如/Users/alice/.ssh/id_rsa），接手人必须手动更新为自己的路径 - 连接测试失败时，错误信息里不会提示“密码为空”，而是直接卡在
Connecting...或抛出Authentication failed，需主动检查连接编辑页的密码框状态
团队版与个人版混用时的交接盲区
如果离职成员曾把 Team 项目导出为个人版格式（.nsq、.nmodel）并本地保存过，这些文件不包含组织级权限元数据，也无法反向导入回 Team 环境作为有效项目。
性能影响：这类文件体积通常比 Team 后端存储的原始项目大 3–5 倍（因含冗余快照和未压缩日志），误传到共享盘会造成协作混乱。
-
.nsq文件只能被同版本 Navicat 个人版打开，Team 版本点击导入会静默失败，无任何提示 - 组织管理员无法通过后台识别或回收成员本地导出的文件，交接清单必须明确要求提供“Team 内项目 ID”而非文件名
- 若已发生混用，唯一补救方式是让离职成员在账号注销前登录 Team Web 控制台，重新共享对应项目链接给接替人
最常被忽略的一点：项目移交后，原成员若仍保有 Navicat 客户端且未登出，可能继续缓存旧权限，在本地误操作后提交冲突变更——建议同步清理设备端登录态，而不仅是后台移除组织成员。
