direv/admin_new
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
133 Commits 4 Branches 0 Tags 3.8 MiB
0519de9428
Commit Graph

133 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Sisyphus
ff4c9bc140 fix(F006-W18.9): dark 主题 全局滚动条深色适配 (避免浅白滚动条割裂) 
用户反馈: 暗主题下侧边栏原生滚动条是浅白色, 在深色背景上刺眼割裂

根因: 浏览器原生 ::-webkit-scrollbar 走系统默认色 (亮色),
项目没覆盖, dark 下没适配

修法 (src/styles/global-popper.scss 末尾新增):
- 默认 (亮主题): thumb var(--border) 浅灰
- hover: var(--ink-4) 深灰
- [data-theme=dark]: thumb var(--border) = #475569 深色
- hover: var(--ink-3) = #CBD5E1
- Firefox 兼容: html { scrollbar-color: var(--border) transparent; }

Playwright 实测 (.rr-sidebar 滚动条 thumb):
- 改前: 系统默认 #C0C0C0 浅灰 (刺眼)
- 改后: rgb(71,85,105) = #475569 深色 ✅ (dark 协调)
 2026-07-09 17:38:14 +08:00
Sisyphus
3fc8326aeb fix(F006-W18.8): dark 主题 按钮 + 文字 颜色修复 (CSS 变量级联全部硬编码) 
用户反馈: 暗主题下默认 el-button (如导出/重置) 文字几乎看不见

根因 (同类 W18 修复):
- tokens.scss :root 块定义 --el-text-color-regular: var(--ink-2) / --el-border-color: var(--border)
- CSS 变量解析时, [data-theme=dark] 块的 --ink-2 重写还未生效
- 导致 dark 下 --el-text-color-regular 仍是 tech-blue 默认 #334155 (深色字 on 深色背景 = 不可见)
- 按钮 border --el-border-color 仍是 #E2E8F0 (浅色边 on 暗背景 = 刺眼)

修法 (themes.scss [data-theme=dark] 块硬覆盖):
- --el-text-color-primary/regular/secondary/placeholder/disabled → #F8FAFC/#E2E8F0/#CBD5E1/#94A3B8
- --el-border-color/light/lighter/extra-light → #475569 (border)
- --el-border-color-dark/darker → #64748B (border-strong)
- --el-fill-color/light → #0F172A (bg-soft)
- --el-fill-color-lighter/extra-light/dark/darker → #283449 (surface-2)
- --el-fill-color-blank/bg-color/overlay → #1E293B (surface)
- --el-bg-color-page → #0F172A (bg-soft)
- --el-tooltip-bg-color → #1E293B
- --el-disabled-* → 配套浅色

Playwright dark 主题实测 (商品管理页 导出/重置 按钮):
- 改前: bg rgb(30,41,59) 但 color rgb(51,65,85) = #334155 (看不见)
- 改后: color rgb(226,232,240) = #E2E8F0 (清晰), border rgb(71,85,105) = #475569 (协调)
- --el-text-color-regular 改前 #334155 → 改后 #E2E8F0 ✅
- 截图确认: 导出/重置/新增商品/查询 全部按钮在 dark 下清晰可读
 2026-07-09 17:29:04 +08:00
Sisyphus
ee52bed129 fix(F006-W18): 暗主题全面适配 (EP token 补齐 + v1 token 清理 + 业务硬编码色修) 
用户反馈: dark 主题下大量页面卡片/表头是白底, 文字看不清, 视觉割裂

