补充用户默认酒店唯一约束

This commit is contained in:
andy
2026-07-10 16:19:43 +08:00
parent 8484b44e87
commit 4745e20b9a
5 changed files with 237 additions and 6 deletions

View File

@@ -79,7 +79,7 @@
- `/api/auth/me``/api/auth/logout` 需要 `Authorization: Bearer <access_token>`
- 初始管理员 bootstrap 只以“启用状态超级管理员”为阻断条件;如果测试库或生产库只剩禁用超级管理员,应通过环境变量恢复一个可登录超级管理员后再排查账号运营问题。
- 内置角色权限矩阵在启动时按代码同步,矩阵移除的旧权限关系会被清理;管理后台上线前不要手工给内置角色追加临时权限作为长期方案。
- 普通用户默认酒店当前由后端写入逻辑保持;如果后续提交单默认唯一约束 migration应在对应上线窗口补充历史数据清理说明
- 普通用户默认酒店由后端写入逻辑和数据库唯一索引共同保持单默认V10 migration 会在建约束前把历史重复默认清理为每个用户保留 id 最大的一条
- 单酒店阶段系统酒店由 `platform_hotel` 唯一 `ACTIVE` 酒店决定V12 migration 会通过唯一索引阻止第二家 `ACTIVE` 酒店。上线前如果已有多家 `ACTIVE` 酒店,必须先调整数据,否则迁移或运行时解析会失败。
- 管理后台还未上线时,不要把数据库手工改用户、角色、权限作为常规运营手段。
@@ -200,10 +200,12 @@
当前 M003 登录权限相关 migration
- `server/src/main/resources/db/migration/V9__create_identity_access_hotel_menu.sql`
- `server/src/main/resources/db/migration/V10__enforce_single_default_user_hotel.sql`
上线前确认:
- 目标数据库为空库或 Flyway history 与当前代码一致。
- 如果某个环境已经在缺少 V10 的临时提交上执行过 V11 / V12不能直接用默认 Flyway 策略补跑 V10应先重建测试库或按运维窗口明确 out-of-order / repair 策略。
- MySQL 版本满足项目要求,默认使用 MySQL 8.0+。
- migration 在 UAT 或测试库已经跑过。
- 表和字段中文注释能正常创建。