人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Approvals 为什么最怕“谁都能改一下”：申请人、审批专员与 approver 访问/写入边界讲透
基于 approvals 源码与测试，讲清申请人何时还能改单、审批专员能改什么、普通 approver 为什么不能随便改 approver 行。
Odoo 企业版 Approvals 为什么不是“建个审批类型”就完了：分类字段模板、经理必审与顺序审批 guardrails 讲透
基于 approvals 分类模型与测试，讲清字段模板、最低审批人数、经理必审、自动编号与顺序审批之间如何互相约束。
Odoo 薪资为什么不是“工资规则从上到下算一遍”：Structure Type、Rules、Worked Days 与 Inputs 的进数链
很多团队做薪资时，只盯着 salary rule 的公式，仿佛把规则从上到下跑一遍就能得到正确工资。真正更关键的是：Structure Type 决定你在什么制度里算，Worked Days 决定工时口径，Inputs 决定临时变量，Rules 只是最后消费这些输入的计算层。
Odoo 企业版 Approvals 为什么删除/复制最容易出事故：附件解绑、产品行清理与 copy 行为边界讲透
基于 approvals 模型与测试，讲清草稿删除、已批准归档、附件清理、产品行删除与复制命名这些容易被忽略的边界。
Odoo 企业版 Approvals 为什么最容易错在“谁是申请人、谁是经理”：request owner、公司域与经理解析链路讲透
基于 approvals 请求模型与测试，讲清 request owner 可选范围、跨公司员工档案匹配，以及经理审批为什么经常选错人。
Odoo 年假计划改了，为什么老余额不会自动重写：Milestone、Carryover 与 Transition 只会沿时间线继续生效
很多 HR 看到累计计划配错了，会直觉觉得“把 accrual plan 改对，旧余额应该一起刷新”。但从 hr.leave.allocation 的累计处理逻辑能看出，milestone、carryover、nextcall、lastcall 和 expiring carryover days 都是在沿时间线推进，而不是每次全量回算整段历史。