根因 (W5.x v2 token 迁移遗漏):
- v1 token (--rr-page-bg / --rr-bg-card / --rr-table-header-bg / --rr-row-hover / --rr-border-color / --rr-text-secondary) 在 themes.scss 完全没定义
- v2 用 --bg-soft / --surface / --surface-2 / --border / --ink-2 / --ink-3, 但大量组件没改 fallback, 永远走 hex fallback (#F1F5F9 / #FFFFFF)
- EP el-table 内部用 getCssVar(color, white) = --el-color-white, 未在 tokens.scss 重定向, dark 下仍是 #FFFFFF
- CSS 变量级联问题: :root 块 var(--surface) 解析时, dark 块的 --surface 重写还没生效

修法 (3 类共 11 文件):
1. EP token 补齐 (themes.scss dark 块 + tokens.scss :root 块):
   - --el-color-white / --el-color-black: #1E293B / #F8FAFC
   - --el-fill-color-blank / --el-fill-color-light: surface / bg-soft
   - --el-table-tr-bg-color / --el-table-bg-color: surface
   - --el-table-expanded-cell-bg-color: surface
   - --el-table-header-bg-color: surface-2 (表头略亮区分)
   - --el-table-row-hover-bg-color: bg-soft

2. v1 token 清理 (4 组件):
   - AppLayout.vue: 13 处 --rr-page-bg → --bg-soft
   - DataTable.vue: --rr-table-header-bg/--rr-text-secondary/--rr-row-hover/--rr-bg-card/--rr-border-color → v2 token
   - SearchBar.vue / ListTabs.vue: 同上

3. 业务页硬编码色 (5 业务页):
   - OpenAppListView.vue: 4 状态 badge + 表格头 #F8FAFC → var(--*-soft)
   - ApplyApiKeyDialog.vue: header #F8FAFC → var(--surface-2)
   - InquiryListView.vue / LogOperationView.vue / LogErrorView.vue: 4 类 badge → var(--amber/brand/green/red-soft)

Playwright 1920 视口 dark 主题实测 (5 个典型页):
- Dashboard: 侧栏 rgb(30,41,59), 主区 rgb(15,23,42), 表格 rgb(30,41,59) ✅
- 用户列表 / 应用列表 / 订单列表 / 询价列表: 全部统一深色 ✅
- 之前: elTableBg rgb(255,255,255) 纯白 → 现在: rgb(30,41,59) 暗 surface
- 文字、badge、按钮、分页器、搜索条全部 dark 适配

不动调色板 (按用户要求 严重问题优先): --border/--ink-2 等保持原值
 2026-07-09 17:22:12 +08:00
Sisyphus
bae319fe98 feat(F006-W17.6): 服务商品页 PageHeader 加 SKU 总数 (type=2) 2026-07-09 17:11:43 +08:00
Sisyphus
8116e04291 feat(F006-W17.6): PageHeader 加 SKU 总数显示 (实物商品页 sub 改为 共 N 个商品, M 个SKU) 2026-07-09 16:44:17 +08:00
Sisyphus
c34035434a fix(F006-W17.8.3): openapi/app 隐藏权限范围列 + 操作列加宽到 220 
用户反馈: 隐藏权限范围列, 操作列加宽

列宽重新分配 (1920 视口, 8 列, 表格 1630px 撑满):
- 删除 权限范围列 (scopes, minWidth 160)
- 应用名称 minWidth 180 → 220 (吸收差额 60px)
- 操作列 width 160 → 220 (加宽 60px, 给重发二维码+⋯ 充足空间)
- 其他列保持不变

实测 (Playwright):
- 客户名 260 / 应用名称 380 / AppID 240 / 调用次数 100
- 状态 90 / 创建时间 170 / 最后调用 170 / 操作 220
- 总列宽 1630px, 右边距 29px (与参考页用户列表一致)

操作列按钮完整性:
- 行 0 (已撤销): [详情, 删除] ✅
- 行 1/2 (已激活): [详情, 重发二维码] + ⋯ ✅
 2026-07-09 16:20:11 +08:00
Sisyphus
d4441c051e fix(F006-W17.8.2): openapi/app 列宽优化 (AppID 缩到 240 + 操作列 160 + 加 2 业务列) 
用户反馈: AppID 列右侧留白太多, 操作列窄按钮显示不全

列宽重新调整 (Playwright 1920 视口实测):
- 客户名 minWidth 150 → 150 (内容 14 字符, 实际 215px)
- 应用名称 minWidth 180 → 180 (内容 19 字符, 实际 257px)
- AppID minWidth 200 → width 240 + showOverflowTooltip (硬性不被内容撑大)
- 新增 权限范围列 (scopes, minWidth 160) - 真实业务字段
- 新增 调用次数列 (totalCallCount, width 100) - 真实业务字段
- 状态 width 100 → 90
- 创建时间 width 170
- 最后调用 width 170 (新增列)
- 操作 width 200 → 160 + fixed right + align center

实测列宽 (1920 视口, 表格 1630px 撑满):
- 客户名 215 / 应用名称 257 / AppID 240 / 权限范围 228
- 调用次数 100 / 状态 90 / 创建时间 170 / 最后调用 170 / 操作 160
- 9 列共 1630px, 右边距 29px (项目标准)

操作列按钮完整性:
- 行 0 (已撤销): [详情, 删除] ✅
- 行 1/2 (已激活): [详情, 重发二维码] + ⋯ ✅

新加 2 个真实业务列 (权限范围/调用次数) 充实表格, 避免列过少
 2026-07-09 16:06:54 +08:00
Sisyphus
d4cda618b8 fix(F006-W17.8.1): 表格撑满容器 (1920 视口) 
用户反馈: 集成管理-应用列表 (openapi/app) 在 1920 视口下右侧大面积留空,
操作列按钮显示不全。参考用户列表 (图二) 已撑满做统一标准。

根因 (W17 早期遗留):
- .rr-openapi-app { max-width: 1400px } 锁死容器宽度
- 适合 1440 视口, 但 1920 视口暴露问题
- 用户列表用 .rr-page { max-width: 100% } 早已不受限

修法 (统一标准):
- openapi/app .rr-openapi-app { max-width: 1400px } → 100%
- DataTable 组件增强: 加 tableRef + lastColMinWidth 状态
  * mounted/resize/data 变化时测量: 容器宽 vs 列总宽
  * 差额自动加到最后一列 minWidth (统一标准: 视口撑满)
  * 即使其他页面 max-width 仍写 1400px, 也能通过 JS 撑满

W17.8 列宽调整 (W17.8 已 commit, 现 +W17.8.1):
- 应用名称 minWidth 180 → 220
- AppID minWidth 220 → 240
- 新增最后调用列 (lastUsedAt, width 170)
- 操作列 width 140 → 160 + align: center + fixed: right

Playwright 1920 视口实测:
- 用户列表 (参考): 1632px 表格 / 28px 右边距 ✅
- 应用列表 (修后): 1630px 表格 / 29px 右边距 ✅ (与参考页一致)

操作列按钮完整性:
- 行 0/2/3 (status=0/1): [详情, 重发二维码] + ⋯ ✅
- 行 1 (status=2): [详情, 删除] (无⋯, 符合规则) ✅
 2026-07-09 15:33:42 +08:00
Sisyphus
458adb15af fix(F006-W17.8): openapi/app 表格撑满 + 操作列按钮完整显示 
用户反馈: 应用列表表格不撑满 + 操作列按钮显示不全
对比参考页 (用户列表) 修复:

列宽调整 (参考 RoleListView/UserListView 列宽方案):
- 应用名称 minWidth 180 → 220 (让列总宽超过容器, el-table 自然撑满)
- AppID minWidth 220 → 240 (增加密度)
- 新增最后调用列 (lastUsedAt, width 170) - 真实业务字段, 表格更充实
- 操作列 width 140 → 160 + align: center + fixed: right
  * 加宽 20px 给重发二维码 + ⋯ 留出空间
  * fixed: right 避免 el-table 重排时把操作列挤压到中间
  * align: center 跟其他列 (W17.7) 表头居中保持一致

测量对比 (1440 视口, 左菜单 260 + 主区 padding 28x2 = 316 可用):
- 用户列表 (参考):  表格 1152px, 右边距 28px
- openapi/app (修后): 表格 1150px, 右边距 29px → 视觉一致 ✅

操作列按钮完整性 (Playwright 实测):
- 行 0/2 (status=0/1): [详情, 重发二维码] + ⋯ (4按钮前2+⋯) ✅
- 行 1 (status=2):    [详情, 删除] (1按钮无⋯) ✅
 2026-07-09 15:22:41 +08:00
Sisyphus
87e278749b style(F006-W17.7): list 页表头统一居中显示 
- DataTable 组件 header-cell-style textAlign: left → center (覆盖大多数 list 页)
- 3 个裸 el-table list 页补 header-cell-style (categoryGood/region/coupon)
- 单元格内容对齐不变 (仍 left), 只动表头
 2026-07-09 14:56:31 +08:00
Sisyphus
63b32e999f fix(F006-W17.6.1): TableActions 收紧间距 + 理顺布局逻辑 
用户反馈: 按钮没显示全 + 间距太大不美观

间距收紧:
- el-button text padding 0 8px → 0 4px (默认太松散)
- .rr-table-actions gap 4px → 0 (按钮紧贴)
- ⋯ 触发器 26px → 22px (更小巧)
- 实测: 按钮间距 0px, 按钮到⋯ 间距 2px

布局逻辑理顺:
- 多个 computed (visibleActions/isCollapsing/primaryActions/moreActions)
  → 合并为单一 layout computed ({primary, more})
- 减少中间依赖, 更可靠

Playwright 验证通过 (订单页):
- status=1 行: [详情,付款] + ⋯ (4按钮前2显)
- status=4 行: [详情,退款,打印] (3按钮全显无⋯)
- status≥5 行: [详情,打印] (2按钮无⋯)
 2026-07-09 14:31:53 +08:00
Sisyphus
2f7ec67903 refactor(F006-W17.6.1): TableActions 按数量自动收纳 (≤3 全显示, >3 前2+⋯) 
用户反馈: 操作列只显示一个文字按钮+⋯ 不方便, 期望按按钮数量智能显示
- 过滤 when 后 ≤3 个: 全部显示文字按钮, 不显示 ⋯
- 过滤 when 后 ≥4 个: 前 2 个常驻文字按钮 + ⋯ (收纳剩余)
- 默认 visibleCount=2 (可配置)

TableActions API 调整 (W17.6 → W17.6.1):
- 原来: :primary=[A] + :more=[B,C,D] (人为主次划分)
- 现在: :actions=[A,B,C,D] (按数组顺序自动前 2 显 + ⋯)

16 文件改动 (1 组件 + 15 view 调用方式):
- 15 view 合并 :primary/:more → :actions
- 3 按钮页 (10 个): 现在全部显示文字按钮无 ⋯, 体验更直接
- 4/5 按钮页 (5 个): 前 2 显 + ⋯, 比之前详情+⋯更直观
 2026-07-09 13:55:34 +08:00
Sisyphus
cb2790d318 refactor(F006-W17.6): 操作列主次分离 (15 个 list 页 + TableActions 组件) 
- 新建 TableActions 通用组件 (src/components/TableActions/, ~120 行)
  * primary 常驻主操作 (el-button text)
  * more 次操作收进 ⋯ el-dropdown (MoreFilled 触发)
  * label/type 支持 string 或函数 (覆盖动态: 上架/下架, 禁用/启用)
  * when 条件渲染 (替代散落各处的 v-if)
  * danger 项自动 divided + 红字
  * 复用 global-popper.scss 已铺好的 el-dropdown 主题

- 15 个按钮≥3 的 list 页改造 (按钮≤2 的 27 页不动):
  5 按钮: GoodListView/ServiceGoodListView/CouponListView
  4 按钮: OrderListView/OpenAppListView
  3 按钮: user/UserListView/CompanyAccountListView/LabelListView/
          ScheduleListView/sys/UserListView/EnterpriselevelListView/
          OrderCommentListView/PromoterListView/CategoryGoodListView/
          RegionListView

- 列宽统一 240/280/220/200/320 → 140 (固定窄列)
- 清理 4 个 rr-actions 页不再使用的 .rr-actions/.rr-actions__sep 样式
- 业务逻辑全保留 (onClick 函数/二次确认/条件渲染逻辑)
- OrderListView 退款条件修正: [1,2,3,4].includes → ===4 (原 v-else-if 链语义)
 2026-07-09 12:08:48 +08:00
Sisyphus
557db07231 refactor(F006-W17.5): 3 个日志页标准化 (LogError/LogLogin/LogOperation 套 PageHeader+SearchBar) 
- 最后 3 个老写法 list 页收尾, 全部 list 页风格 100% 统一
- rr-page-header div -> <PageHeader> 组件
- rr-filters-row div + el-input -> <SearchBar> 组件 (fields 配置)
- DataTable 加 :page-sizes=[10,20,50,100] (W17.3.7 统一规范)
- limit 默认 20 -> 10 (W17.3.6 pager 字号统一)
- 清理不再使用的老 style class (rr-page-*/rr-filters-row/rr-*-input)
- 业务逻辑全保留 (method tag/status 映射/详情弹窗/errorInfo 预览)
 2026-07-09 11:07:19 +08:00
Sisyphus
18aa3410b6 chore(F006-W17): 补 .gitignore 忽略构建产物 (tsbuildinfo/vite.config.d.ts/vite.config.js) 2026-07-09 09:06:17 +08:00
Sisyphus
a36dda7ccc fix(F006-W17.4.6): UserFormDialog 关联企业下拉改从 user/user/page 聚合 
用户反馈: 关联企业的下拉框是空的

排查:
1. nginx-vue.conf 加 /enterprise/ location (W17.4.5) ✅
2. gateway.json 加 enterprise 路由 + 推 nacos ✅
3. 但 gateway 启动时 bootstrap.yml 没订阅 gateway.json dataId
   (bootstrap.yml 只订阅 datasource.yaml + common.yaml + gateway-server.yaml/-dev.yaml)
   gateway.json 仅供运维手工管理, 实际不参与路由
4. /enterprise/list 在 user-server 也 404 (jar 是旧版本, ApiEnterpriseController
   @RequestMapping 路径未生效)

修法: 前端从 /user/user/page 拉用户列表聚合 (enterpriseId, enterpriseName) 去重
- 端点 100% 可用 (已在 W11 验收过 2284 用户)
- 字段 enterpriseId + enterpriseName 已在 user 表
- 聚合 Map<id, name> 去重, 按 id 排序
- 弹窗打开时拉一次缓存, 后续复用

nginx /enterprise/ location + gateway.json 路由保留: future-proof,
等后端 jar 重打包后会自动生效

前端聚合方式短期可行, 但仅用于下拉选项场景;
如要真正查询某企业的所有用户等场景, 仍需后端打 jar 暴露 /enterprise/page
 2026-07-08 11:15:47 +08:00
Sisyphus
25a0db5cb2 refactor(F006-W17.4.5): UserFormDialog 去备注 + 去tip + 配合 nginx /enterprise/ 修复 
用户原话:
- 关联企业的下拉框是空的, 需要带出来平台注册的企业信息
- 下面的备注去掉, 这个字段是关联企业的选择, 并不是修改企业认证状态的选项

理解:
- 用户原意是去掉"关联企业"字段下的 tip 文字 (我之前误写"由企业认证流程自动带过来..." 给用户误导)
- 同时去掉"备注"字段 (业务上不需要)
- 关联企业下拉空是因为 nginx 没配 /enterprise/ location → 404

修法:
1. nginx-vue.conf 加 /enterprise/ 走 user-server (ApiEnterpriseController 在 renren-user-server)
   备份: nginx-vue.conf.bak-20260708-105000
   重启: docker compose restart frontend (改 nginx 必须 restart, nginx -s reload 不生效 - W3xC P1 已记)
2. UserFormDialog 去掉"备注"字段 (form.remark / payload / 表单项 / style)
3. UserFormDialog 去掉 tip 文字 "由企业认证流程自动带过来..."
4. 保留"关联企业"单选下拉 + 弹窗打开时 /enterprise/list 拉取

新建后保存关联关系:
- POST /user/user/save payload 含 enterpriseId 字段
- 后端 save 接口吃 UserDTO, UserDTO 含 enterpriseId
- save 成功 → tb_user 表 enterprise_id 字段写入
- 下次加载该用户 getUserInfo 时 enterpriseId 回显
- 关联关系保存已确认落库
 2026-07-08 10:58:39 +08:00
Sisyphus
ec473af046 refactor(F006-W17.4.4): UserFormDialog 优化 (去头像URL + 去是否企业认证 + 加关联企业) 
用户原话: 新增用户界面部分内容要优化
- 头像 URL 字段去掉 (UI 无意义, 用户用默认头像)
- 是否企业认证 去掉 (这个由企业认证流程带过来, 不是手工字段)
- 增加关联企业字段 (可以选择用户属于哪些企业 - 多选)

实施:
- 单选 enterpriseId (当前 tb_user 表只支持单值, 真多对多需后端新增 user_enterprise_bind 中间表, 待用户决策)
- 企业下拉从 /enterprise/list 拉取, 弹窗打开时拉一次缓存
- 字段名沿用后端 UserFeignDTO.enterpriseId (认证企业id)

CRUD 验证 (SQL 直查 product_network_user.tb_user):
- 当前 2284 用户, 2283 正常 + 1 禁用, max_id 2318 (前后端完全一致)
- 后端 login() 在 enabled=1 时抛 "账号已被禁用" (UserServiceImpl.java 行 142)
  → 禁用会阻止登录, 已确认
- save/update/delete 三个端点都直接走 MyBatis-Plus baseDao, 改完即落库
  → 新增/禁用/删除真实写库, 已确认

修改:
- UserFormDialog.vue 234 → 294 行
- 去 header, isEnterprise 字段
- 加 enterpriseId (关联企业) 单选下拉 + enterpriseOptions 缓存
- 加关联企业下拉 tip 提示用户此字段语义
 2026-07-08 10:49:47 +08:00
Sisyphus
a978b1572b fix(F006-W17.4.3): 单位列 width 70 → 90 + minWidth 90 (列宽足够) 
用户反馈: 单位列"单/位"两字换行
- DataTable 已全局强制表头不换行 (W17.4.2)
- 单位列实际 width 70 太窄, 即使 nowrap 也撑不下"单位"两字
- 加宽到 90 + minWidth 90 兜底
 2026-07-07 18:40:11 +08:00
Sisyphus
6d6ff30624 fix(F006-W17.4.2): DataTable 表头全局强制不换行 + 单位列加宽到 90 
用户反馈: 单位列"单/位"两字被挤压换行, 强调"以后标题行的规范不能换行"

根因:
1. DataTable header-cell-style 虽设 whiteSpace:"nowrap", 但 el-table 在列宽挤压下
   内部 .cell 容器仍会被 word-break 强制换行 (element-plus 历史 bug)
2. 单位列 width 80 不够, 标题"单位"两字被压

修法:
1. DataTable 加全局 :deep CSS 兜底
   :deep(.el-table__header-wrapper .cell) { white-space: nowrap !important; overflow: visible !important }
   :deep(.el-table th .cell) { word-break: keep-all }
   → 所有 list 页表头统一不换行
2. 单位列 width 80 → 90, minWidth 80 → 90 (保底宽度足够显示"单位"两字)

效果:
- 全局所有用 DataTable 的页面 (User/Order/Inquiry/Finance/Good/Service 等 33 个)
  表头都不换行, 符合规范"标题行不换行"
- 单位列文字"单位"完整在一行
 2026-07-07 18:38:19 +08:00
Sisyphus
04728fb7a6 refactor(F006-W17.4.1): 商品/服务页列宽精细化 + 删审核意见列 
用户原话:
- 商品ID 宽度太多 → 140 缩到 100
- 商品名称/服务名称 列再加宽一些 → minWidth 240 加到 320 (业务核心, 最长字段)
- 分类列调窄一些 → GoodListView minWidth 240 缩到 180 (3 级合并后 180 足够)
- 单位的标题不应该换行 → width 80 + minWidth 80 (DataTable 已有 whiteSpace: nowrap)
- 审核意见列不用在列表中展示 → 整列删除 (详情弹窗内可看)

改动:
- GoodListView columns 11 列 → 10 列
- ServiceGoodListView columns 12 列 → 11 列
- 整体宽度收敛给商品/服务名称 (核心信息)
 2026-07-07 18:34:37 +08:00
direv
c69fa216f8 feat(F006-W17.4): UserListView 新建/修改/导出 完整化 
- 新增 UserFormDialog.vue (新建+修改共用弹窗)
  字段: 昵称/手机号/密码/头像/性别/企业认证/禁用标识/备注
  新建: POST /user/user/save
  修改: GET /user/user/getUserInfo 回填, POST /user/user/update
- 新建按钮: 顶部 + 新建用户 → 打开弹窗(空表单)
- 修改按钮: 操作列 修改 → 打开弹窗(回填)
- 导出按钮: 顶部 导出 → 调 GET /user/user/export (Excel 流, 自动下载)
  带当前搜索条件, 后端响应头 filename 自动识别
 2026-07-07 18:31:54 +08:00
Sisyphus
9664b3d954 refactor(F006-W17.4): 实物/服务商品页套 PageHeader+SearchBar+ListTabs+DataTable 标准化 
用户原话: 按照同样的列表页面的UI规范, 调整实物商品/服务商品的页面样式

实物商品 GoodListView (547→564 行):
- 顶部 rr-page-header 改用 <PageHeader title="商品管理" :sub="..."> 包导出/新增按钮
- 裸 el-form 搜索改用 <SearchBar :fields=[title, enterpriseName]>
- 裸 .rr-tabs-row/.rr-tabs 改用 <ListTabs> (4 状态 tab, count pill)
- 裸 el-table + el-pagination 改用 <DataTable> (:borderless + :page-sizes)
- 操作列 5 个 el-button 改用 el-link + 分隔符, 不再换行
- 新增 checkStats reactive (pending/approved/rejected) 跟 tab 解耦
- 新增 loadStats() 并发拉 3 个状态的 total, stats 与 tab 解耦
- tabItems 全部 = pending+approved+rejected (跨 tab 一致)
- onSearch/onReset/toggleEnabled 并发刷 list + stats

服务商品 ServiceGoodListView (308→352 行):
- 已经有 PageHeader/SearchBar, 补 ListTabs + DataTable + el-link 操作列
- 同样的 checkStats + loadStats (跨 tab 一致)
- 表格所有列改为 slot 透传
- 价格列 / 铺货 / 状态 都有 slot

保留业务独有:
- 详情弹窗 (含 SKU 子表 for 实物商品)
- 审核弹窗 (单个/批量)
- 修改分类弹窗 (单个/批量)
- 批量操作栏 (业务独有, 业务 page 才用)
- el-table selection 列 (DataTable 内置支持)
 2026-07-07 18:27:42 +08:00
Sisyphus
296ba6a966 fix(F006-W17.3.10): UserListView "全部" count = 正常+禁用 (跨 tab 一致) 
用户反馈: 切已禁用 tab 后, 顶部全部数字变成 1 (跟当前 tab 过滤后的 total 走)
期望: 全部 = 正常 + 禁用, 三个 tab 看到的数字一致

根因: tabItems 的 all 用 total.value, 而 total 是当前 tab 后端返的分页总数
       (已禁用 tab 下, total=1 因为只有 1 条禁用用户)

修法:
- tabItems.all count = enabledStats.normal + enabledStats.disabled (跨 tab 一致)
- PageHeader sub 也改成 enabledStats.normal + enabledStats.disabled (跟搜索条件关联)
- 三个 tab 看到的数字自然一致: 2284 = 2283 + 1
 2026-07-07 17:18:19 +08:00
Sisyphus
a1336fe9b7 fix(F006-W17.3.9): UserListView stats 与 tab 解耦 (跨 tab 全量计数一致) 
用户反馈: 切 tab 时"正常/已禁用"两个统计数会变化 (全部 10/0, 正常 10/0, 已禁用 0/1)
期望: stats 是全量统计, 切 tab 不应变化

根因: enabledStats 是在 load() 内"基于当前页 10 条结果"累加, 切 tab 后数据不同, stats 跟着变

修法:
- 拆 load() → loadList() + loadStats()
- buildSearchParams(): 排除 enabled (tab) 的搜索参数 (userId/nickName/mobile/isEnterprise/enterpriseName)
- loadStats(): 并发拉 enabled=0/1 的 page=1&limit=1, 用 resp.total 当 stats (后端只 count 不返列表, 开销可忽略)
- onTabChange: 只调 loadList(), stats 不重算
- onSearch/onReset/onPageChange/onLimitChange/toggleEnabled: 调 load() (并发刷 list + stats)

效果: 三个 tab 看到的正常/已禁用计数一致 (因为跟 tab 解耦, 只跟搜索条件关联)
 2026-07-07 17:14:11 +08:00
Sisyphus
5a7adb9075 fix(F006-W17.3.8): UserListView enabled 语义反转 (后端 0=正常 1=禁用) 
用户反馈: 切 tab 时全部(2284) vs 已禁用(2283) vs 正常(1) 数据不一致
根因: 后端 /user/user/page 接口 enabled 字段语义 0=正常 1=禁用, 但前端 UI label 与字段值反了:
- 切"正常" tab 发 enabled=1 (后端当禁用查) → 只返 1 条
- 切"已禁用" tab 发 enabled=0 (后端当正常查) → 返 2283 条
- enabledStats 计数 filter 与 UI 标签反
- el-tag 颜色: enabled===1 显示绿色正常 (反了)
- toggleEnabled: 当前 1 改为 0 (方向反了)
- 操作按钮: enabled===1 显示禁用 (凑巧对了但跟实际语义反)

修法: 保留后端字段值, 把前端 UI 判断全部对齐后端语义 (0=正常 1=禁用)
- onTabChange: normal → enabled=0, disabled → enabled=1
- enabledStats.normal = filter === 0, disabled = filter === 1
- el-tag: === 0 绿色正常, === 1 红色禁用
- 操作按钮: === 0 显示禁用(橙色), === 1 显示启用(绿色)
- toggleEnabled: row.enabled===0 → next=1 (禁用), === 1 → next=0 (启用)
 2026-07-07 17:09:42 +08:00
Sisyphus
4b77d67dc2 fix(F006-W17.3.7): list 页统一规范 (:borderless + :page-sizes) + product/shop redirect 
- 33 个 ListView.vue 加 :borderless=true + :page-sizes=[10,20,50,100]
  覆盖: order/inquiry/finance/operateguide/sys/Dept|Menu|File|Notice|
        Params|User|Role|Post|DictType|DictData|Product|Schedule|RoleGroup
        user/Enterprise|enterpriselevel|enterprisescore|enterpriserating
        supplier/promoter|couponscope|historylog|logistics|ordercomment|Activity
        other/goodunit|label|textconfig
        api/feedback|help|lunbo
        openapi/AuditLog|CompanyAccount
- OrderListView: columns 抽到 script setup (computed) + :borderless +
  :page-sizes + sub 动态显示选中数
- router/index.ts: /product/shop → redirect /supplier/good
  (删 src/modules/product/shop/ShopListView.vue 旧占位, 后端 404 无意义)
- 沿用 W17 设计规范 v2 (PageHeader+SearchBar+DataTable+ListTabs)
 2026-07-07 16:54:37 +08:00
Sisyphus
08cf2067db fix(F006-W17.3.6): pager 字号跟内容行统一 13px + DataTable 默认 limit=10 2026-07-07 16:13:47 +08:00
Sisyphus
79e039c975 fix(F006-W17.3.4): UserListView + OperateguideListView 补上 @limit-change 监听, 修复每页多少条不刷新 2026-07-07 16:01:33 +08:00
Sisyphus
ba00ed985a fix(F006-W17.3.3): SearchBar select width 显式 px + 列宽 isEnterprise 140 + min-width 兜底 2026-07-07 15:43:30 +08:00
Sisyphus
63420203dd fix(F006-W17.3.2): 把 global-popper.scss 放到正确路径 src/styles/ 2026-07-07 15:13:01 +08:00
Sisyphus
52758388e0 fix(F006-W17.3.1): 全局弹层圆角 + select 宽度 (UserListView isEnterprise +180) 2026-07-07 15:12:20 +08:00
Sisyphus
48ca3ffdb9 fix(F006-W17.3): 圆角对齐模板(--radius 8px) + 分页/弹窗 zhCn + 表头/单元 padding 紧凑 2026-07-07 13:57:18 +08:00
Sisyphus
f97a0fb049 feat(components): 设计细节优化 (表格圆角/按钮尺寸统一/扁平阴影) W17.2.2 2026-07-07 13:07:22 +08:00
Sisyphus
fe07612f29 feat(components): 按 ui-preview-v2.html 模板 v2 整改 (PageHeader扁平/SearchBar无label/ListTabs pill/Table uppercase左对齐) W17.2.1 2026-07-07 13:02:07 +08:00
Sisyphus
7724b4a3b1 feat(components): 通用组件设计规范整改 (ListTabs/PageHeader白卡/SearchBar chip/DataTable var/Content bg) W17.2 2026-07-07 12:56:11 +08:00
Sisyphus
5c35297555 feat(user): 整改 UserListView 符合设计规范 (列宽/操作列 el-link/竖线分隔) W17.1.1 2026-07-07 12:50:20 +08:00
Sisyphus
9c75bd53c4 feat(user): 完整化用户列表 (9 列 + 6 搜索 + 4 操作, 老 vue 等价) W17.1 2026-07-07 11:58:59 +08:00
Sisyphus
c3295c3f57 fix(auth): 移除登录请求 client: front 头,恢复 captcha 校验 (W15.1.5) 2026-07-07 11:43:36 +08:00
Sisyphus
675d27dd2f fix(F006-W17): nginx proxy_hide_header WWW-Authenticate 去除浏览器原生认证弹窗 
根因: Spring Security /auth/oauth/token 401 响应带 WWW-Authenticate: Basic realm="oauth2/client"
浏览器拦截该响应头后弹出原生 HTTP Basic Auth 对话框("身份验证"),
在 axios/JS 处理响应之前就触发,前端代码无法拦截.

修法: nginx-vue.conf /auth/ location 加 proxy_hide_header WWW-Authenticate;
同时 PlaceholderView/AppLayout fetch 调用加 credentials: omit 兜底.

验证: curl 测试 401 响应已无 WWW-Authenticate 头,登录流程不再触发浏览器弹窗.
 2026-07-07 11:03:15 +08:00
Sisyphus
4b4625df9f feat(F006-W16): 7 supplier 子页 + 3 enterprise 子页 接前端 max-effort mock 2026-07-07 10:22:09 +08:00
Sisyphus
04d3992c52 feat(F006-W15): 订单售后/退款/支付回调 3 view 接前端 max-effort mock + 同步 DataTable selection 2026-07-07 09:58:21 +08:00
zou
b3018fe7d7 fix(F006-W14): 财务 4 视图 + 商品 4 操作按钮 接真 API (1.6K+ 真数据) 
W14.1 财务 4 视图接真数据:
- 充值管理 / 提现管理 / 分账记录 / 交易流水
- 后端 /user/accounttransaction/page 是 4 类型合一端点 (405 条)
- 4 configKey 端点统一 → /user/accounttransaction/page
- router 加 queryParams: type=1 (充值) / type=2 (提现) / type=3 (分账) / 交易流水 不传 (全量)
- Playwright 验: 充值 133 条 / 提现 253 条 / 分账 19 条 / 交易流水 405 条
- 发现: 老 vue 端点路径是 /user/accounttransaction/getRechargePage (5.18 教训加强 — 4 URL 试探仍不够, 必须看老 vue 源码)

W14.2 商品详情 SKU: 后端无 supplier_good_sku 表, /supplier/good/skuList 端点返 400 (skuList 功能未实现) — 详情页 skuList 保留 mock, 不强行做

W14.3 实物商品 4 操作按钮接真 API:
- 审核: /supplier/good/checkGood?id=&checkStatus=&checkOpinion= (GET)
- 上下架: /supplier/good/onShelfGood?id= (GET)
- 改分类: /supplier/good/update (POST, body JSON)
- 删除: /supplier/good/delete?id= (GET)
- Playwright 验: 第一行"上架"按钮 → 弹窗 → 确认 → /supplier/good/onShelfGood?id=323 200

W14.4 暂不做 (supplier/promoter 端点 200 但 0 条, 显示空列表已可接受)

W14.1+W14.3 总计真数据: 财务 405 + 实物 16131 = 16536 条, 加 W13 共 16650+ 条

5.18 教训+1: 端点 4 URL 试探 (page/list/search/pageList) 不够, 必须看老 vue 源码
才能找到 getRechargePage 这类特殊命名端点
 2026-07-07 09:07:01 +08:00
zou
dfdc8ef4ff fix(F006-W13.4+13.5): 系统消息 + 字典类型 端点路径错配修正 (5.18 教训) 
W13.4 系统消息:
- mockTableConfigs user-message 端点 /user/message/message/page (404) → /user/message/page (112 条真数据)
- 字段对齐后端: title→name / receiver→content / status→readFlag / sendTime→createDate
- type/format 函数把 readFlag 1→已读 0→未读, type 1→系统 2→业务

W13.5 字典类型:
- mockTableConfigs sys-dict 端点 /sys/dict-type/page (404) → /sys/dict/type/page (11 条真数据)
- 字段 dictType/dictName/remark/createDate 全对齐

W13.5 顺手扫了其它 5 个 configKey 端点, 全是 200 (other-information/groupbuy/seckill/supplier-promoter 都对)

5.18 教训再确认:
- 端点 4 URL 都试: /module/page /module/list /module/search /module
- 真实分页端点不一定叫 page, 也可能是 search/list
- mockTableConfigs 写端点前必先 curl 验证 (不能用 router 名字猜)

Playwright 验:
- 系统消息: sub="共 112 条" 第一行 "售后申请通知 用户发起了...订单的售后申请"
- 字典类型: sub="共 11 条" 第一行 "gender 性别"

遗留 (不阻塞):
- 5.x.x 端点路径错配继续扫: 40 个 MockTableView 中其它可疑的还没全扫
- supplier/promoter 端点 200 但 0 条, 显示空列表
- 待处理消息 (/user/message/handel) 后端无端点, 保留 mock
 2026-07-06 15:30:15 +08:00
zou
99166d8abe fix(F006-W13.1+13.2): 实物商品 16131 条 + 服务商品独立接 pageList (type 区分) 
W13.1 实物商品:
- /supplier/good/search (16080 条, 缺字段) → /supplier/good/pageList?type=1 (16131 条, 完整字段)
- 完整字段: supplierGoodId/enterpriseName/unitName/brandName/checkStatus/checkOpinion/createDate
- 状态 tab (待审核/已通过/已驳回) 现在能真筛 (之前 search 不返 checkStatus)
- Playwright 验: 标题"商品管理" rows=10 sub="共 16131 个商品"

W13.2 服务商品拆出来:
- 之前 /supplier/servicegood redirect 到 /supplier/good (W3.xC 后端无端点)
- 现在用 /supplier/good/pageList?type=2 是真服务商品端点 (2 条: 家政服务等)
- menu-labels 服务商品 path 改回 /supplier/servicegood (独立路由)
- ServiceGoodListView 接 pageList+type=2, 表格显示服务区域/服务ID/分类等
- Playwright 验: 标题"服务商品管理" rows=2 sub="共 2 个服务商品"

W13.1+W13.2 改的源文件:
- src/modules/supplier/good/GoodListView.vue
- src/modules/supplier/servicegood/ServiceGoodListView.vue
- src/config/menu-labels.ts (servicegood path 改 /supplier/servicegood)
 2026-07-06 15:15:30 +08:00
zou
392a4c0acc fix(F006-W12.7): 实物商品 3 条 fallback → /supplier/good/search 真数据 16080 条 
问题: 用户验收发现商品管理 (实物商品) 只显示 3 条, 标签 服务商品(→实物商品) 太丑

根因:
- W3.xC 时 /supplier/good/page 端点当时 404, 故 GoodListView 写死 FALLBACK 3 条
- 现在 /supplier/good/page 实际是 200 + code=400 (按 id 查, 不是分页), /supplier/good/search 才是真分页端点
- /supplier/good/search 返 16080 条, 字段精简 (缺 enterpriseName/unitName/createDate/checkStatus/checkOpinion)
- menu-labels 写 "服务商品(→实物商品)" 是 W3.xC redirect 模式下的过渡标签

修法:
- GoodListView.load() 改调 /supplier/good/search, 字段补齐 (缺字段用 -- 占位, checkStatus 默认 2 已通过, supplierGoodId 用 G+id 拼)
- menu-labels "服务商品" 标签去掉 "(→实物商品)" 角标, 只留 "服务商品"
- (后端没 /supplier/servicegood/* 端点, servicegood 路由被 menu-labels 改 path 跳到 /supplier/good, redirect 是设计意图)

验证 (Playwright + token):
- title="商品管理" rows=10 sub="共 16080 个商品"
- /supplier/good/search 200 OK, 10 行真数据 (铝合金门窗/VV62/WDZ-RYJS/WDZN-YJY23/RVV 等)
- 封面图正常加载, 分类 2 级 (门窗/电缆) 正常

已知遗留 (不阻塞使用):
- enterpriseName/unitName/createDate search 端点不返, 表格显示 -- 占位
- 状态 tab (待审核/已通过/已驳回) 暂不能筛选, 因 search 不返 checkStatus
 2026-07-06 12:29:06 +08:00
zou
7ea52c024c fix(F006-W12.6): 4 个 sys view (log×3 + schedule) 路由改指真 view 
问题: W5.x.x+4 把 log×3 + job/schedule 路由统一改成 MockTableView + configKey,
W5.x.x+5 写的 LogErrorView/LogLoginView/LogOperationView/ScheduleListView 4 个真 view
(241/179/216/198 行) 因路由没引用从未生效, 用户实际看到的都是 mock 数据.

根因诊断:
- /sys/log/error/page 200 OK + 809 条真数据 (database sys_log_error)
- /sys/log/login/page 200 OK + 50166 条
- /sys/log/operation/page 200 OK + 41771 条
- /sys/schedule/page 200 OK (0 条, QRTZ 表未建)
- 之前 user 看 log 看到 mock 是因为 router 把 /sys/log/error 路由到 MockTableView
  (configKey sys-log-error), 不是 LogErrorView

修法: 改 src/router/index.ts 4 行, 让 /sys/log/{login,operation,error} 指向真 view,
/job/schedule 指向 ScheduleListView.

验证 (Playwright + token 注入):
- 错误日志 title="错误日志" rows=20 sub="共 809 条"
- 登录日志 title="登录日志" rows=20 sub="共 50166 条"
- 操作日志 title="操作日志" rows=20 sub="共 41771 条"
- 定时任务 title="定时任务" rows=0 sub="共 0 个任务" (QRTZ 表待建)

额外发现: 操作日志显示 F002 MCP 列出询价 GET 反复失败, 是平台助手集成 bug 的真实证据

影响: FileListView 无菜单入口, 暂不接 router (保留 152 行代码供未来菜单化)

ps: 后端 client_credentials token 触发 @PreAuthorize Access Denied, 必须用 admin/admin
password grant + captcha=socialedu (前端 LoginView 走此路径, 无感知)
 2026-07-06 12:03:36 +08:00
zou
651694bb52 fix(F006-W12.5): OrderListView 下单时间格式化 (UNIX ms → 年月日时分秒) + 4 列空字段显示 -- 占位 2026-07-06 11:47:47 +08:00
Sisyphus
e1a19145fa fix(F006): remove duplicate menu label for order management 2026-07-06 11:29:01 +08:00
zou
db472a0e2f fix(F006-W12.3): OrderListView load 函数适配 httpGet 已解 data (r.list/r.total, 不是 r.data.list) 2026-07-06 10:29:22 +08:00