人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
请假批准后，Odoo 为什么要“盖掉”原工时：看懂 Leave 与 Work Entry 的覆盖、冲突与重建
很多用户以为批准请假只是把状态改成已批准。实际上，Odoo 还会重算这一段时间里的 work entries：哪些保留，哪些归档，哪些变成请假工时，取消后又怎样恢复。
为什么 Odoo 不会在候选人一进流程就创建员工：Applicant 到 Employee 的真正边界
很多人以为招聘流程里把候选人推进几步，系统就应该自动变成员工。Odoo 的源码却把 Applicant 和 Employee 分得很开，这不是多此一举，而是在保护招聘、主数据和权限边界。
Odoo 企业版排班打卡为什么不能各算各的：Planning、Attendance 与 Payroll work entry 优先级讲透
基于 hr_work_entry_planning_attendance、planning_attendance 与 hr_payroll_attendance 源码，讲清排班、打卡和工资工时怎样在同一条 work entry 链上消解冲突。
Odoo 企业版 Salary Package Offer 为什么不是“发个 Offer 链接”而已：savepoint 模拟、候选人假员工与 countersign 生命周期讲透
很多人以为 Odoo 企业版 Salary Package Offer 只是给候选人发一个可调薪酬包的链接，再点签字完成入职。源码里真正复杂的地方在于：offer 页面其实跑在 savepoint 里的“模拟版本”，候选人阶段会先造一个 inactive 假员工承接配置，签字后再按单签/会签状态切换版本、激活员工并触发 benefit 相关活动与后续签署。
Odoo 招聘邮箱为什么不是‘收一封邮件建一个候选人’：Job Alias、平台正则和 Applicant 创建链路全拆开讲
很多团队以为招聘邮箱只是把简历邮件导进系统。Odoo 的 hr_recruitment 源码做得更细：岗位可以有自己的 alias，平台来信可以用 regex 抽取姓名，回复地址会跟着岗位走，候选人和联系人还会延迟绑定。它真正处理的是‘邮件来源如何被整理成可持续运营的招聘对象’。
Odoo 员工在不在岗，为什么不只看聊天绿点：IP、邮件、手动改状态三套信号怎么一起工作
很多团队把 Presence 理解成一个在线状态灯。Odoo 的 hr_presence 源码其实在拼三类证据：工作时段内是否应在岗、今天是否有 IP/邮件活动、HR 是否做了手动覆盖。它想回答的不是‘聊天在线吗’，而是‘这名员工现在是否值得被当作在岗处理’。