Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
4.6 KiB
4.6 KiB
[模块名称] - 数据库设计
Schema:
xxx_schema
表数量: X个
依赖: platform_schema.users(如有)
最后更新: YYYY-MM-DD
📋 Schema说明
Schema创建:
CREATE SCHEMA IF NOT EXISTS xxx_schema;
职责范围:
- 功能1相关数据
- 功能2相关数据
- ...
依赖关系:
- 依赖
platform_schema.users(用户信息) - 依赖
platform_schema.xxx(如有)
📊 ER图(可选)
┌─────────────────┐
│ users (外部) │
└────────┬────────┘
│ 1:N
▼
┌─────────────────┐
│ 主表 │
└────────┬────────┘
│ 1:N
▼
┌─────────────────┐
│ 子表 │
└─────────────────┘
📋 表结构设计
1. xxx_table_name(表描述)
用途: 简要说明表的用途
字段说明:
CREATE TABLE xxx_schema.xxx_table_name (
-- 主键
id SERIAL PRIMARY KEY,
-- 外键
user_id INTEGER REFERENCES platform_schema.users(id) ON DELETE CASCADE,
-- 业务字段
field_name VARCHAR(200) NOT NULL,
description TEXT,
status VARCHAR(20) DEFAULT 'active',
-- 时间戳(必须)
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW(),
-- 索引
INDEX idx_xxx_user_id (user_id),
INDEX idx_xxx_status (status)
);
字段详解:
| 字段名 | 类型 | 约束 | 说明 |
|---|---|---|---|
| id | SERIAL | PK | 主键 |
| user_id | INTEGER | FK, NOT NULL | 用户ID |
| field_name | VARCHAR(200) | NOT NULL | 字段说明 |
| description | TEXT | - | 详细描述 |
| status | VARCHAR(20) | DEFAULT 'active' | 状态:active/inactive/deleted |
| created_at | TIMESTAMP | NOT NULL | 创建时间 |
| updated_at | TIMESTAMP | NOT NULL | 更新时间 |
业务规则:
- 每个用户最多创建X个记录
- status字段的有效值:active, inactive, deleted
- 软删除:不物理删除,只修改status为deleted
2. xxx_table_name_2(第二个表)
(重复上面的结构)
🔍 索引设计
单列索引
-- 用户ID索引(外键必须加索引)
CREATE INDEX idx_xxx_user_id ON xxx_schema.xxx_table_name(user_id);
-- 状态索引(常用筛选字段)
CREATE INDEX idx_xxx_status ON xxx_schema.xxx_table_name(status);
-- 创建时间索引(常用排序字段)
CREATE INDEX idx_xxx_created_at ON xxx_schema.xxx_table_name(created_at DESC);
复合索引
-- 用户+状态组合查询
CREATE INDEX idx_xxx_user_status ON xxx_schema.xxx_table_name(user_id, status);
🔗 外键约束
依赖关系
-- 依赖用户表
ALTER TABLE xxx_schema.xxx_table_name
ADD CONSTRAINT fk_xxx_users
FOREIGN KEY (user_id) REFERENCES platform_schema.users(id)
ON DELETE CASCADE; -- 用户删除时级联删除
-- 模块内关联
ALTER TABLE xxx_schema.child_table
ADD CONSTRAINT fk_child_parent
FOREIGN KEY (parent_id) REFERENCES xxx_schema.parent_table(id)
ON DELETE CASCADE;
外键策略
- ✅ ON DELETE CASCADE:用户删除时,自动删除所有关联数据
- ⚠️ 跨Schema外键:只能引用 platform_schema,不能引用其他业务模块
📈 数据迁移(可选)
初始化数据
-- 如果需要初始化数据
INSERT INTO xxx_schema.xxx_table_name (field_name, status) VALUES
('示例1', 'active'),
('示例2', 'active');
迁移脚本
-- 如果需要从旧表迁移数据
-- migrations/xxx_migration.sql
📊 数据量预估
| 表名 | 预估记录数 | 增长速度 |
|---|---|---|
| xxx_table_name | 10万/年 | 中等 |
| xxx_table_name_2 | 100万/年 | 高 |
⚠️ 注意事项
性能优化:
- 大表必须添加分页查询
- 热点字段必须添加索引
- 定期清理软删除的数据
安全性:
- 敏感字段需要加密存储
- 所有外键必须有 ON DELETE 策略
- 避免N+1查询问题
维护性:
- 表结构变更需要写迁移脚本
- 重要变更需要备份数据
🔗 相关文档
规范:
API设计:
最后更新: YYYY-MM-DD
维护人: 技术架构师