## P1 数据库基础 - zqyy_app: 创建 auth/biz schema、FDW 连接 etl_feiqiu - etl_feiqiu: 创建 app schema RLS 视图、商品库存预警表 - 清理 assistant_abolish 残留数据 ## P2 ETL/DWS 扩展 - 新增 DWS 助教订单贡献度表 (dws.assistant_order_contribution) - 新增 assistant_order_contribution_task 任务及 RLS 视图 - member_consumption 增加充值字段、assistant_daily 增加处罚字段 - 更新 ODS/DWD/DWS 任务文档及业务规则文档 - 更新 consistency_checker、flow_runner、task_registry 等核心模块 ## P3 小程序鉴权系统 - 新增 xcx_auth 路由/schema(微信登录 + JWT) - 新增 wechat/role/matching/application 服务层 - zqyy_app 鉴权表迁移 + 角色权限种子数据 - auth/dependencies.py 支持小程序 JWT 鉴权 ## 文档与审计 - 新增 DOCUMENTATION-MAP 文档导航 - 新增 7 份 BD_Manual 数据库变更文档 - 更新 DDL 基线快照(etl_feiqiu 6 schema + zqyy_app auth) - 新增全栈集成审计记录、部署检查清单更新 - 新增 BACKLOG 路线图、FDW→Core 迁移计划 ## Kiro 工程化 - 新增 5 个 Spec(P1/P2/P3/全栈集成/核心业务) - 新增审计自动化脚本(agent_on_stop/build_audit_context/compliance_prescan) - 新增 6 个 Hook(合规检查/会话日志/提交审计等) - 新增 doc-map steering 文件 ## 运维与测试 - 新增 ops 脚本:迁移验证/API 健康检查/ETL 监控/集成报告 - 新增属性测试:test_dws_contribution / test_auth_system - 清理过期 export 报告文件 - 更新 .gitignore 排除规则
102 lines
4.1 KiB
Markdown
102 lines
4.1 KiB
Markdown
# P3:用户认证层 — miniapp-auth-system
|
||
|
||
> 优先级:P3(依赖 P1,可与 P2 并行)
|
||
> 预估工作量:中等
|
||
|
||
---
|
||
|
||
## 需求(Requirements)
|
||
|
||
### 用户故事
|
||
|
||
1. 作为球房工作人员,我需要通过微信登录小程序,首次登录时填写申请表单(球房ID、申请身份、手机号、编号、昵称)。
|
||
2. 作为租户管理员,我需要审核用户申请,将用户关联到对应的助教/员工,并分配身份权限。
|
||
3. 作为系统,我需要通过球房ID+手机号自动建议用户与助教/员工的对应关系(同时匹配 `dwd.dim_assistant` 助教表和 `dwd.dim_staff` + `dwd.dim_staff_ex` 员工信息表)。
|
||
4. 作为用户,我需要看到自己的申请状态(审核中/通过/拒绝)。
|
||
5. 作为用户,我可以同时属于多个店铺(连锁场景),权限按店铺独立。
|
||
|
||
### 验收标准
|
||
|
||
- AC1:微信 code2Session 登录正常,返回 JWT
|
||
- AC2:新用户首次登录后进入申请页面,提交后状态为 pending
|
||
- AC3:管理员审核通过后,用户状态变为 approved,可正常访问小程序
|
||
- AC4:球房ID 不存在时,申请仍可提交,管理端显示"未找到关联信息"
|
||
- AC7:用户申请信息比对时,系统同时在助教表(`dwd.dim_assistant`)和员工信息表(`dwd.dim_staff` / `dwd.dim_staff_ex`)中匹配,返回所有匹配结果供管理员选择
|
||
- AC5:权限中间件正确拦截无权请求(如助教不能看财务看板)
|
||
- AC6:一个用户可关联多个店铺,切换店铺后数据正确隔离
|
||
|
||
---
|
||
|
||
## 设计要点
|
||
|
||
### 表结构
|
||
|
||
```
|
||
auth.users
|
||
- id, wx_openid, wx_union_id, wx_avatar_url, nickname, phone
|
||
- status (pending/approved/rejected/disabled)
|
||
- created_at, updated_at
|
||
|
||
auth.user_applications
|
||
- id, user_id, site_code (球房ID文本), applied_role_text (自由文本)
|
||
- employee_number (选填), status, reviewer_id, review_note
|
||
- created_at, reviewed_at
|
||
|
||
auth.site_code_mapping
|
||
- id, site_code (2字母+3数字), site_id (ETL bigint), site_name
|
||
- tenant_id, created_at
|
||
|
||
auth.user_site_roles
|
||
- id, user_id, site_id, role_id
|
||
- created_at
|
||
|
||
auth.user_assistant_binding
|
||
- id, user_id, site_id, assistant_id (ETL dim_assistant)
|
||
- staff_id (ETL dim_staff,可选,员工绑定时填写)
|
||
- binding_type (assistant/staff/manager)
|
||
- created_at
|
||
```
|
||
|
||
### 人员匹配逻辑(用户申请 → 信息比对)
|
||
|
||
用户提交申请时填写球房ID + 手机号(或编号),系统自动在以下两张表中匹配:
|
||
|
||
1. 助教表 `dwd.dim_assistant`(通过 FDW `fdw_etl.v_assistant`):按 `site_id` + `mobile` 或 `alias_name` 匹配
|
||
2. 员工信息表 `dwd.dim_staff` + `dwd.dim_staff_ex`(通过 FDW):按 `site_id` + `mobile` 或 `staff_name` / `alias_name` / `job_num` 匹配
|
||
|
||
匹配结果合并后返回给管理端,管理员从候选列表中选择正确的关联对象。若两张表均无匹配,显示"未找到关联信息",管理员可手动填写。
|
||
|
||
> 员工信息表数据链路:上游 API → `ods.staff_info_master` → `dwd.dim_staff`(基础维度,SCD2)+ `dwd.dim_staff_ex`(扩展维度,SCD2)
|
||
|
||
### 权限列表(固定)
|
||
|
||
| 权限 code | 说明 |
|
||
|-----------|------|
|
||
| `view_tasks` | 任务板块可见 |
|
||
| `view_board` | 看板板块可见 |
|
||
| `view_board_finance` | 财务板块可见 |
|
||
| `view_board_customer` | 客户板块可见 |
|
||
| `view_board_coach` | 助教板块可见 |
|
||
|
||
### 租户层级
|
||
|
||
```
|
||
租户 (tenant)
|
||
└── 店铺 (site) ← site_code 映射
|
||
└── 用户 (user) ← 可属于多个 site
|
||
└── 角色 (role) ← 按 site 独立分配
|
||
```
|
||
|
||
---
|
||
|
||
## 任务清单
|
||
|
||
- [ ] T1:创建 `auth` Schema 下全部表(users, user_applications, site_code_mapping, user_site_roles, user_assistant_binding)
|
||
- [ ] T2:迁移现有 RBAC 表到 `auth` Schema(或保留 public 但建立关联)
|
||
- [ ] T3:实现微信 code2Session 登录 API
|
||
- [ ] T4:实现用户申请提交 API
|
||
- [ ] T5:实现 JWT 签发与刷新
|
||
- [ ] T6:实现权限中间件(基于 user_site_roles)
|
||
- [ ] T7:实现用户状态查询 API
|
||
- [ ] T8:种子数据:预置权限列表和默认角色
|