人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo Kiosk 打卡为什么不能拿地理位置当“硬门禁”：PIN 认证、设备追踪与 geolocation 只是不同层
很多团队看到 Kiosk 支持 PIN、设备信息和地理位置，就以为 Odoo 已经内建了一套“人在指定地点才能打卡”的硬门禁。可从 hr_attendance 控制器能看出，PIN、device tracking 和 geolocation 分别服务于身份确认、留痕与来源说明，并不是同一个强制控制层。
Odoo 绩效评估为什么不是“发一张表大家打分”：模板、目标与反馈请求其实是三条协作链
很多团队上线绩效模块时，只盯着评估表单长什么样。但 Odoo 里的 appraisal template、员工 goals、feedback request 和最终 appraisal 其实分属不同对象：一个负责结构，一个负责持续目标，一个负责横向取证，一个才负责结论沉淀。
Odoo 合同为什么不是“选个模板生成 PDF”就结束：看懂 Contract Template、work_entry_source 与日历继承链
很多团队把合同理解成一张 PDF，觉得签完、生成完就结束了。可在 Odoo 里，合同文档模板、员工版本时间线、work entry source 和 resource calendar 其实是四层不同对象。把它们混在一起，最容易出现“合同写了兼职，但工时还是全职”的错觉。
Odoo 员工履历为什么不该和技能等级混成一张表：看懂 resume line、course 证据与 skill 边界
很多团队会把“学过什么”“会什么”“做过什么”都塞进同一块员工成长档案里。Odoo hr_skills 源码明显在拆边界：resume line 记录经历与课程，skill line 记录能力等级，证书附件和外链又服务于证据链。它要防的是叙述型履历和可比较能力被混写。
Odoo 请假里的“忽略公共假期”为什么不能随便改：看懂 duration 计算、public holiday 与余额边界
时间假类型上的“Ignore Public Holidays”看起来像个显示偏好，但 Odoo hr_holidays 源码把它当成余额语义开关：它会改变请假时长计算，也会限制你在已有重叠假单时随便切换配置。因为一旦改了，历史余额与审批中的假单都会被重写解释。
Odoo 人才池为什么不是“拖几个候选人进分组”：看懂 email、电话、LinkedIn 的隐式关联链
很多系统的人才池只是一个手工分组功能，Odoo 的 hr_recruitment 则做得更深：候选人进池后，不只自己带 pool 标记，邮箱、电话和 LinkedIn 相同的其他申请也会被间接识别为“与人才池有关”。人才池维护的不是标签，而是候选人身份连续性。