|
|
394e1e39c3
|
feat(分组权限): 统计接口接入数据范围（dashboard / analytics / screen 共 20 个路由）
这三组接口此前是「上帝视角」且**匿名可访问**，现在全部挂 get_data_scope ——
既要求登录、又按业务分组范围过滤。顺带堵上了 AGENTS.md 点名的风险：
/dashboard/people-history/export 此前匿名即可批量导出全员工时台账。
dashboard（11 个函数 / 24 处注入）
· Product 主体 → product_where()；Task、TaskLog 主体 → 先 join(Product) 再 task_where()
· 「卡片数字」与「下钻明细」成对出现的地方用同一谓词，避免「按钮显示 2、点开却是 0 条」
· get_user_operations 的 func.count() 改为 func.count(TaskLog.id) —— 显式化，不依赖
join 形状（当前是 many-to-one 不会放大，但这样写更稳）
· unread_notif **刻意不过滤**：Notification.task_id 可空，按 Product 过滤会漏掉
无任务关联的提醒（就地注释说明）
· get_my_stats 本轮不动 —— 它按本人归因，语义上不受分组影响
analytics（4 个函数 / 9 条语句）
· get_analytics_options 的 4 条独立语句全部处理 —— 它是筛选栏下拉的选项源，
不过滤的话维修组能在下拉里看到生产组的人（最易漏的一处）
· get_device_records 的 product_id 查号是安全闸：范围外 SN 查不出 → 直接返回 []
screen（3 个函数）
· month_production **不做特判** —— 维修组的「本月生产数」本来就该是 0
· get_wip_distribution 按范围裁剪工序柱子，但坚持「恒 0 才裁、有数必现」，
保证 total == sum(items) 在任何 scope 下都成立
实测（17 个端点）：超管全部 200、匿名全部 401。
造 1 生产 + 1 售后产品后：
超管 products=2 / wip-matrix 2 行 / options 2 个型号
生产组 products=1 / wip-matrix 1 行 / options 1 个型号
维修组 products=1 / wip-matrix 1 行 / options 1 个型号
列表与统计口径一致；未分组用户在过渡期开关下仍走 ungrouped_fallback。
测试数据已还原。
|
2026-09-21 17:22:01 +08:00 |
|
