fix(api): 修复专区白名单和商品移除假成功问题
- 调整 .env.development 中 VITE_API_URL 配置为正式接口地址 - 修复 ShopGoods.sectionIds 字段更新时 null 被忽略导致移除专区商品假成功问题 - 通过 UpdateWrapper 显式设置 section_ids 字段避免 MyBatis-Plus 全局更新策略影响 - 补充后端下单接口白名单强校验,防止绕过前端受限专区限制 - 澄清买家用户体系为 sys_user,确认白名单弹窗使用 pageUsers 数据源正确 - 删除白名单弹窗 isStaff 限制,白名单覆盖所有 sys_user 用户 - 记录专区白名单功能设计与实现细节,明确前后端联动机制 - 提示“专区管理”菜单入口需后端菜单表动态下发,确保后台导航可见
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
# 2026-08-17 工作日志
|
||||
|
||||
## 专区商品「移除」假成功 bug 修复
|
||||
- 现象:guilixu.websoft.top/special/zone 移除专区商品提示成功,刷新(重查库)后商品仍在。
|
||||
- 根因:`ShopHomeSectionController.removeGoods` 用 `listByIds` + `updateBatchById` 改 `shop_goods.section_ids`;单专区商品移除后 section_ids 变 null,但 `ShopGoods.sectionIds` 无更新策略注解,MP 全局默认 `NOT_NULL` 会忽略 null 值 → 不生成 `SET section_ids=NULL` → 库字段保持原值(假成功)。多专区商品(变非 null)正常,故仅单专区场景坏。
|
||||
- 修复:`addGoods`/`removeGoods` 改用 `UpdateWrapper.set("section_ids", newVal).eq("goods_id", id)` 显式更新(newVal 可为 null),绕过字段策略。文件:guilixu-java `ShopHomeSectionController.java`。
|
||||
- 部署:需重新编译部署 guilixu-java(线上 shop-api)后端生效;前端无需改动。添加用同样模式统一修复。
|
||||
- 验证:部署后用单专区商品移除测试,刷新不应再出现。
|
||||
- 注:本机环境无 maven,未本地编译;改动为标准 MP 用法(IService.update(Wrapper) / UpdateWrapper.set 允许 null)。
|
||||
|
||||
## 专区白名单功能诊断(功能当前不可用)
|
||||
- 设计意图:专区设为"受限专区"(restricted=1) 后,该专区商品仅白名单用户可用余额购买;小程序结算页 checkout.tsx 已调 `check-permission` 前端拦截。
|
||||
- 致命错配:后台白名单弹窗 `UserSelectModal.vue` 用 `pageUsers`(@/api/system/user → sys_user 后台员工) 选用户;后端 `ShopHomeSectionController.checkPermission` 用 `getLoginUser().getUserId()`(= shop_user 小程序买家 userId)。两套用户体系 id 不一致 → 白名单里加的任何人(后台员工)对真实买家都匹配不上 → 受限专区对买家永远拦截/强制余额,白名单形同虚设。
|
||||
- 次要隐患:后端创建订单接口未做白名单强校验,仅前端拦截,可被绕过。
|
||||
- 修复方向:① 白名单弹窗数据源从 `pageUsers`(sys_user) 改为 `pageShopUser`(@/api/shop/shopUser → shop_user 买家),使存的 user_id 与校验 userId 同体系;② 后端下单接口加白名单强校验防绕过。后台已有 pageShopUser 可用。
|
||||
|
||||
## 专区白名单:用户体系澄清 + 后端强校验(用户 2026-08-17 01:50 指令)
|
||||
- 用户澄清:本项目的买家(小程序用户)就是 `sys_user` 体系,`pageShopUser` 实际不用/返回空。故白名单弹窗用 `pageUsers`(sys_user) 是**正确**的,之前"用户体系错配"判断为误判。
|
||||
- 白名单弹窗 `UserSelectModal.vue` 现状(8-16 已改):`pageUsers({ keywords, ... })`,**不传 isStaff**(搜索覆盖全部 sys_user)。源码无需再改。已 grep 确认 zone 目录下无残留 isStaff/pageShopUser。
|
||||
- 后端补「受限专区白名单强校验」:`OrderBusinessService.java` 新增
|
||||
- import:`ShopHomeSectionService`、`ShopHomeSectionUserService`、`QueryWrapper`、`java.util.Set/LinkedHashSet`;
|
||||
- `@Resource` 注入 `homeSectionService`、`homeSectionUserService`;
|
||||
- `createOrder` 在 `validateDeliveryRegionIfNeeded` 之后调用 `validateSectionPermissionIfNeeded(request, shopOrder, loginUser)`;
|
||||
- 新方法逻辑:遍历 `request.goodsItems` → 取 `ShopGoods.sectionIds` → 找 restricted=1 的专区 → 校验 `loginUser.getUserId()` 是否在 `shop_home_section_user`(count>0),否则抛 `BusinessException("该商品属于受限专区,仅限指定白名单用户购买")`。
|
||||
- 作用:前端 `check-permission` 的后端兜底,防止直接调 `/shop/shop-order` 下单绕过白名单。
|
||||
- 部署:需重新编译部署 guilixu-java(shop-api)。前端无需改动。
|
||||
- 注:本机无 maven,未本地编译;改动为标准 MP 用法(IService.count(QueryWrapper) / getById)。
|
||||
- 待确认:用户 "2.帮我补" 指令只写了前半句,已按上文补后端强校验;若其本意是"补菜单记录"(专区管理入口,动态路由待插入),需另出 INSERT SQL(菜单表结构待确认)。
|
||||
Reference in New Issue
Block a user