Odoo 任务分派为什么不只是改个负责人：user_ids、date_assign、通知与邮件入口背后是一整条链

先说结论

在 Odoo 里，任务分派绝不是“把 user_ids 改一下”。

从 project.task 的 create / write / mail 相关源码看，任务分派至少会牵动这些东西：

• user_ids 多负责人关系
• date_assign 分派时间
• personal stage 补齐
• 自动关注（followers）
• assignment notification 邮件
• 某些场景下自动把当前用户补进 assignees
• 甚至从邮件收件人地址里匹配内部用户作为 assignee

一句话说：

Odoo 的任务分派是一个“字段写入 + 协作订阅 + 通知投递 + 审计时间点”的组合动作。

第一层：Odoo 不是单负责人，而是 user_ids

这点其实已经决定了后面很多设计。

Odoo 的任务负责人不是传统 user_id 单选，而是：

• user_ids Many2many

这意味着系统默认接受：

• 一张任务可以多人协作
• 分派变化不是“换人”，而可能是“新增人 / 减少人 / 保留原集合”

也正因为这样，源码里 _message_auto_subscribe_followers() 专门重写了逻辑，来适配 m2m 分派，而不是沿用传统单负责人自动关注实现。

第二层：为什么 date_assign 很重要

在 project.task 里，date_assign 不是摆设。

它专门记录：

• 任务最近一次被分派或取消分派的时间

create / write 里都能看到：

• 创建任务时如果已有 user_ids，会写 date_assign = now()
• 修改 user_ids 时，如果原来没人、现在有人，会写入当前时间
• 如果 assignee 被清空，date_assign 又会被清掉

这说明 Odoo 对“分派”理解得很明确：

分派不是静态属性，而是可以进入流程统计的事件。

所以后面工作时长指标里，才会有从创建到分派的 elapsed 时间。

第三层：为什么分派会自动把 assignee 变成 follower

Odoo 的逻辑不是“负责人”和“关注者”二选一，而是默认打通。

源码里：

• _message_auto_subscribe_followers() 会根据 user_ids 把对应 partner 自动加入 followers
• create() / write() 后，还会调用 _task_message_auto_subscribe_notify()

这说明官方设计是：

被分派的人不只是字段上的负责人，还应该进入这张任务的消息流。

否则就会出现一种尴尬场景：

• 名义上你是负责人
• 但任务后续讨论、日志、变更提醒你根本收不到

这显然不符合协作工具的直觉。

第四层：为什么 assignment notification 和 follower 订阅要分开处理

新手常会把这两件事混成一件事。

其实源码故意分开：

自动关注

解决的是：

• 以后这张任务的消息你能持续收到

_task_message_auto_subscribe_notify() 通知

解决的是：

• 这一次“你被分派了”要不要马上收到一封明确通知

而且它会用模板 project.project_message_user_assigned 渲染：

• assignee 名字
• 任务链接
• 任务描述上下文

所以自动关注是“长期订阅”，assignment notification 是“一次性告知”。

这两个动作都要有，协作体验才完整。

第五层：为什么创建任务时，系统有时会把当前用户自动补进去

在 create() 逻辑里，如果任务既不挂项目、也不挂父任务，但有 user_ids，源码会在某些情况下把当前用户补进去。

这背后的思路很现实：

• 你创建了这张私有 / 特殊上下文任务
• 又把别人设成 assignee
• 那系统默认你至少也是这条协作链上的参与者

官方并不是在“偷偷改负责人”，而是在避免出现：

• 创建者发起了任务
• 却在访问、跟踪、通知上被排除到链路外

第六层：为什么邮件收件人也可能变成 assignee

这部分特别有意思，也很容易被忽略。

在邮件入口逻辑里，源码会尝试：

• 从收件人邮箱匹配内部用户
• 把匹配到的内部用户加入 user_ids

同时又明确排除：

• portal / public 这类非内部用户
• 发件人本人不应被自动设为 assignee

这说明 Odoo 把邮件入口也纳入任务分派链路里了。

也就是说：

分派不只来自表单点击，也可能来自一封被正确路由的邮件。

这对很多服务团队很实用。

第七层：为什么 portal 用户看到的 assignee 语义和内部用户不同

在 project sharing 场景里，portal 用户对 user_ids 的可见性受限，但系统仍然通过 portal_user_names 暴露名字。

这意味着分派在 Odoo 里有两层语义：

• 内部协作层：真实 res.users 关系
• 外部共享层：够用但受控的 assignee 可见信息

这不是功能不一致，而是有意做的权限切面。

新手最容易误解的 5 件事

1. 以为分派就是改一个字段

不对。它至少还会动到时间、关注者和通知。

2. 以为 follower 和 assignee 没关系

不对。源码默认把 assignee 纳入消息链。

3. 以为 assignment notification 就等于自动关注

不对。一个是持续订阅，一个是一次性提醒。

4. 以为 date_assign 只是展示字段

不对。它是可用于统计和流程分析的时间点。

5. 以为任务分派只能通过界面人工点击

不对。邮件入口也能参与 assignee 推断。

实战上最该注意什么

1. 自定义分派逻辑时，不要只写 user_ids

如果你漏掉通知、关注者或 date_assign 语义，系统行为就会变得“看似分派了，其实协作没跟上”。

2. 统计“多久才有人接单”时，优先理解 date_assign

这比看最后修改时间更接近真实业务含义。

3. 接邮件建任务的团队，要特别测试 assignee 推断边界

尤其是内部用户、共享用户、发件人、抄送人混在一起的时候。

一句话记忆法

Odoo 任务分派不是“填个负责人”，而是“写入 assignees、记录分派时间、自动订阅消息、发送分派通知，必要时还从邮件入口推断负责人”的整条协作链。