|
|
@@ -69,6 +69,9 @@
|
|
|
**API路径约定说明:**
|
|
|
所有新增的用人方小程序API必须遵循 `api/v1/yongren` 前缀约定,确保与现有管理后台API路径隔离。每个故事在实现API接口时需确保路径前缀正确。
|
|
|
|
|
|
+**故事概览:**
|
|
|
+本史诗包含13个故事,其中11个为核心故事(012-01到012-05、012-08到012-13),1个延期故事(012-06),1个冗余故事(012-07)。核心故事已实现10个,剩余1个待实现。
|
|
|
+
|
|
|
### 故事012-01:数据库schema扩展
|
|
|
**背景:** 现有数据库表结构缺少支持用人方小程序完整功能的关键字段,需要在不影响现有数据的前提下扩展schema。
|
|
|
|
|
|
@@ -437,9 +440,100 @@
|
|
|
- [x] 集成测试覆盖新增字段的各种场景
|
|
|
- [x] API文档更新,包含新增字段说明
|
|
|
|
|
|
+### 故事012-13:工作状态统一优化 - 基于order_person.work_status的长期方案
|
|
|
+**背景:** 在当前的企业专用人才API中,工作状态筛选存在数据类型不匹配问题:前端传递中文状态("在职"、"待入职"、"离职"),Schema验证为字符串,但数据库`disabled_person.job_status`字段为smallint类型(0-未在职,1-已在职)。短期修复通过状态映射解决了基本筛选功能,但"待入职"和"离职"都映射到0,无法精确区分。本故事实施长期理想方案:使用`order_person.work_status`字段(enum类型:'not_working'、'pre_working'、'working'、'resigned')作为统一的工作状态源,解决状态不一致问题。
|
|
|
+
|
|
|
+**技术优势分析:**
|
|
|
+1. **语义准确性**:`order_person.work_status`直接记录人员在订单中的工作状态,更准确反映业务实际
|
|
|
+2. **状态完整性**:已有完整的4个状态值,覆盖前端所需的3个状态('pre_working'→"待入职"、'working'→"在职"、'resigned'→"离职")
|
|
|
+3. **类型一致性**:enum类型与Schema验证类型匹配,无需复杂映射
|
|
|
+4. **已有基础设施**:`WorkStatus`枚举、`WorkStatusLabels`中文映射已存在,可直接使用
|
|
|
+
|
|
|
+**关键挑战:**
|
|
|
+1. **关联查询复杂性**:需要从`order_person`表获取最新工作状态(一人可能有多条记录)
|
|
|
+2. **状态转换逻辑**:`WorkStatus`枚举值('working')需要转换为前端期望的中文状态("在职")
|
|
|
+3. **性能影响**:关联查询可能影响性能,需要优化索引
|
|
|
+
|
|
|
+**任务列表:**
|
|
|
+
|
|
|
+1. **查询逻辑重构**(disability-module扩展):
|
|
|
+ - 在`disabled-person.service.ts`的`findAllForCompany`方法中,修改查询逻辑:
|
|
|
+ - 使用`order_person.work_status`而不是`disabled_person.job_status`作为工作状态源
|
|
|
+ - 获取人员最新的`order_person`记录(按`join_date`降序)来确定当前工作状态
|
|
|
+ - 在SELECT语句中添加`MAX(op.work_status)`或通过子查询获取最新状态
|
|
|
+ - 更新结果映射逻辑,将`WorkStatus`枚举值转换为中文状态
|
|
|
+ - 'working' → "在职"
|
|
|
+ - 'pre_working' → "待入职"
|
|
|
+ - 'resigned' → "离职"
|
|
|
+ - 'not_working' → "未就业"(作为后备状态)
|
|
|
+
|
|
|
+2. **筛选条件优化**:
|
|
|
+ - 修改`jobStatus`筛选逻辑,直接使用`order_person.work_status`进行过滤
|
|
|
+ - 支持前端中文状态到`WorkStatus`枚举值的映射:
|
|
|
+ - "在职" → 'working'
|
|
|
+ - "待入职" → 'pre_working'
|
|
|
+ - "离职" → 'resigned'
|
|
|
+ - 更新Schema验证,明确状态映射关系
|
|
|
+
|
|
|
+3. **人才详情API统一**:
|
|
|
+ - 在`findOneForCompany`方法中,同样使用`order_person.work_status`作为工作状态源
|
|
|
+ - 获取人员最新的订单关联记录,确定当前工作状态
|
|
|
+ - 保持与人才列表API一致的状态转换逻辑
|
|
|
+
|
|
|
+4. **数据库性能优化**:
|
|
|
+ - 分析现有索引:`order_person`表已有`['personId', 'workStatus']`、`['joinDate']`等索引
|
|
|
+ - 考虑添加复合索引优化最新状态查询:`['personId', 'joinDate', 'workStatus']`
|
|
|
+ - 验证查询性能,确保响应时间<200ms
|
|
|
+
|
|
|
+5. **Schema和类型更新**:
|
|
|
+ - 更新`CompanyPersonListQuerySchema`,明确状态筛选选项和映射关系
|
|
|
+ - 更新`CompanyPersonListSchema`和`CompanyPersonDetailSchema`,使用一致的枚举类型
|
|
|
+ - 生成准确的TypeScript类型定义,确保前端类型安全
|
|
|
+
|
|
|
+6. **前端状态显示统一**:
|
|
|
+ - 更新人才管理UI包中的状态显示逻辑,使用新的状态值
|
|
|
+ - 确保人才列表页、人才详情页的状态标签显示一致
|
|
|
+ - 更新状态筛选组件的选项说明
|
|
|
+
|
|
|
+7. **集成测试全面覆盖**:
|
|
|
+ - 在`person-extension.integration.test.ts`中新增测试用例,覆盖所有状态场景
|
|
|
+ - 测试状态筛选的精确性:"待入职"和"离职"筛选应返回不同结果
|
|
|
+ - 测试边界条件:无订单关联的人员状态(显示"未就业"或空值)
|
|
|
+ - 测试性能:大数据量下的状态查询性能
|
|
|
+ - 确保测试覆盖率≥60%
|
|
|
+
|
|
|
+8. **兼容性保障**:
|
|
|
+ - 验证现有数据迁移:所有已有关联订单的人员应有正确的`work_status`值
|
|
|
+ - 对于无订单关联的人员,提供合理的默认状态(空值或'not_working')
|
|
|
+ - 确保企业统计中的在职状态分布统计仍能正常工作
|
|
|
+
|
|
|
+**验收标准:**
|
|
|
+- [ ] 人才列表API的"在职"筛选精确返回`work_status='working'`的人员
|
|
|
+- [ ] 人才列表API的"待入职"筛选精确返回`work_status='pre_working'`的人员
|
|
|
+- [ ] 人才列表API的"离职"筛选精确返回`work_status='resigned'`的人员
|
|
|
+- [ ] 人才详情页工作状态显示准确,基于最新的`order_person.work_status`
|
|
|
+- [ ] 状态映射完整:前端中文状态、Schema验证、数据库枚举值保持一致
|
|
|
+- [ ] 查询性能优化,添加必要的数据库索引,响应时间<200ms
|
|
|
+- [ ] 集成测试全面覆盖所有状态场景,测试覆盖率≥60%
|
|
|
+- [ ] API文档更新,包含完整的状态映射说明
|
|
|
+- [ ] 现有功能不受影响,企业统计等依赖工作状态的功能仍能正常工作
|
|
|
+
|
|
|
+**技术决策说明:**
|
|
|
+
|
|
|
+选择`order_person.work_status`而不是扩展`disabled_person.job_status`的原因:
|
|
|
+1. **业务逻辑更准确**:工作状态本质是人员在订单中的状态,不是人员的固有属性
|
|
|
+2. **状态历史可追溯**:`order_person`表记录了状态变化历史,`disabled_person.job_status`只是当前快照
|
|
|
+3. **已有完善设施**:`WorkStatus`枚举体系完整,有对应的中文映射和业务描述
|
|
|
+4. **减少数据冗余**:避免在`disabled_person`和`order_person`表中维护相同状态信息
|
|
|
+
|
|
|
+**回滚保障:**
|
|
|
+1. 保持`disabled_person.job_status`字段不变,作为备用状态源
|
|
|
+2. 实施过程中可分阶段验证,确保每一步都可回退
|
|
|
+3. 完整的测试覆盖,确保任何问题都能及时发现
|
|
|
+
|
|
|
## 史诗进度
|
|
|
|
|
|
-**当前状态**:史诗全部完成,10个核心故事已全部实现(012-01到012-05、012-08到012-12),为企业用户管理功能提供了完整的API支持。故事012-12已补充企业专用人才列表API的出生日期和薪资字段,解决人才列表页年龄和薪资显示问题。故事012-06(系统设置API)延期至后期优化阶段,故事012-07(API文档与测试完善)作为基础设施任务已由各故事分别覆盖。
|
|
|
+**当前状态**:史诗核心功能基本完成,11个核心故事中10个已实现(012-01到012-05、012-08到012-12),为企业用户管理功能提供了完整的API支持。故事012-12已补充企业专用人才列表API的出生日期和薪资字段,解决人才列表页年龄和薪资显示问题。新增故事012-13解决工作状态数据一致性问题,采用基于`order_person.work_status`的长期优化方案。故事012-06(系统设置API)延期至后期优化阶段,故事012-07(API文档与测试完善)作为基础设施任务已由各故事分别覆盖。
|
|
|
|
|
|
**故事完成状态**:
|
|
|
- [x] **故事012-01**:数据库schema扩展 - **已完成**(故事012.001已实现)
|
|
|
@@ -452,13 +546,14 @@
|
|
|
- [x] **故事012-10**:近期分配人才查询API - **已完成**(故事012.010已实现)
|
|
|
- [x] **故事012-11**:企业专用人才管理API - **已完成**(故事012.011已实现)
|
|
|
- [x] **故事012-12**:补充企业专用人才列表API的出生日期和薪资字段 - **已完成**
|
|
|
+- [ ] **故事012-13**:工作状态统一优化 - 基于order_person.work_status的长期方案 - **待实现**
|
|
|
- [ ] **故事012-06**:系统设置API - **P2 - 延期**(后期优化)
|
|
|
- [ ] **故事012-07**:API文档与测试完善 - **冗余**(基础设施已覆盖)
|
|
|
|
|
|
-**总体进度**:10/10 故事完成(100%)
|
|
|
-**MVP进度**:10/10 核心故事完成(100%,排除012-06延期和012-07冗余)
|
|
|
+**总体进度**:11/13 故事完成(85%)
|
|
|
+**MVP进度**:10/11 核心故事完成(91%,排除012-06延期和012-07冗余,包含012-13)
|
|
|
|
|
|
-**最近更新**:2025-12-20 - 故事012-12完成:企业专用人才列表API的出生日期和薪资字段已补充,人才列表页年龄和薪资显示问题已解决。2025-12-20 - 添加故事012-12(补充企业专用人才列表API的出生日期和薪资字段)以解决人才列表页年龄和薪资显示"未知岁"和"待定"的问题。2025-12-19 - 故事011.003企业专用API使用修复:人才详情页已改为使用enterpriseDisabilityClient企业专用API,确保企业用户数据安全隔离。2025-12-18 - 故事012.011完成,企业专用人才管理API已实现。2025-12-18 - 故事012.010完成,近期分配人才查询API已实现。2025-12-18 - 故事012.009完成,管理后台企业用户配置表单扩展已实现。2025-12-18 - 添加故事012-09(管理后台企业用户配置表单扩展)以解决管理后台用户表单缺失企业选择字段的问题。2025-12-17 - 故事012.005完成,视频管理API扩展已实现。史诗012核心功能全部完成。故事012.004完成,订单统计与数据统计API已实现。史诗012故事优先级调整:故事012-08标记为已完成;故事012-06调整为P2延期(系统设置API);故事012-07标记为冗余(API文档与测试完善);故事012-05重新设计(基于order_person_asset实体)。故事012.003完成,企业统计与人才扩展API已实现;故事012.008创建并完成,路由路径规范修复。
|
|
|
+**最近更新**:2025-12-20 - 添加故事012-13(工作状态统一优化):采用基于`order_person.work_status`的长期方案,解决前端中文状态、Schema验证、数据库类型不匹配问题,实现"在职"、"待入职"、"离职"状态的精确筛选和显示。2025-12-20 - 故事012-12完成:企业专用人才列表API的出生日期和薪资字段已补充,人才列表页年龄和薪资显示问题已解决。2025-12-20 - 添加故事012-12(补充企业专用人才列表API的出生日期和薪资字段)以解决人才列表页年龄和薪资显示"未知岁"和"待定"的问题。2025-12-19 - 故事011.003企业专用API使用修复:人才详情页已改为使用enterpriseDisabilityClient企业专用API,确保企业用户数据安全隔离。2025-12-18 - 故事012.011完成,企业专用人才管理API已实现。2025-12-18 - 故事012.010完成,近期分配人才查询API已实现。2025-12-18 - 故事012.009完成,管理后台企业用户配置表单扩展已实现。2025-12-18 - 添加故事012-09(管理后台企业用户配置表单扩展)以解决管理后台用户表单缺失企业选择字段的问题。2025-12-17 - 故事012.005完成,视频管理API扩展已实现。史诗012核心功能全部完成。故事012.004完成,订单统计与数据统计API已实现。史诗012故事优先级调整:故事012-08标记为已完成;故事012-06调整为P2延期(系统设置API);故事012-07标记为冗余(API文档与测试完善);故事012-05重新设计(基于order_person_asset实体)。故事012.003完成,企业统计与人才扩展API已实现;故事012.008创建并完成,路由路径规范修复。
|
|
|
|
|
|
---
|
|
|
|
|
|
@@ -505,7 +600,7 @@
|
|
|
|
|
|
## 完成定义
|
|
|
|
|
|
-- [x] 所有10个核心故事完成(排除012-06延期和012-07冗余),验收标准全部满足
|
|
|
+- [ ] 所有11个核心故事完成(排除012-06延期和012-07冗余),验收标准全部满足
|
|
|
- [x] 数据库schema扩展完成,不影响现有数据(故事012-01已实现)
|
|
|
- [x] 所有补充API功能完整,符合用人方小程序需求
|
|
|
- [x] API与现有allin系统移植模块无缝集成
|
|
|
@@ -538,10 +633,12 @@
|
|
|
3. **故事012-04和012-05已完成**:订单统计与数据统计API、视频管理API扩展已全部实现
|
|
|
4. **故事012-09已完成**:管理后台企业用户配置表单扩展已实现
|
|
|
5. **故事012-10已完成**:近期分配人才查询API已实现
|
|
|
-6. **新增故事012-11**:企业专用人才管理API(待实现)
|
|
|
-7. **延期故事012-06**:系统设置API(P2优先级,后期优化)
|
|
|
-8. **基础设施故事012-07**:API文档与测试完善(冗余,基础设施已覆盖)
|
|
|
-9. **按模块分组**:同一模块的扩展建议由同一开发者完成,确保一致性
|
|
|
+6. **故事012-11已完成**:企业专用人才管理API已实现
|
|
|
+7. **故事012-12已完成**:补充企业专用人才列表API的出生日期和薪资字段已实现
|
|
|
+8. **新增故事012-13**:工作状态统一优化 - 基于order_person.work_status的长期方案(待实现)
|
|
|
+9. **延期故事012-06**:系统设置API(P2优先级,后期优化)
|
|
|
+10. **基础设施故事012-07**:API文档与测试完善(冗余,基础设施已覆盖)
|
|
|
+11. **按模块分组**:同一模块的扩展建议由同一开发者完成,确保一致性
|
|
|
|
|
|
---
|
|
|
|