人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 招聘邮箱为什么不是‘收一封邮件建一个候选人’：Job Alias、平台正则和 Applicant 创建链路全拆开讲
很多团队以为招聘邮箱只是把简历邮件导进系统。Odoo 的 hr_recruitment 源码做得更细：岗位可以有自己的 alias，平台来信可以用 regex 抽取姓名，回复地址会跟着岗位走，候选人和联系人还会延迟绑定。它真正处理的是‘邮件来源如何被整理成可持续运营的招聘对象’。
Odoo 员工在不在岗，为什么不只看聊天绿点：IP、邮件、手动改状态三套信号怎么一起工作
很多团队把 Presence 理解成一个在线状态灯。Odoo 的 hr_presence 源码其实在拼三类证据：工作时段内是否应在岗、今天是否有 IP/邮件活动、HR 是否做了手动覆盖。它想回答的不是‘聊天在线吗’，而是‘这名员工现在是否值得被当作在岗处理’。
Odoo 员工为什么不是“一人一合同一条线”：看懂 hr.version 才看懂员工生命周期
许多用户以为员工档案只是一行记录加一份合同。Odoo 新版 HR 源码其实把员工变化拆成版本时间线，合同只是其中一层，这让调岗、调薪、换排班、未来生效变更都更好处理。
Odoo 请假为什么不只是“申请几天假”：Allocation、Accrual 和剩余额度到底怎么算
很多人把 Odoo 请假理解成填一张申请单，但 Time Off 真正难的是额度来源、累计规则和审批边界。本文把 allocation 和 accrual 讲清楚。
Odoo 候选人转投多个岗位为什么不是改一改 job_id：复制申请、初始阶段重算与 talent pool 解绑讲透
很多团队看到“把候选人加到别的岗位”时，第一反应是直接改 job_id。Odoo 的 job_add_applicants 向导并不这么做：它会复制 applicant 数据，为每个目标岗位新建一条申请，按岗位可用阶段重新选最早的非 fold stage，并显式清空 talent pool 关联，避免把人才池语义和真实岗位申请混成一条记录。
Odoo 批量请假为什么不会粗暴覆盖原记录：冲突拒绝、拆分旧假与时区换算讲透
很多团队以为批量生成 time off 就是选一批员工、选一个区间、点创建。Odoo 的 hr.leave.generate.multi.wizard 源码明显更谨慎：它会先按公司日历时区把日期转成 UTC 区间，检查并拒绝无法自动拆分的小时假，对整天冲突假单做拒绝或拆分，再带着一组特殊 context 批量创建新假单并验证。