很多人看到企业版考勤甘特，会觉得它只是把 hr.attendance 从列表换成甘特图。但 /home/ubuntu/odoo-temp/enterprise/hr_attendance_gantt 真正补的是考勤可解释性：谁还没签退、谁最近有上班但今天没记录、某个时间窗里到底是超时还是欠时。
参考入口：
enterprise/hr_attendance_gantt/models/hr_attendance.pyenterprise/hr_attendance_gantt/tests/test_hr_attendance_gantt.py
一、进度条不是打卡条长度，而是 worked / expected 的比较
_gantt_progress_bar_employee_ids() 会先聚合每个员工在区间内的 worked_hours，再调用 _gantt_compute_max_work_hours_within_interval() 按资源日历算出 max_value。最终显示的是“已工作时长 / 预期工时”。
所以甘特上的进度条不是纯展示效果，它直接回答的是：这个人本时段打卡是否接近日历期望值。
二、开放考勤必须保留，不然管理者会漏看“还没签退的人”
get_gantt_data() 的注释写得很直白：要支持 open-ended records。也就是说，未签退的考勤不能因为没有 check_out 就从甘特视图里掉出去。
这点特别重要。企业现场最怕的不是晚一点记账，而是管理者看不到“人还在班上但记录没闭合”。如果只用严格闭区间搜索，开放记录就会被误判成不存在。
三、为什么还要补 60 天内有过打卡的员工行
官方又额外把“开始日期前 60 天内有打卡、但当前分组里没出现”的员工补进甘特 group。原因不是为了好看，而是为了避免管理者只看到“有记录的人”，看不到“最近活跃但当前窗口为空的人”。
这类员工经常对应三种场景：请假、轮班空窗、数据未补齐。把行补出来，才有机会在同一屏里核对异常。
四、不可用区间不是简单的非工作时间，还要考虑多日历与弹性工时
_gantt_unavailability() 的处理很细：
- 先按员工拿到 calendar periods；
- 再按 calendar 批量算 work intervals；
- 对 fully flexible 日历直接视为始终可用；
- 最后把“没有 calendar 覆盖的区间”和“calendar 内非工作区间”合成不可用区间。
这解释了一个常见误解：甘特底色不是固定朝九晚五模板，而是跟着员工资源日历、时区和弹性工时策略走。
五、overtime_progress 也不是“加班越多越红”这么简单
_compute_overtime_progress() 用 100 - overtime_hours / worked_hours * 100 来算值；如果 worked hours 近似为零，则直接给 100，避免零除问题。它的含义更接近“正常工时占比”，不是单纯把加班时长画成一条独立柱。
因此在看板里，低进度并不一定表示没干活，也可能是超时工作占比过高。
六、实战建议
- 排查“甘特里看不到人”时，先看是否是 open attendance、历史活跃行、还是 user domain 过滤问题。
- 进度条异常时，先核对员工资源日历和 flexible hours，而不是先怀疑打卡记录。
- 多时区公司尤其要注意 start/stop 在 UTC 与本地时区之间的转换。
七、结论
hr_attendance_gantt 的核心价值，不是把考勤画出来，而是把“开放记录、预期工时、历史活跃员工、日历不可用区间”放进同一个管理视图里。它解决的是考勤解释问题，而不只是界面问题。
DISCUSSION
评论区