人才库为什么不是“把候选人打个标签”就完事：Odoo Talent Pool 的去重、复制与复用边界
很多团队以为人才库就是在候选人身上挂个 pool 标签。Odoo 源码其实做得更细：有直接入池、复制成 talent、通过邮箱/电话/LinkedIn 间接识别同人，以及专门避免重复加池的搜索逻辑。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 招聘阶段为什么不只是拖看板：看懂 hired stage、date_closed、rotting 与流程语义
招聘看板里一个阶段卡片看起来只是个列名，但 Odoo 源码把阶段做成了流程语义控制器：hired_stage 会决定 hire date，fold 影响看板行为，rotting_threshold_days 决定陈旧判断，legend 和邮件模板又影响团队协作。阶段不是 UI，而是招聘状态机的一部分。
Odoo 报销分摊为什么不该靠员工手填到底：看懂 analytic distribution、员工工作联系人与转嫁边界
很多公司希望员工提报时自己把费用分到项目、部门、客户。Odoo 的 hr_expense 源码更保守：它会优先从 analytic distribution model 按产品、科目、员工工作联系人等条件推分摊，避免把成本归属完全交给填写人。报销真正难的不是录金额，而是成本语义一致。
Odoo 报销为什么会同时提示“同收据”和“疑似重复”：看懂 receipt hash、金额匹配与审核顺序
报销单里出现“same receipt”和“duplicate expense”时，很多人会以为系统重复报错。其实 Odoo 源码故意做了两套不同检测：一套看附件 checksum 找同一张收据，一套看员工、产品、日期、金额、公司和币种找疑似重复报销。它们要拦的是两类风险。
Odoo 自动签退为什么不是“到点就关单”：看懂 open attendance、跨天修补与 auto check-out 的排错顺序
很多团队开了自动签退后，以为系统会在下班时间准点把打卡关掉。Odoo 的 hr_attendance 源码实际更谨慎：它先判断有没有 open attendance，再结合时区、当日历史工时、排班段和容忍度计算该签到哪里。它解决的是“漏签退如何被修补”，不是“排班系统替你写结论”。
Odoo 考勤 Kiosk 为什么不是“开个公共页面打卡”就完了：token、PIN、条码与设备追踪边界
考勤 kiosk 看起来像一个公共签到页，但 Odoo 源码其实把它拆成了公司 token、员工条码、可选 PIN、设备追踪、手动选择和会话退出几层控制。它要平衡的是“前台要够顺手”和“公共终端不能轻易冒签”。
Odoo 组织架构为什么不怕“经理的经理又回到自己”：看懂递归下属、经理环路与 org chart 边界
很多人以为组织架构树只要 parent_id 一路往下展开就行。Odoo 的 hr_org_chart 明显想得更远：它既要展示直接下属，也要算间接下属，还要防止“CEO 属于某部门、部门又层层回指 CEO”这种递归环路把统计搞炸。源码真正做的是一个可容错的层级遍历器。