Files

HaHafeng 66255368b7 feat(admin): Add user management and upgrade to module permission system

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

2026-01-16 13:42:10 +08:00

2.9 KiB

Raw Blame History

REDCap 原生录入与 AI Workbench 操作边界划分

针对您的关键问题：“CRC 到底在哪里录入数据？”，我们采取**“双轨并行，场景区分”**的原则。

1. 核心策略：尊重“数据真理源”

原则：为了确保 GxP 合规性和维护用户的既有习惯，REDCap 始终是主要的数据录入入口。
逻辑：我们不应该重新发明一个录入界面，而是要在录入时通过 AI 进行“实时监护”。

2. 详细场景划分

场景	操作位置	AI 的角色	理由
常规数据录入	REDCap 界面	实时监护	保持 CRC 习惯，降低迁移成本。AI 通过 Webhook 实时质控。
大批量数据导入	AI Workbench	智能搬运	外部 Excel 或多张化验单。AI 清洗后，CRC 确认一次，一键注入。
图像/PDF 提取录入	AI Workbench	OCR 提取	REDCap 原生不支持复杂的 OCR 解析。在 Workbench 完成提取比对最顺手。
质疑(Query)处理	AI Workbench	冲突展示	在 Workbench 可以同屏看“证据原文”和“建议值”，体验远好于 REDCap。
项目初始化配置	AI Workbench	架构定义	复杂的 RAG 知识库上传、映射表配置，属于 AI 平台的特有逻辑。

3. 典型流程对比

流程 A：常规录入 (CRC 在 REDCap 操作)

CRC 登录 REDCap，打开患者表单。
输入血红蛋白值：8.0（单位录错）。
点击保存 -> REDCap 写入 MySQL -> 触发 Webhook。
我们的后端感知后，QC Agent 发现逻辑错误。
反馈：
- 低延时提醒：通过 EM 插件在 REDCap 页面上方显示：“AI 提示：该值偏离历史均值，请确认单位”。
- 异步质疑：在我们的 Workbench 生成一条 Pending Action。

流程 B：AI 增强录入 (CRC 在 Workbench 操作)

CRC 收到一张化验单照片。
CRC 登录我们的 Workbench，上传照片。
AI 提取出 10 个指标。
预览比对：界面左侧是照片，右侧是提取的表格，高亮显示不确定的值。
一键注入：CRC 确认无误，点击“同步”。系统自动调用 REDCap API 将这 10 个值一次性填满 REDCap 表单。

4. 结论与思路总结

REDCap 登录：用于**“手动、少量、常规”**的临床记录。
AI Workbench 登录：用于**“大批量、文档提取、质控确认、方案解析”**的高级任务。

这种设计的优势在于：不强制改变用户习惯，但用 AI 让任务变得更轻松。 我们不需要做一个完整的 EDC，我们要做的是 EDC 的“智能加速器”。

您认可这个“双轨制”吗？ 特别是关于“大批量和文档提取才去 Workbench”的设定。

2.9 KiB Raw Blame History Unescape Escape