人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版出勤生成工时为什么不是“打卡一保存就结束”：attendance、overtime intervals 与 validated work entry 防线讲透
基于 hr_work_entry_attendance 源码，讲清打卡如何触发 work entry、加班区间如何映射，以及为什么 validated entry 会锁住修改和删除。
Odoo 报销拆分为什么不是改几行金额：split wizard、附件复制与 split origin 关系链讲透
很多团队以为报销拆分就是把一张单据拆成几行金额。Odoo 的 hr_expense 源码做得更严谨：它会先改写原单、再复制新单、再复制附件，并用 split_expense_origin_id 把整组拆分结果串回同一个来源，避免拆完以后证据链和追溯关系散掉。
Odoo 企业版面试预约为什么不是“给候选人一个日历链接”：booking、阶段路由与面试官可用性讲透
基于 appointment_hr_recruitment 与 appointment 源码，讲清候选人专属 invite code、面试预约 booking、阶段流转与面试官可用性是如何绑在一起的。
Odoo 企业版招聘分析为什么不是“漏斗看板”而已：SQL 视图、meeting 计数与 recruiter leaderboard 口径讲透
基于 hr_recruitment_reports 源码，讲清招聘分析为什么单独建 SQL 视图、hired/refused/in progress 的状态口径怎么来，以及 leaderboard 为何按 applicant 与 meeting 聚合而不是直接看阶段列表。
Odoo 企业版绩效技能为什么不是“给 appraisal 多几行 skill”而已：target job 基线、确认快照与完成差异回写讲透
基于 hr_appraisal_skills 源码与测试，讲清 target job 如何补齐技能基线、员工确认时为何复制当前技能快照，以及完成评估后怎样只回写真正发生变化的技能。
Odoo 企业版 Approvals 为什么不是“建个审批类型”就完了：分类字段模板、经理必审与顺序审批 guardrails 讲透
基于 approvals 分类模型与测试，讲清字段模板、最低审批人数、经理必审、自动编号与顺序审批之间如何互相约束。