核心变更: - 数据权限过滤从基于账号层级改为基于用户类型的多策略过滤 - 移除 AccountStore 中的 GetSubordinateIDs 等旧方法 - 重构认证中间件,支持 enterprise_id 和 customer_id - 更新 GORM Callback,根据用户类型自动选择过滤策略(代理/企业/个人客户) - 更新所有集成测试以适配新的 API 签名 - 添加功能总结文档和 OpenSpec 归档 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
3.9 KiB
3.9 KiB
Feature Specification: 旧系统清理和代码整理
Feature Branch: remove-legacy-rbac-cleanup
Created: 2026-01-09
Status: Draft
REMOVED Requirements
Requirement: 账号层级递归查询
系统不再支持基于 tb_account.parent_id 的账号层级递归查询,该功能已被店铺层级递归查询取代。
Scenario: 移除账号下级查询
- WHEN 清理完成后
- THEN
GetSubordinateIDs(accountID)方法不再存在
Scenario: 移除账号下级缓存
- WHEN 清理完成后
- THEN Redis 中不再使用
account:subordinates:*格式的 key
Reason: 账号层级概念已被店铺层级取代,数据权限过滤改为基于店铺。
Migration: 使用 shop_store.GetSubordinateShopIDs(shopID) 替代。
ADDED Requirements
Requirement: 基于店铺的数据权限过滤
系统 SHALL 在 Store 层的 List 方法中自动应用基于店铺的数据权限过滤:代理账号只能查询自己店铺及下级店铺的数据。
Scenario: 代理账号查询数据
- WHEN 代理账号(user_type=3,shop_id=X)查询业务数据列表
- THEN 系统自动添加 WHERE 条件:
shop_id IN (X, 及X的所有下级店铺ID)
Scenario: 企业账号查询数据
- WHEN 企业账号(user_type=4,enterprise_id=Y)查询业务数据列表
- THEN 系统自动添加 WHERE 条件:
enterprise_id = Y
Scenario: 平台用户跳过过滤
- WHEN 平台用户(user_type=1 或 2)查询业务数据列表
- THEN 系统不添加任何过滤条件,返回所有数据
Scenario: C端用户跳过过滤
- WHEN context 中包含 SkipOwnerFilter 标记(C端用户)
- THEN 系统跳过 shop_id/enterprise_id 过滤,由业务代码自行处理
Requirement: 认证中间件适配新用户体系
系统 SHALL 更新认证中间件以支持新的用户类型和组织关联,在 context 中正确设置用户信息。
Scenario: B端用户认证
- WHEN B端 Token 验证成功
- THEN 中间件在 context 中设置:user_id、user_type、shop_id(代理)或 enterprise_id(企业)
Scenario: C端用户认证
- WHEN C端 Token 验证成功
- THEN 中间件在 context 中设置:customer_id、SkipOwnerFilter=true
Scenario: Token类型不匹配
- WHEN C端 Token 访问 /api/v1/ 或 B端 Token 访问 /api/c/
- THEN 中间件返回 401 Unauthorized
Requirement: 权限校验适配新体系
系统 SHALL 更新权限校验中间件以支持角色类型匹配和权限端口校验。
Scenario: 权限端口校验
- WHEN 用户访问权限保护的接口
- THEN 中间件检查用户权限的 platform 字段是否与请求来源匹配
Scenario: 超级管理员跳过权限
- WHEN 超级管理员(user_type=1)访问任意接口
- THEN 中间件跳过权限校验,允许访问
Requirement: 访问日志记录新字段
系统 SHALL 在访问日志中记录新的用户体系字段,便于问题排查和数据分析。
Scenario: B端用户访问日志
- WHEN B端用户发起 HTTP 请求
- THEN 访问日志包含字段:user_id、user_type、shop_id(或 enterprise_id)
Scenario: C端用户访问日志
- WHEN C端用户发起 HTTP 请求
- THEN 访问日志包含字段:customer_id、标记为 C 端用户
Key Entities
无新增实体,本提案主要是代码清理和逻辑调整。
Success Criteria
- SC-001: 所有基于
account.parent_id的代码已移除或更新 - SC-002: Redis 中不再存在
account:subordinates:*格式的 key - SC-003: 数据权限过滤正确基于店铺层级工作
- SC-004: 认证中间件正确设置新的 context 字段
- SC-005: 权限校验正确执行端口匹配
- SC-006: 所有现有测试通过,无回归问题
- SC-007: 应用启动无错误,核心 API 正常工作