foodie-server/specs/022-merchant-store-subaccounts/quickstart.md

快速验证：商家门店分管账号

前置条件

1. 使用 JDK 21：C:\Users\qmj\.jdks\graalvm-jdk-21.0.7。
2. 数据库迁移只从 updatesql/sql.md 人工执行；Codex 不直接执行迁移。
3. 准备一个类型 1 主商家、三家归属门店和两个可接收推送的测试设备账号。

自动化验证

$env:JAVA_HOME='C:\Users\qmj\.jdks\graalvm-jdk-21.0.7'
$env:Path="$env:JAVA_HOME\bin;$env:Path"
mvn -pl ruoyi-admin -am -Dtest=MerchantStoreAccessServiceTest,MerchantSubaccountControllerTest,MerchantSubaccountAdminControllerTest,MerchantNotificationRouterTest,InfoUserControllerTest,PosStoreControllerTest,PosFoodControllerAccessTest,PosOrderShOprateControllerTest -Dsurefire.failIfNoSpecifiedTests=false test
mvn -pl ruoyi-admin -am -DskipTests package

商家端：

Set-Location E:\QtwCode\foodie\foodie-store
npm run build

平台端：

Set-Location E:\QtwCode\foodie\foodie-admin-vue
npm run build:prod

手工验收路径

1. 主账号创建分管账号甲并授权店铺 A、B；甲登录后只看到 A、B。
2. 甲通过手工构造请求访问同主账号店铺 C 的订单、商品和退款，后端全部拒绝。
3. 甲调用新增或删除店铺、支付配置和财务接口，后端拒绝。
4. 主账号取消甲对 A 的授权；甲不重新登录，下一次访问 A 立即失败。
5. A 同时配置甲、乙且两者 App 会话有效；触发 A 通知，甲乙各有一条消息，主账号没有重复消息。
6. 甲乙均无有效 App 会话；再次触发 A 通知，主账号获得兜底消息。
7. 平台商家列表、导出和统计只出现主账号；从主商家行进入分管账号视图可看到甲乙。
8. 平台停用甲后，甲的现有会话失效；主账号尝试启用甲也不能覆盖平台状态。
9. 平台恢复甲但主账号仍停用甲，甲仍不能登录；主账号再次启用后才恢复。
10. 平台停用主商家，甲乙全部不能登录、操作或接收通知。

安全检查

• 请求日志、异常日志和测试输出不包含密码、RSA 密文、完整 Token 或 CID。
• 所有越权失败在业务写入之前发生，不产生部分授权、订单状态或退款状态变更。
• git diff --check 无空白错误；两个 Vue 仓库的原 CRLF 不被批量改写。

2026-08-28 自动化验证结果

• JDK 21 定向测试：38 个测试通过，0 失败、0 错误、0 跳过。
• 商品下架过滤兼容测试：1 个测试通过；旧测试夹具已按新的商家会话鉴权链补齐依赖。
• 后端完整回归：293 个测试通过，0 失败、0 错误、0 跳过。
• 后端打包：mvn -pl ruoyi-admin -am -DskipTests package 成功。
• 商家端：npm run build 成功；仅有既有 Browserslist、Node 弃用及包体积提示。
• 平台端：npm run build:prod 成功；存在既有 promotion/index.vue~、pointcontrol/pointTier.vue~ 解析警告及包体积提示，未阻断构建。
• 数据库迁移未执行，updatesql/sql.md 由开发者统一手动执行。
• 尚未执行依赖真实数据库、Redis、App 会话、CID 和 iOS 云函数的手工验收；上方 10 条手工路径保持为上线前验收清单。

2026-11-04 商家旧业务入口回归

1. 主账号拥有门店 A/B/C，分管只授权 A/B。用分管 token 调用营业时间、优惠券、促销、评论：A/B 可操作，C 的列表/详情/增删改应拒绝。
2. 修改 C 的记录时在请求体改成 A，仍应拒绝；批量删除 [A记录,C记录] 应全部不执行。
3. 清空分管授权：首页及评论/账单应为零或空，不能退化成主账号全部数据。恢复授权后立即生效；停用分管或主账号后立即拒绝。
4. 旧日/周/月账单不传 mdId 时只汇总 A/B，指定 A 只统计 A；isCancel 和 cancelCount 也不包含 C。确认普通商家及骑手账单沿用原行为。
5. 首页传入其他商家 id 不得改变统计对象；分管不返回主账号 ketixian 余额。现有客户端需在新增受保护入口发送 token。
6. 匿名或商家 token 调用全量维护接口不可执行；平台只有具备对应权限才可执行。无需为验收实际触发全量维护。

上述真实账号与客户端联调由发布后执行，单元测试和本地构建结果见 tasks.md。

2026-11-06 前端接入调整：用户名与联系手机号分开

• 新增表单将“姓名”入口改为“用户名”，传userName；手机号phone继续必填，password仍RSA加密，storeIds保持。
• POST /merchant/subaccounts 示例：{"userName":"store_staff","phone":"0912345678","password":"RSA密文","storeIds":[101]}。name可不传，不将phone复制到userName。
• 列表显示接口新增的userName作为登录账号；phone仅显示为联系手机号。
• PUT /merchant/subaccounts/{id} 传userName和storeIds可修改存量登录名，原密码不变；改名后重新登录。
• 登录继续调用POST /infouser/user/shanglodeing，传userName和RSA密码。接口路径及权限规则不变。
• 后端不自动把存量姓名当用户名，也不批量改历史账号；手机号形式的旧用户名在主账号改名前仍可使用。
• 本轮未修改前端代码，前端需按上述字段独立接入。