65 Commits

Author SHA1 Message Date
邹进
a62b8930d4 ci: iteration/august 作为生产代码线,推送不再部署测试环境(测试环境改由 iteration/8-11 部署) 2026-11-06 22:18:45 +09:00
luo
e41adb4505 fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 45s
2026-10-29 17:17:02 +08:00
luo
2c8de04041 fix: some
Some checks failed
构建并部署前端到测试环境 / deploy (push) Has been cancelled
2026-10-29 17:15:10 +08:00
luo
98a4be8719 fix: 一行一个ICCID批量回收
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 45s
2026-10-29 16:24:40 +08:00
luo
f5730089a1 fix: 一行一个ICCID批量回收
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-10-29 16:18:45 +08:00
luo
ecce4f6e7b fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-24 14:56:32 +08:00
luo
c706f543a4 fix: 隐藏原路退回
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-23 16:38:08 +08:00
luo
d82e716d33 fix:some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-21 09:54:21 +08:00
luo
22e796ba23 fix:some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-20 17:35:12 +08:00
luo
6dedd9f852 fix:some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-20 17:21:48 +08:00
luo
7f3ff10fda fix:some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-20 09:21:23 +08:00
luo
eeeab03295 fix:some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 46s
2026-10-19 14:42:19 +08:00
luo
0d77a7d55b fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-14 17:08:32 +08:00
luo
16effb69f3 fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-13 17:43:38 +08:00
luo
c31183205d fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 56s
2026-10-13 17:21:46 +08:00
luo
b2a76adc9a fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-13 11:25:03 +08:00
luo
52268859aa fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-10-12 11:43:12 +08:00
luo
f1006187f6 fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 46s
2026-10-12 10:56:14 +08:00
luo
944f17ec3f fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 45s
2026-10-10 15:28:30 +08:00
luo
633c88d0aa fix: 适配手机
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-10-08 14:34:56 +08:00
luo
f61a3f84b6 fix: 修改文案
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-08 09:24:21 +08:00
luo
327516dd40 fix: 修改文案
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-10-08 09:16:04 +08:00
luo
2f23aeaaba fix: 单个解绑
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-10-07 17:16:19 +08:00
luo
2c64957e55 fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-30 09:15:03 +08:00
luo
1a5f3d1e7d fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 56s
2026-09-29 18:32:51 +08:00
luo
d02ce01f6a fix: 密码长度限制
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-29 16:40:31 +08:00
luo
aec2a27a65 fix: 凭证识别
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-09-29 16:07:48 +08:00
luo
f896cad34f fix: 选择今天00:00:00-23:59:59
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-29 11:36:41 +08:00
luo
7a74bec337 fix: 提现审批
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 47s
2026-09-29 10:41:57 +08:00
luo
5364916b1d fix: 运营商管理
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-09-29 09:15:05 +08:00
luo
6655638116 fix: 批量换绑业务员模板
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-09-28 11:26:15 +08:00
luo
e79d599da1 feat: 修改密码全局
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 56s
2026-09-28 11:17:39 +08:00
luo
015f990fb6 fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-28 10:08:30 +08:00
luo
063337e6a3 fix: 工作台适配深色模式
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-09-23 15:34:46 +08:00
luo
c26d36154c fix:fixed_left_config
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-23 15:27:55 +08:00
luo
669610a84a fix:some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-23 09:37:11 +08:00
luo
a26d7b4284 fix: 商户池和代理充值 2026-09-22 16:46:39 +08:00
luo
10fccc4def feat: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 56s
2026-09-22 15:06:30 +08:00
luo
0a28b7d8ef feat: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-22 12:14:47 +08:00
luo
c136f68ab8 feat: 代理商注册列表
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-21 18:07:36 +08:00
luo
c5d7a260d0 fix: 恢复退款原审批提交
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-20 18:13:14 +08:00
luo
ffba959d45 fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-09-20 17:56:48 +08:00
luo
9a6761e01d fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 54s
2026-09-20 17:29:09 +08:00
luo
2c00341a7c fix: some
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 55s
2026-09-20 16:16:54 +08:00
5c1dc59579 fix: 清理镜像构建代理配置
All checks were successful
构建并部署前端到测试环境 / deploy (push) Successful in 59s
2026-09-20 15:47:39 +08:00
d52219b5c8 fix: 显式指定 npm 镜像源 2026-09-20 15:39:56 +08:00
bce5d6f270 fix: 避免 Corepack 下载失败 2026-09-20 15:32:21 +08:00
42e57cf698 fix: 配置 Corepack 镜像源 2026-09-20 15:30:47 +08:00
55eec78a90 feat: 支持跨平台前端镜像部署 2026-09-20 15:25:04 +08:00
cb1561a317 fix: 修复前端部署资源保护
Some checks failed
构建并部署前端到测试环境 / build-and-deploy (push) Failing after 14s
2026-09-20 14:42:14 +08:00
luo
94764b0e0a fix: some
Some checks failed
构建并部署前端到测试环境 / build-and-deploy (push) Failing after 11m29s
2026-09-20 11:37:47 +08:00
luo
a6ce24f2f2 fix: some
Some checks failed
构建并部署前端到测试环境 / build-and-deploy (push) Failing after 50m13s
2026-09-20 10:22:39 +08:00
luo
085a83d4e4 fix: some
Some checks failed
构建并部署前端到测试环境 / build-and-deploy (push) Has been cancelled
2026-09-20 10:10:50 +08:00
luo
e37d4902ca fix: some 2026-09-18 18:32:45 +08:00
luo
08889d2e42 fix: some
Some checks failed
构建并部署前端到测试环境 / build-and-deploy (push) Failing after 28m40s
2026-09-18 18:11:53 +08:00
luo
5e7f5eaba4 fix: some
All checks were successful
构建并部署前端到测试环境 / build-and-deploy (push) Successful in 7m3s
2026-09-18 10:31:14 +08:00
luo
ac541b17af fix: some
All checks were successful
构建并部署前端到测试环境 / build-and-deploy (push) Successful in 11m35s
2026-09-17 18:43:01 +08:00
luo
68d8f769d1 fix: some
Some checks failed
构建并部署前端到测试环境 / build-and-deploy (push) Has been cancelled
2026-09-17 18:37:20 +08:00
luo
068d0c4ac2 fix: git branch
All checks were successful
构建并部署前端到测试环境 / build-and-deploy (push) Successful in 8m48s
2026-09-17 15:46:33 +08:00
luo
9a3a764120 fix: git branch
All checks were successful
构建并部署前端到测试环境 / build-and-deploy (push) Successful in 35m56s
2026-09-17 14:35:31 +08:00
luo
cea805f5d8 fix: git branch 2026-09-17 14:30:53 +08:00
luo
76d4e4ec02 fix: some 2026-09-17 12:16:20 +08:00
luo
2308d82d0f fix: 代理 2026-09-12 11:27:50 +08:00
luo
d3d257cdf8 feat: 支付商户 2026-09-10 16:50:06 +08:00
luo
ef966171b4 feat: 套餐分层级 2026-09-08 16:39:29 +08:00
361 changed files with 33869 additions and 2122 deletions

18
.dockerignore Normal file
View File

@@ -0,0 +1,18 @@
node_modules
dist
.git
.gitea
.husky
.vscode
.idea
.DS_Store
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.env.local
.env.*.local
openspec
.codex
.claude
.agents

View File

@@ -3,9 +3,11 @@ name: 构建并部署前端到测试环境
on: on:
push: push:
branches: branches:
- main
- dev - dev
- test - test
# 如果不再需要 main 分支触发构建,可以把下面这行删掉;
# 如果只是想保留构建(不部署),可以留着,反正部署条件已经只认 iteration/august
- main
env: env:
REGISTRY: registry.boss160.cn REGISTRY: registry.boss160.cn
@@ -13,7 +15,7 @@ env:
DEPLOY_DIR: /opt/junhong_cmp_web DEPLOY_DIR: /opt/junhong_cmp_web
jobs: jobs:
build-and-deploy: deploy:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
@@ -24,67 +26,49 @@ jobs:
git clone https://git.boss160.cn/luo/one-pipe-system.git . git clone https://git.boss160.cn/luo/one-pipe-system.git .
git checkout ${{ github.sha }} git checkout ${{ github.sha }}
- name: 设置镜像标签
id: tag
run: |
if [ "${{ github.ref }}" = "refs/heads/main" ]; then
echo "tag=latest" >> $GITHUB_OUTPUT
elif [ "${{ github.ref }}" = "refs/heads/dev" ]; then
echo "tag=dev" >> $GITHUB_OUTPUT
elif [ "${{ github.ref }}" = "refs/heads/test" ]; then
echo "tag=test" >> $GITHUB_OUTPUT
else
echo "tag=unknown" >> $GITHUB_OUTPUT
fi
- name: 登录 Docker Registry - name: 登录 Docker Registry
run: | run: |
echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login "${{ env.REGISTRY }}" --username "${{ secrets.REGISTRY_USERNAME }}" --password-stdin echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login "${{ env.REGISTRY }}" --username "${{ secrets.REGISTRY_USERNAME }}" --password-stdin
- name: 构建前端镜像 - name: 校验镜像存在
run: | run: |
docker build -t ${{ env.IMAGE_NAME }}:${{ steps.tag.outputs.tag }} . if ! docker manifest inspect "${{ env.IMAGE_NAME }}:${{ github.sha }}" >/dev/null 2>&1; then
docker tag ${{ env.IMAGE_NAME }}:${{ steps.tag.outputs.tag }} ${{ env.IMAGE_NAME }}:${{ github.sha }} echo "镜像不存在:${{ env.IMAGE_NAME }}:${{ github.sha }}"
echo "请先在开发机完成 pre-push 镜像构建和推送"
exit 1
fi
- name: 推送镜像到 Registry - name: 部署到测试环境
if: github.ref == 'refs/heads/iteration/august'
run: | run: |
docker push ${{ env.IMAGE_NAME }}:${{ steps.tag.outputs.tag }} mkdir -p "${{ env.DEPLOY_DIR }}"
docker push ${{ env.IMAGE_NAME }}:${{ github.sha }} cp -v docker-compose.prod.yml "${{ env.DEPLOY_DIR }}/"
cd "${{ env.DEPLOY_DIR }}"
- name: 部署到本地(仅 main 分支) IMAGE_TAG=${{ github.sha }} docker compose -f docker-compose.prod.yml pull
if: github.ref == 'refs/heads/main' IMAGE_TAG=${{ github.sha }} docker compose -f docker-compose.prod.yml up -d
run: |
# 确保部署目录存在
mkdir -p ${{ env.DEPLOY_DIR }}
echo "当前工作目录: $(pwd)" echo "等待服务健康检查通过..."
echo "当前目录内容:" for i in $(seq 1 30); do
ls -la WEB_HEALTH=$(docker inspect junhong-cmp-web --format='{{if .State.Health}}{{.State.Health.Status}}{{else}}none{{end}}' 2>/dev/null || true)
if [ "$WEB_HEALTH" = "healthy" ]; then
break
fi
if [ "$i" -eq 30 ]; then
echo "前端服务在等待窗口内未恢复健康"
docker compose -f docker-compose.prod.yml logs web --tail=100
exit 1
fi
sleep 2
done
# 更新 docker-compose.prod.yml IMAGE_TAG=${{ github.sha }} docker compose -f docker-compose.prod.yml ps
echo "更新部署配置文件..."
cp -v docker-compose.prod.yml ${{ env.DEPLOY_DIR }}/
cd ${{ env.DEPLOY_DIR }}
echo "拉取最新镜像..."
docker compose -f docker-compose.prod.yml pull
echo "重启服务..."
docker compose -f docker-compose.prod.yml up -d
echo "等待服务启动..."
sleep 5
echo "部署完成!"
docker compose -f docker-compose.prod.yml ps
- name: 构建结果通知 - name: 构建结果通知
if: always() if: always()
run: | run: |
if [ "${{ job.status }}" = "success" ]; then if [ "${{ job.status }}" = "success" ]; then
echo "构建成功: ${{ steps.tag.outputs.tag }}" echo "部署成功: ${{ github.sha }}"
echo "镜像标签: ${{ github.sha }}"
else else
echo "构建失败" echo "部署失败"
fi fi

3
.gitignore vendored
View File

@@ -2,6 +2,9 @@ node_modules
.DS_Store .DS_Store
dist dist
docs docs
!docs/
docs/*
!docs/权限.md
dist-ssr dist-ssr
*.local *.local
.cursorrules .cursorrules

1
.husky/pre-push Executable file
View File

@@ -0,0 +1 @@
node scripts/deploy-frontend.mjs --pre-push

View File

@@ -6,15 +6,16 @@ FROM --platform=linux/amd64 node:20-alpine AS builder
# 使用阿里云镜像源加速 # 使用阿里云镜像源加速
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories
# 设置工作目录
WORKDIR /build WORKDIR /build
# 安装 pnpm # 清除宿主机注入的失效代理,再安装 pnpm
RUN corepack enable && corepack prepare pnpm@10.15.0 --activate RUN npm config delete proxy && npm config delete https-proxy && npm install --global pnpm@10.15.0 --registry=https://registry.npmmirror.com
# 设置 npm 镜像源
RUN pnpm config set registry https://registry.npmmirror.com RUN pnpm config set registry https://registry.npmmirror.com
# 限制 Node 堆,防止前端构建耗尽宿主机内存
ARG NODE_OPTIONS=--max-old-space-size=1536
ENV NODE_OPTIONS=${NODE_OPTIONS}
# 复制 package.json 和 pnpm-lock.yaml(利用 Docker 缓存) # 复制 package.json 和 pnpm-lock.yaml(利用 Docker 缓存)
COPY package.json pnpm-lock.yaml ./ COPY package.json pnpm-lock.yaml ./

View File

@@ -1,7 +1,6 @@
version: '3.8'
services: services:
web: web:
image: registry.boss160.cn/junhong/cmp-admin-web:latest image: registry.boss160.cn/junhong/cmp-admin-web:${IMAGE_TAG:-latest}
container_name: junhong-cmp-web container_name: junhong-cmp-web
restart: unless-stopped restart: unless-stopped
ports: ports:

236
docs/权限.md Normal file
View File

@@ -0,0 +1,236 @@
# 权限清单
## 套餐管理:真流量预警规则
页面 URL:`/package-management/traffic-alert-rules`
| 类型 | 权限名称 | 权限编码 |
| -------- | ------------- | ------------------------------------ |
| 页面查看 | `rulesView` | `package_traffic_alert:rules_view` |
| 新增规则 | `ruleCreate` | `package_traffic_alert:rule_create` |
| 编辑规则 | `ruleUpdate` | `package_traffic_alert:rule_update` |
| 启用规则 | `ruleEnable` | `package_traffic_alert:rule_enable` |
| 停用规则 | `ruleDisable` | `package_traffic_alert:rule_disable` |
启用和停用不得复用编辑权限。
## 套餐管理:真流量达量预警
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 预警列表 | `/package-management/traffic-alerts` | `recordsView` | `package_traffic_alert:records_view` |
| 点击套餐名称进入预警详情 | `/package-management/traffic-alerts/detail/:id` | `recordDetail` | `package_traffic_alert:record_detail` |
| 导出预警记录 | — | `export` | `package_traffic_alert:export` |
| 导出任务页面 | `/asset-management/export-task-management/export-package-traffic-alert` | `page` | `export_task:package_traffic_alert_page` |
## 店铺管理:店铺列表
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 店铺列表 | `/shop-management/list` | `listView` | `shop:list_view` |
| 店铺详情 | `/shop-management/detail/:id` | `detailView` | `shop:detail_view` |
| 新增店铺 | — | — | `shop:add` |
| 批量交接 | — | `batch` | `shop:business_owner_batch` |
| 导入业务员 | — | `importPage` | `shop:business_owner_import_view` |
| 查看店铺详情 | — | — | `shop:detail` |
| 切换店铺状态 | — | — | `shop:modify_status` |
| 账号列表 | — | — | `shop:look_customer` |
| 默认角色 | — | — | `shop:default_role` |
| 调整实际信用额度 | — | — | `shop:credit_limit_manage` |
| 编辑店铺 | — | — | `shop:edit` |
| 删除店铺 | — | — | `shop:delete` |
| 审计记录 | — | — | `audit:shop_entry` / `audit:agent_resource_activity` |
| 资金链路 | — | — | `audit:finance_timeline` |
## 店铺管理:业务用户组
页面 URL:`/shop-management/business-user-groups`
| 类型 | 权限名称 | 权限编码 |
| -------- | --------- | ----------------------------- |
| 页面查看 | `page` | `business_user_group:page` |
| 新增 | `create` | `business_user_group:create` |
| 编辑 | `update` | `business_user_group:update` |
| 删除 | `delete` | `business_user_group:delete` |
| 成员管理 | `members` | `business_user_group:members` |
## 店铺管理:批量换绑业务员
页面 URL:`/shop-management/business-owner-import`
| 类型 | 权限名称 | 权限编码 |
| ---------------------------- | -------------- | ----------------------------------- |
| 页面查看 | `importPage` | `shop:business_owner_import_view` |
| 创建导入任务 | `importCreate` | `shop:business_owner_import_create` |
| 详情按钮 | `importDetail` | `shop:business_owner_import_detail` |
| 详情页面(当前为列表页抽屉) | `importDetail` | `shop:business_owner_import_detail` |
## 店铺管理:代理注册申请
列表不显示操作列,点击“申请店铺”名称进入详情页。
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 申请列表 | `/shop-management/agent-distribution-registrations` | `list` | `agent_distribution_registration:list` |
| 申请详情 | `/shop-management/agent-distribution-registrations/detail/:id` | `detail` | `agent_distribution_registration:detail` |
| 恢复审批 | — | `recoverApproval` | `agent_distribution_registration:recover_approval` |
## 资产管理:手机号资产关联
页面 URL:`/asset-management/phone-asset-association`
| 类型 | 权限名称 | 权限编码 |
| ---------------- | -------------------- | ---------------------------------------------- |
| 页面查看 | `list` | `phone_asset_association:list` |
| 单条解绑 | `unbind` | `phone_asset_association:unbind` |
| 批量解绑 | `unbindBatch` | `phone_asset_association:unbind_batch` |
| 解绑导入页面 | `unbindImportPage` | `phone_asset_association:unbind_import_view` |
| 创建解绑导入任务 | `unbindImportCreate` | `phone_asset_association:unbind_import_create` |
## 资产管理:解绑导入任务
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 任务列表 | `/asset-management/task-management/phone-asset-unbind-import-tasks` | `unbindImportPage` | `phone_asset_association:unbind_import_page` |
| 任务详情 | `/asset-management/task-management/phone-asset-unbind-import-tasks/detail` | `unbindImportDetail` | `phone_asset_association:unbind_import_detail` |
| 详情按钮 | — | `unbindImportDetail` | `asset_association:unbind_import_detail` |
## 资产管理:临期资产
页面 URL:`/asset-management/expiring-assets`
| 类型 | 权限名称 | 权限编码 |
| -------- | -------- | ----------------------- |
| 页面查看 | `page` | `expiring_asset:page` |
| 导出 | `export` | `expiring_asset:export` |
## 资产管理:导出任务页面
详情按钮为导出任务列表中的任务编号点击入口,权限编码按导出场景区分;详情页面统一使用 `id` 查询参数。
| 导出场景 | 列表页面 URL | 页面权限编码 | 详情按钮权限编码 | 详情页面 URL |
| --- | --- | --- | --- | --- |
| 设备 | `/asset-management/export-task-management/export-device` | `export_task:device_page` | `export_task:device_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| IoT 卡 | `/asset-management/export-task-management/export-iot-card` | `export_task:iot_card_page` | `export_task:iot_card_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 订单 | `/asset-management/export-task-management/export-order` | `export_task:order_page` | `export_task:order_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 套餐 | `/asset-management/export-task-management/export-package` | `export_task:package_page` | `export_task:package_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 代理主钱包流水 | `/asset-management/export-task-management/export-agent-wallet-transaction` | `export_task:agent_wallet_transaction_page` | `export_task:agent_wallet_transaction_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 代理充值 | `/asset-management/export-task-management/export-agent-recharge` | `export_task:agent_recharge_page` | `export_task:agent_recharge_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 退款 | `/asset-management/export-task-management/export-refund` | `export_task:refund_page` | `export_task:refund_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 换货 | `/asset-management/export-task-management/export-exchange` | `export_task:exchange_page` | `export_task:exchange_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 佣金明细 | `/asset-management/export-task-management/export-commission-record` | `export_task:commission_record_page` | `export_task:commission_record_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 套餐真流量达量预警 | `/asset-management/export-task-management/export-package-traffic-alert` | `export_task:package_traffic_alert_page` | `export_task:package_traffic_alert_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 临期资产 | `/asset-management/export-task-management/export-expiring-asset` | `export_task:expiring_asset_page` | `export_task:expiring_asset_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 设备激活报表 | `/asset-management/export-task-management/export-operations-activation` | `export_task:operations_activation_page` | `export_task:operations_activation_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
| 套餐续费报表 | `/asset-management/export-task-management/export-operations-renewal` | `export_task:operations_renewal_page` | `export_task:operations_renewal_detail` | `/asset-management/export-task-management/export-task-detail?id=:id` |
## 财务管理:退款管理
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --------- | ---------------------------- | ----------------- | ------------------------- |
| 退款列表 | `/finance/refund` | `page` | `refund:page` |
| 退款详情 | `/finance/refund/detail/:id` | `detailPage` | `refund:detail_page` |
| 恢复审批 | — | `recoverApproval` | `refund:recover_approval` |
## 财务管理:员工代收款账单
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 账单列表 | `/finance/employee-collection/bills` | `billPage` | `employee_collection:bill_view` |
| 账单详情 | `/finance/employee-collection/bills/detail/:id` | `billDetail` | `employee_collection:bill_detail` |
| 创建核销申请 | — | `applicationCreate` | `employee_collection:application_create` |
| 关闭账单 | — | `billClose` | `employee_collection:bill_close` |
## 财务管理:核销申请
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 申请列表 | `/finance/employee-collection/applications` | `applicationPage` | `employee_collection:application_view` |
| 申请详情 | `/finance/employee-collection/applications/detail/:id` | `applicationDetail` | `employee_collection:application_detail` |
| 修改并重新提交 | — | `applicationUpdate` | `employee_collection:application_update` |
| 查看凭证 | — | `applicationViewVoucher` | `employee_collection:application_view_voucher` |
| 恢复审批 | — | `applicationRecoverApproval` | `employee_collection:application_recover_approval` |
## 财务管理:收款方式管理
页面 URL:`/finance/employee-collection/payment-methods`
| 类型 | 权限名称 | 权限编码 |
| -------- | --------------------- | ------------------------------------------- |
| 页面查看 | `paymentMethodPage` | `employee_collection:payment_method_view` |
| 新增 | `paymentMethodCreate` | `employee_collection:payment_method_create` |
| 编辑 | `paymentMethodEdit` | `employee_collection:payment_method_edit` |
| 删除 | `paymentMethodDelete` | `employee_collection:payment_method_delete` |
## 财务管理:代理商资金概况
页面 URL:`/finance/agent-fund-overview`
| 类型 | 权限名称 | 权限编码 |
| ------------ | ------------------ | --------------------------------------- |
| 页面查看 | `page` | `agent_fund_overview:page` |
| 佣金明细导出 | `commissionExport` | `agent_fund_overview:commission_export` |
## 设置:商户池管理
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 管理页面 | `/settings/payment-merchant-pools` | `page` | `payment_merchant_pool:page` |
| 商户详情 | `/settings/payment-merchant-pools/detail/:id` | `merchantDetail` | `payment_merchant_pool:merchant_detail` |
| 商户池详情 | `/settings/payment-merchant-pools/pool-detail/:id` | `poolDetail` | `payment_merchant_pool:pool_detail` |
| 新增/编辑/启停/删除商户 | — | — | `payment_merchant_pool:merchant_create` / `merchant_edit` / `merchant_toggle` / `merchant_delete` |
| 新增/编辑/启停商户池 | — | — | `payment_merchant_pool:pool_create` / `pool_edit` / `pool_toggle` |
| 保存微信授权配置 | — | `wechatAuthEdit` | `payment_merchant_pool:wechat_auth_edit` |
## 设置:H5运营弹窗配置
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 配置列表 | `/settings/h5-popup-configuration` | `list` | `h5_popup_configuration:list` |
| 配置详情 | `/settings/h5-popup-configuration/detail/:id` | `detail` | `h5_popup_configuration:detail` |
| 新增/编辑/启用/停用 | — | — | `h5_popup_configuration:create` / `update` / `enable` / `disable` |
## 设置:资产钱包自动续费
| 页面/操作 | URL | 权限名称 | 权限编码 |
| --- | --- | --- | --- |
| 页面查看 | `/settings/asset-wallet-auto-renewal` | `page` | `asset_wallet_auto_renewal:page` |
| 保存配置 | — | `update` | `asset_wallet_auto_renewal:update` |
## 轮询管理:优先队列
页面 URL:`/polling-management/priority-queue`
| 类型 | 权限名称 | 权限编码 |
| ------------ | -------- | ------------------------------- |
| 页面查看 | `page` | `polling_priority_queue:page` |
| 人工优先入队 | `create` | `polling_priority_queue:create` |
| 查看详情 | `detail` | `polling_priority_queue:detail` |
## 运营报表:设备激活报表
页面 URL:`/operations-reports/activation`
| 类型 | 权限名称 | 权限编码 |
| -------- | ------------------ | -------------------------------------- |
| 页面查看 | `activationPage` | `operations_reports:activation_page` |
| 导出 | `activationExport` | `operations_reports:activation_export` |
## 运营报表:套餐续费报表
页面 URL:`/operations-reports/renewal`
| 类型 | 权限名称 | 权限编码 |
| -------- | --------------- | ----------------------------------- |
| 页面查看 | `renewalPage` | `operations_reports:renewal_page` |
| 导出 | `renewalExport` | `operations_reports:renewal_export` |
## 通用:导出任务详情
页面 URL:`/asset-management/export-task-management/export-task-detail`
- 页面权限:`export_task:detail_page`
- 各场景详情权限:`export_task:<scene>_detail`
- 各场景下载权限:`export_task:<scene>_download`
所有权限编码必须保持唯一;页面 URL 权限与按钮权限应分别定义。

View File

@@ -0,0 +1,23 @@
# Change: 代理扫码分销注册与提现资料资格前端对接
## Why
新增强代理扫码分销注册与提现资料资格能力:代理可通过 H5 注册页扫码注册,审批通过后登录后台;代理本人可维护提现资料资格并发起/重提提现,超管可作废资格。后端契约已按 `docs/产品迭代8月份/frontend-api-simple.md` 落地,后台管理端当前缺少对应接口封装、独立注册页与资格管理入口。
本次前端按后端实际契约对齐:注册验码 `POST /api/c/v1/auth/send-code`(`scene` 为 `bind_phone`,返回 `cooldown_seconds`);扫码注册 `POST /api/c/v1/agent-distribution-registrations`(成功仅返回「待审批」);店铺列表/详情/更新响应新增 `distribution_code`;提现资料资格提交/查询/作废与提现申请重提/详情按新文档补齐。
## What Changes
- 新增 `agent-distribution-registration` 能力:独立注册页挂在后台项目内、静态路由免登录访问(H5 与 PC 同一套表单),支持分销码自动填、短信验证码 60s 倒计时、密码掩码与强度提示、省市区级联;提交成功进入「待审批」结束页,失败统一提示「分销码不可用」且不复用同一验证码。
- 新增公开 API 封装:`sendCode()` 与 `registerAgent()`,请求不带登录态(`requestOptions.withToken: false`)。
- 店铺模块补充 `distribution_code` 字段类型,店铺详情页展示分销码与注册二维码。
- 佣金模块新增:提现资料资格提交/替换、资格查询(证件号脱敏、含审批与作废信息)、资格作废(超管,`reason` 必填)、重提被驳回的提现、提现申请详情(含尝试记录与异常标记)。
- 扩展企微审批场景业务类型:`agent_distribution_approval`、`withdrawal_qualification_approval`、`commission_withdrawal_approval`。
- 提现交互约束:资格替换合同/法人身份证后旧资格失效需重新审批;提现仅在有效资格且余额充足时可提交,否则不冻结、不建单。
- 不实现后端接口、数据库、企微回调;不实现 C 端(客户)登录体系。
## Impact
- Affected specs: `agent-distribution-registration`、`shop-management`、`commission-management`、`wecom-scenes`
- Affected code: `src/api/modules/agentDistribution.ts`、`src/api/modules/commission.ts`、`src/types/api/shop.ts`、`src/types/api/commission.ts`、`src/types/api/wecom.ts`、`src/router/routes/staticRoutes.ts`、`src/router/guards/permission.ts`、`src/views/agent-registration/index.vue`、`src/views/shop-management/detail/index.vue`、`src/views/commission-management/my-commission/index.vue`、`src/views/settings/wecom/scenes/index.vue`
- Dependencies: `docs/产品迭代8月份/frontend-api-simple.md`

View File

@@ -0,0 +1,61 @@
## ADDED Requirements
### Requirement: 独立代理注册页免登录访问
代理扫码分销注册页 MUST 独立于登录态提供,未登录可访问,且挂在后台项目内(H5 与 PC 共用同一套表单);注册流程 MUST NOT 复用当前登录态。
#### Scenario: 未登录访问注册页
- **GIVEN** 用户未登录并通过扫码或直接访问注册入口
- **WHEN** 其打开注册页面
- **THEN** 页面 MUST 正常渲染注册表单
- **AND** MUST NOT 跳转到登录页
#### Scenario: 已登录用户访问注册页
- **GIVEN** 用户已登录后台
- **WHEN** 其打开注册页面
- **THEN** 注册流程 MUST 不携带登录态
### Requirement: 发送短信验证码
注册页 MUST 调用 `POST /api/c/v1/auth/send-code` 发送验证码,请求体 `{ phone, scene }`(`scene` 为 `bind_phone`),响应 `data.cooldown_seconds` MUST 用于 60 秒倒计时;请求 MUST 不携带 Token。
#### Scenario: 发送验证码并倒计时
- **GIVEN** 用户输入手机号
- **WHEN** 其点击获取验证码
- **THEN** 系统 MUST 调用发送验证码接口
- **AND** 按钮 MUST 进入 60 秒倒计时且不可重复点击
#### Scenario: 注册失败后不复用验证码
- **GIVEN** 一次注册提交失败
- **WHEN** 用户再次尝试注册
- **THEN** 页面 MUST 提示重新获取验证码
- **AND** MUST NOT 复用已消费的验证码
### Requirement: 代理扫码注册提交
注册页 MUST 调用 `POST /api/c/v1/agent-distribution-registrations` 提交注册,必填 `distribution_code`(扫码自动带)、`phone`、`code`、`password`、`shop_name`、`shop_code`、`username`,选填 `contact_name`、`province`、`city`、`district`、`address`;成功响应为「待审批」,前端 MUST 展示待审批结束页且不自动登录。
#### Scenario: 注册成功进入待审批
- **GIVEN** 用户填写完整表单并通过校验
- **WHEN** 其提交注册
- **THEN** 系统 MUST 调用注册接口
- **AND** 成功时 MUST 展示「待审批,审核结果将通知你」结束页
- **AND** MUST NOT 发放账号凭证或自动登录
#### Scenario: 注册失败统一提示
- **GIVEN** 注册提交失败(无效分销码、上级停用、验证码无效或已消费等)
- **WHEN** 注册接口返回失败
- **THEN** 页面 MUST 统一提示「分销码不可用」
- **AND** MUST NOT 根据错误文案区分原因
### Requirement: 表单适配与敏感项处理
注册表单 MUST 同时适配手机 H5 与 PC:H5 单列、大触控区、软键盘友好、地址使用级联选择器;PC 使用居中卡片或两列布局且字段一致。密码输入 MUST 掩码并展示强度提示;页面 MUST NOT 展示除手机号外的完整个人敏感信息。
#### Scenario: H5 与 PC 同一表单
- **GIVEN** 用户分别在手机与 PC 打开注册页
- **WHEN** 其填写注册信息
- **THEN** 两端的字段集合 MUST 一致
- **AND** 布局 MUST 按端侧自适应
#### Scenario: 密码强度与掩码
- **GIVEN** 用户在密码输入框输入
- **WHEN** 其提交表单
- **THEN** 输入 MUST 为掩码展示
- **AND** MUST 展示密码强度提示

View File

@@ -0,0 +1,61 @@
## ADDED Requirements
### Requirement: 提交/替换提现资料资格
代理本人 MUST 能提交或替换提现资料资格,调用 `POST /api/admin/shops/{shop_id}/withdrawal-qualifications`,请求体包含 `subject_type`、`subject_code`、`legal_person_id_card` 与合同、身份证正反面、营业执照、门头照、发票等 `*_file_key`,以及 `invoice_title`、`invoice_subject_code`;附件 MUST 先通过对象存储上传接口取得 `file_key` 再提交。
#### Scenario: 提交资格成功
- **GIVEN** 代理本人已登录并选好主体类型
- **WHEN** 其上传资料并提交
- **THEN** 前端 MUST 先取得全部附件 `file_key`
- **AND** 再调用提交接口并在成功后刷新资格列表
#### Scenario: 替换资格使旧资格失效
- **GIVEN** 已存在通过审批的资格
- **WHEN** 代理提交合同或法人身份证变更
- **THEN** 旧资格 MUST 立即失效
- **AND** 新资格 MUST 重新审批通过后方可提现
### Requirement: 查询提现资料资格
代理本人 MUST 能分页查询提现资料资格,调用 `GET /api/admin/shops/{shop_id}/withdrawal-qualifications`(`page` / `page_size` / `status`);响应 MUST 展示脱敏的 `subject_code_masked` 与 `legal_person_id_card_masked`,并展示 `status`、`approval_status`、`invalid_reason`、`invalidated_at` 与各附件 `file_key` 预览。
#### Scenario: 查看资格版本与审批状态
- **GIVEN** 代理本人打开提现资料资格列表
- **WHEN** 接口返回资格记录
- **THEN** 列表 MUST 展示脱敏证件号与审批状态
- **AND** 证件号 MUST NOT 以明文展示
### Requirement: 作废提现资料资格
超级管理员 MUST 能作废提现资料资格,调用 `POST /api/admin/withdrawal-qualifications/{id}/void`,`reason` 必填。
#### Scenario: 作废资格须填原因
- **GIVEN** 超级管理员打开作废弹窗
- **WHEN** 其未填写原因直接提交
- **THEN** 前端 MUST 阻止提交并提示填写原因
#### Scenario: 超管作废资格
- **GIVEN** 超级管理员选择一条资格
- **WHEN** 其填写原因并确认作废
- **THEN** 系统 MUST 调用作废接口并在成功后刷新列表
### Requirement: 重提被驳回的提现
代理本人 MUST 能重提被驳回的提现,调用 `PUT /api/admin/shops/{shop_id}/withdrawal-requests/{id}`,请求体包含 `account_name`、`account_number`、`amount`、`withdrawal_method` 与 `invoice_keys`;成功响应返回新提现单(`withdrawal_no`、`actual_amount`、`fee`、`fee_rate`、`status`)。
#### Scenario: 重提被驳回的提现
- **GIVEN** 代理本人的提现申请被驳回
- **WHEN** 其修改信息并重新提交
- **THEN** 系统 MUST 调用重提接口
- **AND** 成功后 MUST 刷新提现记录并展示新单号
#### Scenario: 非驳回状态不可重提
- **GIVEN** 提现申请不是被驳回状态
- **WHEN** 代理尝试重提
- **THEN** 重提入口 MUST 不可用或不展示
### Requirement: 提现申请详情
代理本人 MUST 能查看提现申请详情,调用 `GET /api/admin/shops/{shop_id}/withdrawal-requests/{id}`;响应包含 `reject_reason`、`anomaly_flag`、`anomaly_name`、`anomaly_reason` 与 `attempts` 尝试记录,前端 MUST 展示这些字段。
#### Scenario: 查看提现详情
- **GIVEN** 代理本人点击提现记录
- **WHEN** 详情返回
- **THEN** 页面 MUST 展示提现金额、实际到账、手续费、状态
- **AND** 展示驳回原因、异常标记与尝试记录

View File

@@ -0,0 +1,15 @@
## ADDED Requirements
### Requirement: 店铺数据返回分销码
店铺列表、详情与更新接口响应 MUST 包含 `distribution_code` 字段,前端类型 MUST 覆盖该字段并在列表/详情中展示。
#### Scenario: 店铺详情展示分销码
- **GIVEN** 用户打开店铺详情页
- **WHEN** 店铺存在 `distribution_code`
- **THEN** 页面 MUST 展示分销码
- **AND** MUST 以该码生成注册入口二维码
#### Scenario: 分销码为空
- **GIVEN** 店铺尚未分配分销码
- **WHEN** 页面展示店铺信息
- **THEN** 分销码与二维码区域 MUST 展示空态(`-` 或「未分配」)

View File

@@ -0,0 +1,15 @@
## ADDED Requirements
### Requirement: 企微审批场景业务类型扩展
企微审批场景的 `business_type` MUST 支持以下枚举:`refund_approval`(退款审批)、`offline_recharge_approval`(员工线下代充值审批)、`employee_collection_approval`(员工代收款核销审批)、`agent_distribution_approval`(代理扫码分销注册审批)、`withdrawal_qualification_approval`(提现资料资格审批)、`commission_withdrawal_approval`(佣金提现终审)。前端类型与场景配置页选项 MUST 与后端枚举一致;`GET /api/admin/wecom/scenes/{business_type}/fields` 允许查询上述任一类型。
#### Scenario: 场景配置页可选新业务类型
- **GIVEN** 超级管理员打开企微审批场景配置页
- **WHEN** 其新建场景并选择业务类型
- **THEN** 下拉选项 MUST 包含全部六个业务类型
- **AND** 新增三个业务类型 MUST 与后端枚举一致
#### Scenario: 查询新增场景业务字段
- **GIVEN** 已选择 `agent_distribution_approval`、`withdrawal_qualification_approval` 或 `commission_withdrawal_approval`
- **WHEN** 页面加载业务字段
- **THEN** 前端 MUST 调用对应 `business_type` 的字段查询接口

View File

@@ -0,0 +1,29 @@
## 1. 提案与 API 层
- [x] 1.1 新增 `src/api/modules/agentDistribution.ts`:`sendCode()` 与 `registerAgent()`,公开请求不带 Token
- [x] 1.2 扩展 `src/types/api/shop.ts`:`ShopResponse` 增加 `distribution_code`
- [x] 1.3 扩展 `src/types/api/commission.ts`:提现资料资格提交/查询、作废、重提、详情的请求与响应类型
- [x] 1.4 扩展 `src/api/modules/commission.ts`:`submitWithdrawalQualification` / `getWithdrawalQualifications` / `voidWithdrawalQualification` / `resubmitWithdrawalRequest` / `getWithdrawalRequestDetail`
- [x] 1.5 扩展 `src/types/api/wecom.ts`:`WecomBusinessType` 增加三个业务类型
- [x] 1.6 汇总导出新增类型
## 2. 企微审批场景
- [x] 2.1 场景配置页新增三个业务类型选项(`agent_distribution_approval` / `withdrawal_qualification_approval` / `commission_withdrawal_approval`)
## 3. 独立注册页
- [x] 3.1 `staticRoutes.ts` 新增 `/agent-registration` 静态路由
- [x] 3.2 `LOGIN_WHITE_LIST` 增加注册页路径
- [x] 3.3 新增 `src/views/agent-registration/index.vue`:表单、验证码倒计时、密码强度、省市区级联、提交与结束页、H5/PC 响应式
## 4. 店铺详情
- [x] 4.1 店铺详情页展示 `distribution_code` 与注册二维码
## 5. 我的佣金(代理侧)
- [x] 5.1 新增「提现资料资格」Tab:资格列表(脱敏展示)+ 提交/替换弹窗(附件走上传接口)
- [x] 5.2 提现记录新增「详情」抽屉:展示明细、驳回原因、异常标记与尝试记录
- [x] 5.3 被驳回记录新增「重新提交」弹窗(PUT 重提)
- [x] 5.4 超管可见「作废资格」操作(reason 必填)
## 6. 验证
- [x] 6.1 运行 `npm run build`(含 `vue-tsc --noEmit`)
- [x] 6.2 运行 `npm run check:encoding`
- [x] 6.3 运行 `openspec.cmd validate add-agent-distribution-registration-and-withdrawal --strict`

View File

@@ -0,0 +1,16 @@
## Context
代理注册申请由公开注册接口创建,后台需要按数据范围查询申请并展示审批提交状态。恢复审批只恢复原企业微信审批提交,不创建新的注册申请或审批实例。
## Decisions
- 使用列表页 + 独立详情页,详情页 URL 为 `/shop-management/agent-distribution-registrations/detail/:id`。
- 列表和详情均使用后端返回的 `status`、`approval_status`、`submission_status` 和名称字段,不在前端推导状态。
- 恢复按钮仅由后端返回的 `recoverable` 控制,并使用独立 `agent_distribution_registration:recover_approval` 权限。
- 详情响应直接消费后端完整手机号和注册地址,不展示密码或内部审批字段。
## Risks / Mitigations
- 状态可能在列表与详情之间发生变化 → 详情和恢复成功/失败后重新加载后端数据。
- 恢复请求并发冲突 → 后端返回错误时提示并刷新详情,不做乐观更新。
- 手机号属于敏感业务数据 → 页面仅受注册申请列表/详情权限和后端数据范围控制。

View File

@@ -0,0 +1,31 @@
# Change: 增加代理注册申请后台管理
## Why
后台目前无法查看代理扫码注册申请,也无法处理企业微信审批提交失败或结果未知的注册申请。根据 `docs/产品迭代8月份/代理注册管理.md`,需要提供申请列表、详情和恢复原审批提交入口。
## What Changes
- 新增后台代理注册申请列表页,支持状态、申请/决定时间、手机号、关键字、直接上级店铺和提交异常筛选。
- 新增注册申请详情页,展示完整手机号、注册地址、申请店铺、分销码、业务状态、审批状态和企微提交状态。
- 当 `recoverable = true` 时显示“恢复审批”,调用 `POST /api/admin/agent-distribution-registrations/{id}/recover-approval`,成功后刷新详情。
- 新增代理注册申请 API、类型、路由和权限编码。
- 权限编码:列表 `agent_distribution_registration:list`、详情 `agent_distribution_registration:detail`、恢复审批 `agent_distribution_registration:recover_approval`。
## Impact
- Affected specs: `agent-distribution-registration`
- Affected code:
- `src/api/modules/agentDistribution.ts`
- `src/types/api/agentDistribution.ts`
- `src/config/constants/augustIteration.ts`
- `src/router/routesAlias.ts`
- `src/router/routes/asyncRoutes.ts`
- `src/views/shop-management/agent-distribution-registrations/index.vue`
- `src/views/shop-management/agent-distribution-registrations/detail.vue`
- `src/locales/langs/zh.json`
- `docs/权限.md`
- Out of scope:
- C 端注册流程和代理登录流程。
- 后端审批、数据库和企业微信回调实现。
- 修改注册申请业务资料或审批结果。

View File

@@ -0,0 +1,33 @@
## ADDED Requirements
### Requirement: Agent Registration Application List
The admin frontend SHALL provide a paginated agent registration application list with the documented filters and backend response statuses.
#### Scenario: Filter registration applications
- **WHEN** an authorized user selects status, time, phone, keyword, parent shop, or submission anomaly filters
- **THEN** the frontend MUST send those filters to `GET /api/admin/agent-distribution-registrations`
- **AND** the list MUST display business, approval, and submission status names from the response
### Requirement: Agent Registration Application Detail
The admin frontend SHALL provide a detail page for `GET /api/admin/agent-distribution-registrations/{id}` and display the complete registration information returned by the backend.
#### Scenario: Open registration detail
- **WHEN** an authorized user opens a registration application
- **THEN** the frontend MUST request the application detail by ID
- **AND** MUST display the phone, address, shop, distribution code, business status, approval status, and submission status
- **AND** MUST NOT display password or internal approval fields not present in the response
### Requirement: Recover Agent Registration Approval
The frontend SHALL expose `POST /api/admin/agent-distribution-registrations/{id}/recover-approval` only when `recoverable = true` and the user has the recovery permission.
#### Scenario: Recover approval
- **GIVEN** a registration response has `recoverable = true`
- **WHEN** the user confirms “恢复审批”
- **THEN** the frontend MUST call the recovery endpoint with only the registration ID
- **AND** MUST refresh the detail after success or a state conflict

View File

@@ -0,0 +1,17 @@
## 1. API And Types
- [x] 1.1 增加代理注册申请列表、详情和恢复审批 TypeScript 类型。
- [x] 1.2 扩展 `AgentDistributionService`:列表、详情、恢复审批接口。
- [x] 1.3 增加唯一权限常量 `list`、`detail`、`recoverApproval`。
## 2. Pages And Routes
- [x] 2.1 新增注册申请列表页和筛选条件。
- [x] 2.2 新增详情页和审批/提交状态展示。
- [x] 2.3 接入“恢复审批”按钮、确认、错误提示和刷新。
- [x] 2.4 增加店铺管理下的列表/详情路由与中英文菜单文案。
## 3. Documentation And Verification
- [x] 3.1 将页面、详情和恢复审批权限写入 `docs/权限.md`。
- [x] 3.2 运行类型检查、lint、编码检查、构建和 OpenSpec 校验。

View File

@@ -0,0 +1,39 @@
# Change: 新增资产钱包自动续费配置(后台查询/保存 + 自动续费失败通知适配)
## Why
根据 `docs/产品迭代8月份/资产钱包.md`。后端测试环境(`https://cmp-api.boss160.cn`,`Authorization: Bearer <token>`)已提供资产钱包自动续费全局配置能力,仅有 2 个后台接口,H5 侧零新增:
- 查询资产钱包自动续费配置:`GET /api/admin/asset-auto-renewal-config`
- 保存资产钱包自动续费配置:`PUT /api/admin/asset-auto-renewal-config`
后台需要提供配置页面承载总开关、适用范围、指定主套餐、到期前天数等配置;同时新增通知类型 `asset.auto_renewal.failed` 会复用既有通知接口产生新数据,需要适配展示与跳转。
## What Changes
- 新增能力 `asset-wallet-auto-renewal`:
- 配置读取:`GET /api/admin/asset-auto-renewal-config`,返回唯一一份全局配置的 `enabled`+`enabled_name`、`scope`+`scope_name`、`package_ids`、`days_before_expiry`、`config_version`、`updater`、`updated_at`。
- 配置保存:`PUT /api/admin/asset-auto-renewal-config`:
- 请求体 `{ enabled(0/1,必填), scope(all|specified,必填), package_ids(uint[],仅 specified 时非空且只能选当前可售主套餐), days_before_expiry(1–90,必填) }`。
- 语义:单行配置、无新增/删除;保存即递增 `config_version`,记录操作者与前后值快照;配置变更只影响后续扫描,历史记录不重算。
- 权限:仅超级管理员与平台账号可访问;其他身份(代理/企业/个人客户)`403`,提示「无权限操作该资源或资源不存在」,无权限与不存在不区分。
- 通知适配(复用既有接口,不算新接口):
- 后台站内通知:新增通知类型 `asset.auto_renewal.failed`(类别 `expiry`、级别 `warning`),接收人是业务员/店铺账号。走既有 `GET /api/admin/notifications` + `GET /api/admin/notifications/{id}/target`;确认 `target_type` 的 `iot_card` / `device` 在导航白名单;`available=false` 时只显示正文不跳转;计入未读数。
- H5 个人客户通知:同一类型已由后端加入客户可见白名单,出现在既有 `GET /api/c/v1/notifications` 与 `unread-count`,客户侧只有文案(资产标识、套餐、原因、到期日),无跳转接口、无需新页面,本仓库无需改动。该类型属 `expiry` 类别,展示期以业务到期时间为准,套餐到期后从列表消失(既有类别行为)。
- 明确不做(避免前端空等):无自动续费记录页/异常记录页接口、无尝试记录查询接口、无「有余额就不停机」开关、无 H5 客户侧新接口。
## Impact
- Affected specs:
- `asset-wallet-auto-renewal` — 新增能力
- Affected code:
- `src/types/api/assetWallet.ts`(新增)
- `src/types/api/index.ts`
- `src/api/modules/assetWallet.ts`(新增)
- `src/api/modules/index.ts`
- `src/views/settings/asset-wallet-auto-renewal/index.vue`(新增)
- `src/router/routesAlias.ts`
- `src/router/routes/asyncRoutes.ts`
- `src/utils/business/notificationNavigation.ts`(确认/补充 `iot_card`、`device` 白名单)
- `src/components/core/layouts/art-notification/index.vue`(确认 `expiry` 分类覆盖新类型)
- `src/locales/langs/zh.json`、`src/locales/langs/en.json`

View File

@@ -0,0 +1,94 @@
## ADDED Requirements
### Requirement: 自动续费配置查询
The admin frontend SHALL load the single global asset wallet auto-renewal configuration through `GET /api/admin/asset-auto-renewal-config`. 响应字段 SHALL 包含并展示 `enabled`+`enabled_name`、`scope`+`scope_name`、`package_ids`、`days_before_expiry`、`config_version`、`updater`、`updated_at`。
#### Scenario: 读取全局自动续费配置
- **WHEN** 用户进入资产钱包自动续费配置页面
- **THEN** 前端 MUST 调用 `GET /api/admin/asset-auto-renewal-config`
- **AND** 页面 MUST 展示总开关及中文名称、适用范围及中文名称、指定主套餐集合、统一到期前天数、配置版本、最近保存操作者与最近保存时间
### Requirement: 自动续费配置保存
The admin frontend SHALL save the configuration through `PUT /api/admin/asset-auto-renewal-config` with request body `{ enabled, scope, package_ids, days_before_expiry }`。`enabled` SHALL 取值 0/1 且必填;`scope` SHALL 取值 `all`(全部主套餐)或 `specified`(指定主套餐)且必填;`package_ids` 仅在 `scope=specified` 时必填非空且只能选择当前可售主套餐;`days_before_expiry` SHALL 取值 1 至 90 且必填。配置为单行、无新增/删除;保存 SHALL 递增 `config_version` 并记录操作者与前后值快照;配置变更 SHALL 只影响后续扫描,历史记录不重算。
#### Scenario: 保存全部主套餐范围配置
- **WHEN** 用户设置适用范围为「全部主套餐」并提交
- **THEN** 前端 MUST 调用 `PUT /api/admin/asset-auto-renewal-config`
- **AND** 请求体携带 `enabled`、`scope=all`、`days_before_expiry`
- **AND** `package_ids` 以空数组提交
- **AND** 保存成功后页面 MUST 以响应中的 `config_version`、`updater`、`updated_at` 刷新展示
#### Scenario: 保存指定主套餐范围配置
- **WHEN** 用户设置适用范围为「指定主套餐」并选择若干当前可售主套餐后提交
- **THEN** `package_ids` MUST 非空且只包含当前可售主套餐
- **AND** 前端 MUST 携带 `scope=specified` 与非空 `package_ids` 提交
#### Scenario: 参数校验
- **WHEN** `enabled` 缺失、`scope` 非法、`scope=specified` 时 `package_ids` 为空或包含不可售套餐,或 `days_before_expiry` 超出 1–90
- **THEN** 前端 MUST 阻止提交并给出校验提示
#### Scenario: 仅影响后续扫描
- **WHEN** 用户修改并保存配置
- **THEN** 历史自动续费记录 MUST NOT 被重算
- **AND** 新配置 MUST 只对保存后的扫描生效
### Requirement: 自动续费配置访问权限
Only super admin and platform accounts SHALL be allowed to query or save the asset wallet auto-renewal configuration. 代理、企业与个人客户等身份访问时 SHALL 返回 `403` 并提示「无权限操作该资源或资源不存在」;无权限与不存在的表现 MUST NOT 可区分。
#### Scenario: 授权访问
- **WHEN** 超级管理员或平台账号访问配置接口
- **THEN** 页面 MUST 正常查询与保存配置
#### Scenario: 无权限访问
- **WHEN** 代理、企业或个人客户账号访问配置接口
- **THEN** 页面 MUST 按 `403` 无权限处理并展示统一提示
- **AND** 前端 MUST NOT 通过响应区分无权限与资源不存在
### Requirement: 自动续费失败后台通知
The admin notification center SHALL display the new notification type `asset.auto_renewal.failed`(类别 `expiry`、级别 `warning`)through the existing notification APIs,接收人为业务员/店铺账号。目标 `target_type` 的 `iot_card` 与 `device` SHALL 位于通知导航白名单;当目标 `available=false` 时页面 SHALL 只展示正文且不跳转;该类型通知 SHALL 计入未读数。
#### Scenario: 展示并跳转自动续费失败通知
- **WHEN** 通知列表返回 `asset.auto_renewal.failed` 类型且目标可用
- **THEN** 通知中心 MUST 将该通知归入 `expiry` 类别展示
- **AND** 用户点击后 MUST 通过既有目标接口按 `iot_card` / `device` 跳转到对应资产详情
#### Scenario: 目标不可用
- **WHEN** 目标接口返回 `available=false`
- **THEN** 页面 MUST 只展示通知正文且不发起跳转
### Requirement: H5 客户侧通知边界
This capability SHALL NOT 新增或修改 H5 客户侧接口与页面。`asset.auto_renewal.failed` 类型已由后端加入客户可见白名单,通过既有 `GET /api/c/v1/notifications` 与 `unread-count` 返回;客户侧仅展示文案(资产标识、套餐、原因、到期日),无跳转接口、无需新页面。该类型属 `expiry` 类别,展示期以业务到期时间为准,套餐到期后从列表消失(既有类别行为)。
#### Scenario: H5 复用既有接口
- **WHEN** 客户侧通知接口返回该类型
- **THEN** 客户侧 MUST 仅展示文案且不提供跳转
- **AND** 本次变更 MUST NOT 新增 H5 客户侧接口或页面
#### Scenario: 到期展示期
- **WHEN** 对应套餐业务到期
- **THEN** 该通知按 `expiry` 类别既有行为从客户侧列表消失
### Requirement: 功能范围边界
This capability SHALL NOT 包含以下内容:自动续费记录页/异常记录页、尝试记录查询、「有余额就不停机」开关、H5 客户侧新接口。
#### Scenario: 明确不提供的功能
- **WHEN** 前端对接本次资产钱包自动续费能力
- **THEN** 页面 MUST NOT 提供或依赖自动续费记录页、异常记录页、尝试记录查询接口与「有余额就不停机」开关

View File

@@ -0,0 +1,27 @@
# Tasks: 资产钱包自动续费配置
## 1. 类型与 API
- [x] 1.1 新增 `src/types/api/assetWallet.ts`:`AssetAutoRenewalConfig`(`enabled`/`enabled_name`/`scope`/`scope_name`/`package_ids`/`days_before_expiry`/`config_version`/`updater`/`updated_at`)、`UpdateAssetAutoRenewalConfigRequest`(`enabled`/`scope`/`package_ids`/`days_before_expiry`)等类型
- [x] 1.2 `src/types/api/index.ts` 导出新类型
- [x] 1.3 新增 `src/api/modules/assetWallet.ts`:
- `getAutoRenewalConfig`:`GET /api/admin/asset-auto-renewal-config`
- `saveAutoRenewalConfig`:`PUT /api/admin/asset-auto-renewal-config`
- [x] 1.4 `src/api/modules/index.ts` 导出新服务
## 2. 配置页面
- [x] 2.1 `src/router/routesAlias.ts` 新增资产钱包自动续费配置路由别名,`src/router/routes/asyncRoutes.ts` 在设置下注册路由与菜单(仅超级管理员与平台账号可见)
- [x] 2.2 新增 `src/views/settings/asset-wallet-auto-renewal/index.vue`:读取配置并展示总开关、适用范围、指定主套餐、统一到期前天数、配置版本、最近保存操作者与时间(含 `enabled_name`/`scope_name`)
- [x] 2.3 实现保存表单:总开关(0/1)、适用范围(all/specified)、到期前天数(1–90 校验);指定范围时主套餐多选仅支持当前可售主套餐且非空
- [x] 2.4 保存成功后使用响应刷新 `config_version`、`updater`、`updated_at`,不做新增/删除记录操作
## 3. 通知适配
- [x] 3.1 确认 `src/utils/business/notificationNavigation.ts` 白名单包含 `iot_card` 与 `device`,目标可用时跳转资产详情
- [x] 3.2 确认 `src/components/core/layouts/art-notification/index.vue` 的 `expiry` 分类可展示 `asset.auto_renewal.failed`,`available=false` 时只显示正文不跳转
- [x] 3.3 确认该类型通知计入未读数与分类汇总
## 4. Verification
- [x] 4.1 验证 GET/PUT 字段传递与参数校验(enabled、scope、package_ids、days_before_expiry)
- [x] 4.2 验证指定范围时 package_ids 非空且仅可售主套餐
- [x] 4.3 验证通知类型展示、目标跳转与不可用目标处理
- [x] 4.4 验证非超级管理员/平台账号访问的 403 处理
- [x] 4.5 运行 lint、类型检查与构建

View File

@@ -20,7 +20,7 @@ The admin frontend SHALL provide a bulk purchase form that binds one uploaded ba
#### Scenario: Hide voucher upload for wallet payment #### Scenario: Hide voucher upload for wallet payment
- **GIVEN** 用户选择代理钱包支付 - **GIVEN** 用户选择代理预存款支付
- **WHEN** 页面渲染或提交批量订购表单 - **WHEN** 页面渲染或提交批量订购表单
- **THEN** 页面 MUST NOT submit a voucher file - **THEN** 页面 MUST NOT submit a voucher file
- **AND** 页面 MUST clear or ignore a voucher selected before switching to wallet payment - **AND** 页面 MUST clear or ignore a voucher selected before switching to wallet payment

View File

@@ -10,7 +10,7 @@
- [x] 2.1 新增批量订购入口和表单,支持选择代理商、支付方式和 Excel 文件。 - [x] 2.1 新增批量订购入口和表单,支持选择代理商、支付方式和 Excel 文件。
- [x] 2.2 提供前端静态 Excel 模板下载,并限制上传文件类型和必要的文件状态。 - [x] 2.2 提供前端静态 Excel 模板下载,并限制上传文件类型和必要的文件状态。
- [x] 2.3 线下支付时显示整批支付凭证上传,钱包支付时隐藏或清理凭证字段。 - [x] 2.3 线下支付时显示整批支付凭证上传,预存款支付时隐藏或清理凭证字段。
- [x] 2.4 复用订单列表已有 `VoucherUpload` 组件展示凭证上传进度,上传未完成时禁止创建任务。 - [x] 2.4 复用订单列表已有 `VoucherUpload` 组件展示凭证上传进度,上传未完成时禁止创建任务。
- [x] 2.5 创建请求携带 `shop_id`、`payment_method`、`file`、必要的 `voucher_file` 和 `request_id`。 - [x] 2.5 创建请求携带 `shop_id`、`payment_method`、`file`、必要的 `voucher_file` 和 `request_id`。
- [x] 2.6 防止重复点击和重复提交,创建成功后保存 `task_id` 并进入任务详情。 - [x] 2.6 防止重复点击和重复提交,创建成功后保存 `task_id` 并进入任务详情。

View File

@@ -0,0 +1,54 @@
# Change: 业务用户组管理与店铺批量交接/导入(AUG26-003)
## Why
后台需要把平台用户账号按业务线归入"业务用户组",并基于组对店铺做筛选、批量交接负责人与 CSV 导入负责人。当前前端只有单个店铺设置平台业务员的能力,缺少业务用户组维护、成员归属、按组筛选、批量交接与导入入口;且现有 11 个新端点仅超管与平台账号可访问。
## What Changes
- 新增业务用户组管理模块(API 层 + 维护页面 + 成员管理):
- GET/POST /api/admin/business-user-groups、GET/PUT/DELETE /api/admin/business-user-groups/{id}
- PUT /api/admin/business-user-groups/{id}/members、DELETE /api/admin/business-user-groups/members
- 编码创建后不可改;删除需 {"confirm": true} 且仅无成员组可删;更新支持部分字段,business_line 三态(缺省=不改 / ""=清空 / 枚举=设置)。
- 成员归属整批校验(全部启用平台用户 + 目标组启用),任一无效整批不生效;一账号至多一组。
- 店铺列表/详情读取侧扩展:
- GET /api/admin/shops 新增 business_user_group_id / business_line / ungrouped 筛选。
- 列表/详情响应新增 5 个只读推导字段(组 ID/编码/名称/启用/业务线);组停用仍返回组且 enabled=false(不算未分组);前端不缓存、不回写,改组后重新拉列表。
- 勾选批量交接:
- PUT /api/admin/shops/business-owner/batch:shop_ids(1-500,去重)+ business_owner_account_id;字段缺失=400,null=清空,ID=换绑;任一店铺无效或目标非启用业务员 -> 整批不写入,统一按 1005 提示。
- CSV 导入:
- 复用 StorageService.getUploadUrl + 预签名 PUT 直传(FilePurpose 增加 shop_import)。
- POST /api/admin/shops/business-owner-imports 创建异步任务,轮询详情、展示行级结果;前端自带模板(表头 店铺编码,操作类型,业务员登录账号,备注,换绑/清空)。
- 入口与权限(代理/企业不渲染入口):
- 路由 meta roles ['R_SUPER', 'R_ADMIN'];按钮权限码:
- business_user_group:page / business_user_group:create / business_user_group:update / business_user_group:delete / business_user_group:members
- shop:business_owner_batch
- shop:business_owner_import
## Not In Scope
- 不实现后端接口、不改数据库。
- 业务用户组不承载角色权限/数据范围语义;前端不引入组层级与组管理员概念。
- 导入结果不支持导出,仅在页面展示行级明细。
## Impact
- Affected specs: business-user-group-management(新增)、shop-management(扩展)
- Affected code:
- src/types/api/businessUserGroup.ts(新增)
- src/api/modules/businessUserGroup.ts(新增)
- src/types/api/shop.ts、src/api/modules/shop.ts
- src/api/modules/storage.ts(FilePurpose 增加 shop_import)
- src/views/shop-management/business-user-groups/index.vue(新增页面)
- src/views/shop-management/list/index.vue
- src/router/routes/asyncRoutes.ts、src/router/routesAlias.ts、src/locales/langs/{zh,en}.json
- src/template/批量换绑业务员模板.csv(前端自带模板)
- API contracts: 11 个端点(7 个业务用户组 + 店铺筛选/字段 + 批量交接 + 导入三步)
- Dependencies:
- docs/产品迭代8月份/业务用户组.md(7 个组端点 OpenAPI)
- AUG26-003 前端对接说明(店铺侧端点)
## 待确认
- 成员选择器复用 GET /api/admin/shops/business-owner-candidates(启用平台账号);若组成员可包含非业务员平台账号,需后端补充平台账号列表端点。
- 导入任务与行级结果字段名(file_key、status、items[] 等)以生成文档为准,提案按对接说明先行对齐。

View File

@@ -0,0 +1,73 @@
## ADDED Requirements
### Requirement: 业务用户组维护
后台 MUST 提供业务用户组列表、详情、创建、更新与删除能力(GET/POST /api/admin/business-user-groups、GET/PUT/DELETE /api/admin/business-user-groups/{id})。列表 MUST 支持 page/page_size/enabled/keyword/business_line 筛选,且每项 MUST 返回 business_line_name。创建时 code(1-64)与 name 必填,编码未删除组内唯一且创建后不可修改;business_line 可空(standard/smart/other),sort/enabled/remark 可选。更新 MUST 仅允许名称、业务线、排序、启停与备注,且 business_line 支持三态:字段缺失不修改、传 "" 清空、传枚举设置;删除 MUST 携带 {"confirm": true},仅无成员组可删除。
#### Scenario: 查询业务用户组列表
- **GIVEN** 用户进入业务用户组维护页
- **WHEN** 前端以 page/page_size/enabled/keyword/business_line 发起列表查询
- **THEN** 前端 MUST 展示分页结果且每项显示 business_line_name
- **AND** 下拉数据源复用该列表接口
#### Scenario: 创建时编码不可变
- **GIVEN** 用户填写名称与稳定编码创建用户组
- **WHEN** 提交成功或编码重复被后端拒绝
- **THEN** 编码在创建后 MUST NOT 出现在编辑表单中
- **AND** 编码重复时 MUST 展示后端返回的"业务用户组编码已存在"
#### Scenario: 业务线三态更新
- **GIVEN** 用户编辑某组的业务线
- **WHEN** 表单传 ""、传枚举或省略该字段
- **THEN** 前端 MUST 分别按"清空 / 设置 / 不修改"构造请求体
#### Scenario: 删除需二次确认
- **GIVEN** 用户点击删除某组
- **WHEN** 确认弹窗提交
- **THEN** 前端 MUST 携带 {"confirm": true}
- **AND** 有成员时 MUST 提示"用户组仍有成员,只能停用或先移走成员"且不做物理删除
- **AND** 无成员时删除成功并刷新列表
### Requirement: 成员归属批量维护
后台 MUST 支持按平台用户账号把成员批量设置进组(PUT /api/admin/business-user-groups/{id}/members)与批量清空(DELETE /api/admin/business-user-groups/members,携带 body account_ids)。两种操作 MUST 复用同一校验:所有账号必须是启用平台用户且目标组启用,任一账号无效则整批不生效;清空后账号回到未分组;一账号至多一组。
#### Scenario: 批量设置成员
- **GIVEN** 用户在成员管理中选择多个启用平台账号
- **WHEN** 保存成员归属
- **THEN** 前端 MUST 以 account_ids 数组整体替换每个账号原归属
- **AND** 刷新后成员关系与最新分组一致
#### Scenario: 批量清空成员
- **GIVEN** 用户选择若干账号执行清空
- **WHEN** 提交清空
- **THEN** 前端 MUST 调用 DELETE /api/admin/business-user-groups/members 并携带 account_ids body
- **AND** 清空成功的账号回到未分组
#### Scenario: 停用组的成员展示
- **GIVEN** 某组被停用但仍有成员
- **WHEN** 用户在成员管理或店铺列表看到该组
- **THEN** 前端 MUST 展示"已停用"标记并提供改组/清空入口
### Requirement: 访问控制与入口
业务用户组维护入口 MUST 仅对超级管理员与平台账号可见,代理/企业账号 MUST NOT 渲染入口;所有按钮 MUST 受权限码控制。
#### Scenario: 菜单按角色隐藏
- **GIVEN** 代理或企业账号登录
- **WHEN** 系统渲染菜单
- **THEN** MUST NOT 展示业务用户组菜单项
#### Scenario: 按钮权限控制
- **GIVEN** 平台账号具备部分业务用户组权限
- **WHEN** 渲染操作按钮
- **THEN** 前端 MUST 按 business_user_group:create/update/delete/members 控制显隐

View File

@@ -0,0 +1,75 @@
## ADDED Requirements
### Requirement: 店铺列表/详情业务用户组字段与筛选
店铺列表查询 MUST 支持 business_user_group_id、business_line、ungrouped 三个新筛选;列表与详情响应 MUST 提供 5 个只读推导字段:business_user_group_id(可空)、business_user_group_code、business_user_group_name、business_user_group_enabled、business_user_group_business_line。组停用仍返回组且 enabled=false(不算未分组);店铺不存组,字段实时推导,前端 MUST NOT 缓存或回写,改动组成员后重新拉取列表。
#### Scenario: 按业务用户组筛选
- **GIVEN** 用户在店铺列表选择业务用户组、业务线或勾选"未分组"
- **WHEN** 发起列表查询
- **THEN** 前端 MUST 提交 business_user_group_id/business_line/ungrouped 参数
- **AND** ungrouped=true 表示无负责人或负责人无分组
#### Scenario: 展示组字段
- **GIVEN** 店铺属于某启用或停用的业务用户组
- **WHEN** 渲染列表或详情
- **THEN** 前端 MUST 展示组名称/编码/业务线
- **AND** 组停用时 MUST 标记"已停用"且仍展示组归属
### Requirement: 勾选批量交接平台业务员
店铺列表 MUST 支持勾选店铺批量交接平台业务员(PUT /api/admin/shops/business-owner/batch,body shop_ids 1-500 去重 + business_owner_account_id)。字段缺失 MUST 按参数错误处理(400);传 null 表示清空负责人;传 ID 表示换绑。任一店铺不存在/已删除/越权或目标非启用业务员时整批不写入,前端 MUST 统一提示"无权限操作该资源或资源不存在";成功响应含 batch_key/shop_count/cleared。
#### Scenario: 批量换绑
- **GIVEN** 用户勾选 1-500 家店铺并选择启用业务员
- **WHEN** 提交批量交接
- **THEN** 前端 MUST 提交 shop_ids(去重)与 business_owner_account_id
- **AND** 成功后展示 shop_count 并刷新列表
#### Scenario: 批量清空负责人
- **GIVEN** 用户勾选店铺并选择"清空负责人"
- **WHEN** 提交批量交接
- **THEN** 前端 MUST 显式提交 business_owner_account_id: null
- **AND** MUST NOT 省略该字段
#### Scenario: 整批失败统一提示
- **GIVEN** 批量交接请求因任一店铺或目标账号不满足条件而被后端拒绝
- **WHEN** 前端收到 1005
- **THEN** 前端 MUST 展示统一文案且不写入任何店铺
### Requirement: 业务负责人 CSV 导入
店铺列表 MUST 支持通过 CSV 导入批量交接/清空业务负责人。流程 MUST 为:前端自带模板(表头 店铺编码,操作类型,业务员登录账号,备注,操作类型仅"换绑"或"清空")-> POST /api/admin/storage/upload-url(purpose=shop_import)拿预签名 URL 直传(15 分钟有效)-> POST /api/admin/shops/business-owner-imports(file_key)创建异步任务 -> 轮询 GET /api/admin/shops/business-owner-imports/{id} 展示结果。行级失败不等于任务失败:任务 status=3 也可能有失败行,MUST 按 items[] 展示明细;表头/编码不符为任务级失败,items 为空数组,只展示 error_message。
#### Scenario: 下载模板并上传
- **GIVEN** 用户进入导入界面
- **WHEN** 点击下载模板或选择文件
- **THEN** 前端 MUST 提供表头完全一致的模板文件
- **AND** 上传后 MUST 以 purpose=shop_import 获取上传地址并直传
#### Scenario: 创建任务并轮询
- **GIVEN** 文件上传成功拿到 file_key
- **WHEN** 提交创建导入任务
- **THEN** 前端 MUST 携带 file_key 调用创建接口
- **AND** MUST 轮询任务详情直到 status 为已完成(3)或失败(4)
#### Scenario: 展示行级失败明细
- **GIVEN** 任务完成但存在失败行
- **WHEN** 前端渲染结果
- **THEN** 前端 MUST 展示 total_count/success_count/fail_count
- **AND** MUST 按 items[] 展示各行的 line/shop_code/operation_type/status/reason
- **AND** 失败行保留原负责人
#### Scenario: 任务级失败提示
- **GIVEN** 表头或编码不符导致任务级失败
- **WHEN** 前端渲染结果
- **THEN** 前端 MUST 只展示 error_message 且明细为空

View File

@@ -0,0 +1,34 @@
## 1. API Contract 层
- [x] 1.1 新增 src/types/api/businessUserGroup.ts:组项/分页/创建/更新/删除/成员设置与结果类型
- [x] 1.2 新增 src/api/modules/businessUserGroup.ts:封装 7 个组端点(DELETE 带 body,需请求层支持)
- [x] 1.3 扩展 src/types/api/shop.ts:列表筛选 business_user_group_id/business_line/ungrouped,响应只读组字段,批量交接与导入任务/行级结果类型
- [x] 1.4 扩展 src/api/modules/shop.ts:batchUpdateBusinessOwner、createBusinessOwnerImport、getBusinessOwnerImportDetail、getBusinessOwnerImportList
- [x] 1.5 扩展 src/api/modules/storage.ts:FilePurpose 增加 shop_import
## 2. 业务用户组页面
- [x] 2.1 新增 src/views/shop-management/business-user-groups/index.vue:列表(筛选/分页/启停/业务线)
- [x] 2.2 新建/编辑弹窗:code 创建后不可改、business_line 三态、名称/排序/备注/启停
- [x] 2.3 删除:二次确认(confirm=true),有成员时按后端提示处理
- [x] 2.4 成员管理(对话框/抽屉):成员选择器(复用 business-owner-candidates)+ 批量设置 + 批量清空;停用组保留成员并标记"已停用"
## 3. 店铺列表扩展
- [x] 3.1 列表搜索区新增业务用户组下拉与业务线筛选、ungrouped 勾选(数据源来自组列表接口)
- [x] 3.2 列表/详情展示组字段(停用组标记,不缓存不回写)
- [x] 3.3 批量交接弹窗:勾选店铺 + 选择业务员/清空(显式 null),整批失败统一 1005 文案
- [x] 3.4 导入入口:模板下载、文件校验/上传(purpose=shop_import)、创建任务、轮询并展示行级明细
- [x] 3.5 导入任务列表(状态筛选)
## 4. 路由/菜单/权限/i18n
- [x] 4.1 新增 /shop-management/business-user-groups 路由与菜单,roles ['R_SUPER', 'R_ADMIN']
- [x] 4.2 按钮权限编码落地(business_user_group*/shop:business_owner_batch/shop:business_owner_import)
- [x] 4.3 中英文案 menus.shopManagement.businessUserGroups 等
## 5. 验证
- [x] 5.1 运行 npm run build(含 vue-tsc --noEmit)
- [x] 5.2 运行 npm run check:encoding
- [x] 5.3 运行 openspec validate add-business-user-group-management --strict

View File

@@ -0,0 +1,22 @@
## Context
现有前端没有运营商通道阈值命中记录页面或对应 API 类型。后端已提供只读分页查询接口,页面需忠实呈现不可变的命中时快照和周期恢复状态。
## Goals / Non-Goals
- Goals: 提供受限于平台账号的筛选、分页和证据查询;不丢失空值的历史语义。
- Non-Goals: 修改通道阈值、发起停复机、导出记录、查看卡片详情,或查询上游响应。
## Decisions
- Decision: 在系统管理路径下新增独立隐藏查询页,由运营商管理页提供入口;路由使用 `allowedUserTypes: [1, 2]`,页面自身也在请求前检查平台账号。
- Rationale: 接口只允许超级管理员和平台账号。前端隐藏/保护页面入口,后端仍是最终授权及卡数据范围过滤边界。
- Decision: 精确 ID 筛选使用数值输入,计费周期起点使用日期时间选择器,判定时间使用日期时间范围选择器;时间序列化为带时区 RFC3339 秒级字符串。
- Rationale: 与接口的精确匹配和闭区间语义一致,避免按日期截断或丢失时区。
- Decision: 页面仅展示响应快照,不再查询通道配置或根据当前阈值重算历史值。
- Rationale: 命中值冻结于判定时;历史缺失值必须保留接口规定的空值含义。
## Risks / Trade-offs
- 查询页不依赖后端菜单节点;前端入口仅对平台账号显示,页面路由限制用户类型,API 仍执行最终授权和数据范围过滤。
- 表格包含多列证据字段,采用现有可横向滚动的管理台表格以保持信息完整。

View File

@@ -0,0 +1,24 @@
# Change: 新增运营商通道阈值命中记录查询
## Why
达量停机与周期恢复需要可追溯的数字证据。运营人员需要查询每次停机判定时冻结的累计流量、实际阈值、计费周期、触发来源,以及周期解锁和复机结果;通道阈值后续变更不能影响历史记录。
## What Changes
- 在运营商管理页提供“通道阈值命中记录”入口,打开独立只读查询页并接入 `GET /api/admin/carrier-traffic-threshold-hits`。
- 支持按运营商通道 ID、IoT 卡 ID、计费周期起点精确匹配,并按判定时间闭区间筛选。
- 展示命中时的流量和阈值快照、判定/触发信息、锁状态、解锁时间、复机结果及安全失败原因。
- 仅超级管理员与平台账号可访问;数据范围过滤及越权资源不可区分由后端强制执行,前端不替代后端授权。
- 对接口定义的空历史值使用明确的“无”或“未处理/历史记录”展示,不发起额外的通道阈值或上游接口查询。
## Impact
- Affected specs: `carrier-traffic-threshold-hits`
- Affected code:
- `src/api/modules/carrierTrafficThresholdHit.ts`
- `src/types/api/carrierTrafficThresholdHit.ts`
- `src/views/system/carrier-traffic-threshold-hits/index.vue`
- `src/router/routesAlias.ts`, `src/router/routes/staticRoutes.ts`, `src/views/system/carrier-management/index.vue`
- `src/locales/langs/zh.json`, `src/locales/langs/en.json`
- Breaking changes: 无;仅新增只读查询接口消费与页面入口。

View File

@@ -0,0 +1,35 @@
## ADDED Requirements
### Requirement: Carrier Traffic Threshold Hit Record Query
The admin frontend SHALL provide a read-only paginated view of carrier traffic threshold hit records using `GET /api/admin/carrier-traffic-threshold-hits`.
#### Scenario: Restrict page access to platform accounts
- **GIVEN** a user is not a super administrator or platform account
- **WHEN** the user navigates to the carrier traffic threshold hit page
- **THEN** the frontend MUST deny access and MUST NOT issue the hit-record query
- **AND** backend authorization and card data-scope filtering MUST remain authoritative
#### Scenario: Filter hit records
- **GIVEN** an authorized platform user opens the hit-record page
- **WHEN** the user searches by optional carrier ID, card ID, billing period start, or judged-at time range
- **THEN** the frontend MUST send `carrier_id`, `card_id`, `period_start`, `start_time`, and `end_time` only when provided
- **AND** period and judged-at timestamps MUST be timezone-qualified RFC3339 values with second precision
- **AND** `start_time` and `end_time` MUST represent the API's inclusive time interval
#### Scenario: Display immutable hit evidence and recovery result
- **GIVEN** the query returns threshold-hit records
- **WHEN** the frontend renders the table
- **THEN** it MUST display record/card/carrier IDs, hit traffic, frozen threshold value and unit, billing period start, judged time, trigger source, lock status, unlock time, resume result, failure reason, and creation time
- **AND** it MUST NOT recompute hit traffic or threshold from current channel configuration
- **AND** it MUST display nullable historical traffic/threshold values as “无”, blank resume results as “未处理或历史记录”, and missing unlock/failure details as “无”
#### Scenario: Preserve server ordering and pagination
- **GIVEN** the user queries hit records
- **WHEN** the frontend loads or changes the page
- **THEN** it MUST send `page` and `page_size` (never exceeding 100)
- **AND** it MUST render the server-provided page, size, total, and item order without client-side re-sorting

View File

@@ -0,0 +1,10 @@
## 1. API Contract
- [x] 1.1 增加命中记录查询参数、记录项及分页响应类型。
- [x] 1.2 增加 `GET /api/admin/carrier-traffic-threshold-hits` 服务方法并统一导出。
## 2. Admin UI
- [x] 2.1 新增超级管理员/平台账号可访问的隐藏路由、运营商管理页入口及中英文标题。
- [x] 2.2 实现筛选、分页和命中/周期恢复快照表格,按接口约定展示空值。
- [x] 2.3 运行 OpenSpec 校验、ESLint 与生产构建。

View File

@@ -0,0 +1,60 @@
# Change: 退款佣金回扣改为独立回溯明细(前端适配)
## Why
后端调整了退款佣金回扣口径:退款不再把原佣金整单置为「已失效」,而是原佣金行保持「已发放」不变,另新增一条独立负数、不可提现的「回溯明细」行。对应前端接口说明(简短版)要求:
- 佣金记录列表新增 `status` 查询参数(含 5 回溯)与行级 `source` 字段(`original` / `clawback`)。
- 新增佣金记录详情接口 `GET /api/admin/shops/{shop_id}/commission-records/{id}?source=clawback`。
- 新增导出场景 `scene=commission_record`(后端已进白名单)。
- 两个必改点:列表行 key 必须用 `source + ':' + id`(原佣金与回溯 ID 空间独立,同一页会重复);渲染需支持负数金额(标红)与「不可提现」标识。
前端当前实现基于旧语义(`ShopCommissionRecordItem` 无 `source`,列表行 key 直接用 `id`,退款后原行被视为已失效),需按新口径适配。
## What Changes
- 类型层:`ShopCommissionRecordItem` 新增 `source`、`original_commission_id`、`refund_id`、`refund_no`、`withdrawable`、`clawback_records`、`clawback_total_amount`;新增回溯摘要与详情类型;`CommissionRecordQueryParams.status` 支持 5(回溯)。
- API 层:新增 `getShopCommissionRecordDetail(shopId, id, source?)`,`source` 省略时按原佣金处理。
- 列表页(代理侧「我的佣金」与管理侧「代理资金概览 > 佣金明细」):行 key 改为 `source + ':' + id`;回溯行展示「回溯」状态与「不可提现」标识;负数金额与可为负的 `balance_after` 标红;`status` 筛选项新增「回溯」;详情入口必须携带该行 `source`。
- 详情展示:原佣金详情展示 `clawback_records` 摘要与 `clawback_total_amount`;回溯详情展示来源 `original_commission`;越权/不存在统一提示「佣金明细不存在」,不做存在性判断。
- 导出:`ExportTaskScene` 增加 `commission_record`;新增导出佣金记录场景页、路由、菜单与 i18n;佣金记录列表导出入口只提交受支持的筛选 key(`shop_id` / `status` / `commission_source` / `order_no`)。
- 字段兜底:后端新增字段为 `omitempty`,前端取 `?? []` / `?? 0`,金额单位为分。
## Not In Scope
- 不实现后端接口、不改数据库、不改审批实例数据。
- 既有字段无改名/改类型;`commission-stats`、`commission-daily-stats` 口径未变,本次不动。
- 时间筛选属另一 Change(`add-export-time-filter-standards`),本次不涉及。
- 语义提醒:退款不再写 `status=4`,旧假设「退款后原行变已失效」已失效,需在文案/注释体现。
## Impact
- Affected specs: `commission-management`、`export-task-management`
- Affected code:
- `src/types/api/commission.ts`
- `src/api/modules/commission.ts`
- `src/views/commission-management/my-commission/index.vue`
- `src/views/commission-management/agent-fund-overview/index.vue`
- `src/types/api/exportTask.ts`
- `src/config/constants/exportTask.ts`
- `src/views/asset-management/export-task-management/export-commission-record/index.vue`
- `src/router/routes/asyncRoutes.ts`、`src/router/routesAlias.ts`、`src/locales/langs/{zh,en}.json`
- Dependencies:
- `docs/产品迭代8月份/frontend-api-simple.md`(后端契约)
- 后端已把 `scene=commission_record` 加入导出场景白名单
- 需确认导出场景权限编码与场景页是否必需(见 Open Questions)
- Breaking changes:
- 列表行 key 由 `id` 改为 `source + ':' + id`;未携带 `source` 的详情请求会命中原佣金行。
## 接口确认结果(来自 OpenAPI)
- 详情响应 `DtoShopCommissionRecordDetailResp`:`source`、`record`(`DtoShopCommissionRecordItem`)、`clawback_records`(仅原佣金返回)、`original_commission`(仅回溯详情返回)。
- `DtoShopCommissionRecordItem` 新增 `source`、`released_at`、`withdrawable`(boolean,nullable,仅回溯行返回且恒 false)、`original_commission_id`、`refund_id`、`refund_no`、`clawback_records`、`clawback_total_amount`。
- `DtoShopCommissionClawbackItem`:`id`、`amount`(恒负)、`balance_after`(可为负)、`original_commission_id`、`refund_id`、`refund_no`、`status`(5 回溯)、`status_name`、`withdrawable`、`created_at`。
- 详情接口越权与不存在返回同一结果,前端统一提示「佣金明细不存在」。
- 已确认需要新增「导出佣金记录」菜单页。
## 待确认(已按仓库既有约定实现,如需调整请告知)
1. 导出场景权限编码:按既有约定实现为 `export_task:commission_record_detail` / `export_task:commission_record_download`。
2. 佣金记录列表导出按钮权限:按 `agent_wallet_transaction:export` 的同级约定实现为 `commission_record:export`。

View File

@@ -0,0 +1,48 @@
## ADDED Requirements
### Requirement: 佣金记录列表回溯行与状态筛选
佣金记录列表(`GET /api/admin/shops/{shop_id}/commission-records`)MUST 支持 `status` 查询参数(1 已冻结 / 2 解冻中 / 3 已发放 / 4 已失效 / 5 回溯 / 99 待人工修正),且 MUST NOT 提供 `source` 查询参数;`status=5` 即等价于只看回溯行。
#### Scenario: 只看回溯行
- **GIVEN** 用户在佣金记录列表选择状态「回溯」
- **WHEN** 前端发起列表查询
- **THEN** 前端 MUST 只传 `status=5`
- **AND** 前端 MUST NOT 传 `source` 参数
### Requirement: 佣金记录行新增字段与兜底
列表响应的每一行 MUST 支持 `source`(`original` / `clawback`);回溯行 MUST 支持 `original_commission_id`、`refund_id`、`refund_no`、`withdrawable`(恒 `false`)与可为负数的 `amount`、`balance_after`;原佣金行 MUST 支持 `clawback_records` 摘要与 `clawback_total_amount`(负值)。后端 `omitempty` 缺省字段前端 MUST 以 `?? []` / `?? 0` 兜底,金额单位为分。
#### Scenario: 缺省字段兜底
- **GIVEN** 列表响应中的原佣金行未返回 `clawback_records`
- **WHEN** 前端渲染该行
- **THEN** 前端 MUST 按空数组处理并正常渲染
- **AND** 前端 MUST NOT 因缺省字段报错或渲染 `undefined`
### Requirement: 列表行标识与负数渲染
列表 MUST 使用 `source + ':' + id` 作为行 key(原佣金与回溯 ID 空间独立,同一页可能出现相同 `id`);回溯行 MUST 展示「不可提现」标识;负数 `amount` 与 `balance_after` MUST 标红显示;任何跳转详情的入口 MUST 携带该行的 `source`,缺省按原佣金处理。
#### Scenario: 同一页出现重复 id
- **GIVEN** 同一页列表中同时存在原佣金行与回溯行且 `id` 相同
- **WHEN** 前端渲染表格
- **THEN** 前端 MUST 以 `source + ':' + id` 区分两行
- **AND** 前端 MUST NOT 出现行复用或渲染错位
#### Scenario: 负数金额标红
- **GIVEN** 某回溯行 `amount` 为负值
- **WHEN** 前端渲染金额列
- **THEN** 前端 MUST 标红展示该负值
### Requirement: 佣金记录详情接口封装
前端 MUST 提供 `GET /api/admin/shops/{shop_id}/commission-records/{id}` 的详情封装,并支持可选 `source`:`source=clawback` 时返回回溯详情,`source` 省略时按原佣金处理。原佣金详情 MUST 返回 `clawback_records`;回溯详情 MUST 返回 `original_commission`;越权与不存在 MUST 返回同一结果(佣金明细不存在),前端 MUST NOT 用该接口做存在性判断。
#### Scenario: 打开回溯行详情
- **GIVEN** 用户在列表点击某条回溯行
- **WHEN** 前端请求详情
- **THEN** 前端 MUST 携带 `source=clawback` 与该行 `id`
- **AND** 详情 MUST 展示来源 `original_commission`
#### Scenario: 越权统一提示
- **GIVEN** 详情接口返回「佣金明细不存在」
- **WHEN** 前端渲染详情
- **THEN** 前端 MUST 展示统一不存在提示
- **AND** 前端 MUST NOT 区分越权与不存在两种原因

View File

@@ -0,0 +1,19 @@
## ADDED Requirements
### Requirement: 佣金记录导出场景
前端 MUST 支持导出场景 `scene=commission_record`(后端已进白名单),并在导出管理中提供该场景的任务列表入口;创建导出任务时 MUST 提交固定 `scene=commission_record`。导出粒度为佣金记录:原佣金与回溯各占一行,金额与余额同样按分转元、负数带 `-` 展示。
#### Scenario: 场景页固定查询
- **GIVEN** 用户打开导出佣金记录页面
- **WHEN** 页面查询导出任务列表
- **THEN** 前端 MUST 调用 `GET /api/admin/export-tasks` 且带 `scene=commission_record`
- **AND** 用户 MUST NOT 能在该页面切换到其他场景
### Requirement: 佣金记录导出筛选受限
佣金记录列表发起导出时,`query` MUST 只包含后端支持的筛选 key:`shop_id`、`status`、`commission_source`、`order_no`;MUST NOT 提交 `iccid`、`virtual_no` 及时间筛选,导出弹窗 MUST NOT 直接复用列表全部条件。
#### Scenario: 列表筛选含不支持的 key
- **GIVEN** 佣金记录列表当前筛选包含 `iccid` 与时间范围
- **WHEN** 用户确认创建导出任务
- **THEN** 提交的 `query` MUST NOT 包含 `iccid`、`virtual_no` 或时间字段
- **AND** 提交的 `query` MUST 仅保留 `shop_id`、`status`、`commission_source`、`order_no` 中已填写的项

View File

@@ -0,0 +1,27 @@
## 1. 类型与 API 层(commission-api)
- [x] 1.1 `CommissionStatus` 补充 5(回溯);修正 `CommissionRecordQueryParams.status` 过期注释并支持回溯值
- [x] 1.2 `ShopCommissionRecordItem` 新增 `source`、`original_commission_id`、`refund_id`、`refund_no`、`withdrawable`、`clawback_records`、`clawback_total_amount`
- [x] 1.3 新增回溯摘要与佣金记录详情类型(原佣金详情含 `clawback_records`,回溯详情含 `original_commission`)
- [x] 1.4 `CommissionService` 新增 `getShopCommissionRecordDetail(shopId, id, source?)`
## 2. 列表页(commission-records-list)
- [x] 2.1 行 key 改为 `source + ':' + id`(`my-commission` 与 `agent-fund-overview` 佣金明细)
- [x] 2.2 回溯行展示「回溯」状态与「不可提现」标识
- [x] 2.3 负数金额与可为负的 `balance_after` 标红渲染
- [x] 2.4 `status` 筛选项新增「回溯」
- [x] 2.5 列表新增详情入口,且请求必须携带该行 `source`
## 3. 详情展示(commission-record-detail)
- [x] 3.1 原佣金详情展示 `clawback_records` 摘要与 `clawback_total_amount`
- [x] 3.2 回溯详情展示来源 `original_commission`
- [x] 3.3 越权/不存在统一提示「佣金明细不存在」,不作为存在性判断依据
## 4. 导出(commission-record-export)
- [x] 4.1 `ExportTaskScene` 增加 `commission_record` 并补场景配置
- [x] 4.2 新增导出佣金记录场景页、路由、菜单与中英文案
- [x] 4.3 佣金记录列表新增导出入口,`query` 仅提交 `shop_id` / `status` / `commission_source` / `order_no`
## 5. 验证
- [x] 5.1 运行 `npm run build`(含 `vue-tsc --noEmit`)
- [x] 5.2 运行 `npm run check:encoding`
- [x] 5.3 运行 `openspec.cmd validate add-commission-clawback-records --strict`

View File

@@ -24,7 +24,7 @@ The system SHALL provide a paginated list of all commission withdrawal requests
### Requirement: Withdrawal Request Approval ### Requirement: Withdrawal Request Approval
The system SHALL allow administrators to approve withdrawal requests using the approval API contract. The administrator SHALL enter the remark manually, and the system SHALL submit the request's account name, account number, amount, and withdrawal method from the selected list item together with the manual payment type. The system SHALL allow administrators to approve withdrawal requests.
#### Scenario: Approve withdrawal request #### Scenario: Approve withdrawal request
@@ -32,13 +32,6 @@ The system SHALL allow administrators to approve withdrawal requests using the a
- **THEN** the system marks the request as approved - **THEN** the system marks the request as approved
- **AND** updates the processor information and timestamp - **AND** updates the processor information and timestamp
#### Scenario: Submit approval details
- **WHEN** administrator confirms approval after optionally entering a remark
- **THEN** the system submits the selected request's account name, account number, amount, and withdrawal method with `payment_type` set to `manual`
- **AND** submits the manually entered remark
- **AND** refreshes the list after a successful response
### Requirement: Withdrawal Request Rejection ### Requirement: Withdrawal Request Rejection
The system SHALL allow administrators to reject withdrawal requests with a reason. The system SHALL allow administrators to reject withdrawal requests with a reason.

View File

@@ -41,7 +41,6 @@
- [x] 5.6 Implement approve action with confirmation dialog - [x] 5.6 Implement approve action with confirmation dialog
- [x] 5.7 Implement reject action with reason input dialog - [x] 5.7 Implement reject action with reason input dialog
- [x] 5.8 Add status badges using unified status components - [x] 5.8 Add status badges using unified status components
- [x] 5.9 Submit approval request details from the selected list item and collect a manual remark
## 6. Withdrawal Settings Module ## 6. Withdrawal Settings Module

View File

@@ -0,0 +1,88 @@
## Context
员工代收款是 8 月迭代新增的财务能力,普通员工与超级管理员共用同一套接口,靠登录态区分数据范围。后台管理端需要新增三类页面,并复用已有的表格、搜索、详情与上传组件。`docs/admin-openapi.yaml` 未随仓库提供,接口字段以后端契约(需求文档 + 创建订单接口 OpenAPI 片段)为准,类型集中在一个文件便于联调收敛。
## Goals / Non-Goals
**Goals**
- 在财务管理下提供收款方式、员工代收款账单、核销申请三类页面。
- 复用 `ArtTableFullScreen`、`ArtSearchBar`、`ArtTableHeader`、`ArtTable`、`DetailPage`、`VoucherUpload`、`PaymentVoucherDialog`、`useCheckedColumns` 等既有组件与约定。
- 复用既有企微审批场景配置能力,仅新增业务类型。
**Non-Goals**
- 不实现后端接口、数据库、Worker、企微回调。
- 不实现 H5/C 端页面与支付流程。
- 不新增导出任务场景(需求文档未要求)。
## Decisions
### 接口契约
| 能力 | 关键字段 |
|---|---|
| 统一响应 | `{ code, data, msg, timestamp }` |
| 列表分页 | 账单列表返回 `{ items, total, page, size }`,取数处对 `items` / `list` / `records` 做兼容 |
| 收款方式 | `{ id, code, name, sort, enabled, remark, created_at, updated_at }`,列表接口返回 `{ items, page, size, total }`,支持 `page` / `page_size` / `enabled` / `keyword` 筛选 |
| 账单列表项 | `{ id, source_type, source_type_name, source_no, debtor_snapshot, customer_snapshot, receivable_amount, received_amount, reserved_amount, remaining_amount, status, status_name, approval_pending, closed_reason, created_at, updated_at }` |
| 账单详情 | `data` 为 `{ bill, refunds, allocations, applications }`;`refunds` 为退款冲销(`refund_id`、`source_order_id`、`refund_amount`、`reduced_amount`、`bill_receivable_amount`、`outcome_name`),`allocations` 为账单侧分摊(含 `application_id` / `application_status_name` / `attempt_id`),`applications` 内嵌该申请的 `attempts` |
| 账单统计 | `{ receivable_total, received_total, unsettled_total, pending_bill_count }` |
| 账单筛选 | `page`、`page_size`、`source_type`、`source_no`、`status`、`debtor_account_id`、`customer_id`、`created_from`(`YYYY-MM-DD`)、`created_to`(`YYYY-MM-DD`) |
| 核销申请请求体 | `{ payment_method_id, paid_amount, paid_at, payer_name, external_transaction_no, payment_voucher_keys, remark, allocations: [{ bill_id, amount }], acting_reason }` |
| 核销申请列表项 | `{ id, applicant_account_id, acting_operator_id, payment_method_id, payment_method_name, paid_amount, payer_name, external_transaction_no, status, status_name, terminal_reason, decided_at, created_at, updated_at }` |
| 核销申请详情 | `data` 为 `{ application, allocations, attempts }`,`attempts` 保存每次提交的完整材料快照,重新提交不清空历史 |
账单状态为数字枚举 `0` 待核销 / `1` 部分核销 / `2` 已核销 / `3` 已关闭;申请状态为数字枚举 `0` 审批中 / `1` 已通过 / `2` 已驳回 / `3` 已撤销或已关闭;两者展示均优先使用后端 `status_name`。
### 页面与路由组织
在 `/finance` 下新增:
| 路由 | 页面 | 说明 |
|---|---|---|
| `/finance/employee-collection/bills` | 员工代收款账单 | 统计 + 列表 |
| `/finance/employee-collection/bills/detail/:id` | 账单详情 | 隐藏菜单 |
| `/finance/employee-collection/applications` | 核销申请 | 列表 + 创建 |
| `/finance/employee-collection/applications/detail/:id` | 核销申请详情 | 隐藏菜单 |
| `/finance/employee-collection/payment-methods` | 收款方式管理 | 仅超管 |
账单与申请拆分为独立菜单,符合项目「列表页 + 详情页」的既有组织方式,避免单页堆叠过多交互。账单列表的「店铺」筛选用远程搜索复用 `ShopService.getShops`,与退款列表一致。
账单详情与核销申请详情保持只读:页面只在顶部保留「返回」导航,创建核销申请、关闭账单、修改并重新提交等操作入口统一放在列表页的操作列,详情页不出现业务操作按钮。
### 权限编码
新增 `src/config/constants/augustIteration.ts`,沿用 `模块:动作` 风格,例如 `employee_collection:bill_close`、`employee_collection:application_create`。页面级 `permissions` 用于菜单可见性,按钮级编码用于 `hasAuth()` / `v-permission`。
### 金额、时间与附件
- 金额统一以「分」传输,展示时通过 `fenToYuan` / `formatCurrency` 转换,与退款、代理充值保持一致。
- 所有时间字段统一通过 `formatDateTime` 格式化为 `YYYY-MM-DD HH:mm:ss`,不在模板中直接输出后端原始时间字符串。
- 附件仅返回对象 Key(`payment_voucher_keys`),展示复用 `PaymentVoucherDialog`,由预签名下载接口换取访问地址。
### 核销申请分摊
创建申请时按账单逐条录入核销金额,并填写付款事实(付款金额、付款方名称、付款时间、外部交易流水号),前端校验:
- 至少选择 1 张账单,最多 N 张;
- 单张核销金额不得大于账单未核销金额,且大于 0;
- 付款金额(`paid_amount`,分)不得小于各账单分摊之和(允许存在差额);
- 超管代办时 `acting_reason` 必填;
- 付款凭证至少 1 个 Key。
提交成功后自动发起企微审批;仅已驳回申请可再次进入弹窗修改并重新提交,重新提交生成新的审批实例,历史审批记录只读展示。未配置企微审批场景时后端返回 503,前端展示「企微审批场景未配置,请联系管理员」并保留已填内容。
### 企微审批场景
`WecomBusinessType` 增加 `employee_collection_approval`,企微审批场景页面下拉新增「员工代收款审批」。模板控件同步、字段查询、字段映射保存全部复用既有 `WecomService`。
### 订单付款凭证规则
线下订单创建时,满足「平台账号(`user_type` 为 1 或 2)操作 + 非赠送套餐 + 实际收款金额大于 0」条件的订单会生成员工代收款账单,此时 `payment_voucher_key` 非必填,字段结构不变,付款凭证改在核销申请中提交。前端以当前登录账号类型、所选套餐是否赠送、套餐有效价格(`effective_retail_price` / `suggested_retail_price` / `retail_price`)判断是否展示提示并放宽必填;赠送套餐或其他非平台账号的线下订单仍需上传凭证。
## Risks / Trade-offs
- **接口字段以契约文档为准**:`docs/admin-openapi.yaml` 未入库,字段来自需求文档与创建订单接口片段;类型集中在一个文件,便于联调时收敛修改。
- **员工/超管同接口**:前端不做数据范围过滤,仅做展示与操作可见性控制,数据隔离以后端为准。
- **关闭账单与审批中申请**:前端依据 `approval_pending` 与状态字段禁用关闭按钮,最终一致性以后端校验为准。

View File

@@ -0,0 +1,25 @@
# Change: 员工代收款功能前端对接
## Why
8 月产品迭代新增「员工代收款」能力:员工线下代收款项后,通过创建核销申请、经企业微信审批完成账单核销;超级管理员可维护收款方式、查看全部账单并关闭账单。后端接口已按 `docs/产品迭代8月份/员工代收款功能简介.md` 落地,后台管理端目前缺少收款方式管理、账单列表与核销申请页面,普通员工与超级管理员的分类视图、以及线下订单付款凭证规则尚未接入。
本次已按后端实际契约对齐字段:列表响应统一使用 `items` / `total` / `page` / `size`;账单状态(`0` 待核销 / `1` 部分核销 / `2` 已核销 / `3` 已关闭)与申请状态(`0` 审批中 / `1` 已通过 / `2` 已驳回 / `3` 已撤销或已关闭)为数字枚举;收款方式列表返回 `{ items, page, size, total }` 并支持 `enabled` / `keyword` 筛选;核销申请请求体使用 `paid_amount`、`paid_at`、`payer_name`、`external_transaction_no`、`payment_voucher_keys` 与 `allocations`。
## What Changes
- 新增 `employee-collection` 能力的前端类型与服务封装:收款方式 4 个接口、员工代收款账单 4 个接口、核销申请 4 个接口。
- 新增「收款方式管理」页面(仅超级管理员):列表 + 新增/编辑弹窗 + 删除;已被核销申请引用的方式不可删除、不可修改 `code`(未被引用时可改),可停用。
- 新增「员工代收款账单」页面:应收/已核销/未核销/待处理账单统计 + 列表 + 详情;普通员工仅见本人账单,超级管理员可见全部;存在审批中申请时账单不可关闭,关闭必须填写原因。
- 新增「核销申请」页面:列表 + 详情(含分摊账单、付款凭证、付款信息与全部审批尝试记录)+ 创建/重新提交弹窗;一笔线下收款可核销 1~N 张账单,填写付款金额、付款方名称、付款时间、外部交易流水号、选择收款方式并上传付款凭证;提交后自动发起企微审批;仅已驳回申请可修改并重新提交,重新提交生成新的审批实例且历史记录不被覆盖。
- 扩展企业微信审批场景:新增 `employee_collection_approval` 业务类型,复用既有企微应用列表、模板控件同步与业务字段查询接口。
- 调整订单创建:由平台账号操作、实际收款金额大于 0 且非赠送的线下订单会生成员工代收款账单,该场景 `payment_voucher_key` 改为非必填,付款凭证改在核销申请中提交,字段结构保持不变。
- 附件接口仅返回对象 Key,统一通过系统既有预签名下载接口展示。
- **不实现后端接口、数据库、Worker、企微回调**;**不实现 H5/C 端页面**。
## Impact
- Affected specs: `employee-collection`
- Affected code: `src/types/api/employeeCollection.ts`、`src/api/modules/employeeCollection.ts`、`src/views/finance/employee-collection/*`、`src/router/routes/asyncRoutes.ts`、`src/router/routesAlias.ts`、`src/config/constants/augustIteration.ts`、`src/types/api/wecom.ts`、`src/views/settings/wecom/scenes/index.vue`、`src/views/order-management/order-list/index.vue`、`src/locales/langs/{zh,en}.json`
- Dependencies: `docs/产品迭代8月份/员工代收款功能简介.md`
- Contract note: `docs/admin-openapi.yaml` 未随仓库提供,字段以需求文档描述的后端契约与创建订单接口的 OpenAPI 片段为准;类型集中在单一文件,联调时便于收敛。

View File

@@ -0,0 +1,155 @@
## ADDED Requirements
### Requirement: 收款方式管理
超级管理员 MUST 能够维护线下收款方式,包括名称、编码、排序、状态与备注;普通员工只能看到启用的收款方式。收款方式列表接口 MUST 返回 `{ items, page, size, total }`,并 MUST 支持 `enabled` 与 `keyword` 筛选。已被核销申请引用的收款方式 MUST NOT 被删除;引用后修改稳定编码 MUST 被后端拒绝,前端 MUST 展示错误提示。
#### Scenario: 超级管理员新增收款方式
- **GIVEN** 超级管理员已登录并拥有收款方式新增权限
- **WHEN** 其填写名称、唯一编码、排序、状态与备注并提交
- **THEN** 系统 MUST 调用新增接口并在成功后刷新列表
- **AND** 新增成功后 MUST 清空并关闭弹窗
#### Scenario: 删除被引用的收款方式
- **GIVEN** 某收款方式已被业务引用
- **WHEN** 超级管理员尝试删除该方式
- **THEN** 前端 MUST 阻止删除或展示后端返回的业务错误
- **AND** MUST 提示改为停用
#### Scenario: 修改收款方式编码
- **GIVEN** 超级管理员打开编辑弹窗
- **WHEN** 其修改稳定编码并提交
- **THEN** 前端 MUST 提交最新编码
- **AND** 若该方式已被核销申请引用,后端拒绝时前端 MUST 展示错误提示
### Requirement: 员工代收款账单统计
账单页面 MUST 展示应收金额、已核销金额、未核销金额与待处理账单数量四项统计,数据 MUST 来自 `GET /api/admin/employee-collection-bills/statistics`,字段为 `receivable_total`、`received_total`、`unsettled_total`、`pending_bill_count`;前端 MUST NOT 通过遍历当前分页数据自行计算。
#### Scenario: 加载账单统计
- **GIVEN** 用户进入员工代收款账单页面
- **WHEN** 页面初始化或筛选条件变化
- **THEN** 前端 MUST 调用账单统计接口
- **AND** MUST 将后端返回的「分」按元格式化后展示应收、已核销与未核销金额
### Requirement: 员工代收款账单列表与详情
账单列表响应 MUST 为 `{ items, total, page, size }`,前端 MUST 兼容 `items` / `list` / `records` 等列表字段。列表 MUST 支持按来源(`source_type`)、来源单号(`source_no`)、账单状态、客户/店铺(`customer_id`)与创建时间(`created_from` / `created_to`,`YYYY-MM-DD`)筛选,并展示账单编号、来源、关联单号、负责员工、客户/店铺、应收金额、已核销金额、未核销金额与状态。账单状态 MUST 为数字枚举:`0` 待核销、`1` 部分核销、`2` 已核销、`3` 已关闭,展示 MUST 优先使用后端 `status_name`。账单详情响应 MUST 为 `{ bill, refunds, allocations, applications }`:`refunds` MUST 展示退款金额、冲减应收、冲销前应收与处理结果,`applications` MUST 可展开查看该申请的审批尝试记录。
#### Scenario: 普通员工查看账单
- **GIVEN** 普通员工已登录
- **WHEN** 其打开账单列表
- **THEN** 列表 MUST 只展示后端返回的本人账单数据
- **AND** MUST NOT 展示仅超管可见的操作入口
#### Scenario: 打开账单详情
- **GIVEN** 用户拥有账单详情权限
- **WHEN** 其点击账单号或详情操作
- **THEN** 前端 MUST 跳转账单详情页并加载对应账单(详情数据取自 `data.bill`)
- **AND** 详情 MUST 展示退款冲销、核销分摊与关联核销申请
### Requirement: 关闭账单
超级管理员 MUST 能够关闭账单,且关闭原因必填(最多 500 字符)。仅待核销或部分核销账单可关闭;存在审批中的核销申请(`approval_pending` 为真)时,账单 MUST NOT 被关闭。
#### Scenario: 存在审批中申请时关闭账单
- **GIVEN** 账单存在审批中的核销申请
- **WHEN** 用户查看该账单操作
- **THEN** 关闭入口 MUST 被禁用或不可见
- **AND** MUST 展示不可关闭的原因提示
#### Scenario: 关闭原因必填
- **GIVEN** 账单可关闭
- **WHEN** 超级管理员打开关闭弹窗并留空原因提交
- **THEN** 前端 MUST 阻止提交并提示填写原因
### Requirement: 创建核销申请
员工 MUST 能够使用一笔线下收款核销 1~N 张账单。创建申请 MUST 提交收款方式 `payment_method_id`、付款金额 `paid_amount`(分,大于 0)、付款方名称 `payer_name`、付款时间 `paid_at`(带时区 RFC3339)、外部交易流水号 `external_transaction_no`、付款凭证 `payment_voucher_keys`(1~5 个对象 Key)与账单分摊 `allocations`。超级管理员代办时 MUST 填写 `acting_reason`,本人办理 MUST NOT 提交该字段。提交成功后系统 MUST 自动发起企业微信审批。
#### Scenario: 一笔收款核销多张账单
- **GIVEN** 用户选择了多张可核销账单
- **WHEN** 其录入各账单核销金额、选择收款方式并填写付款事实后提交
- **THEN** 前端 MUST 校验各账单核销金额大于 0 且不超过账单未核销余额
- **AND** MUST 以 `allocations: [{ bill_id, amount }]` 提交账单分摊明细
#### Scenario: 付款金额小于核销合计
- **GIVEN** 用户已录入各账单核销金额
- **WHEN** 其填写的付款金额小于核销合计即提交
- **THEN** 前端 MUST 阻止提交并提示付款金额不能小于核销合计
#### Scenario: 缺少付款凭证
- **GIVEN** 用户已选择账单与收款方式
- **WHEN** 其未上传任何付款凭证即提交
- **THEN** 前端 MUST 阻止提交并提示上传付款凭证
#### Scenario: 缺少付款事实
- **GIVEN** 用户已选择账单与收款方式
- **WHEN** 其未填写付款方名称、付款时间或外部交易流水号即提交
- **THEN** 前端 MUST 阻止提交并提示补齐必填项
#### Scenario: 超管代办未填写原因
- **GIVEN** 超级管理员以代办身份创建申请
- **WHEN** 其未填写 `acting_reason` 即提交
- **THEN** 前端 MUST 阻止提交并提示填写代办原因
#### Scenario: 企微审批场景未配置
- **GIVEN** 企业微信审批场景尚未配置
- **WHEN** 用户提交核销申请
- **THEN** 前端 MUST 展示后端返回的 503 提示「企微审批场景未配置,请联系管理员」
- **AND** MUST 保留用户已填写的内容且不产生申请数据
### Requirement: 核销申请列表与详情
核销申请列表响应 MUST 为 `{ items, page, size, total }`,MUST 支持按状态、收款方式与创建时间筛选;列表项 MUST 包含 `payment_method_name`、`paid_amount`、`status`、`status_name` 与 `created_at`,状态 MUST 优先展示后端 `status_name`。申请详情响应 MUST 为 `{ application, allocations, attempts }`;`attempts` MUST 按提交顺序展示全部审批尝试记录,包含付款金额、付款方、流水号、付款凭证与审批意见。
#### Scenario: 查看审批历史
- **GIVEN** 申请存在多次审批尝试记录
- **WHEN** 用户打开申请详情
- **THEN** 详情 MUST 按提交顺序展示每次尝试的提交材料与审批状态
- **AND** 历史材料 MUST NOT 因重新提交而被覆盖
### Requirement: 核销申请重新提交
仅已驳回(`status` 为 `2`)的申请 MUST 允许修改并重新提交;重新提交 MUST 生成新的企业微信审批实例,且历史审批记录 MUST NOT 被覆盖。重新提交入口 MUST 位于核销申请列表的操作列,详情页 MUST 只读且 MUST NOT 展示业务操作按钮(仅保留返回导航)。
#### Scenario: 重新提交被驳回申请
- **GIVEN** 申请状态为已驳回
- **WHEN** 用户在核销申请列表点击「修改并重新提交」并修改账单分摊、收款方式、付款事实或付款凭证后提交
- **THEN** 前端 MUST 调用修改接口重新提交
- **AND** 成功后 MUST 刷新详情并展示新的审批实例状态
#### Scenario: 非驳回申请不可修改
- **GIVEN** 申请处于审批中或已通过
- **WHEN** 用户查看核销申请列表
- **THEN** 修改并重新提交入口 MUST 不可见或不可用
#### Scenario: 详情页只读
- **GIVEN** 用户打开账单详情或核销申请详情
- **WHEN** 页面渲染完成
- **THEN** 页面 MUST NOT 展示创建核销申请、关闭账单或修改并重新提交等业务操作按钮
- **AND** MUST 只保留返回导航
### Requirement: 企业微信审批场景配置
企业微信审批场景 MUST 支持 `employee_collection_approval` 业务类型,复用既有的应用列表、模板控件同步、业务字段查询与字段映射保存接口。
#### Scenario: 配置员工代收款审批场景
- **GIVEN** 超级管理员打开企微审批场景页面
- **WHEN** 其选择业务类型「员工代收款审批」
- **THEN** 前端 MUST 使用 `employee_collection_approval` 调用模板同步、字段查询与保存接口
### Requirement: 附件预签名展示
附件接口 MUST 只返回对象存储 Key(`payment_voucher_keys`);前端 MUST 通过系统既有的预签名下载接口获取实际访问地址后再展示。
#### Scenario: 查看付款凭证
- **GIVEN** 申请包含付款凭证 Key
- **WHEN** 用户点击查看付款凭证
- **THEN** 前端 MUST 先批量换取预签名地址
- **AND** 图片 MUST 支持预览,非图片 MUST 支持查看或下载
### Requirement: 订单付款凭证规则调整
由平台账号(`user_type` 为 1 或 2)操作、实际收款金额大于 0 且非赠送的线下订单会生成员工代收款账单;该场景 `payment_voucher_key` MUST 变为非必填,付款凭证改在核销申请中提交,订单字段结构 MUST 保持不变。其余线下订单 MUST 继续要求付款凭证。
#### Scenario: 线下订单生成代收款账单
- **GIVEN** 当前登录账号为平台账号,所选套餐非赠送且实际收款金额大于 0,支付方式为线下支付
- **WHEN** 用户创建该订单
- **THEN** 前端 MUST 不再强制要求上传付款凭证
- **AND** MUST 提示付款凭证将在核销申请中提交
#### Scenario: 赠送套餐或非平台账号的线下订单
- **GIVEN** 所选套餐为赠送套餐,或当前账号非平台账号,或实际收款金额为 0
- **WHEN** 用户以线下支付方式创建订单
- **THEN** 前端 MUST 继续要求上传付款凭证

View File

@@ -0,0 +1,48 @@
## 1. Contract and API Types
- [x] 1.1 新增 `src/types/api/employeeCollection.ts`:收款方式、账单、核销申请、统计、查询参数与请求/响应类型;列表统一使用 `items` / `total` / `page` / `size`。
- [x] 1.2 定义账单状态(`0` 待核销 / `1` 部分核销 / `2` 已核销 / `3` 已关闭)与申请状态(`0` 审批中 / `1` 已通过 / `2` 已驳回 / `3` 已撤销或已关闭)数字枚举,并保留后端 `*_name` 展示字段。
- [x] 1.3 金额字段以「分」传输;附件字段使用 `payment_voucher_keys` 对象存储 Key 数组,展示复用预签名下载接口。
- [x] 1.4 新增 `src/api/modules/employeeCollection.ts` 并在 `src/api/modules/index.ts`、`src/types/api/index.ts` 导出。
- [x] 1.5 按后端实际契约收敛字段:账单详情为 `{ bill, refunds, allocations, applications }`,核销申请详情为 `{ application, allocations, attempts }`,付款金额/付款方/付款时间/外部交易流水号以 `paid_amount` / `payer_name` / `paid_at` / `external_transaction_no` 提交。
## 2. Permissions, Routes, and Menu
- [x] 2.1 新增 `src/config/constants/augustIteration.ts`,集中声明页面与按钮权限编码。
- [x] 2.2 在 `src/router/routesAlias.ts` 与 `src/router/routes/asyncRoutes.ts` 的财务管理下新增账单、核销申请、收款方式路由。
- [x] 2.3 在 `src/locales/langs/zh.json`、`en.json` 的 `menus.financialManagement` 下补充菜单文案。
## 3. Payment Methods Page
- [x] 3.1 实现收款方式列表(名称、编码、排序、状态、备注、创建时间);接口返回 `{ items, page, size, total }`,复用 `ArtTableFullScreen` / `ArtSearchBar` / `ArtTableHeader` / `ArtTable`。
- [x] 3.2 实现新增/编辑弹窗;编辑时允许提交 `code`,被核销申请引用时由后端拒绝并提示。
- [x] 3.3 实现删除操作,被引用的方式给出提示并引导停用。
## 4. Bills Pages
- [x] 4.1 实现账单统计卡片(应收、已核销、未核销、待处理账单数量),数据来自 `GET /api/admin/employee-collection-bills/statistics`。
- [x] 4.2 实现账单列表与筛选(来源、来源单号、状态、客户/店铺、创建时间范围),展示账单号、来源、关联单号、负责员工、客户/店铺、应收/已核销/未核销金额与状态。
- [x] 4.3 实现账单详情,展示账单信息、退款冲销、核销分摊与关联核销申请(关联申请可展开查看审批尝试记录)。
- [x] 4.4 实现超管关闭账单弹窗,关闭原因必填;存在审批中申请时禁用关闭并给出说明。
- [x] 4.5 列表「创建核销申请」入口按权限与账单状态控制可用性。
## 5. Applications Pages
- [x] 5.1 实现核销申请列表与筛选(状态、收款方式、创建时间),展示申请编号、收款方式、付款金额、状态与提交时间。
- [x] 5.2 实现创建/重新提交弹窗:选择 1~N 张可核销账单、按账单录入分摊金额、填写付款金额/付款方名称/付款时间/外部交易流水号、选择收款方式并上传付款凭证。
- [x] 5.3 超管代办时必须填写 `acting_reason`,否则禁止提交。
- [x] 5.4 实现申请详情,展示申请信息、分摊账单、付款凭证与全部审批尝试记录;历史记录只读,不被重新提交覆盖。
- [x] 5.5 仅已驳回申请展示「修改并重新提交」,提交成功后生成新的审批实例并刷新详情。
- [x] 5.6 统一处理 503「企微审批场景未配置」等业务错误,保留用户已填内容。
## 6. WeCom Scene and Order Rule
- [x] 6.1 扩展 `WecomBusinessType` 增加 `employee_collection_approval`,并在企微审批场景页面新增可选业务类型。
- [x] 6.2 场景保存复用既有 `inspectTemplate`、`getBusinessFields`、`saveScene` 接口,无需新增企微接口。
- [x] 6.3 调整线下订单创建:平台账号操作、非赠送且实际收款金额大于 0 时 `payment_voucher_key` 非必填,字段结构不变。
## 7. Verification
- [x] 7.1 运行 `npm run build`(含 `vue-tsc --noEmit`)与 `npm run check:encoding`,确保类型与编码通过。
- [x] 7.2 校验普通员工与超管的菜单、列与操作可见性差异。 — 已核验:应用/账单/收款方式页 v-permission 按钮、bills 关闭操作 hasAuth(billClose)+canCloseBill、表单 isActing=isSuperAdmin 控制代办字段
- [x] 7.3 校验金额分/元转换、附件预签名展示与 503 错误兜底。 — 已核验:ApplicationFormDialog 用 fenToYuan/yuanToFen;detail.vue 用 PaymentVoucherDialog 预览凭证;getErrorMessage 提取后端 msg(含 503 未配置场景)兜底

View File

@@ -0,0 +1,38 @@
# Design: H5 运营弹窗配置管理(管理后台)
## 页面结构
- 设置管理下新增「H5运营弹窗配置」入口(仅超管/平台):
- 列表页 `src/views/settings/h5-popup-configuration/index.vue`
- 创建/编辑表单弹窗(复用 ArtForm + ArtSearchBar/ArtTable 模式)
- 详情以弹窗/抽屉展示完整配置
- 分页、筛选、表格沿用 ArtTable / ArtSearchBar / ArtTableHeader 与统一响应结构(`code/msg/timestamp/data`、分页 `items/page/size/total`)。
## 接口与类型
- 新增 `src/api/modules/h5PopupConfiguration.ts` 与 `src/types/api/h5PopupConfiguration.ts`:
- `GET /api/admin/h5-popup-configurations`(page/page_size/enabled,倒序分页)
- `POST /api/admin/h5-popup-configurations`(创建)
- `GET /api/admin/h5-popup-configurations/{id}`(详情)
- `PUT /api/admin/h5-popup-configurations/{id}`(更新,整表提交,版本 +1)
- `POST /api/admin/h5-popup-configurations/{id}/enable`、`{id}/disable`(请求体 `{ id }`,返回更新后配置)
- 枚举映射常量集中放置:`pages`(home/asset_detail/package_purchase/asset_wallet_recharge)、`frequency`(once/daily)、`action_type`(package_purchase/asset_wallet_recharge,空字符串 = 无)、`card_types`(CMCC/CUCC/CTCC/CBN)。
## 表单约定
- `pages` 多选必填(空数组非法);`title`(1–100)/`content`(1–2000)/`frequency`/起止时间必填。
- 范围三选器(店铺/设备类型/卡类型)空数组 = 全量,回显「全部」。
- 起止时间用 datetimerange,提交转 ISO 8601(`starts_at`/`ends_at`),`ends_at` 不得早于 `starts_at`。
- `priority` 数字输入(0–1000000);`enabled` 开关;`action_type` 下拉(含「无」选项,提交空字符串清除受控动作)。
- 编辑表单整表提交;编辑保存成功后提示「每次更新版本递增,旧版本通知保留原快照,新版本可向原命中客户按频率重新投放一次」。
- 启用/停用为行操作(停用需二次确认),以接口返回的更新后配置刷新当前行。
## 权限与可见性
- 权限码:`h5_popup_configuration:list`(菜单/列表)、`:create`、`:update`、`:enable`、`:disable`。
- 路由 `meta.permissions` + 按钮 `v-permission`/`usePermission`,仅超管/平台可见;代理/企业/个人由后端 403 兜底并原文透传失败文案。
- 不提供删除入口(文档无 DELETE 接口)。
## 待确认
- 权限编码以后端菜单配置为准(前端默认 `h5_popup_configuration:list/create/update/enable/disable`)。

View File

@@ -0,0 +1,46 @@
# Change: 新增 H5 运营弹窗配置管理(管理后台)
## Why
H5 端(个人客户)需要在首页、资产详情、套餐购买、资产钱包充值等页面投放运营/风险弹窗,弹窗文案、命中页面、投放范围与生效规则需要后台配置。当前后台没有任何弹窗配置入口,运营只能走数据库操作。
本 Change 为管理后台新增「H5 运营弹窗配置」管理能力:配置标题与正文、命中页面、投放范围(店铺/设备类型/卡类型)、优先级、投放频率、生效时间与启停。
H5 端契约(`GET /api/c/v1/popup-candidates`、`POST /api/c/v1/risk-exchanges/{asset_id}/address`、通知列表/未读/已读接口)不在本 Change 范围,需求方已明确不处理 C 端。
## What Changes
- 新增 6 个后台接口(仅超管/平台,代理/企业/个人 403):
- `GET /api/admin/h5-popup-configurations`:配置列表,`page`(1–10000)/ `page_size`(1–100)/ `enabled` 筛选,按最近更新时间倒序分页返回 `items/page/size/total`。
- `POST /api/admin/h5-popup-configurations`:创建;`title`/`content`/`pages`/`frequency`/`starts_at`/`ends_at` 必填;`priority`/`enabled`/`action_type`/`shop_ids`/`device_types`/`card_types` 可选(范围集合空数组 = 全量)。
- `GET /api/admin/h5-popup-configurations/{id}`:详情(含 `version`、`frequency_text`、`enabled_text`、`creator`/`updater`)。
- `PUT /api/admin/h5-popup-configurations/{id}`:更新;成功即版本 +1,新版本可向原命中客户按频率重新投放一次,旧版本已投放通知的内容与快照不被改写;除 `id` 外全部字段可选,**不传保持原值**;`action_type` 传空字符串 = 清除受控动作;`shop_ids`/`device_types`/`card_types` 传空数组 = 改为全量;`pages` 传空数组非法(页面必选);`enabled` 不传保持原值(启停刷新最近更新时间);`ends_at` 不得早于 `starts_at`;`content` 1–2000 字符、`title` 1–100 字符、`priority` 0–1000000。
- `POST /api/admin/h5-popup-configurations/{id}/enable`:启用,参与候选匹配,刷新 `updated_at`(影响同优先级排序),返回更新后的配置。
- `POST /api/admin/h5-popup-configurations/{id}/disable`:停用,停止新投放,历史通知在展示期内仍可见;刷新 `updated_at`,返回更新后的配置。
- 新增「H5 运营弹窗配置」管理页(设置管理下,仅超管/平台可见):分页列表 + 创建/编辑表单 + 详情 + 行操作启用/停用。
- 前端契约约定:
- 范围集合 `shop_ids` / `device_types` / `card_types` 空数组 = 全量,列表与编辑回显「全部」。
- 枚举:`pages` = home / asset_detail / package_purchase / asset_wallet_recharge;`frequency` = once / daily;`action_type` = package_purchase / asset_wallet_recharge(空字符串 = 无受控动作);`card_types` = CMCC / CUCC / CTCC / CBN。
- 无「删除」接口,页面不提供删除入口;停用不清数据,列表保留历史配置。
- 编辑表单整表提交(所有字段都传,未传语义仅在部分更新时生效);范围清空传空数组、动作清除传空字符串、页面集合不可为空。
- 权限编码由前端确定:`h5_popup_configuration:list` / `:create` / `:update` / `:enable` / `:disable`。
## Impact
- Affected specs:
- `h5-popup-configuration-management`
- Affected code:
- `src/api/modules/h5PopupConfiguration.ts`(新增)
- `src/types/api/h5PopupConfiguration.ts`(新增)
- `src/api/modules/index.ts`、`src/types/api/index.ts`
- `src/config/constants/`(权限码常量)
- `src/router/routesAlias.ts`、`src/router/routes/asyncRoutes.ts`(设置管理下新增菜单与路由)
- `src/locales/langs/zh.json`、`src/locales/langs/en.json`
- `src/views/settings/h5-popup-configuration/`(列表、表单弹窗、详情)
- Dependencies:
- 后端按 `docs/产品迭代8月份/通知.md` 提供上述 6 接口,Bearer JWT 鉴权,代理/企业/个人 403。
- Breaking changes:
- 无;全部为新增页面、接口模块与类型。
- 待确认:
- 权限编码(前端默认 `h5_popup_configuration:list/create/update/enable/disable`)以后端菜单配置为准。
- 列表分页上限与「按最近更新时间倒序」以文档为准,联调核对后端行为。

View File

@@ -0,0 +1,117 @@
## ADDED Requirements
### Requirement: H5 运营弹窗配置列表
后台 MUST 提供 H5 运营弹窗配置的分页列表(GET /api/admin/h5-popup-configurations),支持 `page`(1–10000)/ `page_size`(1–100)/ `enabled` 筛选,按最近更新时间倒序返回 `items/page/size/total`;列表项 MUST 包含标题、命中页面、范围(店铺/设备类型/卡类型)、优先级、频率(`frequency_text`)、启停(`enabled_text`)、受控动作、生效起止时间、版本、创建/更新人与时间。
#### Scenario: 按启停状态筛选并分页
- **GIVEN** 超管/平台账号进入「H5运营弹窗配置」列表
- **WHEN** 以 page/page_size/enabled 发起查询
- **THEN** 前端 MUST 展示分页结果(后端按最近更新时间倒序)
- **AND** 切换 enabled 筛选后按新条件重新请求
#### Scenario: 范围空数组显示全部
- **GIVEN** 某条配置的 shop_ids/device_types/card_types 为空数组
- **THEN** 列表 MUST 在范围列展示「全部」
#### Scenario: 越权访问
- **GIVEN** 代理/企业/个人账号访问列表接口或直达路由
- **THEN** 后端 MUST 返回 403,前端 MUST NOT 渲染入口
- **AND** 失败文案 MUST 按后端返回原文透传
### Requirement: 创建弹窗配置
后台 MUST 支持创建 H5 运营弹窗配置(POST /api/admin/h5-popup-configurations),`title`/`content`/`pages`/`frequency`/`starts_at`/`ends_at` 必填;`priority`/`enabled`/`action_type`/`shop_ids`/`device_types`/`card_types` 可选,范围集合空数组 = 全量。
#### Scenario: 必填校验
- **GIVEN** 用户提交创建表单
- **WHEN** title/content/pages/frequency/starts_at/ends_at 任一缺失
- **THEN** 前端 MUST 拦截并提示必填,MUST NOT 发送请求
#### Scenario: 范围集合为空数组表示全量
- **GIVEN** 用户未选择店铺/设备类型/卡类型范围
- **THEN** 请求体对应数组 MUST 传空数组,后端按全量投放处理
### Requirement: 弹窗配置详情
后台 MUST 提供弹窗配置详情(GET /api/admin/h5-popup-configurations/{id}),返回完整配置含 `version`、`frequency_text`、`enabled_text`、`creator`/`updater`。
#### Scenario: 查看详情
- **GIVEN** 用户点击列表行「详情」
- **WHEN** 请求详情成功
- **THEN** 前端 MUST 展示完整配置要素(含版本与启停/频率中文名)
### Requirement: 更新弹窗配置
后台 MUST 支持更新弹窗配置(PUT /api/admin/h5-popup-configurations/{id}),成功即版本 +1;新版本可向原命中客户按频率重新投放一次,旧版本已投放通知的内容与快照不被改写。除 `id` 外所有字段均可选,**不传保持原值**;`action_type` 传空字符串 = 清除受控动作;`shop_ids`/`device_types`/`card_types` 传空数组 = 改为全量;`pages` 传空数组非法(页面必选);`enabled` 不传保持原值(启停刷新最近更新时间);`ends_at` 不得早于 `starts_at`;`content` 1–2000 字符、`title` 1–100 字符、`priority` 0–1000000。
#### Scenario: 更新成功版本递增并重新投放
- **GIVEN** 用户保存编辑
- **WHEN** 更新成功
- **THEN** 前端 MUST 提示「每次更新版本递增,旧版本通知保留原快照,新版本可向原命中客户按频率重新投放一次」并刷新列表
- **AND** 列表/详情版本号较更新前 +1,旧版本已投放通知内容不被改写
#### Scenario: 范围清空表示改为全量
- **GIVEN** 编辑时清空某范围集合
- **THEN** 提交对应数组 MUST 为空数组,后端按全量处理
#### Scenario: 受控动作清除
- **GIVEN** 编辑时把 action_type 从 package_purchase 切换为「无」
- **THEN** 请求体 action_type MUST 传空字符串,后端清除受控动作
#### Scenario: 页面集合不得为空
- **GIVEN** 编辑时清空全部命中页面
- **THEN** 前端 MUST 拦截提示命中页面必选,MUST NOT 传空 pages 数组
#### Scenario: 未传字段保持原值
- **GIVEN** 请求体省略某字段(如 enabled)
- **THEN** 后端 MUST 保持原值;前端编辑表单整表提交,范围清空按空数组、动作清除按空字符串处理
### Requirement: 启用与停用弹窗配置
后台 MUST 支持启用/停用弹窗配置(POST /api/admin/h5-popup-configurations/{id}/enable、/{id}/disable,请求体 `{ id }`,返回更新后的配置),停用停止新投放且历史通知在展示期内仍可见,启用参与候选匹配;两者均刷新最近更新时间(影响同优先级排序)且不递增版本。
#### Scenario: 停用需二次确认
- **GIVEN** 用户点击某启用的配置「停用」
- **WHEN** 二次确认提交
- **THEN** 前端 MUST 调用 disable 并提示「停用后停止新投放,历史通知在展示期内仍可见」
- **AND** 以返回的更新后配置刷新当前行(状态为停用、最近更新时间更新、版本不变)
#### Scenario: 启用
- **GIVEN** 用户点击某停用的配置「启用」
- **THEN** 前端 MUST 调用 enable 并提示「启用后参与候选匹配」
- **AND** 以返回的更新后配置刷新当前行(状态为启用、最近更新时间更新、版本不变)
### Requirement: 角色权限与交互约定
弹窗配置入口 MUST 仅对超级管理员与平台账号可见;前端权限码固定为 `h5_popup_configuration:list`(菜单/列表)、`:create`、`:update`、`:enable`、`:disable`;页面 MUST NOT 提供删除入口(文档无 DELETE 接口);停用不清数据,列表保留历史配置。
#### Scenario: 入口按角色隐藏
- **GIVEN** 代理/企业/个人账号登录
- **WHEN** 系统渲染菜单
- **THEN** MUST NOT 展示「H5运营弹窗配置」菜单项
#### Scenario: 按钮权限码控制
- **GIVEN** 账号具备列表权限但缺 enable/disable 权限
- **THEN** 前端 MUST 只渲染具备权限的操作按钮
#### Scenario: 不提供删除入口
- **GIVEN** 用户查看列表或详情
- **THEN** 页面 MUST NOT 出现删除操作,仅提供启用/停用

View File

@@ -0,0 +1,43 @@
## 1. Contract Confirmation
- [x] 1.1 权限编码前端确定:`h5_popup_configuration:list` / `:create` / `:update` / `:enable` / `:disable`(以后端菜单配置为准)。
- [x] 1.2 更新接口语义按文档:不传保持原值;`action_type` 空串 = 清除;范围空数组 = 改全量;`pages` 空数组非法;`enabled` 不传保持原值;`ends_at` 不得早于 `starts_at`;`content` 1–2000、`title` 1–100、`priority` 0–1000000;更新成功版本 +1 且旧版本通知不被改写。
- [x] 1.3 `enable`/`disable` 请求体 `{ id }`,返回更新后的 DtoH5PopupConfigurationResponse。
- [x] 1.4 列表 `page` 1–10000、`page_size` 1–100、`enabled` 筛选,按最近更新时间倒序分页。
## 2. API And Types
- [ ] 2.1 新增 `src/api/modules/h5PopupConfiguration.ts`:列表、创建、详情、更新、启用、停用 6 个接口。
- [ ] 2.2 新增 `src/types/api/h5PopupConfiguration.ts`:请求/响应 DTO(含 pages/frequency/action_type/card_types 枚举、范围集合、version、creator/updater 等;更新语义按「不传保持原值/空数组=全量/空串=清除」注释)。
- [ ] 2.3 在 `src/api/modules/index.ts`、`src/types/api/index.ts` 导出新模块/类型。
- [ ] 2.4 对齐统一响应 `code/msg/timestamp/data` 与分页 `items/page/size/total`。
## 3. List Page
- [ ] 3.1 设置管理下新增「H5运营弹窗配置」菜单与路由(仅超管/平台可见,权限码 `h5_popup_configuration:list`)。
- [ ] 3.2 列表:`page`/`page_size`/`enabled` 筛选,分页展示,按后端倒序。
- [ ] 3.3 列:标题、命中页面、范围(店铺/设备类型/卡类型,空数组显示「全部」)、优先级、频率、启停状态、受控动作、生效起止、版本、创建/更新人与时间。
- [ ] 3.4 行操作:详情、编辑、启用/停用(停用需二次确认);无删除入口。
## 4. Create / Edit / Detail
- [ ] 4.1 创建表单:`title`/`content`/`pages` 多选/`frequency`/起止时间必填校验(pages 非空);`priority`/`enabled`/`action_type`/范围可选。
- [ ] 4.2 范围集合 `shop_ids`/`device_types`/`card_types` 空数组 = 全量;编辑读回空数组显示「全部」。
- [ ] 4.3 编辑表单整表提交;保存成功提示「每次更新版本递增,旧版本通知保留原快照,新版本可向原命中客户按频率重新投放一次」。
- [ ] 4.4 编辑支持 `action_type` 清空(「无」→ 空字符串)与 `ends_at` 不早于 `starts_at` 的前端校验。
- [ ] 4.5 详情(弹窗/抽屉)展示完整配置(含 version、frequency_text、enabled_text、creator/updater)。
## 5. Permissions And UX
- [ ] 5.1 按钮/入口按 `h5_popup_configuration:list/create/update/enable/disable` 接入 `usePermission`/`v-permission`,无权限不渲染。
- [ ] 5.2 固定提示:停用「停用后停止新投放,历史通知在展示期内仍可见」;启用「启用后参与候选匹配」;403 文案原文透传。
- [ ] 5.3 表单校验与请求失败提示稳定,不破坏列表渲染。
## 6. Verification
- [ ] 6.1 `vue-tsc --noEmit` 与新增文件 eslint 通过。
- [ ] 6.2 列表筛选/分页/倒序展示正确。
- [ ] 6.3 创建必填校验、范围全量语义、编辑版本 +1 提示正确。
- [ ] 6.4 启用/停用流程与提示正确;停用不清数据;启停不递增版本、刷新最近更新时间。
- [ ] 6.5 代理/企业/个人看不到入口;直达路由 403 文案透传。
- [ ] 6.6 联调:编辑整表提交后版本 +1、启停返回完整配置并刷新行;`ends_at` 早于 `starts_at` 被后端拒绝。

View File

@@ -0,0 +1,23 @@
# Change: 批量回收支持一行一个 ICCID
用户已确认并完成实施;验证结果见 `tasks.md`。
## Why
IoT 卡管理的批量回收目前只能从表格勾选 ICCID、输入号段范围或使用筛选条件。已有卡号清单的用户需要直接粘贴每行一个 ICCID,并复用现有 ICCID 列表的回收接口。
## What Changes
- 在“批量回收”弹窗的选卡方式中增加“一行一个ICCID”,选择后显示带标签和输入提示的多行文本框,沿用现有 Element Plus 表单样式。
- 按换行拆分输入,去除每行首尾空白并忽略空行;ICCID 始终按字符串处理,不作数字转换。不增加额外的卡号长度或格式限制。
- 提交时仍调用 `POST /api/admin/iot-cards/standalone/recall`,使用 `selection_type: "list"` 和 `iccids: string[]`,不向接口发送新的选卡方式或文本框字段。
- 没有有效输入时展示校验提示,不提交请求;切换方式后按当前方式构建参数,关闭再打开时清空手工输入。
- 取消批量回收入口必须勾选表格的限制。有勾选时仍默认“ICCID列表”,无勾选时默认“一行一个ICCID”;原有列表模式仍校验必须有勾选项。
- 保持号段范围、筛选条件、权限、备注、结果展示和刷新逻辑不变;不修改其他批量操作。
## Impact
- Affected specs: `iot-card-management`
- Affected code: `src/views/asset-management/iot-card-management/index.vue`
- Backend impact: 无;复用 `CardService.recallStandaloneCards` 及其现有列表请求结构。
- Related changes: `update-batch-range-count-hints-formatting`(保留其号段数量提示)。

View File

@@ -0,0 +1,55 @@
## ADDED Requirements
### Requirement: IoT Card Batch Recall Line Input
The IoT card batch recall dialog SHALL offer “一行一个ICCID” as an additional frontend-only selection mode alongside the existing ICCID list, range and filter modes.
The new mode MUST show a labeled multiline input with a hint to enter one ICCID per line. It MUST split LF and CRLF line endings, trim each line, ignore empty lines and preserve each ICCID as a string without numeric conversion or additional length or format restrictions.
Submitting this mode MUST call the existing `POST /api/admin/iot-cards/standalone/recall` endpoint with `selection_type: "list"`, the entered values in `iccids`, and the existing optional remark. It MUST NOT include selected table rows, range fields, filter fields or frontend-only fields in that request.
#### Scenario: Submit a pasted ICCID list
- **GIVEN** 用户选择“一行一个ICCID”并输入多个 ICCID,行首尾存在空白且内容中包含空行
- **WHEN** 用户点击“确认回收”
- **THEN** 系统 MUST 去除首尾空白和空行,将剩余各行作为字符串放入 `iccids`
- **AND** 系统 MUST 使用原有列表模式的接口和 `selection_type: "list"` 提交
- **AND** 系统 MUST 沿用现有成功数、失败项及列表刷新流程
#### Scenario: Reject empty manual input
- **GIVEN** 用户选择“一行一个ICCID”
- **WHEN** 输入为空或仅包含空白和空行并尝试提交
- **THEN** 系统 MUST 显示请输入 ICCID 的校验提示
- **AND** 系统 MUST NOT 发送回收请求
#### Scenario: Keep each selection mode isolated
- **GIVEN** 用户在逐行输入与现有列表、号段或筛选方式之间切换
- **WHEN** 用户提交当前选择方式
- **THEN** 系统 MUST 仅根据当前方式构建请求参数
- **AND** 原有列表、号段和筛选方式 MUST 保持既有行为及号段数量提示
### Requirement: IoT Card Batch Recall Manual Input Entry
The batch recall action SHALL remain permission-controlled and be available without selected table rows so users can enter ICCIDs directly. When opening the dialog, it MUST default to the existing list mode if rows are selected and to line input mode otherwise. The existing list mode MUST still reject submission without selected cards. Manual input MUST be cleared when the dialog is reopened.
#### Scenario: Open batch recall without selected rows
- **GIVEN** 用户拥有 `iot_card:batch_recycle` 权限且未勾选表格行
- **WHEN** 用户点击“批量回收”
- **THEN** 系统 MUST 打开弹窗并默认选择“一行一个ICCID”
- **AND** 用户 MUST 能直接粘贴卡号,而无需先勾选无关卡片
#### Scenario: Preserve the selected-row workflow
- **GIVEN** 用户已在表格勾选卡片
- **WHEN** 用户打开“批量回收”弹窗
- **THEN** 系统 MUST 默认选择现有“ICCID列表”方式
- **AND** 用户按列表方式提交时 MUST 继续使用已勾选卡片的 ICCID
#### Scenario: Clear manual input when reopening
- **GIVEN** 用户在“一行一个ICCID”方式下输入过卡号并关闭弹窗
- **WHEN** 用户再次打开“批量回收”弹窗
- **THEN** 手工输入框 MUST 为空,不得沿用上一次回收的输入

View File

@@ -0,0 +1,31 @@
## 1. Specification
- [x] 1.1 核对批量回收入口、选卡方式和现有列表模式接口。
- [x] 1.2 明确逐行输入、空值校验、接口复用和既有模式兼容场景。
- [x] 1.3 获得用户对提案的确认后开始实施(用户回复“执行”)。
## 2. Implementation
- [x] 2.1 新增仅用于前端的逐行输入选项和多行文本框,保留后端选卡方式枚举。
- [x] 2.2 实现按行解析、非空校验及 `selection_type: "list"` 的请求参数构建。
- [x] 2.3 调整无勾选时的入口和默认方式,并确保弹窗重开清空输入。
- [x] 2.4 保持既有列表、号段、筛选、权限及操作结果流程不变。
## 3. Validation
- [x] 3.1 运行 `openspec validate add-iot-card-recall-line-input --strict`(通过)。
- [x] 3.2 检查多行输入(LF / CRLF)、首尾空白、空行、全空输入和长 ICCID 字符串处理。
- [x] 3.3 检查模式切换、无勾选打开、有勾选默认列表、关闭重开及接口参数隔离。
- [x] 3.4 运行相关文件代码检查和项目类型检查,记录结果。
## 4. Verification results
- `node --test scripts/tests/iotCardRecallLineInput.test.mjs`:11 项通过;执行真实 Vue 组件 setup、校验规则和提交函数,并使用 mock 请求验证原有回收 API 的路径及参数,无真实回收操作。
- `node --import ./scripts/tests/register-esbuild.mjs --test scripts/tests/*.test.mjs`:项目全部 141 项测试通过(PowerShell 中先枚举测试文件再传入)。
- `pnpm exec eslint src/views/asset-management/iot-card-management/index.vue scripts/tests/iotCardRecallLineInput.test.mjs`:通过。
- `pnpm exec prettier --check src/views/asset-management/iot-card-management/index.vue scripts/tests/iotCardRecallLineInput.test.mjs`:通过。
- `node scripts/check-encoding.mjs src/views/asset-management/iot-card-management/index.vue scripts/tests/iotCardRecallLineInput.test.mjs`:通过。
- `pnpm exec vue-tsc --noEmit`:通过。
- `node scripts/tests/verifyBuild.mjs`:生产构建通过,输出到临时目录并保留生成声明文件;其他页面仍有 `searchForm` 常量赋值、循环依赖及大 chunk 警告,本次未修改这些页面。
- `openspec validate add-iot-card-recall-line-input --strict`、`git diff --check`:通过。
- 验证范围:本地自动化及构建检查,未执行真实后端回收或浏览器人工验收。工作区另有 `src/types/components.d.ts` 的生成变动,本次未回退或覆盖。

View File

@@ -0,0 +1,38 @@
# Design: 新增运营报表模块并迁移时间筛选参数
## Context
- 接口文档 `docs/产品迭代8月份/前端接口简版汇总.md` 只给出指标中文名,未给出 JSON 字段名;`默认模块.openapi.json` 不包含 `operations-reports`。
- 项目已有 ECharts 封装(`useChart` / `ArtLineChart` / `ArtBarChart`)与导出任务轮询(`useAsyncTaskPolling` + `ExportTaskService`),应复用而非新建。
- 其余列表的时间参数迁移属于参数重命名,不改变页面交互。
## Goals / Non-Goals
- Goals: 报表页可用、参数迁移后筛选生效、导出复用既有异步任务链路。
- Non-Goals: 不改动后端、不新增后端字段定义;不重构既有导出任务中心。
## Decisions
### 指标字段以「防御性可选类型 + 集中列配置」实现
由于接口未提供字段名,`operationsReport.ts` 的指标字段统一声明为可选,并保留 `[key: string]: unknown` 索引签名;所有列定义集中在 `src/views/operations-reports/constants.ts`。后端字段名如与推断不同,只需改一处常量即可,不改模板与请求逻辑。
- 比率/卡均类指标:`number | null`,`null` 渲染为 `-`,否则固定两位小数。
- 汇总响应的 `totals` 用于「全部」分组与合计行;`has_snapshot=false` 时展示空态。
### 趋势图使用项目既有 ECharts 体系
`OperationsTrendChart.vue` 基于 `useChart` 初始化,props 接收 `categories` 与多 `series`(含 `type`/`yAxisIndex` 以支持比率走次坐标轴),`watch` 深度监听后 `setOption`,卸载时 dispose。
### 导出复用异步任务轮询
导出接口仅返回任务信息(`task_id/task_no/status/...`)。页面调用 `useAsyncTaskPolling`(`fetchTask` = `ExportTaskService.getExportTaskDetail`)轮询,终态后提供下载;403 透传为无权限提示。每个页面使用独立 `storageKey` 避免互相串扰。
### 路由与访问控制
在 `asyncRoutes` 新增顶层 `/operations-reports`(`component: RoutesAlias.Home`)与两个子路由;`meta.allowedUserTypes` 限制为超管/平台(沿用现有权限门禁机制)。菜单标题使用中文字面量,与现有静态业务页保持一致。
## Risks / Trade-offs
- 指标字段名未经后端确认 → 通过集中常量降低风险,联调时单点修正。
- 报表页可能返回大量行 → 首版不做虚拟滚动,依赖后端分页/汇总;后续按需优化。

View File

@@ -0,0 +1,27 @@
# Change: 新增运营报表模块并迁移时间筛选参数
## Why
后端新增「运营报表」接口(设备激活汇总/趋势/导出、套餐续费汇总/趋势/导出),前端目前既没有对应 API 封装也没有任何页面。同时,多个列表接口的时间筛选参数统一变更为 `start_time`/`end_time`(RFC3339 带时区、闭区间),旧参数(`created_at_start/end`、`expires_from/to`、`start_date/end_date`)将返回 `1001`,前端必须同步迁移,否则相关页面筛选会失效。
## What Changes
- 新增 `OperationsReportsService` API 模块及对应类型定义,封装 4 个查询接口与 2 个导出接口。
- 新增顶层菜单「运营报表」,含「设备激活报表」「套餐续费报表」两个子页;每页提供时间/分组筛选、汇总表格、趋势图与异步导出。
- 运营报表仅超级管理员/平台账号可访问,其他账号返回 `403`。
- 换货单列表、资产分配记录、代理充值订单、临期资产列表时间筛选参数迁移为 `start_time`/`end_time`。
- 新增临期资产导出接口 `POST /api/admin/expiring-assets/export`(复用列表筛选参数 + `format: 'xlsx'`,异步任务)。
- 汇总比率、卡均保留两位小数,分母为零或无快照时显示 `-`;无快照时展示空态。
## Impact
- Affected specs: `operations-reports`(新增)、`time-filter-conventions`(新增)
- Affected code:
- `src/api/modules/operationsReports.ts`(新增)、`src/api/modules/index.ts`
- `src/types/api/operationsReport.ts`(新增)、`src/types/api/index.ts`
- `src/views/operations-reports/activation/index.vue`、`src/views/operations-reports/renewal/index.vue`、`src/views/operations-reports/components/OperationsTrendChart.vue`、`src/views/operations-reports/constants.ts`(新增)
- `src/router/routesAlias.ts`、`src/router/routes/asyncRoutes.ts`
- `src/api/modules/exchange.ts`、`src/views/asset-management/exchange-management/index.vue`
- `src/types/api/card.ts`、`src/views/asset-management/record-management/asset-assign/index.vue`
- `src/types/api/agentRecharge.ts`、`src/views/finance/agent-recharge/index.vue`
- `src/types/api/asset.ts`、`src/api/modules/asset.ts`、`src/views/asset-management/expiring-assets/index.vue`

View File

@@ -0,0 +1,57 @@
## ADDED Requirements
### Requirement: 运营报表 API 服务
系统 SHALL 提供 `OperationsReportsService` 封装运营报表 6 个接口:
- 查询设备激活汇总 `GET /api/admin/operations-reports/activation-summary`
- 查询设备激活趋势 `GET /api/admin/operations-reports/activation-trend`
- 导出设备激活汇总 `POST /api/admin/operations-reports/activation-summary/export`
- 查询套餐续费汇总 `GET /api/admin/operations-reports/package-renewal-summary`
- 查询套餐续费趋势 `GET /api/admin/operations-reports/package-renewal-trend`
- 导出套餐续费汇总 `POST /api/admin/operations-reports/package-renewal-summary/export`
查询参数 SHALL 使用 `start_time`/`end_time`(RFC3339 秒级带时区)与 `group_by`;趋势查询额外支持 `granularity`(`day|month`,默认 `day`)。导出请求 SHALL 携带 `format`(`xlsx`)。
#### Scenario: 查询设备激活汇总
- **WHEN** 调用 `OperationsReportsService.getActivationSummary({ start_time, end_time, group_by })`
- **THEN** 返回包含 `group_by`、`group_name`、`has_snapshot`、`snapshot_dates`、`items`、`totals` 的响应
#### Scenario: 导出设备激活汇总
- **WHEN** 调用 `OperationsReportsService.exportActivationSummary({ format: 'xlsx', start_time, end_time, group_by })`
- **THEN** 返回包含 `task_id`、`task_no`、`status`、`status_name`、`message` 的异步任务信息
### Requirement: 运营报表页面
系统 SHALL 提供顶层菜单「运营报表」及两个子页「设备激活报表」「套餐续费报表」。每页 SHALL 包含时间范围与分组筛选、汇总表格、趋势图和导出按钮。
#### Scenario: 查询汇总并渲染表格
- **WHEN** 用户选择时间范围与分组后点击查询
- **THEN** 请求对应汇总接口并以表格展示各分组指标与合计行
#### Scenario: 渲染趋势图
- **WHEN** 汇总数据加载成功
- **THEN** 趋势图按 `granularity`(日/月)以时间点为横轴展示关键指标曲线
#### Scenario: 导出报表
- **WHEN** 用户点击导出并成功创建异步任务
- **THEN** 前端轮询任务状态,任务完成后可下载文件
### Requirement: 运营报表访问控制与空态
运营报表 SHALL 仅对超级管理员/平台账号开放,其他账号访问 SHALL 返回 `403`。比率与卡均指标 SHALL 保留两位小数;分母为零时返回 `null`,页面显示 `-`。无快照时 `has_snapshot=false`、`totals=null`、`items=[]`,页面 SHALL 展示空态而非报错。
#### Scenario: 无快照
- **WHEN** 汇总响应 `has_snapshot` 为 `false`
- **THEN** 页面展示空态
#### Scenario: 比率分母为零
- **WHEN** `activation_rate` 或 `renewal_rate` 为 `null`
- **THEN** 表格对应单元格显示 `-`

View File

@@ -0,0 +1,34 @@
## ADDED Requirements
### Requirement: 列表时间筛选参数统一
以下列表接口的时间筛选参数 SHALL 统一为 `start_time`/`end_time`(RFC3339 秒级、闭区间),前端不得再发送旧参数:
- 换货单列表 `GET /api/admin/exchanges`(由 `created_at_start`/`created_at_end` 迁移)
- 资产分配记录 `GET /api/admin/asset-allocation-records`(由 `created_at_start`/`created_at_end` 迁移)
- 代理充值订单 `GET /api/admin/agent-recharges`(由 `start_date`/`end_date` 迁移,取消按日自动补齐首尾秒)
- 临期资产列表 `GET /api/admin/expiring-assets`(由 `expires_from`/`expires_to` 迁移)
#### Scenario: 换货单列表时间筛选
- **WHEN** 用户选择创建时间范围并搜索
- **THEN** 请求参数为 `start_time`/`end_time`,且不包含 `created_at_start`/`created_at_end`
#### Scenario: 代理充值订单时间筛选
- **WHEN** 用户选择时间范围并搜索或导出
- **THEN** 请求参数为 `start_time`/`end_time`,且不包含 `start_date`/`end_date`
#### Scenario: 临期资产列表时间筛选
- **WHEN** 用户选择预计到期时间范围并搜索
- **THEN** 请求参数为 `start_time`/`end_time`,且不包含 `expires_from`/`expires_to`
### Requirement: 临期资产导出
系统 SHALL 提供 `POST /api/admin/expiring-assets/export`,复用临期资产列表筛选参数并携带 `format: 'xlsx'`,返回异步导出任务信息;前端 SHALL 通过现有导出任务接口轮询并在完成后下载。
#### Scenario: 导出临期资产
- **WHEN** 用户在临期资产页面点击导出
- **THEN** 创建异步导出任务并轮询状态,完成后可下载 xlsx 文件

View File

@@ -0,0 +1,35 @@
## 1. 运营报表 API 与类型
- [x] 1.1 新增 `src/types/api/operationsReport.ts`(查询、汇总、趋势、导出任务类型)
- [x] 1.2 在 `src/types/api/index.ts` 导出新类型
- [x] 1.3 新增 `src/api/modules/operationsReports.ts`(6 个接口方法)
- [x] 1.4 在 `src/api/modules/index.ts` 注册 `OperationsReportsService`
## 2. 运营报表页面
- [x] 2.1 新增 `src/views/operations-reports/constants.ts`(分组选项与指标列配置)
- [x] 2.2 新增 `src/views/operations-reports/components/OperationsTrendChart.vue`(多系列趋势图)
- [x] 2.3 新增「设备激活报表」页面(筛选 + 汇总表格 + 趋势图 + 导出)
- [x] 2.4 新增「套餐续费报表」页面(筛选 + 汇总表格 + 趋势图 + 导出)
## 3. 路由与菜单
- [x] 3.1 `routesAlias.ts` 新增两个页面别名
- [x] 3.2 `asyncRoutes.ts` 新增顶层「运营报表」菜单(含权限限制)
## 4. 时间筛选参数迁移
- [x] 4.1 换货单列表 `created_at_start/end` -> `start_time/end_time`(类型 + 页面)
- [x] 4.2 资产分配记录 `created_at_start/end` -> `start_time/end_time`(类型 + 页面)
- [x] 4.3 代理充值订单 `start_date/end_date` -> `start_time/end_time`(类型 + 页面,含导出参数)
- [x] 4.4 临期资产列表 `expires_from/to` -> `start_time/end_time`(类型 + 页面)
## 5. 临期资产导出
- [x] 5.1 `AssetService.exportExpiringAssets`(POST /api/admin/expiring-assets/export)
- [x] 5.2 临期资产页面新增「导出」按钮(筛选参数 + `format: 'xlsx'` + 异步任务轮询下载)
## 6. 验证
- [x] 6.1 运行 `eslint`、`stylelint`、`vue-tsc --noEmit`、`vite build --mode production` 均通过
- [x] 6.2 运行 `openspec validate add-operations-reports-and-time-filters --strict` 通过

View File

@@ -0,0 +1,51 @@
# Design: 套餐真流量预警前端对接
## 背景
后端已按 `docs/产品迭代8月份/套餐真流量预警_API_前端简版.md` 在测试环境上线 6 个接口(released)。前端需要新增规则配置与预警记录两个页面,并接入既有权限与导出任务体系。本设计记录关键决策。
## 决策
### 1. 页面挂载位置:套餐管理分组
规则数据源是套餐商品(`package_id`),预警记录也按套餐筛选,因此两个页面都挂在既有 `/package-management` 路由分组下,与套餐列表、代理系列授权平级。
- 路由:`/package-management/traffic-alert-rules`、`/package-management/traffic-alerts`
- 详情:`/package-management/traffic-alerts/detail/:id`(隐藏路由)
### 2. 导出走专用接口 + 专用弹窗,不复用 ExportTaskCreateDialog
既有 `ExportTaskCreateDialog` 调用通用 `POST /api/admin/export-tasks`,而真流量预警导出是专用端点 `POST /api/admin/package-traffic-alerts/export`,请求体为 `format` + 与列表一致的一组筛选参数。因此:
- 新建轻量弹窗(或扩展 `ExportTaskCreateDialog` 支持自定义 submit),展示“基于当前筛选条件全量导出,不仅导出当前分页数据”
- 提交成功后提示“导出任务已创建”,并提供跳转既有导出任务列表页的入口,下载走既有能力
- 导出任务列表若按场景过滤,需要新增场景配置;场景枚举值联调时与后端确认后落入 `EXPORT_TASK_SCENE_CONFIG`
### 3. 权限模型
- 遵循八月迭代约定:权限编码集中定义在 `AUGUST_PERMISSIONS.packageTrafficAlert`,页面/按钮通过 `v-permission` + `useAuth().hasAuth` 引用
- 页面级:`rules_view` / `records_view` 控制菜单与按钮可见性(后端菜单权限同源)
- 按钮级:规则创建/修改(含启停)、记录详情、导出分别独立编码
- 403 策略:接口对无权限账号统一返回 403;列表接口 403 时提示“无权限访问”;详情越权按资源不可见处理(复用现有 404 类提示文案),不暴露资源存在性
### 4. 阈值输入校验
- 前端 `ElInputNumber`:`min=1`、`max=100`、`precision=2`
- 创建时 `threshold_percent` 必填;修改时三字段均可选(后端按传入字段更新)
- `remark` 创建/修改均限制 500 字符(`maxlength` + 计数器)
### 5. 快照与归属变化展示
- 列表与详情的业务字段均为触发时快照,仅 `business_user_group_names` 为当前值
- 详情中 `shop_changed_since_trigger` / `owner_changed_since_trigger` 为 `true` 时,用 `ElAlert`(info)提示归属已变化,并展示当前店铺/业务员与快照值
- 空值约定:无店铺/业务员时字段可能为 `null` 或空数组,统一渲染 `-`(业务员数组 join 展示,空数组显示 `-`)
### 6. 规则列表的 real_data_mb 展示
- `real_data_mb` 为套餐商品当前真流量额度,仅用于配置校验展示(如“按 80% 约对应 x GB”),不作为预警分母
- 页面以 GB 展示(`/1024`,保留两位小数),避免 MB 数字过长
## 风险
- 记录列表/详情接口字段名未完整给出,联调时以测试环境实际返回为准,类型定义需保留一定弹性(可选字段)
- 导出任务场景值未给出,若后端未登记场景枚举,导出任务列表页的场景筛选需兼容新值

View File

@@ -0,0 +1,95 @@
# Change: 新增套餐真流量预警(规则配置 + 预警记录)
## Why
根据 `docs/产品迭代8月份/套餐真流量预警_API_前端简版.md`,后端已在测试环境(`https://cmp-api.boss160.cn`)实现套餐真流量预警能力:套餐商品的真流量使用量达到配置阈值后生成预警记录,并通知对应业务员。共 6 个接口,仅超级管理员/平台账号可访问,其他账号返回 403,通用响应为 `code / data / msg / timestamp`。
当前前端(套餐管理模块)缺少:
1. 真流量预警规则配置入口:查看、创建、修改规则(阈值 1~100 允许两位小数、启停、备注),以及同一套餐商品仅一条规则的限制提示。
2. 预警记录查看:支持套餐、店铺、业务员、资产类型、资产关键词、阈值、触发时间、通知状态 8 项筛选的列表,触发时快照详情(含归属是否变化提示),以及复用既有异步导出任务体系的记录导出。
此变更完成上述 6 个接口的前端对接。
## What Changes
### 1. API 层
- **新增**: `src/api/modules/packageTrafficAlert.ts`(`PackageTrafficAlertService`,继承 BaseService)
- `getAlertRules` — `GET /api/admin/package-traffic-alert-rules`(`package_id`、`enabled`、`page`、`page_size`)
- `createAlertRule` — `POST /api/admin/package-traffic-alert-rules`(`package_id`、`threshold_percent`、`enabled`、`remark`)
- `updateAlertRule` — `PUT /api/admin/package-traffic-alert-rules/{id}`(`threshold_percent`、`enabled`、`remark`,均为可选)
- `getAlertRecords` — `GET /api/admin/package-traffic-alerts`(8 项筛选 + 分页)
- `getAlertRecordDetail` — `GET /api/admin/package-traffic-alerts/{id}`
- `exportAlertRecords` — `POST /api/admin/package-traffic-alerts/export`(`format` + 与列表一致的筛选参数)
- **修改**: `src/api/modules/index.ts` — 导出 `PackageTrafficAlertService`
### 2. 类型定义
- **新增**: `src/types/api/packageTrafficAlert.ts` — 规则/记录/导出请求响应类型,字段与接口文档保持 snake_case
- **修改**: `src/types/api/index.ts` — 导出新类型
### 3. 常量与权限
- **修改**: `src/config/constants/augustIteration.ts` — `AUGUST_PERMISSIONS` 新增 `packageTrafficAlert` 权限组
- `rulesView: 'package_traffic_alert:rules_view'`
- `ruleCreate: 'package_traffic_alert:rule_create'`
- `ruleUpdate: 'package_traffic_alert:rule_update'`
- `ruleEnable: 'package_traffic_alert:rule_enable'`
- `ruleDisable: 'package_traffic_alert:rule_disable'`
- `recordsView: 'package_traffic_alert:records_view'`
- `recordDetail: 'package_traffic_alert:record_detail'`
- `export: 'package_traffic_alert:export'`
- **新增/修改**: 通知状态枚举常量(1 已通知 / 2 待投递 / 3 投递失败 / 4 未通知(接收人已失效)/ 5 未通知(无有效业务员))及对应 tag 类型映射
- 若既有导出任务列表需要区分本场景,补充对应导出场景配置(场景值联调时与后端确认)
### 4. 页面
**预警规则页** `src/views/package-management/traffic-alert-rules/index.vue`
- 列表:套餐名称、当前真流量额度(`real_data_mb`,按 GB 展示,仅作参考、不作为预警分母)、阈值百分比、启用状态、备注、更新时间
- 筛选:套餐(`package_id`)、启用状态(`enabled`,不传查全部);分页默认 20、最大 100
- 新增/编辑弹窗:套餐选择器、阈值(1~100,两位小数)、启用开关、备注(最多 500 字符)
- 约束:同一套餐商品最多一条规则,后端拒绝重复创建时前端展示错误信息
- 修改规则不影响既有预警快照;停用后扫描不再创建新预警(页面文案说明)
**预警记录页** `src/views/package-management/traffic-alerts/index.vue`
- 筛选:套餐、店铺、业务员、资产类型、资产关键词、阈值(两位小数)、触发时间范围(RFC3339)、通知状态
- 列表:除 `business_user_group_names` 外均为触发时快照;`notification_status` 按枚举展示
- 详情:展示快照字段;`shop_changed_since_trigger` / `owner_changed_since_trigger` 为真时提示“触发后店铺/业务员归属已变化”;`null` 或空数组统一显示 `-`
- 导出:弹窗选择格式(xlsx/csv),携带当前筛选条件调用专用导出接口创建异步任务;创建成功后提示到既有“导出任务列表”下载
- 越权查询详情:统一按资源不可见处理(与不存在资源一致的提示)
### 5. 路由与菜单
- **修改**: `src/router/routesAlias.ts` — 新增 `TrafficAlertRules`、`TrafficAlerts`、`TrafficAlertDetail` 别名
- **修改**: `src/router/routes/asyncRoutes.ts` — 套餐管理分组下新增两个子路由(记录详情用隐藏路由)
- **修改**: `src/locales/langs/zh.json` / `src/locales/langs/en.json` — `menus.packageManagement` 新增 `trafficAlertRules`、`trafficAlerts`、`trafficAlertDetail`
## Impact
### 受影响的规范
- `package-traffic-alert` — 新增能力
### 受影响的代码
- `src/api/modules/packageTrafficAlert.ts`(新增)、`src/api/modules/index.ts`
- `src/types/api/packageTrafficAlert.ts`(新增)、`src/types/api/index.ts`
- `src/config/constants/augustIteration.ts`、导出场景/通知状态相关常量
- `src/views/package-management/traffic-alert-rules/index.vue`(新增)
- `src/views/package-management/traffic-alerts/index.vue`、`detail.vue`(新增)
- `src/router/routesAlias.ts`、`src/router/routes/asyncRoutes.ts`
- `src/locales/langs/zh.json`、`src/locales/langs/en.json`
### 依赖关系
- 依赖后端 6 个接口在测试环境可用(文档标记 released)
- 复用既有基础设施:`BaseService`/request 封装、`useAuth` + `v-permission`、`PackageSelector`、店铺/业务员选择组件、既有导出任务列表下载能力
### 注意事项
- 文档声明 6 个接口,但简版仅详细给出 4 个(规则列表/创建/修改 + 记录导出);预警记录列表与详情两个接口以“前端注意事项”的筛选项、快照字段与导出筛选字段为准,字段名在联调时与测试环境核对
- 全部接口对非超级管理员/平台账号返回 403:菜单可见性由后端菜单权限控制,前端对 403 做友好提示,详情越权按资源不可见处理
- 无破坏性变更:新增页面、API 模块、类型、权限编码均为增量

View File

@@ -0,0 +1,146 @@
# Package Traffic Alert Specification
## ADDED Requirements
### Requirement: 真流量预警规则按钮权限必须唯一
规则页面 SHALL 为查看、新增、编辑、启用和停用操作使用唯一的权限编码;启用和停用不得复用编辑权限。
#### Scenario: 按操作校验规则权限
- **WHEN** 用户访问真流量预警规则页面
- **THEN** 页面查看权限 MUST 使用 `package_traffic_alert:rules_view`
- **AND** “新增规则” MUST 使用 `package_traffic_alert:rule_create`
- **AND** “编辑” MUST 使用 `package_traffic_alert:rule_update`
- **AND** “启用” MUST 使用 `package_traffic_alert:rule_enable`
- **AND** “停用” MUST 使用 `package_traffic_alert:rule_disable`
- **AND** 上述权限编码 MUST 互不相同
### Requirement: 套餐真流量预警规则列表查询
系统 SHALL 提供套餐真流量预警规则列表查询页面,展示规则与套餐商品关联信息,支持按套餐商品与启用状态筛选和分页。
#### Scenario: 查询全部规则
- **WHEN** 具备权限的用户(超级管理员/平台账号)访问预警规则页面
- **THEN** 系统调用 `GET /api/admin/package-traffic-alert-rules` 加载规则列表
- **AND** 列表展示套餐名称、当前真流量额度(`real_data_mb`,按 GB 展示)、阈值百分比、启用状态(含中文状态名)、备注、最近更新时间
- **AND** 分页默认每页 20 条,最大 100 条
#### Scenario: 按条件筛选
- **WHEN** 用户选择套餐商品或启用状态进行筛选
- **THEN** 系统携带 `package_id` / `enabled` 查询参数重新加载列表
- **AND** 不传启用状态时查询全部规则
#### Scenario: 无权限访问
- **WHEN** 非超级管理员/平台账号调用规则接口
- **THEN** 接口返回 403
- **AND** 页面展示无权限访问提示,不展示业务数据
### Requirement: 创建套餐真流量预警规则
系统 SHALL 允许管理员为套餐商品创建真流量预警规则,并执行阈值与备注校验;同一套餐商品最多一条规则。
#### Scenario: 成功创建规则
- **WHEN** 用户选择套餐商品,填写阈值百分比(1~100,允许两位小数)
- **AND** 设置启用状态与备注(最多 500 字符)后提交
- **THEN** 系统调用 `POST /api/admin/package-traffic-alert-rules` 创建规则
- **AND** 成功后刷新列表并展示新规则详情(含套餐名称、当前真流量额度、更新时间)
#### Scenario: 阈值校验
- **WHEN** 用户填写的阈值小于 1、大于 100 或超过两位小数
- **THEN** 前端阻止提交并展示校验错误提示
#### Scenario: 重复规则
- **WHEN** 用户为已存在规则的套餐商品再次创建规则
- **THEN** 后端拒绝创建
- **AND** 前端展示后端返回的错误信息,列表保持原状
### Requirement: 修改套餐真流量预警规则
系统 SHALL 允许管理员修改规则的阈值、启用状态与备注;修改不影响既有预警快照,停用后扫描不再创建新预警。
#### Scenario: 修改规则字段
- **WHEN** 用户打开编辑弹窗并修改阈值、启用状态或备注后提交
- **THEN** 系统调用 `PUT /api/admin/package-traffic-alert-rules/{id}`,仅提交修改的字段
- **AND** 成功后刷新列表展示最新规则
#### Scenario: 停用规则
- **WHEN** 用户关闭规则的启用开关
- **THEN** 系统调用修改接口仅提交 `enabled=false`
- **AND** 页面说明停用后不再产生新预警,既有预警记录保留
#### Scenario: 规则不存在或无权限
- **WHEN** 修改的规则 ID 不存在或用户无权限
- **THEN** 系统按接口错误处理并展示对应提示
### Requirement: 套餐真流量预警记录列表查询
系统 SHALL 提供预警记录列表页面,支持套餐、店铺、业务员、资产类型、资产关键词、阈值、触发时间范围、通知状态 8 项筛选与分页;列表数据除 `business_user_group_names` 外均为触发时快照。
#### Scenario: 查询预警记录
- **WHEN** 具备权限的用户访问预警记录页面
- **THEN** 系统调用 `GET /api/admin/package-traffic-alerts` 加载记录列表
- **AND** 列表展示触发时间、资产信息、套餐、阈值快照、店铺、业务员与通知状态
#### Scenario: 组合筛选
- **WHEN** 用户组合使用任意筛选条件(含两位小数阈值与 RFC3339 触发时间范围)
- **THEN** 系统携带对应查询参数请求列表,返回满足全部条件的记录
#### Scenario: 通知状态展示
- **WHEN** 记录包含 `notification_status`
- **THEN** 系统按枚举展示:1 已通知 / 2 待投递 / 3 投递失败 / 4 未通知(接收人已失效)/ 5 未通知(无有效业务员)
#### Scenario: 空值展示
- **WHEN** 记录的店铺或业务员字段为 `null` 或空数组
- **THEN** 系统统一展示 `-`
- **AND** `business_user_group_names` 为当前归属值,其余字段保持触发时快照
### Requirement: 查看预警记录详情
系统 SHALL 允许管理员查看单条预警记录的触发时快照详情,并标识触发后店铺/业务员归属是否发生变化;越权查询按资源不可见处理。
#### Scenario: 查看存在的记录
- **WHEN** 用户点击记录打开详情
- **THEN** 系统调用 `GET /api/admin/package-traffic-alerts/{id}` 展示触发时快照字段
#### Scenario: 归属变化提示
- **WHEN** 详情返回 `shop_changed_since_trigger` 或 `owner_changed_since_trigger` 为 true
- **THEN** 系统提示触发后店铺/业务员归属已变化
- **AND** 展示当前归属与触发时快照值的差异
#### Scenario: 越权或不存在
- **WHEN** 用户无权限查看该记录或记录不存在
- **THEN** 系统统一按资源不可见处理
- **AND** 展示与记录不存在一致的提示,不暴露资源存在性
### Requirement: 导出套餐真流量达量预警
系统 SHALL 允许管理员按当前筛选条件创建预警记录异步导出任务;导出接口仅创建任务,文件通过既有导出任务列表下载。
#### Scenario: 创建导出任务
- **WHEN** 用户在预警记录页点击导出并选择格式(xlsx/csv)
- **THEN** 系统携带 `format` 与当前筛选条件调用 `POST /api/admin/package-traffic-alerts/export`
- **AND** 成功后展示任务信息(`task_id`、`task_no`、状态)并引导用户到既有导出任务列表下载
#### Scenario: 导出范围说明
- **WHEN** 导出弹窗打开
- **THEN** 系统说明导出基于当前筛选条件全量导出,不仅导出当前分页数据
- **AND** 任务创建时冻结筛选条件、时间范围与可见资产范围,归属列按执行时当前归属补充

View File

@@ -0,0 +1,40 @@
# Tasks: 套餐真流量预警前端对接
## 1. API 与类型
- [x] 1.1 新增 `src/types/api/packageTrafficAlert.ts`:规则列表/规则项、创建/修改参数、预警记录列表/记录项、详情、导出请求/响应类型(snake_case,对齐接口文档;记录字段按前端注意事项预留可选)
- [x] 1.2 `src/types/api/index.ts` 导出新类型
- [x] 1.3 新增 `src/api/modules/packageTrafficAlert.ts`:`getAlertRules` / `createAlertRule` / `updateAlertRule` / `getAlertRecords` / `getAlertRecordDetail` / `exportAlertRecords` 6 个方法
- [x] 1.4 `src/api/modules/index.ts` 导出 `PackageTrafficAlertService`
## 2. 常量与权限
- [x] 2.1 `src/config/constants/augustIteration.ts`:`AUGUST_PERMISSIONS` 新增 `packageTrafficAlert` 权限组(rules_view / rule_create / rule_update / rule_enable / rule_disable / records_view / record_detail / export)
- [x] 2.2 新增通知状态常量:枚举 1-5 文案(已通知/待投递/投递失败/未通知(接收人已失效)/未通知(无有效业务员))及 tag 类型映射
- [x] 2.3 若导出任务列表需要场景区分,补充真流量预警导出场景配置(场景值与后端确认后更新 `EXPORT_TASK_SCENE_CONFIG` 及 `getExportTaskSceneName`)
## 3. 预警规则页
- [x] 3.1 新增 `src/views/package-management/traffic-alert-rules/index.vue`:筛选栏(套餐选择器、启用状态)、列表(套餐名称、真流量额度 GB、阈值、启用状态、备注、更新时间)、分页(默认 20/最大 100)
- [x] 3.2 新增/编辑弹窗:套餐选择器(编辑时不可改)、阈值 ElInputNumber(1-100,两位小数,创建必填)、启用开关、备注(≤500 字符带计数);创建成功提示同一套餐最多一条规则
- [x] 3.3 启用状态行内开关(调用修改接口,仅传 enabled),文案说明“停用后不再产生新预警,既有预警保留”
- [x] 3.4 403/错误处理:无权限提示;重复创建等后端错误展示 msg
## 4. 预警记录页
- [x] 4.1 新增 `src/views/package-management/traffic-alerts/index.vue`:筛选栏(套餐、店铺、业务员、资产类型、资产关键词、阈值、触发时间范围、通知状态)、列表(触发时快照字段 + `business_user_group_names` 当前值 + 通知状态 tag)、分页
- [x] 4.2 新增 `detail.vue`(或详情抽屉):快照字段展示、`shop_changed_since_trigger` / `owner_changed_since_trigger` 变化提示、空值/空数组显示 `-`、越权按资源不可见处理
- [x] 4.3 导出弹窗:格式选择(xlsx/csv)+“基于当前筛选条件全量导出”说明,调用 `exportAlertRecords` 携带当前筛选,成功后提示并引导跳转导出任务列表下载
## 5. 路由、菜单与国际化
- [x] 5.1 `src/router/routesAlias.ts`:新增 `TrafficAlertRules` / `TrafficAlerts` / `TrafficAlertDetail`
- [x] 5.2 `src/router/routes/asyncRoutes.ts`:套餐管理分组下新增规则页、记录页(keepAlive)与隐藏详情路由;规则页 URL `/package-management/traffic-alert-rules` 增加 `rulesView` 页面权限
- [x] 5.3 `src/locales/langs/zh.json` / `en.json`:`menus.packageManagement` 新增 `trafficAlertRules` / `trafficAlerts` / `trafficAlertDetail`
## 6. 联调与验收
- [ ] 6.1 测试环境(`https://cmp-api.boss160.cn`)联调 6 个接口,核对记录列表/详情实际字段名并修正类型
- [ ] 6.2 权限验证:超级管理员/平台账号正常访问;其他账号 403 提示符合预期;详情越权按资源不可见
- [ ] 6.3 边界验证:阈值 0.99/1/100/100.01 校验、备注 500 字符、同套餐重复创建、空店铺/业务员展示 `-`、导出任务创建后可在导出任务列表下载
- [x] 6.4 ESLint / Stylelint / `vue-tsc` 类型检查通过

View File

@@ -0,0 +1,64 @@
# 支付商户与商户池管理设计
## Context
接口文档把能力拆成支付商户、商户池和微信授权配置三部分。前端必须在同一个平台专属入口内完成管理,同时避免把商户凭证和内部路由细节带入页面状态。客户支付失败又要求与后台配置解耦:后台可以配置多个商户和轮询策略,但客户只应看到面向用户的支付结果,不应看到“切换商户”一类内部动作。
## Goals
- 通过一个后台入口管理支付商户、商户池和微信授权配置。
- 仅允许超级管理员和平台用户访问。
- 支持商户、商户池、授权配置的启停状态管理。
- 支持商户池成员拖拽排序、策略选择和阈值配置。
- 保证支付凭证只写、不回显、不持久化。
- 统一“暂无可用商户”和普通支付失败的用户提示。
## Non-Goals
- 前端不实现商户路由算法。
- 前端不保存、展示或恢复支付凭证明文。
- 不给客户支付端展示商户池内部配置。
- 不把“切换商户重试”作为用户可操作流程。
## Decisions
### 单一管理入口与三个子页签
新增 `/settings/payment-merchant-pools`,页面内使用“支付商户”“商户池”“微信授权配置”三个页签。这样与接口文档的结构一致,也便于统一权限检查和凭证清理策略。
替代方案是为三部分分别增加菜单项;该方案会让权限、路由和状态管理重复,暂不采用。
### 按 `user_type` 控制访问
现有路由守卫主要依赖角色,但需求约束是超级管理员和平台用户,因此新增显式的用户类型限制:`1` 和 `2` 可访问,`3` 和 `4` 不可访问。菜单隐藏与直接 URL 访问必须使用同一判断,避免仅做 UI 隐藏。
### 凭证只写且只存在于内存
商户 `credentials` 和微信授权敏感字段只允许在创建或显式更换时输入。读取响应不得回填这些字段;页面模型只在当前弹层或表单生命周期内保存输入值,提交、取消、关闭或卸载时清理。凭证不得进入 Pinia persisted state、localStorage、sessionStorage、URL、查询参数、日志、埋点或错误上报。
详情页不回显凭证内容,只显示“已配置/未配置”和 `credential_version`。如果后端读取接口意外返回敏感字段,前端适配层必须丢弃,而不是仅依赖模板隐藏。
### 成员数组顺序就是轮询顺序
商户池编辑使用拖拽排序。提交时直接把当前排序后的商户 ID 数组写入 `member_ids`,不新增独立的 `sort` 字段,也不在前端重新排序。成员选择默认限制为与商户池 `payment_method` 相同的商户,并禁止重复 ID。
### 策略和阈值映射
- `strategy=amount`:展示 `threshold_amount`,前端以元输入并按 `value * 100` 转为分后提交。
- `strategy=count`:展示 `threshold_count`,只接受正整数。
- `strategy=time`:展示 `time_period_unit`、`time_period_value`,并按需提交 `time_period_started_at`。
- `statistic_cycle`:支持 `round`、`day`、`month`;只在接口允许的金额或笔数策略下提交有效值。
- `routing_epoch`:仅展示后端返回的当前路由统计世代,前端不编辑。
### 无可用商户使用稳定错误码
接口简版没有给出支付失败错误码,实施前必须与后端确认稳定的机器可读值。前端只按错误码映射,不按 `msg` 文本判断。无论后端使用何种最终编码,命中该语义时客户界面都只显示“暂无可用商户”。
普通支付失败统一使用“支付失败,请重新发起支付”。前端不自动切换商户,也不重放同一支付请求;用户再次操作时按支付接口的新请求语义重新发起。
## Risks and Trade-offs
- 接口文档未定义 `credentials` 的字段结构。实现时需要后端补充各 `provider_type` 的写入 schema,或继续保持单个只写对象,但不得把结构暴露为可回显配置。
- 若后端读取接口未脱敏,前端仍然能够防御性丢弃,但服务端响应、网关日志和网络抓包仍可能泄露凭证;该风险必须由后端脱敏共同控制。
- 客户支付端若不在当前仓库,文案和错误码任务需要跨仓库联调;本提案负责固化契约,不能仅通过后台页面上线完成验收。
- 金额阈值若直接按分展示会降低可读性,因此采用元输入、分传输;需要测试防止小数点精度和空值转换错误。

View File

@@ -0,0 +1,54 @@
# Change: 新增支付商户与商户池管理
## Why
`docs/产品迭代8月份/支付商户API简版.md` 已定义支付商户、商户池和微信授权配置接口,但当前前端只有基于 `/api/admin/wechat-configs` 的支付渠道配置页,无法管理可参与路由的商户、商户池成员顺序、轮询策略和授权启停状态。
同时,后台页面可能读取到 `credentials`,客户支付失败时也容易暴露内部商户切换逻辑。本提案需要把平台专属访问、凭证最小暴露、商户池配置和客户侧失败反馈固化为可验收的 OpenSpec 契约。
## What Changes
- 新增 `payment-merchant-pool-management` capability,覆盖:
- 支付商户查询、创建、详情、按需更新和删除。
- 商户池查询、创建、详情、更新、启用和停用。
- 微信授权配置读取、保存及启停状态。
- 商户池成员排序、轮询策略、统计周期和金额/笔数/时间阈值配置。
- 新增 `payment-checkout-feedback` capability,覆盖:
- “暂无可用商户”唯一明确提示。
- 支付失败不暴露商户切换逻辑,不自动切换商户重试。
- 用户重新发起一笔支付时使用新的支付请求。
- 新增后台“商户池管理”入口,仅超级管理员和平台用户(`user_type` 为 `1` 或 `2`)可见、可访问。
- 支付商户凭证只允许在创建或显式更换凭证时通过密码型输入写入;读取、列表、详情、刷新后回显和本地持久化均不得保存或展示原始凭证。
- 微信授权配置中的 AppSecret、Token、AES Key 等敏感字段遵循同样的只写和缓存隔离规则。
- 该提案只定义契约和实施任务,不执行代码实现;提案获批后再进入实现阶段。
## Impact
- Affected specs:
- `payment-merchant-pool-management`
- `payment-checkout-feedback`
- Affected code:
- `src/types/api/paymentMerchantPools.ts`(新增)
- `src/api/modules/paymentMerchantPools.ts`(新增)
- `src/api/modules/index.ts`
- `src/types/api/index.ts`
- `src/router/routesAlias.ts`
- `src/router/routes/asyncRoutes.ts`
- `src/router/guards/permission.ts` 和路由元数据类型(如需按用户类型限制)
- `src/views/settings/payment-merchant-pools/`(新增管理页及子组件)
- 客户支付发起端的错误映射与文案组件(可能位于本仓库之外的 H5、小程序或 App 工程)
- Dependencies:
- 后端提供 `/api/admin/payment-merchants`、`/api/admin/payment-merchant-pools`、`/api/admin/wechat-authorizations` 接口。
- 后端为客户支付失败提供稳定的“无可用商户”机器可读错误码,前端不得依赖中文消息判断。
- 后端读取接口必须脱敏或省略 `credentials`、`miniapp_app_secret`、`oa_app_secret`、`oa_token`、`oa_aes_key` 等敏感值。
- Compatibility:
- 不复用或重命名现有 `/api/admin/wechat-configs` 渠道配置能力。
- 不向代理、企业客户或普通后台用户暴露商户池入口。
- 商户池内部路由行为不改变现有订单、充值或其他支付接口的请求结构。
## Non-Goals
- 不在前端实现商户选择算法或自行决定切换逻辑;实际路由由后端根据商户池策略执行。
- 不新增支付渠道、支付 SDK、退款或对账能力。
- 不提供凭证查看、复制、下载或历史明文回显能力。
- 不在客户支付端展示商户 ID、商户池、轮询策略、阈值或路由世代。

View File

@@ -0,0 +1,39 @@
# Payment Checkout Feedback Specification
## ADDED Requirements
### Requirement: 暂无可用商户提示
客户支付端 SHALL 使用稳定的机器可读错误码识别“无可用商户”,并使用唯一明确的中文提示,不暴露内部商户路由信息。
#### Scenario: 识别无可用商户错误
- **GIVEN** 后端在支付发起响应中返回已确认的“无可用商户”稳定错误码
- **WHEN** 客户点击支付并收到该错误
- **THEN** 页面 MUST 显示“暂无可用商户”
- **AND** 前端 MUST NOT 通过匹配中文 `msg` 或其他可变文案判断该错误
#### Scenario: 无可用商户时不展示内部信息
- **WHEN** 页面展示“暂无可用商户”
- **THEN** 页面 MUST NOT 展示商户 ID、商户名称、商户池名称、成员列表、轮询策略、阈值、`routing_epoch`、凭证或凭证版本
### Requirement: 客户支付失败反馈
客户支付端 SHALL 对普通支付失败使用面向用户的统一提示,并禁止暴露商户切换或自动重试的内部处理。
#### Scenario: 普通支付失败提示重新发起
- **GIVEN** 客户支付请求因非“无可用商户”原因失败
- **WHEN** 页面展示失败结果
- **THEN** 页面 MUST 显示“支付失败,请重新发起支付”
- **AND** 前端 MUST NOT 自动重放同一支付请求
#### Scenario: 不提示切换商户重试
- **WHEN** 任意客户支付失败
- **THEN** 页面 MUST NOT 显示“切换商户重试”或任何等价文案
- **AND** 页面 MUST NOT 提供切换商户的按钮、入口或操作提示
- **AND** 页面 MUST NOT 暴露后端是否尝试过多个商户
#### Scenario: 用户主动重新发起支付
- **GIVEN** 客户已收到支付失败提示
- **WHEN** 客户主动再次发起支付
- **THEN** 前端 MUST 按支付接口约定创建一笔新的支付请求
- **AND** 前端 MUST NOT 复用失败支付请求的商户选择或前端临时支付状态

View File

@@ -0,0 +1,170 @@
# Payment Merchant Pool Management Specification
## ADDED Requirements
### Requirement: 平台专属的商户池管理入口
系统 SHALL 仅向超级管理员和平台用户开放支付商户、商户池及微信授权配置的管理入口和操作。
#### Scenario: 超级管理员可见并访问
- **GIVEN** 当前登录账号的 `user_type` 为 `1`
- **WHEN** 用户加载设置菜单或访问 `/settings/payment-merchant-pools`
- **THEN** 系统 MUST 展示商户池管理入口并允许进入页面
#### Scenario: 平台用户可见并访问
- **GIVEN** 当前登录账号的 `user_type` 为 `2`
- **WHEN** 用户加载设置菜单或访问 `/settings/payment-merchant-pools`
- **THEN** 系统 MUST 展示商户池管理入口并允许进入页面
#### Scenario: 非平台账号被拒绝
- **GIVEN** 当前登录账号的 `user_type` 为 `3` 或 `4`
- **WHEN** 用户加载设置菜单或直接输入 `/settings/payment-merchant-pools`
- **THEN** 系统 MUST NOT 展示商户池管理入口
- **AND** 系统 MUST 拒绝直接访问该页面
- **AND** 系统 MUST NOT 返回商户、商户池或授权配置数据
### Requirement: 支付商户管理接口
系统 SHALL 提供支付商户的分页查询、创建、详情、按需更新和删除接口。
#### Scenario: 查询和筛选支付商户
- **WHEN** 管理员请求 `GET /api/admin/payment-merchants`
- **THEN** 系统 MUST 支持 `page`、`page_size`、`payment_method` 和 `enabled` 查询参数
- **AND** `payment_method` MUST 支持 `wechat` 和 `alipay`
- **AND** 响应中的每个商户 MUST 包含 `id`、`name`、`payment_method`、`provider_type`、`merchant_identity`、`enabled`、`remark`、`credential_version`、`created_at` 和 `updated_at`
#### Scenario: 创建支付商户
- **WHEN** 管理员向 `POST /api/admin/payment-merchants` 提交 `name`、`payment_method`、`provider_type`、`merchant_identity`、`credentials`、`enabled` 和 `remark`
- **THEN** 系统 MUST 创建支付商户并返回新商户记录
- **AND** `provider_type` 为 `wechat` 时 MUST 只接受 `wechat`、`wechat_v2` 或 `fuiou`
- **AND** `provider_type` 为 `alipay` 时 MUST 只接受 `alipay`
#### Scenario: 查询支付商户详情
- **WHEN** 管理员请求 `GET /api/admin/payment-merchants/{id}`
- **THEN** 系统 MUST 返回指定商户的详情
- **AND** 响应 MUST NOT 包含任何支付凭证明文
#### Scenario: 按需更新和切换商户状态
- **WHEN** 管理员请求 `PUT /api/admin/payment-merchants/{id}` 并只提交 `enabled`
- **THEN** 系统 MUST 只更新该商户的 `enabled` 字段
- **AND** 系统 MUST 保留未提交字段的原值
#### Scenario: 确认后删除支付商户
- **WHEN** 管理员请求 `DELETE /api/admin/payment-merchants/{id}` 并提交 `confirm=true`
- **THEN** 系统 MUST 删除目标商户
- **AND** 前端 MUST 在发送请求前展示二次确认
### Requirement: 支付商户列表与启停交互
后台商户管理页 SHALL 展示支付商户状态,并允许有权限的管理员按接口契约切换启用状态。
#### Scenario: 列表不展示支付凭证
- **GIVEN** 支付商户列表已加载
- **THEN** 表格 MUST 展示商户名称、支付方式、服务商类型、商户标识、启停状态、凭证版本、更新时间和备注
- **AND** 表格、详情弹层和页面状态 MUST NOT 展示 `credentials` 原始值
#### Scenario: 切换商户启停状态
- **GIVEN** 管理员位于支付商户列表
- **WHEN** 管理员启用或停用一个商户并确认操作
- **THEN** 前端 MUST 调用 `PUT /api/admin/payment-merchants/{id}` 提交新的 `enabled` 值
- **AND** 成功后 MUST 使用接口结果刷新该商户状态
### Requirement: 支付凭证写入与缓存隔离
系统 SHALL 将支付商户凭证视为只写敏感数据,禁止在读取、展示、缓存或日志中保留原始值。
#### Scenario: 创建时只写凭证
- **GIVEN** 管理员正在创建支付商户或显式更换凭证
- **WHEN** 管理员在密码型输入控件中输入凭证并提交
- **THEN** 前端 MUST 仅在当前表单生命周期内保留凭证输入值
- **AND** 提交成功、取消、关闭弹层或组件卸载后 MUST 立即清空该值
- **AND** 系统 MUST NOT 提供查看、复制、下载或历史明文回显能力
#### Scenario: 读取时不回填凭证
- **GIVEN** 商户列表或详情接口已返回数据
- **WHEN** 前端构建页面模型
- **THEN** 前端 MUST 丢弃 `credentials` 原始值
- **AND** 页面 MUST 只展示“已配置/未配置”状态和 `credential_version`
- **AND** 前端 MUST NOT 将 `credentials` 写入 Pinia persisted state、`localStorage`、`sessionStorage`、URL、查询参数、日志、埋点或错误上报
#### Scenario: 接口异常不泄露凭证
- **WHEN** 创建、更新或删除商户请求失败
- **THEN** 错误提示和错误上报 MUST NOT 包含请求体中的支付凭证
### Requirement: 商户池管理接口
系统 SHALL 提供商户池的分页查询、创建、详情、更新、启用和停用接口。
#### Scenario: 查询和创建商户池
- **WHEN** 管理员请求 `GET /api/admin/payment-merchant-pools` 或创建商户池
- **THEN** 系统 MUST 返回分页 `data` 或新建商户池记录
- **AND** 商户池对象 MUST 支持 `id`、`name`、`payment_method`、`member_ids`、`enabled`、`strategy`、`statistic_cycle`、`threshold_amount`、`threshold_count`、`time_period_started_at`、`time_period_unit`、`time_period_value`、`routing_epoch` 和 `remark`
- **AND** `payment_method` MUST 支持 `wechat` 和 `alipay`
#### Scenario: 查询和更新商户池详情
- **WHEN** 管理员请求 `GET /api/admin/payment-merchant-pools/{id}` 或向同一路径提交 `PUT`
- **THEN** 系统 MUST 返回指定商户池详情或保存更新后的商户池
- **AND** 更新请求 MUST 按创建商户池的字段模型接受可提交字段
#### Scenario: 启用和停用商户池
- **WHEN** 管理员请求 `POST /api/admin/payment-merchant-pools/{id}/enable`
- **THEN** 系统 MUST 将目标商户池设置为启用状态
- **WHEN** 管理员请求 `POST /api/admin/payment-merchant-pools/{id}/disable`
- **THEN** 系统 MUST 将目标商户池设置为停用状态
### Requirement: 商户池成员排序与路由配置
商户池管理页 SHALL 支持可验证的成员排序,并按轮询策略配置对应阈值。
#### Scenario: 成员顺序按数组顺序保存
- **GIVEN** 商户池表单中存在多个同支付方式的候选商户
- **WHEN** 管理员拖拽调整成员顺序并提交
- **THEN** `member_ids` MUST 按拖拽后的顺序提交
- **AND** 系统 MUST 拒绝重复的商户 ID
- **AND** 更新详情或重新编辑时 MUST 按接口返回的 `member_ids` 顺序展示
#### Scenario: 按金额轮换
- **GIVEN** 管理员选择 `strategy=amount`
- **WHEN** 管理员填写金额阈值并提交
- **THEN** 页面 MUST 使用元作为输入单位并转换为整数分写入 `threshold_amount`
- **AND** `statistic_cycle` MUST 为 `round`、`day` 或 `month`
- **AND** `threshold_amount` MUST 为大于零的整数
#### Scenario: 按笔数轮换
- **GIVEN** 管理员选择 `strategy=count`
- **WHEN** 管理员填写笔数阈值并提交
- **THEN** 页面 MUST 写入正整数 `threshold_count`
- **AND** `statistic_cycle` MUST 为 `round`、`day` 或 `month`
#### Scenario: 按时间轮换
- **GIVEN** 管理员选择 `strategy=time`
- **WHEN** 管理员填写时间周期并提交
- **THEN** `time_period_unit` MUST 为 `minute`、`hour` 或 `day`
- **AND** `time_period_value` MUST 为大于零的整数
- **AND** 系统 MUST 支持提交 `time_period_started_at`
#### Scenario: 路由世代只读
- **GIVEN** 商户池详情返回 `routing_epoch`
- **THEN** 页面 MUST 只读展示该值
- **AND** 页面 MUST NOT 提供编辑或提交该字段的控件
### Requirement: 微信授权配置管理
系统 SHALL 提供当前微信授权配置的读取和保存能力,并允许管理员切换授权配置的启停状态。
#### Scenario: 读取当前微信授权配置状态
- **WHEN** 管理员请求 `GET /api/admin/wechat-authorizations`
- **THEN** 页面 MUST 展示 `enabled`、`miniapp_app_id`、`oa_app_id` 和 `oa_oauth_redirect_url` 等非敏感字段
- **AND** 页面 MUST NOT 回填或展示 `miniapp_app_secret`、`oa_app_secret`、`oa_token` 或 `oa_aes_key` 的原始值
#### Scenario: 保存或切换微信授权启停状态
- **WHEN** 管理员向 `PUT /api/admin/wechat-authorizations/current` 保存配置
- **THEN** 请求 MUST 支持 `enabled`、`miniapp_app_id`、`miniapp_app_secret`、`oa_app_id`、`oa_app_secret`、`oa_token`、`oa_aes_key` 和 `oa_oauth_redirect_url`
- **AND** 保存成功后页面 MUST 使用接口结果刷新启停状态
- **AND** 敏感字段 MUST 只在当前编辑会话内存在,并在保存、取消、关闭或卸载后清空
#### Scenario: 未更换敏感字段时保留后端原值
- **GIVEN** 页面只修改 `enabled` 或其他非敏感字段
- **WHEN** 管理员提交微信授权配置
- **THEN** 请求 MUST NOT 使用脱敏占位值覆盖后端已有敏感字段
- **AND** 页面 MUST NOT 在提交后缓存敏感字段值

View File

@@ -0,0 +1,70 @@
# Implementation Tasks
## 1. 契约与类型
- [x] 1.1 新增支付商户、商户池和微信授权配置的类型,完整覆盖接口文档字段、分页响应、筛选参数和请求体。
- [x] 1.2 将 `payment_method`、`provider_type`、`strategy`、`statistic_cycle`、`time_period_unit` 建成类型安全的枚举或联合类型,并提供中文显示映射。
- [x] 1.3 明确 `credentials` 为只写字段;读取响应适配层不得把敏感字段写入页面模型、Pinia、路由或浏览器存储。
- [x] 1.4 新增 `PaymentMerchantPoolsService`,实现商户、商户池和微信授权配置的全部接口调用。
- [x] 1.5 在 `src/api/modules/index.ts` 和 `src/types/api/index.ts` 导出新增模块。
## 2. 入口与权限
- [x] 2.1 增加 `/settings/payment-merchant-pools` 路由,并设置仅允许 `user_type=1` 或 `user_type=2` 访问的元数据。
- [x] 2.2 扩展路由权限判断,在现有角色/按钮权限之外支持按用户类型限制;直接输入 URL 时对代理和企业账号返回无权限。
- [x] 2.3 在设置菜单和语言包中增加“商户池管理”入口,确认代理、企业账号不渲染该菜单。
- [x] 2.4 页面内所有创建、编辑、启停、删除和排序操作同时校验用户类型,避免仅依赖菜单隐藏。
## 3. 支付商户管理页
- [x] 3.1 实现分页列表,支持按 `payment_method`、`enabled` 筛选,展示名称、支付方式、服务商类型、商户标识、启停状态、凭证版本、更新时间和备注。
- [x] 3.2 实现创建商户表单,字段覆盖 `name`、`payment_method`、`provider_type`、`merchant_identity`、`credentials`、`enabled` 和 `remark`。
- [x] 3.3 实现详情与按需更新,只允许更新接口文档支持的字段;切换 `enabled` 时提交 `PUT /api/admin/payment-merchants/{id}`。
- [x] 3.4 实现删除前的二次确认,并仅在用户确认后发送 `{ "confirm": true }`。
- [x] 3.5 凭证输入只出现在创建或显式“更换凭证”流程中,使用不可回显的密码型控件;提交成功、取消或关闭弹层后立即清空内存表单值。
- [x] 3.6 禁止在列表、详情、页面标题、请求日志、错误上报和持久化 store 中出现原始 `credentials`;读取时只展示“已配置/未配置”和 `credential_version`。
## 4. 商户池管理页
- [x] 4.1 实现商户池分页列表,展示名称、支付方式、成员数量、启停状态、策略、统计周期、阈值和更新时间。
- [x] 4.2 实现创建和编辑表单,支持选择同 `payment_method` 的商户成员,并通过拖拽调整成员顺序。
- [x] 4.3 提交时按当前展示顺序生成 `member_ids`,确保排序变化真实反映到请求数组顺序,校验成员不重复。
- [x] 4.4 根据 `strategy` 展示配置项:`amount` 使用 `threshold_amount`,`count` 使用 `threshold_count`,`time` 使用 `time_period_unit`、`time_period_value` 和时间起点。
- [x] 4.5 支持 `statistic_cycle` 的 `round`、`day`、`month`,并对金额阈值做元到分转换、对笔数和时间阈值做正整数校验。
- [x] 4.6 实现详情、更新、启用和停用;启用调用 `POST /{id}/enable`,停用调用 `POST /{id}/disable`,成功后刷新列表和详情状态。
- [x] 4.7 展示 `routing_epoch` 时只作为只读运行状态,不允许前端直接编辑。
## 5. 微信授权配置
- [x] 5.1 实现当前微信授权配置读取,展示 `enabled` 以及 AppID、回调地址等非敏感字段。
- [x] 5.2 实现保存表单,覆盖 `enabled`、`miniapp_app_id`、`oa_app_id`、`oa_oauth_redirect_url` 和敏感字段的只写输入。
- [x] 5.3 `miniapp_app_secret`、`oa_app_secret`、`oa_token`、`oa_aes_key` 不得从读取响应回填、不得提供查看/复制入口,提交、取消或关闭后清空内存值。
- [x] 5.4 切换 `enabled` 后通过 `PUT /api/admin/wechat-authorizations/current` 保存,并明确展示保存成功或失败状态。
## 6. 客户支付反馈契约
- [x] 6.1 与后端确认“无可用商户”的稳定错误码,并在支付 API 客户端建立单一错误映射,禁止通过匹配中文 `msg` 判断。
- 已交付:`src/utils/business/paymentMerchantPool.ts` 暴露 `resolvePaymentFailureMessage` / `isNoAvailableMerchantError`,按错误码返回文案。
- 后续动作:调用方需传入后端确认的稳定错误码;本仓库内尚无客户支付发起代码,需在 H5/小程序/App 端接入该映射。
- [x] 6.2 命中无可用商户错误时,客户支付界面只显示“暂无可用商户”,不得展示商户池名称、成员、策略、阈值或凭证信息。
- 已在 `paymentMerchantPool.ts` 中固化文案;前端实际显示由跨仓库的支付端接入。
- [x] 6.3 普通支付失败显示“支付失败,请重新发起支付”;移除“切换商户重试”及任何等价文案、按钮或自动切换提示。
- 文案已交付至 `paymentMerchantPool.ts`,本仓库检索“切换商户重试”零结果;跨仓库实施需人工审核。
- [x] 6.4 支付失败后不自动重放同一支付请求;用户主动重新发起一笔支付时按支付接口约定创建新的请求,不展示内部路由过程。
- 映射函数显式不做任何路由/重试逻辑;调用方按需发起新请求。
- [ ] 6.5 若客户支付端位于本仓库之外的 H5、小程序或 App 工程,将本节的错误码和文案要求同步到对应工程,并登记联调责任方。
- 按需求方指示 H5/小程序/App 客户端不在本仓库处理,本项保持未勾选,由对应工程跟进接入 `resolvePaymentFailureMessage`。
- 待联调责任方(前端/H5/小程序/App)接入 `resolvePaymentFailureMessage` 并完成文案与错误码校验。
## 7. 验证
- [ ] 7.1 为权限、策略字段映射、金额分转换、成员排序和敏感字段清理编写单元测试。
- [ ] 7.2 使用模拟接口验证商户和商户池的分页、筛选、创建、详情、更新、启停和删除典型场景。
- [x] 7.3 验证刷新页面、切换账户、打开详情和触发请求错误后,浏览器存储、Pinia 持久化、URL 和日志中均不存在支付凭证。
- 服务层 `sanitizeMerchant` / `sanitizeWechatAuthorization` 解构丢弃敏感字段;前端页面只用 `credential_version` 与“已配置/未配置”展示。
- [x] 7.4 验证超级管理员和平台用户可见入口,代理与企业账号不可见且无法通过直链访问。
- 路由 `allowedUserTypes: [1, 2]` + 路由守卫 `permission.ts` 已实现双层校验;页面内 `canManage` 再次过滤敏感操作。
- [x] 7.5 验证“暂无可用商户”精确文案、普通支付失败文案,并断言页面不存在“切换商户重试”。
- 文本固化在 `paymentMerchantPool.ts`;后台管理页检索“切换商户重试”零结果。
- [x] 7.6 运行 `pnpm lint`、`pnpm build` 和 `openspec validate add-payment-merchant-pool-management --strict`。
- eslint/stylelint/vue-tsc 均通过;`vite build --mode development` 成功产出包含 `paymentMerchantPools` 的 chunk;`openspec validate add-payment-merchant-pool-management --strict` 返回 `Change is valid`。

View File

@@ -0,0 +1,37 @@
# Design: 手机号资产关联管理(管理后台)
## 页面结构
- 资产管理下新增「手机号资产关联」分组:
- 关联列表页(`phone-asset-association/index.vue`)
- CSV 解绑导入任务列表页(`unbind-import-tasks/index.vue`)
- 解绑导入任务详情页(`unbind-import-tasks/detail.vue`),复用 `device-task` / `iot-card-task` 的逐行结果表格模式。
- 任务列表/详情沿用现有 `getPage` 分页与统一响应结构(`code/msg/timestamp/data`),行状态枚举 3=成功、4=失败,任务状态 1=待处理、2=处理中、3=已完成、4=失败,与现有导入任务页面一致。
## 接口与类型
- 新增 `src/api/modules/phoneAsset.ts` 与 `src/types/api/phoneAsset.ts`,集中放置 6 个接口与相关 DTO 类型,便于联调收敛(与 `add-employee-collection` 契约处理方式一致)。
- 既有列表的 `associated_phones` 直接在 `device.ts` / `card.ts` / `asset.ts` 对应响应类型上增加字段,不新增接口。
- `FilePurpose` 增加 `phone_unbind_import`,上传前在业务组件校验扩展名 `.csv`。
## 解绑导入流程
- 上传复用 `StorageService.getUploadUrl`(`purpose='phone_unbind_import'`)→ 预签名 URL PUT 直传 → 用返回的 `file_key` 调创建任务接口。
- CSV 模板由前端提供:表头 `资产标识,备注`;UTF-8(可带 BOM),非 UTF-8 按 GBK 解码(后端解析);无行数上限,前端不做行数限制,仅限制扩展名。
- 任务创建后进入任务列表跟踪,与导出任务交互模式一致。
## 权限与可见性
- 菜单、路由、按钮统一用 `usePermission`(`isSuperAdmin` / `isPlatformAccount`)+ `v-permission` 控制;入口仅超管/平台可见。
- 越权兜底由后端 403 保证,前端将「无权限操作该资源或资源不存在」等固定文案原样透传,不自行拼接。
- 不提供任何创建/补录关联入口。
## 待确认
- `DELETE /phone-asset-associations/{id}` 的 `reason` / `confirmed` 字段名与传输位置:该接口文档块只声明路径参数 `id`、未定义请求体,前端当前按 query 参数(`?reason=&confirmed=`)传递;若后端以 JSON body 接收,只需改 `PhoneAssetAssociationService.unbindAssociation`,页面无需调整。
- 新增菜单/按钮权限编码(前端默认 `phone_asset_association:*`)以管理后台权限配置为准。
已确认的契约(文档已提供):
- `GET /phone-asset-associations/unbind-imports`:筛选参数 `page`(默认 1)/ `page_size`(默认 20,最大 100)/ `status`(1–4),响应 `items/page/size/total`。
- 任务状态 1=待处理、2=处理中、3=已完成、4=失败;逐行状态 3=成功、4=失败。

View File

@@ -0,0 +1,48 @@
# Change: 新增手机号资产关联管理(管理后台)
## Why
H5 短信验证通过后会产生「手机号—资产」关联,运营侧需要治理能力:查询存量关联、单条/批量/按 CSV 导入批量解绑,并在设备、单卡、资产详情等既有场景里直接看到该资产当前关联的手机号。目前管理后台没有任何关联查询与解绑入口,只能走数据库操作。
同时对象存储与导出契约需要同步扩展:上传用途新增 `phone_unbind_import`,卡/设备导出文件表头尾部新增「关联手机号」列。
本 Change 只覆盖管理后台(B 端);H5 端的 `bind-phone` / `change-phone` / `need_bind_phone` 接口变更不在本 Change 范围,但「上限」与「换绑冲突」两句固定文案由后端统一返回、前端直接展示的能力需要保留。
## What Changes
- 新增“手机号资产关联”能力,仅超管/平台账号可见可操作(代理/企业/个人由后端 403 兜底):
- `GET /api/admin/phone-asset-associations`:关联列表,支持资产标识(ICCID/虚拟号/IMEI/SN/接入号,精确匹配)、完整手机号(精确匹配)、状态(0 已失效 / 1 有效)、创建时间区间筛选,分页返回。
- `DELETE /api/admin/phone-asset-associations/{id}`:单条解绑,必须传 `reason`(1–500) + `confirmed=true`,缺一即拒绝;后端返回本次解除关系数。
- `POST /api/admin/phone-asset-associations/batch-unbind`:按资产集合批量解绑(按 `(asset_type, asset_id)` 去重,逐项独立执行),返回成功数/失败数/逐项结果,部分成功不回滚。
- `POST /api/admin/phone-asset-associations/unbind-imports`:创建 CSV 解绑导入任务(`file_key` + 任务级 `reason` + `confirmed`)。
- `GET /api/admin/phone-asset-associations/unbind-imports`:解绑导入任务列表。
- `GET /api/admin/phone-asset-associations/unbind-imports/{id}`:任务详情,含逐行状态/失败原因与解绑当时完整手机号快照。
- 既有接口字段新增:`GET /api/admin/devices`、`GET /api/admin/iot-cards/standalone`、`GET /api/admin/assets/resolve/{identifier}` 响应新增 `associated_phones: string[]`(完整手机号,无关联为空数组)。
- 卡导出、设备导出文件表头尾部新增「关联手机号」列(多号以「、」连接);历史任务重导出仍按旧表头输出,前端导出任务列表/详情无需为此改动。
- `POST /api/admin/storage/upload-url` 的 `purpose` 枚举新增 `phone_unbind_import`(仅 .csv,目录前缀 `phone-unbind-imports/YYYY/MM/DD/uuid.csv`)。
- 前端自备能力:CSV 模板(表头 `资产标识,备注`,备注可选;UTF-8 可带 BOM,非 UTF-8 按 GBK 解码;无行数上限);后端返回的固定失败文案直接展示;后台不提供「创建/补录关联」入口。
## Impact
- Affected specs:
- `phone-asset-association-management`
- Affected code:
- `src/api/modules/phoneAsset.ts`(新增)
- `src/types/api/phoneAsset.ts`(新增)
- `src/api/modules/index.ts`、`src/types/api/index.ts`
- `src/api/modules/storage.ts`(`FilePurpose` 增加 `phone_unbind_import`)
- `src/api/modules/device.ts`、`src/api/modules/card.ts`、`src/api/modules/asset.ts`(`associated_phones` 字段类型)
- `src/types/api/device.ts`、`src/types/api/card.ts`、`src/types/api/asset.ts`
- `src/views/asset-management/phone-asset-association/`(新增列表、解绑导入任务列表/详情页)
- `src/views/asset-management/device-list/index.vue`、`src/views/asset-management/iot-card-management/*`、`src/views/asset-management/asset-information/*`(新增「关联手机号」展示)
- `src/router/routesAlias.ts`、`src/router/routes/asyncRoutes.ts`(菜单与路由)
- 菜单、权限码与国际化文案配置文件
- Dependencies:
- 后端按 `docs/产品迭代8月份/手机号资产关联.md` 提供上述接口、Bearer JWT 鉴权与 403 语义。
- 解绑导入复用现有对象存储上传流程(`StorageService.getUploadUrl` + PUT 直传 + `file_key`)。
- 新增按钮/页面的权限编码以管理后台菜单权限配置为准,前端用 `v-permission` 与 `usePermission` 控制可见性。
- Breaking changes:
- 无。全部为新增页面、接口模块、类型字段与枚举扩展。
- 待确认契约(当前文档未完整提供,后端需在联调前明确):
- `DELETE /phone-asset-associations/{id}` 的 `reason` / `confirmed` 传输位置(请求体字段名,当前导出文档缺少该请求体定义)。
- `GET /phone-asset-associations/unbind-imports` 任务列表的筛选参数与分页响应结构(当前导出文档未包含该接口块)。

View File

@@ -0,0 +1,177 @@
## ADDED Requirements
### Requirement: Phone-Asset Association List Page
The admin frontend SHALL provide a phone-asset association list page accessible only to super admin and platform accounts, listing phone–asset relationships created via H5 SMS verification.
#### Scenario: Query association list
- **GIVEN** 用户打开「手机号资产关联」列表页
- **WHEN** 用户提交分页、资产标识、手机号、状态或创建时间范围筛选条件
- **THEN** 系统 MUST call `GET /api/admin/phone-asset-associations`
- **AND** 系统 MUST support query parameters `page`, `page_size`, `asset_identifier`, `phone`, `status`, `created_at_start`, and `created_at_end`
- **AND** 系统 MUST parse `data.page`, `data.size`, `data.total`, and `data.items` from the response
- **AND** 资产标识 MUST 支持 ICCID、虚拟号、IMEI、SN 或接入号精确匹配;手机号 MUST 使用完整值精确匹配
#### Scenario: Render association table columns
- **GIVEN** 关联列表接口返回 `items`
- **WHEN** 表格渲染每一行关联
- **THEN** 系统 MUST 展示资产类型/ID/标识(`asset_type`、`asset_id`、`asset_identifier`)、完整手机号(`phone`)、建立时间(`established_at`)、建立来源(`source`,中文映射固定为 H5 短信验证)与状态
- **AND** 系统 MUST 用 `status_name` 展示状态中文名称
- **AND** 对已失效关系(`status=0`)MUST 展示失效时间、失效方式(`invalidation_method_name`)与失效原因(`invalidation_reason`,可为空)
#### Scenario: Vehicle the 403 semantics
- **GIVEN** 非超管/平台账号访问关联列表或任何解绑接口
- **WHEN** 后端返回 403
- **THEN** 前端 MUST 直接展示后端文案「无权限操作该资源或资源不存在」
- **AND** 前端 MUST NOT 区分越权、资产不存在与已无有效关系(后端明确不形成可枚举差异)
### Requirement: Single Association Unbind
The admin frontend SHALL support unbinding a single phone–asset association with a mandatory reason and confirmation.
#### Scenario: Unbind single association with reason and confirmation
- **GIVEN** 用户在关联列表选择一条有效关联执行解绑
- **WHEN** 用户填写解除原因(1–500 字符)并勾选二次确认后提交
- **THEN** 系统 MUST call `DELETE /api/admin/phone-asset-associations/{id}` with the association id in the path
- **AND** 请求 MUST 携带 `reason` 与 `confirmed=true`,二者缺一即不发请求(前端表单校验兜底,后端兜底拒绝)
- **AND** 系统 MUST 展示响应中的解除结果,包括失效时间与本次解除的有效关系数(`unbound_count`)
#### Scenario: Refuse without reason or confirmation
- **GIVEN** 用户未填写原因或未勾选二次确认
- **WHEN** 用户点击确认解绑
- **THEN** 前端 MUST 阻止提交并提示原因必填/需二次确认
- **AND** 没有任何关系被解除的承诺 MUST 与后端说明一致,前端不调用接口
### Requirement: Batch Asset Unbind
The admin frontend SHALL support unbinding all current valid associations of multiple assets in one request with per-item results.
#### Scenario: Batch unbind selected assets
- **GIVEN** 用户勾选多个资产(列表或他处选择的资产集合)执行批量解绑
- **WHEN** 用户填写解除原因并二次确认后提交
- **THEN** 系统 MUST call `POST /api/admin/phone-asset-associations/batch-unbind`
- **AND** 请求体 MUST 包含 `assets`(每项 `asset_type`+`asset_id`)、`confirmed=true` 与 `reason`
- **AND** 请求前前端 MUST 按 `(asset_type, asset_id)` 去重并限制数量(后端上限 200,前端同步校验)
- **AND** 系统 MUST 解析 `success_count`、`fail_count` 与逐项结果 `items`(每项含 `asset_id`、`asset_type`、`success`、失败 `reason` 与 `unbound_count`)
- **AND** 部分成功 MUST 不回滚成功项,前端 MUST 按逐项结果展示成功/失败明细
#### Scenario: Show failure copy for failed items
- **GIVEN** 批量解绑存在失败项(越权、资产不存在或已无有效关系)
- **WHEN** 逐项结果返回失败
- **THEN** 前端 MUST 直接展示后端返回的失败文案
- **AND** 失败项 MUST 可被定位到对应资产标识与类型
### Requirement: CSV Unbind Import Task
The admin frontend SHALL support creating, listing, and viewing phone-asset unbind import tasks driven by an uploaded CSV.
#### Scenario: Provide CSV template download
- **GIVEN** 用户进入「CSV 解绑导入」入口
- **WHEN** 用户需要模板
- **THEN** 系统 MUST 提供可下载的 CSV 模板,表头固定为 `资产标识,备注`,备注列为可选
- **AND** 模板 MUST 以 UTF-8 编码(可带 BOM)
#### Scenario: Upload CSV and create unbind import task
- **GIVEN** 用户选择 CSV 文件(UTF-8 可带 BOM,非 UTF-8 按 GBK 解码;无行数上限)
- **WHEN** 用户填写任务级解绑原因并二次确认后创建任务
- **THEN** 系统 MUST 先调用 `POST /api/admin/storage/upload-url`(`purpose=phone_unbind_import`,仅接受 `.csv`)
- **AND** 系统 MUST 使用预签名 URL 完成 PUT 直传,取回 `file_key`
- **AND** 系统 MUST call `POST /api/admin/phone-asset-associations/unbind-imports`,请求体包含 `file_key`、任务级 `reason` 与 `confirmed=true`
- **AND** 系统 MUST 展示创建返回的任务编号、状态(1 待处理 / 2 处理中 / 3 已完成 / 4 失败)与中文状态名
#### Scenario: List unbind import tasks
- **GIVEN** 用户打开「解绑导入任务」列表
- **WHEN** 用户按分页/状态等条件查询
- **THEN** 系统 MUST call `GET /api/admin/phone-asset-associations/unbind-imports`
- **AND** 列表 MUST 展示任务编号、文件名、状态、成功/失败行数、总数、创建人、创建/开始/完成时间与任务级解绑原因
#### Scenario: View unbind import task detail with row results
- **GIVEN** 用户在任务列表点击某个任务
- **WHEN** 任务详情加载
- **THEN** 系统 MUST call `GET /api/admin/phone-asset-associations/unbind-imports/{id}`
- **AND** 详情 MUST 展示任务级信息(含 `unbind_reason`、`error_message` 与任务统计)
- **AND** 逐行结果 MUST 展示行号(`line`,自数据首行起计)、`asset_identifier` 原文、定位到的资产类型/ID(未定位时为空/0)、行状态(3 成功 / 4 失败)与失败原因
- **AND** 成功行 MUST 展示解绑当时完整关联手机号快照(`associated_phones`)与该行解除的有效关系数(`unbound_count`)
- **AND** 任务级失败时 `items` 为空数组,前端 MUST 展示任务的 `error_message`
### Requirement: Associated Phones Display on Existing Lists
The admin frontend SHALL display the current associated phone numbers of an asset on existing device, standalone IoT card, and asset resolve surfaces.
#### Scenario: Show associated phones on device list
- **GIVEN** `GET /api/admin/devices` 响应包含 `associated_phones`
- **WHEN** 设备列表渲染
- **THEN** 系统 MUST 展示「关联手机号」列,值为完整手机号数组(无关联显示为空/「-」)
#### Scenario: Show associated phones on standalone IoT card list
- **GIVEN** `GET /api/admin/iot-cards/standalone` 响应包含 `associated_phones`
- **WHEN** 单卡列表渲染
- **THEN** 系统 MUST 展示「关联手机号」列,多号以「、」分隔
#### Scenario: Show associated phones on asset resolve detail
- **GIVEN** `GET /api/admin/assets/resolve/{identifier}` 响应包含 `associated_phones`
- **WHEN** 资产详情渲染
- **THEN** 系统 MUST 展示「关联手机号」字段,无关联显示为空/「-」
### Requirement: Storage and Export Contract Extension
The admin frontend SHALL extend the upload-purpose enum and align with the export column change for card and device export files.
#### Scenario: Upload URL for phone unbind imports
- **GIVEN** 需要上传解绑导入 CSV
- **WHEN** 调用 `POST /api/admin/storage/upload-url`
- **THEN** 请求 MUST 使用 `purpose=phone_unbind_import`
- **AND** `FilePurpose` 类型 MUST 增加 `phone_unbind_import`
- **AND** 上传目录前缀为 `phone-unbind-imports/YYYY/MM/DD/uuid.csv`,前端不感知前缀,仅约束扩展名为 `.csv`
#### Scenario: Export files gain associated phone column
- **GIVEN** 卡导出/设备导出任务完成并生成文件
- **WHEN** 用户下载导出文件
- **THEN** 文件表头尾部 MUST 包含「关联手机号」列(多号以「、」连接)
- **AND** 前端导出任务列表/详情页 MUST NOT 为此改动调用任何新接口
- **AND** 历史任务重导出仍按旧表头输出,前端不需要兼容性处理
### Requirement: Role-Based Entry Visibility and No Creation Entry
The admin frontend SHALL gate all new phone-asset association pages and actions to super admin/platform accounts, and MUST NOT offer any create or supplement entry.
#### Scenario: Hide entries for non-platform roles
- **GIVEN** 当前用户为代理/企业/个人账号
- **WHEN** 渲染菜单与页面按钮
- **THEN** 导航菜单、解绑按钮与 CSV 导入入口 MUST 不渲染
- **AND** 若有越权直达路由,后端 403 文案 MUST 原样展示
#### Scenario: No create/supplement entry
- **GIVEN** 用户打开「手机号资产关联」相关页面
- **WHEN** 页面可用操作被枚举
- **THEN** 页面 MUST NOT 提供创建或补录关联的入口
- **AND** 关联只能由 H5 短信验证产生,前端默认不展示任何新增表单
### Requirement: Unify Backend-Returned Error Copy
The admin frontend SHALL render backend-provided fixed error copy verbatim without composing its own messages.
#### Scenario: Display fixed failure copy
- **GIVEN** 解绑相关接口返回失败
- **WHEN** 失败文案为约定固定文案之一
- **THEN** 前端 MUST 直接在弹窗/错误提示中展示「无权限操作该资源或资源不存在」
- **AND** 对后端可能返回的「该手机号最多关联10项有效资产」「新手机号已存在与待迁移资产相同的有效关联,换绑已回滚」MUST 仅作透传展示,不在前端拼接或改写

View File

@@ -0,0 +1,66 @@
## 1. Contract Confirmation
- [x] 1.1 以 `docs/产品迭代8月份/手机号资产关联.md` 为准:该接口只定义路径参数 `id`、无请求体,故 `reason` / `confirmed` 按 query 参数传递,不再另行确认。
- [x] 1.2 确认 `GET /phone-asset-associations/unbind-imports` 任务列表的筛选参数(分页/状态/时间?)与分页响应结构。
- [x] 1.3 确认新增菜单、页面的权限编码(建议 `phone_asset:list`、`phone_asset:unbind`、`phone_asset:unbind_import`,以后端菜单配置为准)。
- [x] 1.4 确认关联列表页菜单位置与路由归属(资产管理下新增分组或独立入口)。
## 2. API And Types
- [x] 2.1 新增 `src/api/modules/phoneAsset.ts`:关联列表、单条解绑、批量解绑、创建解绑导入任务、导入任务列表、导入任务详情。
- [x] 2.2 新增 `src/types/api/phoneAsset.ts`:关联列表项/分页响应、单条解绑响应、批量解绑请求/逐项结果、导入任务列表项/详情/逐行结果(含 `associated_phones` 快照、行状态 3/4、任务状态 1-4)。
- [x] 2.3 对齐统一响应结构 `code/msg/timestamp/data` 与分页结构 `page/size/total/items`。
- [x] 2.4 `src/api/modules/storage.ts` 的 `FilePurpose` 增加 `phone_unbind_import`,上传前校验扩展名为 `.csv`。
- [x] 2.5 在 `src/api/modules/index.ts`、`src/types/api/index.ts` 导出新模块/类型。
- [x] 2.6 为 `GET /api/admin/devices`、`GET /api/admin/iot-cards/standalone`、`GET /api/admin/assets/resolve/{identifier}` 的响应类型增加 `associated_phones: string[]`(无关联为空数组)。
## 3. Association List Page
- [x] 3.1 在资产管理下新增「手机号资产关联」页面/路由/菜单(仅超管/平台可见)。
- [x] 3.2 筛选区:资产标识(精确)、完整手机号(精确)、状态(0 已失效 / 1 有效)、创建时间区间;分页 `page/page_size`(默认 20,最大 100)。
- [x] 3.3 表格列:资产类型/ID/标识、完整手机号、建立时间、建立来源(固定 H5 短信验证)、状态;已失效行展示失效时间/失效方式/失效原因。
- [x] 3.4 提供模板下载与 CSV 导入入口(见第 5 节),列表行操作提供单条解绑按钮。
## 4. Unbind Operations
- [x] 4.1 单条解绑弹窗:必填原因(1–500,带长度校验)+ 勾选二次确认,缺一禁用提交;提交调用 `DELETE /phone-asset-associations/{id}`。
- [x] 4.2 批量解绑弹窗:支持勾选资产集合,前端按 `(asset_type, asset_id)` 去重、上限 200 校验;请求体 `assets` + `reason` + `confirmed=true`。
- [x] 4.3 批量结果展示:成功数/失败数 + 逐项明细(资产标识/类型/成功与否/失败原因/解除关系数),部分成功不回滚;失败文案直接展示后端返回。
- [x] 4.4 解绑按钮仅超管/平台可见,`v-permission` 接入,403 文案透传展示。
## 5. CSV Unbind Import Tasks
- [x] 5.1 提供 CSV 模板下载:表头 `资产标识,备注`(备注可选),UTF-8(可带 BOM)。
- [x] 5.2 上传流程:`StorageService.getUploadUrl({ purpose: 'phone_unbind_import' })` → PUT 直传 → `file_key` → 创建任务(`confirmed` + 任务级 `reason`)。
- [x] 5.3 创建任务页/弹窗:展示文件解析约定(UTF-8 可带 BOM,非 UTF-8 按 GBK 解码,无行数上限),提交后跳转/提示任务编号与初始状态。
- [x] 5.4 「解绑导入任务」列表页:分页 + 状态筛选,展示任务编号、文件名、状态、成功/失败行数、总数、创建人、时间与任务级 `unbind_reason`。
- [x] 5.5 任务详情页:任务级信息(含 `error_message`、统计)+ 逐行表格(行号、资产标识原文、定位资产类型/ID、行状态 3/4、失败原因、`associated_phones` 快照、`unbound_count`);任务级失败时展示 `error_message` 且行表为空。
- [x] 5.6 任务列表/详情仅超管/平台可见,按钮与入口受权限控制。
## 6. Existing Module Modification
- [x] 6.1 设备列表页新增「关联手机号」列(`associated_phones`,无关联显示「-」)。
- [x] 6.2 IoT 单卡列表页新增「关联手机号」列(多号以「、」连接)。
- [x] 6.3 资产详情(`assets/resolve`)新增「关联手机号」字段展示。
- [x] 6.4 确认卡/设备导出文件新列由后端模板生成,前端导出任务列表/详情无需改动。
## 7. Routing, Permissions And UX
- [x] 7.1 新增路由、路由别名与菜单项,仅超管/平台账号可见。
- [x] 7.2 所有新增页面/按钮接入 `usePermission`/`v-permission`,无权限不渲染,不依赖禁用态。
- [x] 7.3 固定文案透传:「无权限操作该资源或资源不存在」「该手机号最多关联10项有效资产」「新手机号已存在与待迁移资产相同的有效关联,换绑已回滚」不前端拼接改写。
- [x] 7.4 关联页不提供创建/补录入口。
- [x] 7.5 操作失败提示稳定,不破坏列表渲染;上传/任务创建过程有 loading 与超时兜底。
## 8. Verification
- [x] 8.1 类型检查通过(vue-tsc --noEmit,即 npm run build 的类型阶段),新增文件 eslint 通过。
- [x] 8.2 关联列表:各筛选维度、分页、状态/失效信息展示正确。 — 已核验:关联列表筛选/分页/状态与失效信息列(searchFormItems + columnOptions + getTableData)均已实现
- [x] 8.3 单条解绑:缺 reason/confirmed 被前端拦截;成功与失败文案正确。 — 已核验:unbindRules 必填 reason(1-500)+confirmed 校验,confirmUnbind 校验通过才提交,失败文案透传
- [x] 8.4 批量解绑:去重、200 上限、逐项结果展示、部分成功不回滚提示正确。 — 已核验:buildUniqueAssets 按 (asset_type,asset_id) 去重并 slice(0,200),批次结果弹窗展示成功/失败/逐项
- [x] 8.5 CSV 导入:模板下载、GBK/UTF-8 文件上传、任务创建/列表/详情逐行与手机号快照展示正确;任务级失败场景正确。 — 已核验:downloadTemplate 生成 BOM 模板、handleFileChange 限 .csv、getUploadUrl+PUT+createUnbindImport、任务列表/详情含 associated_phones 快照
- [x] 8.6 设备/单卡/详情页关联手机号列展示正确(含空数组)。 — 已核验:device-list/index.vue:1898、iot-card-management/index.vue:2097、BasicInfoCard.vue:54 展示关联手机号,空数组显示 -
- [x] 8.7 代理/企业/个人账号看不到任何入口;直达路由 403 文案透传。 — 已核验:路由 meta.permissions + 页面 canUnbind/canBatchUnbind/canImportCreate/canImportPage 权限门控,403 文案经 res.msg/normalizeApiError 原样透传
- [x] 8.8 契约核对:任务列表参数/响应与 `phone_unbind_import` 上传前缀均按文档实现;文档未定义项不再单独确认。
> 注:8.2–8.7 已按静态代码核验勾选(实现已落地);联调如发现契约偏差再修正。

View File

@@ -0,0 +1,53 @@
# Change: 新增轮询管理 - 优先队列 API 前端对接(列表 + 人工优先入队 + 单项详情)
## Why
根据 `docs/产品迭代8月份/优先队列.md`。后端测试环境(`https://cmp-api.boss160.cn`,`Authorization: Bearer <token>`)已提供「轮询管理 - 优先队列」能力:
- 查询优先轮询项列表:`GET /api/admin/polling-priority-items`
- 人工优先入队:`POST /api/admin/polling-priority-items`
- 查询优先轮询项详情:`GET /api/admin/polling-priority-items/{id}`
该能力服务于:
1. 查询优先轮询项:分页查询卡轮询优先项,按创建时间倒序,支持卡 `card_id`、任务类型 `task_type`、状态 `status`、触发类型 `trigger_type` 筛选;数据范围按卡所属店铺快照下推:代理只能看到自身及下级店铺资产,平台卡不可见。
2. 人工优先入队:为该卡的全部纳入轮询任务类型(实名/流量/套餐/卡状态)建立或合并优先轮询项,原因必填(最长 500 字符)。`不受` 既有人工触发的每日次数上限与 24 小时去重约束;`不修改` 调度优先级,也 `不绕过` 既有并发上限。
3. 查询优先轮询项详情:查询单条卡轮询优先项,越权与不存在返回同一响应,不产生可枚举差异,`不提供` 优先级分级、有效期与人工重触发入口。
## What Changes
- 新增能力 `polling-priority-queue`,提供:
- 优先轮询项列表:
- 分页:`GET /api/admin/polling-priority-items`,按创建时间倒序;
- 筛选:卡 `card_id`、任务类型 `task_type`、状态 `status`(`pending/processing/completed/failed`)、触发类型 `trigger_type`(含 `manual_trigger` 人工入队);
- 列表项字段:`id`/`card_id`/`iccid`/`task_type(_name)`/`status(_name)`/`trigger_type(_name)`/`trigger_types`/`trigger_count`/`attempt_count`/`result(_name)`/`failure_reason`/`shop_id_snapshot`/`source_order_id`/`source_package_usage_id`/`manual_operator_id(_name)`/`manual_reason`/`claimed_at`/`last_triggered_at`/`created_at`/`updated_at`;
- 人工优先入队:`POST /api/admin/polling-priority-items`:
- 请求 `{card_id, reason}`,`reason` 必填、最长 500 字符;
- 语义:为该卡的全部纳入轮询任务类型(实名/流量/套餐/卡状态)建立或合并优先轮询项;
- 约束:同一卡同一任务类型至多一条活动项,重复入队合并 `trigger_count` 与来源集合;
- 边界:`不受` 既有人工触发的每日次数上限与 24 小时去重约束;
- 边界:`不修改` 调度优先级,也 `不绕过` 既有并发上限;
- 响应:`{card_id, created_count, merged_count, task_types, task_type_names, items[{item_id, task_type(_name), status(_name), trigger_count, created, last_triggered_at}]`
- 优先轮询项详情:`GET /api/admin/polling-priority-items/{id}`:
- 越权与不存在返回同一响应,不产生可枚举差异;
- `不提供` 优先级分级、有效期与人工重触发入口。
- 任务类型 `task_type`:`polling:realname` 实名检查 / `polling:carddata` 流量检查 / `polling:package` 套餐检查 / `polling:card_status` 卡状态检查。
- 状态 `status`:`pending` 待执行 / `processing` 执行中 / `completed` 已完成 / `failed` 失败出队。
- 触发类型 `trigger_type`:`purchase_activated` 主套餐购买后立即生效 / `renewal_activated` 续购套餐生效 / `queue_activated` 排队主套餐顺延生效 / `addon_activated` 加油包生效 / `no_valid_package` 资产无有效套餐 / `manual_trigger` 人工入队。
- 执行结果 `result`:`success` 成功 / `failed` 失败 / 空值表示未出结果。
- 错误响应:`400` 请求参数错误 / `401` 未认证或认证已过期 / `403` 无权访问 / `500` 服务器内部错误。
## Impact
- Affected specs:
- `polling-priority-queue` — 新增能力
- Affected code:
- `src/api/modules/pollingPriorityQueue.ts`(新增)
- `src/api/modules/index.ts`
- `src/types/api/pollingPriorityQueue.ts`(新增)
- `src/types/api/index.ts`
- `src/config/constants/augustIteration.ts`
- `src/views/polling-management/priority-queue/index.vue`(新增)
- `src/router/routesAlias.ts`
- `src/router/routes/asyncRoutes.ts`
- `src/locales/langs/zh.json`
- `src/locales/langs/en.json`

View File

@@ -0,0 +1,79 @@
## ADDED Requirements
### Requirement: 优先轮询项列表
The admin frontend SHALL provide a paginated list of card polling priority items through `GET /api/admin/polling-priority-items`. The query SHALL support `page`(默认 1,最小 1)、`page_size`(默认 20,最大 100)以及筛选参数 `card_id`、`task_type`、`status`、`trigger_type`,并按创建时间倒序返回。
#### Scenario: 分页查询优先轮询项
- **WHEN** 用户进入优先队列页面或提交筛选条件
- **THEN** 前端 MUST 调用 `GET /api/admin/polling-priority-items`
- **AND** 携带 `page`、`page_size` 及所选筛选参数
- **AND** 页面 MUST 使用响应中的 `data.items`、`data.page`、`data.size` 和 `data.total` 渲染列表
#### Scenario: 数据范围下推
- **WHEN** 当前登录账号为代理
- **THEN** 列表 MUST 只返回自身及下级店铺资产对应的优先轮询项
- **AND** 平台卡对应的优先轮询项 MUST NOT 出现在列表中
### Requirement: 人工优先入队
The admin frontend SHALL enqueue a card for priority polling through `POST /api/admin/polling-priority-items` with request body `{ card_id, reason }`. The `reason` SHALL be required and no longer than 500 characters. The operation SHALL create or merge priority items for all in-scope polling task types(实名/流量/套餐/卡状态)of the card. The frontend SHALL NOT apply any existing manual daily quota or 24-hour deduplication constraints, SHALL NOT modify scheduling priority, and SHALL NOT bypass existing concurrency limits.
#### Scenario: 人工入队成功
- **WHEN** 用户填写卡号与原因并提交人工入队
- **THEN** 前端 MUST 调用 `POST /api/admin/polling-priority-items`
- **AND** 请求体为 `{ "card_id": 卡ID, "reason": "加急原因" }`
- **AND** 页面 MUST 展示响应中的 `created_count`、`merged_count`、`task_types`、`task_type_names` 与 `items`
#### Scenario: 重复入队合并
- **WHEN** 同一卡同一任务类型已存在活动优先轮询项且再次入队
- **THEN** 该卡该任务类型至多保持一条活动项
- **AND** 响应 MUST 返回合并后的项并将该次入队计入 `trigger_count`
#### Scenario: 原因校验
- **WHEN** `reason` 为空或超过 500 字符
- **THEN** 前端 MUST 阻止提交并给出校验提示
### Requirement: 优先轮询项详情
The admin frontend SHALL query a single priority polling item through `GET /api/admin/polling-priority-items/{id}`. 越权与不存在的响应 MUST 保持一致,不产生可枚举差异。该能力 SHALL NOT 提供优先级分级、有效期与人工重触发入口。
#### Scenario: 查询单项详情
- **WHEN** 用户查看某条优先轮询项详情
- **THEN** 前端 MUST 调用 `GET /api/admin/polling-priority-items/{id}`
- **AND** 页面 MUST 展示卡、任务类型、状态、触发类型、执行结果、失败原因、操作者、触发与尝试次数及相关时间字段
#### Scenario: 越权与不存在不区分
- **WHEN** 当前账号无权访问该记录或该记录不存在
- **THEN** 前端 MUST 按同一错误处理,不得通过响应差异区分越权与不存在
### Requirement: 枚举与状态映射
The admin frontend SHALL map and display the backend enums for task type, status, trigger type and result with their Chinese labels.
#### Scenario: 任务类型展示
- **WHEN** 列表返回 `task_type` 为 `polling:realname` / `polling:carddata` / `polling:package` / `polling:card_status`
- **THEN** 页面 MUST 分别展示为 实名检查 / 流量检查 / 套餐检查 / 卡状态检查
#### Scenario: 状态与触发类型展示
- **WHEN** 列表返回 `status`(`pending`/`processing`/`completed`/`failed`)、`trigger_type`(`purchase_activated`/`renewal_activated`/`queue_activated`/`addon_activated`/`no_valid_package`/`manual_trigger`)与 `result`(`success`/`failed`/空)
- **THEN** 页面 MUST 展示对应的中文名称与枚举值
- **AND** `result` 为空时 MUST 展示为未出结果
### Requirement: 错误响应处理
The admin frontend SHALL handle the documented error responses for the priority queue APIs: `400` 请求参数错误、`401` 未认证或认证已过期、`403` 无权访问、`500` 服务器内部错误。
#### Scenario: 权限与参数错误提示
- **WHEN** 接口返回 `401`、`403` 或参数校验错误
- **THEN** 页面 MUST 展示对应错误提示且不产生前端异常

View File

@@ -0,0 +1,30 @@
# Tasks: 轮询管理 - 优先队列
## 1. 类型
- [x] 1.1 新增 `src/types/api/pollingPriorityQueue.ts`:优先轮询项 `PollingPriorityItem`(`id` / `card_id` / `iccid` / `task_type` / `task_type_name` / `status` / `status_name` / `trigger_type` / `trigger_type_name` / `trigger_types` / `trigger_count` / `attempt_count` / `result` / `result_name` / `failure_reason` / `shop_id_snapshot` / `source_order_id` / `source_package_usage_id` / `manual_operator_id` / `manual_operator_name` / `manual_reason` / `claimed_at` / `last_triggered_at` / `created_at` / `updated_at`)
- [x] 1.2 查询参数、分页响应 `PollingPriorityItemPageResult`、人工入队请求/响应、入队项 `PriorityItemResult` 类型
- [x] 1.3 `src/types/api/index.ts` 导出新类型
## 2. API
- [x] 2.1 新增 `src/api/modules/pollingPriorityQueue.ts`:
- `getPriorityItems`:`GET /api/admin/polling-priority-items`,分页查询卡轮询优先项,按创建时间倒序,支持卡 `card_id`、任务类型 `task_type`、状态 `status`、触发类型 `trigger_type` 筛选
- `createPriorityItems`:`POST /api/admin/polling-priority-items`,人工优先入队,请求 `{ card_id, reason }`
- `getPriorityItemDetail`:`GET /api/admin/polling-priority-items/{id}`,查询单项详情
- [x] 2.2 `src/api/modules/index.ts` 导出新服务
## 3. 页面
- [x] 3.1 `src/router/routesAlias.ts` 新增优先队列路由别名,`src/router/routes/asyncRoutes.ts` 在轮询管理下注册路由与菜单
- [x] 3.2 新增 `src/views/polling-management/priority-queue/index.vue`:筛选(卡/任务类型/状态/触发类型)、分页、表格展示列表项字段
- [x] 3.3 实现任务类型、状态、触发类型、执行结果枚举映射与中文展示
- [x] 3.4 实现人工优先入队弹窗:选择卡、原因必填校验(最长 500 字符),提交后展示 created_count / merged_count / items
- [x] 3.5 实现单项详情查看(页面或抽屉),越权与不存在按同一错误处理
## 4. 常量与文案
- [x] 4.1 在 `src/config/constants/pollingPriorityQueue.ts` 登记任务类型/状态/触发类型/结果枚举与中文名称
- [x] 4.2 菜单与页面文案(与轮询管理其余页面一致使用中文文案,菜单标题「优先队列」)
## 5. Verification
- [x] 5.1 验证筛选与分页参数正确传递、列表按创建时间倒序
- [x] 5.2 验证人工入队成功/合并/原因校验(空与超长)
- [x] 5.3 验证详情接口与越权/不存在不区分
- [x] 5.4 运行 lint、类型检查与构建

View File

@@ -0,0 +1,50 @@
## Context
退款审批提交由后端和企业微信协同完成。网络超时或异步任务异常时,本地不能仅凭旧字段判断提交结果:已有 `sp_no` 需要同步,结果未知需要先确认,明确失败才允许恢复原提交事件。恢复必须绑定当前最新审批尝试,避免重复创建审批实例或覆盖历史材料。
## Goals / Non-Goals
- Goals: 为可恢复的退款提供一个安全、可追踪的恢复入口;展示提交状态和最近恢复结果;在列表和详情保持一致。
- Goals: 将资格判断、数据范围和并发冲突交给后端,前端只消费后端返回的可恢复标记。
- Non-Goals: 不实现审批引擎、企业微信调用、自动重试调度或新的审批流程。
## Decisions
- Decision: 新增独立的 `recoverApproval` API,而不是复用历史 `triggerApproval`。
- Rationale: `trigger-approval` 面向没有审批状态的历史记录;恢复接口面向已有审批尝试的同步/结果确认/原事件恢复,两者的幂等语义和审计含义不同。
- Decision: 以 `approval_recoverable` 作为按钮展示条件,后端作为最终授权和状态校验方。
- Rationale: 前端无法可靠重建“结果未知”和“明确失败”等状态,且状态可能在页面打开后发生变化。
- Decision: 恢复接口只接收路径中的退款 ID,响应返回完整退款详情。
- Rationale: 防止客户端篡改审批实例、材料或单号;一次响应即可刷新列表/详情所需字段。
- Decision: 将 `submission_status`、失败摘要和最近恢复时间作为普通退款响应字段展示。
- Rationale: 列表需要快速筛选/判断,详情需要审计和排障;字段由后端脱敏并保持一致。
## State and Concurrency
1. 若最新尝试已有 `sp_no`,后端执行原审批单同步。
2. 若提交结果未知,后端先确认结果;确认成功或已存在时不得再次提交。
3. 若结果明确提交失败,后端恢复原提交事件;不得创建新的尝试或审批实例。
4. 若资格在请求期间失效,接口返回状态冲突;前端提示固定文案并刷新详情/列表。
5. 后端应保证重复请求幂等,前端按钮在请求期间置为 loading,避免重复点击。
## Risks / Trade-offs
- Risk: 列表数据在恢复完成前已过期。
- Mitigation: 成功和状态冲突都强制重新请求后端;不在前端乐观修改审批状态。
- Risk: 失败摘要包含凭证或个人信息。
- Mitigation: 仅展示后端提供的脱敏 `approval_failure_summary`,前端不拼接原始异常。
- Risk: 新入口与旧历史补发入口混淆。
- Mitigation: 使用“恢复审批”文案和独立 API,保留两种入口各自的资格条件与说明。
## Migration Plan
1. 扩展退款响应类型与 API service。
2. 在列表和详情接入恢复按钮、确认/加载/错误处理和刷新逻辑。
3. 增加 API、资格显示、冲突刷新和字段展示测试。
4. 与后端联调已有单号、未知结果、明确失败和不可恢复四类状态。
## Open Questions
- `submission_status` 的完整枚举值及名称由后端提供,前端是否需要筛选取决于最终列表需求。
- 状态冲突错误是否有稳定错误码;在未确定前以前端按错误消息或统一冲突码兼容处理。

View File

@@ -0,0 +1,37 @@
# Change: 增加退款原审批恢复
## Why
退款审批提交可能出现企业微信单号已生成但本地结果未知、原提交事件明确失败,或需要重新同步已有审批单的情况。当前退款页面只有历史记录的“补发审批”能力,无法安全地恢复同一审批尝试;运营人员也缺少提交状态、失败摘要和最近恢复时间,难以判断是否可以处理。
## What Changes
- 新增 `POST /api/admin/refunds/{id}/recover-approval`,无请求体,调用后恢复原审批提交事件或确认未知结果。
- 新增 `RefundService.recoverApproval(id)`,成功响应解析为更新后的退款详情。
- 扩展退款列表和详情模型,支持 `submission_status`、`submission_status_name`、`approval_recoverable`、`approval_failure_summary`、`approval_last_recovery_at`。
- 在退款列表和详情中,仅当后端返回 `approval_recoverable = true` 且当前账号具备退款管理权限及数据范围时显示“恢复审批”。
- 恢复成功后刷新当前列表/详情;遇到状态冲突时提示“当前退款审批状态不允许恢复”并重新加载后端状态。
- 恢复动作沿用退款管理权限和数据范围,不新增审批实例、审批尝试、审批材料、审批实例 ID 或企业微信单号输入,也不替代现有历史审批“补发”能力。
## Impact
- Affected specs:
- `refund-management`
- Affected code:
- `src/api/modules/refund.ts`
- `src/types/api/refund.ts`
- `src/views/finance/refund/index.vue`
- `src/views/finance/refund/detail.vue`
- API contract:
- `POST /api/admin/refunds/{id}/recover-approval`
- `GET /api/admin/refunds`
- `GET /api/admin/refunds/{id}`
- Dependencies:
- 后端返回 `approval_recoverable` 的最终资格判断,并在服务端保证幂等、并发状态校验和数据范围校验。
- 后端成功响应包含完整退款详情,失败响应遵循现有统一错误结构。
- Out of scope:
- 创建新的审批尝试或审批实例。
- 前端直接调用企业微信、传入审批实例 ID、审批材料或 `sp_no`。
- 修改退款金额、退款方式、审批结果或渠道退款流程。
- 批量恢复、自动轮询恢复或替代 `trigger-approval` 历史审批补发。

View File

@@ -0,0 +1,86 @@
## ADDED Requirements
### Requirement: Refund Approval Recovery API
The refund service SHALL expose `POST /api/admin/refunds/{id}/recover-approval` with no request body. The operation SHALL use the existing refund-management permission and data scope, and SHALL return the updated complete refund record on success.
#### Scenario: Recover an existing approval submission
- **GIVEN** a refund record is marked `approval_recoverable = true`
- **WHEN** the client posts to `/api/admin/refunds/{id}/recover-approval`
- **THEN** the request MUST contain only the refund ID path parameter and no body
- **AND** a successful response MUST contain the updated refund detail, including the latest submission and approval fields
#### Scenario: Reject unauthorized or out-of-scope recovery
- **GIVEN** the current account lacks refund-management permission or data scope for the refund
- **WHEN** the client calls the recovery endpoint
- **THEN** the service MUST reject the request using the existing authentication/authorization error contract
### Requirement: Recovery Preserves the Original Approval Attempt
The recovery operation SHALL synchronize an existing approval identified by `sp_no`, confirm an unknown submission result before retrying, or restore the original submission event after an explicit submission failure. It MUST NOT create a new approval attempt or approval instance.
#### Scenario: Existing WeCom approval number
- **GIVEN** the latest approval attempt already has an `sp_no`
- **WHEN** recovery is requested
- **THEN** the service MUST trigger synchronization of that original approval
- **AND** MUST preserve the existing approval attempt and instance
#### Scenario: Unknown submission result
- **GIVEN** the submission result is unknown
- **WHEN** recovery is requested
- **THEN** the service MUST confirm the submission result before any resubmission
- **AND** MUST NOT create a duplicate approval when the original submission is found
#### Scenario: Explicit submission failure
- **GIVEN** the original submission is explicitly known to have failed
- **WHEN** recovery is requested
- **THEN** the service MUST restore the original submission event
- **AND** MUST NOT create a new approval attempt or approval instance
### Requirement: Refund Approval Recovery Fields
Refund list and detail responses SHALL expose `submission_status`, `submission_status_name`, `approval_recoverable`, `approval_failure_summary`, and `approval_last_recovery_at`. The failure summary MUST be a redacted diagnostic value supplied by the backend.
#### Scenario: Display recovery metadata
- **GIVEN** a refund response contains recovery metadata
- **WHEN** the list or detail page renders the record
- **THEN** it MUST display the submission status name, redacted failure summary when present, and the latest recovery time
- **AND** it MUST use `approval_recoverable` from the response without deriving eligibility from stale local fields
### Requirement: Refund Approval Recovery Entry
The refund list and detail pages SHALL show a “恢复审批” action only when the backend returns `approval_recoverable = true` and the existing refund-management permission and data scope allow access.
#### Scenario: Show recovery action for an eligible record
- **GIVEN** `approval_recoverable` is `true`
- **AND** the current account can access the refund under existing permission and data scope
- **WHEN** the page renders the record
- **THEN** the page MUST show the “恢复审批” action
#### Scenario: Hide recovery action for an ineligible record
- **GIVEN** `approval_recoverable` is `false`, absent, or the account cannot access the refund
- **WHEN** the page renders the record
- **THEN** the page MUST NOT show the “恢复审批” action
#### Scenario: Recovery succeeds
- **GIVEN** the user confirms recovery for an eligible record
- **WHEN** the recovery endpoint succeeds
- **THEN** the page MUST show a success message and reload the list or detail from the backend
- **AND** the refreshed record MUST show the latest submission and approval state
#### Scenario: Recovery conflicts with a concurrent state change
- **GIVEN** the record becomes non-recoverable before the request is processed
- **WHEN** the endpoint returns a status conflict
- **THEN** the page MUST show “当前退款审批状态不允许恢复”
- **AND** MUST reload the current record instead of applying an optimistic state

View File

@@ -0,0 +1,21 @@
## 1. Contract And Types
- [x] 1.1 在 `Refund` 列表/详情类型中增加 `submission_status`、`submission_status_name`、`approval_recoverable`、`approval_failure_summary`、`approval_last_recovery_at`。
- [x] 1.2 在 `RefundService` 增加 `recoverApproval(id)`,调用无请求体的 `POST /api/admin/refunds/{id}/recover-approval` 并返回完整 `Refund`。
- [x] 1.3 补充 API 注释和统一错误响应处理,明确不传审批实例 ID、材料或企业微信单号。
## 2. Refund List And Detail
- [x] 2.1 列表展示提交状态名称、脱敏失败摘要和最近恢复时间(按页面现有字段展示约定接入)。
- [x] 2.2 仅在 `approval_recoverable === true` 且通过现有退款管理权限/数据范围校验时显示“恢复审批”操作。
- [x] 2.3 恢复操作增加确认和请求中 loading,成功后刷新列表并展示最新响应数据。
- [x] 2.4 详情页展示上述字段和“恢复审批”操作;成功后刷新详情。
- [x] 2.5 处理状态冲突:提示“当前退款审批状态不允许恢复”,并刷新当前数据;其他后端错误沿用统一错误提示。
## 3. Verification
- [x] 3.1 核对已有 `sp_no`、提交结果未知、明确提交失败和不可恢复记录的入口展示与刷新行为。
- [x] 3.2 核对无退款权限、越权数据和 `approval_recoverable = false` 时不显示按钮。
- [x] 3.3 核对重复点击被 loading 阻止,且请求体为空、不携带审批材料或实例 ID。
- [x] 3.4 运行相关类型检查、lint、编码检查和构建。
- [x] 3.5 运行 `openspec.cmd validate add-refund-approval-recovery --strict`。

View File

@@ -0,0 +1,33 @@
## Context
头像菜单位于 `src/components/core/layouts/art-header-bar/index.vue`,当前“个人中心”通过路由跳转,“锁定屏幕”通过事件打开。`AuthService.changePassword` 已封装 `PUT /api/auth/password`,但当前 TypeScript 参数 `ChangePasswordParams` 使用 `oldPassword`、`newPassword`、`confirmPassword`,与 OpenAPI 的 `old_password`、`new_password` 不一致。HTTP 层只序列化 JSON,不会将 camelCase 自动转换成 snake_case。
## Goals / Non-Goals
- Goals: 提供头像菜单入口和简单的自助修改密码流程;遵循给定 OpenAPI 请求契约;不增加权限编码或权限判断。
- Non-Goals: 修改后端接口、增加路由、改变锁屏行为、增加权限管理配置。
## Decisions
- Decision: 使用头像菜单中的对话框承载表单,不为此功能新增页面路由。入口依次位于个人中心、修改密码、锁定屏幕。
- Decision: 表单收集当前密码、新密码和确认密码;确认密码仅用于客户端一致性校验,提交时仅构造 `{ old_password, new_password }`。
- Decision: 将 API DTO 类型调整为精确表达 OpenAPI 的 snake_case 字段,避免依赖 HTTP 层不存在的字段转换。
- Decision: 所有已登录用户均可见并可操作该入口,不使用 RBAC、按钮权限或菜单权限配置进行隐藏/拦截;API 请求仍携带现有 Bearer Token。
- Decision: 接口成功时清空敏感表单数据、提示成功,再调用 `userStore.clearLocalState()` 清除旧 token 并跳转登录页;接口失败时展示错误反馈,不记录密码值。
## Risks / Trade-offs
- 当前类型与接口字段不一致,直接复用旧 camelCase 参数会发送错误字段;以 DTO 对齐及请求验证覆盖此风险。
- 密码策略细节未在给定 OpenAPI 中定义;本次不自行新增密码复杂度规则,沿用后端校验结果并反馈错误。
## Migration Plan
无需数据迁移或后端变更。前端发布后,已登录用户可从头像菜单使用入口;回滚时可移除菜单项及对话框实现。
## Open Questions
- None.
## Session Handling
After a successful password change, clear the current client authentication state with `userStore.clearLocalState()` and redirect to the login route. Do not attempt the logout API after changing the password because the old token may already be invalid.

View File

@@ -0,0 +1,21 @@
# Change: 添加自助修改密码功能
## Why
当前头像菜单提供个人中心和锁定屏幕入口,但用户无法从该处修改自己的登录密码。认证服务已提供 `PUT /api/auth/password`,需要补齐可发现的前端入口和修改流程。
## What Changes
- 在头像菜单的“个人中心”和“锁定屏幕”之间增加“修改密码”入口。
- 点击后打开修改密码表单,提交当前密码和新密码至 `PUT /api/auth/password`。
- 按 OpenAPI 使用 `old_password`、`new_password` 请求字段;确认密码(如表单提供)只在前端校验,不发送给接口。
- 修改密码入口面向所有已登录用户,不新增权限编码、路由权限或按钮权限。
- 修改成功后清理本地认证状态并跳转登录页,要求用户使用新密码重新登录。
- 为新增文案提供中英文国际化。
## Impact
- Affected specs: `admin-authentication`
- Affected code: `src/components/core/layouts/art-header-bar/index.vue`、`src/components/core/layouts/art-header-bar/ChangePasswordDialog.vue`、`src/components/core/layouts/art-header-bar/style.scss`、`src/api/modules/auth.ts`、`src/types/api/auth.ts`、`src/locales/langs/zh.json`、`src/locales/langs/en.json`
- API: 已有 `PUT /api/auth/password`;请求体按 OpenAPI 发送 `old_password` 和 `new_password`,使用当前登录 Bearer Token。
- Authorization: 不新增前端权限配置;接口仍按认证 API 的 Bearer 认证要求调用。

View File

@@ -0,0 +1,33 @@
## ADDED Requirements
### Requirement: Self-Service Password Change Entry
The authenticated admin interface SHALL provide a password-change entry in the avatar menu between “个人中心” and “锁定屏幕”. The entry SHALL be available to every authenticated user without a frontend route, button, or menu permission check.
#### Scenario: User opens password-change form from avatar menu
- **GIVEN** the user is authenticated in the admin interface
- **WHEN** the user opens the avatar menu
- **THEN** the menu shows “个人中心”, “修改密码”, and “锁定屏幕” in that order
- **AND** selecting “修改密码” opens the password-change form
- **AND** the entry is not hidden or disabled based on a permission code
### Requirement: Change Current User Password
The password-change form SHALL collect the current password and new password, and SHALL submit them through `PUT /api/auth/password` using the current Bearer token. The request body MUST contain exactly the API fields `old_password` and `new_password`; any confirmation value used for client-side validation MUST NOT be sent. Password values MUST NOT be written to application logs.
#### Scenario: Password change succeeds
- **GIVEN** the user has entered a current password and matching new-password values
- **WHEN** the user submits the form and the API returns success
- **THEN** the frontend sends `old_password` and `new_password` to `PUT /api/auth/password`
- **AND** the frontend displays success feedback and clears the password form values
- **AND** the frontend clears the local authentication state and redirects the user to the login page
- **AND** the user must authenticate again with the new password
#### Scenario: Password change is rejected
- **GIVEN** the user submits the password-change form
- **WHEN** the API rejects the request
- **THEN** the frontend displays error feedback and does not report success
- **AND** the frontend does not log any password value

View File

@@ -0,0 +1,13 @@
## 1. 头像菜单与修改密码表单
- [x] 1.1 在头像菜单“个人中心”和“锁定屏幕”之间添加“修改密码”入口,不设置权限判断。
- [x] 1.2 实现修改密码表单,收集当前密码、新密码及确认密码,并在前端校验必填项与两次新密码一致。
- [x] 1.3 调用认证 API;请求仅包含 `old_password` 和 `new_password`,成功后清空表单并提示结果,失败时显示错误反馈。
- [x] 1.4 添加中英文菜单、表单、校验及结果提示文案。
## 2. API 契约与验证
- [x] 2.1 对齐 `ChangePasswordParams` 与 `AuthService.changePassword` 的请求 DTO,确保网络请求字段为 OpenAPI 定义的 snake_case,且不发送确认密码。
- [x] 2.2 验证菜单顺序、表单校验、成功与失败反馈,以及入口不依赖任何权限编码。
- [x] 2.3 运行相关类型检查和构建,处理本次改动引入的问题。
- [x] 2.4 密码修改成功后清理本地认证状态并跳转登录页。

View File

@@ -1,27 +0,0 @@
# Change: 新增当前用户修改密码弹窗
状态:用户已确认执行(2026-10-09),按本提案实施。
## Why
当前顶部用户菜单只有“个人中心”和“锁定屏幕”,缺少当前登录用户修改密码的入口。统一认证接口已有 `PUT /api/auth/password`,但前端参数类型仍使用不符合接口约定的驼峰字段。
## What Changes
- 在顶部用户菜单“个人中心”和“锁定屏幕”之间新增“修改密码”,点击后打开弹窗,并关闭用户菜单浮层。
- 弹窗包含旧密码、新密码、确认新密码;输入隐藏并允许切换可见,新密码及确认新密码长度为 8–32 位,确认密码必须一致。旧密码必填,不套用新密码长度限制,以兼容已有密码。
- 复用 Element Plus 表单、弹窗及主题,提供字段校验、取消、确认、提交中状态和重复提交保护,兼容窄屏及键盘操作。
- 复用 `AuthService.changePassword`,修正参数类型,仅发送 `old_password` 和 `new_password`;确认密码不发送给后端,Bearer 认证沿用现有请求层。
- 成功后提示并关闭弹窗、清空密码和旧的记住密码凭证;不主动退出登录。失败时保持弹窗,由现有请求层展示后端错误,401 沿用现有认证过期处理。
- 补齐中文及英文菜单与表单文案,以及参数映射、密码长度边界、密码一致性、成功/失败与重复提交验证。
## Impact
- Affected specs: `user-auth`(当前无已归档的能力规范,本提案新增增量规范)。
- Affected code: `src/components/core/layouts/art-header-bar/index.vue`、新增修改密码弹窗组件、`src/types/api/auth.ts`、`src/api/modules/auth.ts`、`src/locales/langs/zh.json`、`src/locales/langs/en.json`。
- 不涉及管理员给其他账号重置密码,不修改锁屏密码,不引入新依赖,不调用测试环境真实密码修改接口。
- 本次另行完成的资产实名时间修正属于现有展示问题修复:仅指定三个 `real_name_at` 展示位置在现有逻辑基础上加 8 小时,不属于本提案的审批范围。
## Validation
审批后验证 7、8、32、33 位新密码边界、确认密码不一致、旧密码为空、成功及失败响应、重复点击,以及菜单位置与重新打开后的密码清空。运行相关测试、类型检查和受影响文件的代码检查。

View File

@@ -1,74 +0,0 @@
## ADDED Requirements
### Requirement: Self-service password menu entry
系统 SHALL 在顶部用户菜单“个人中心”和“锁定屏幕”之间提供“修改密码”入口,点击后显示当前登录用户的修改密码弹窗,不跳转页面。
#### Scenario: 打开修改密码弹窗
- **WHEN** 当前登录用户点击顶部菜单“修改密码”
- **THEN** 系统 MUST 关闭用户菜单浮层并显示修改密码弹窗
- **AND** 弹窗 MUST 包含旧密码、新密码、确认新密码、取消及确认操作
- **AND** 输入 MUST 默认隐藏密码并支持切换可见
### Requirement: Password form validation
系统 SHALL 校验旧密码必填、新密码及确认新密码长度为 8–32 位且两次新密码一致,在校验通过前不得发送修改密码请求。系统 MUST NOT 自动裁剪或修改用户输入的密码,也不得对旧密码新增长度限制。
#### Scenario: 密码长度边界
- **WHEN** 新密码或确认新密码长度为 7 或 33 位
- **THEN** 表单 MUST 提示长度要求并阻止提交
- **AND** 长度为 8 或 32 位且其他校验通过时 MUST 允许提交
#### Scenario: 必填及一致性校验
- **WHEN** 任一密码字段为空,或者两次新密码不一致
- **THEN** 表单 MUST 展示对应字段错误并阻止提交
### Requirement: Unified authentication password contract
系统 SHALL 通过现有统一认证请求层调用 `PUT /api/auth/password`,请求体 MUST 仅包含 `old_password` 和 `new_password`,Bearer 认证 MUST 沿用当前登录会话,确认密码 MUST NOT 发送到服务端。
#### Scenario: 提交有效表单
- **WHEN** 用户提交通过校验的密码表单
- **THEN** 系统 MUST 发送旧密码至 `old_password`、新密码至 `new_password`
- **AND** 请求方法 MUST 为 PUT,请求路径 MUST 为 `/api/auth/password`
- **AND** 请求 MUST 沿用现有请求层的 Bearer 认证
### Requirement: Password submission lifecycle
系统 SHALL 在提交期间提供加载状态并阻止重复提交;成功后提示、关闭弹窗并清空敏感字段及记住密码凭证;普通失败时保留弹窗并展示后端错误;认证过期 MUST 沿用现有请求层处理。成功后系统 MUST NOT 主动退出登录或改变锁屏密码。
#### Scenario: 重复点击提交
- **WHEN** 修改密码请求尚未完成时用户再次确认
- **THEN** 系统 MUST 保持加载状态且不得发送重复请求
#### Scenario: 修改成功
- **WHEN** 修改密码请求成功
- **THEN** 系统 MUST 提示成功并关闭弹窗
- **AND** 系统 MUST 清空全部密码字段及保存的旧登录凭证
- **AND** 系统 MUST 保留当前登录状态,不修改锁屏密码
#### Scenario: 修改失败
- **WHEN** 接口返回普通错误,如旧密码错误或服务器错误
- **THEN** 系统 MUST 通过现有请求层展示错误并保留弹窗
- **AND** 系统 MUST 解除提交中状态以允许用户更正后重试
#### Scenario: 取消后重新打开
- **WHEN** 用户取消或关闭弹窗后重新打开
- **THEN** 所有密码字段及校验状态 MUST 为空
### Requirement: Password dialog interface consistency
修改密码弹窗 SHALL 复用现有 Element Plus 组件和主题,支持中英文、键盘操作及窄屏展示,密码输入 MUST 具备可识别标签和可见校验反馈。
#### Scenario: 窄屏及键盘操作
- **WHEN** 用户在窄屏设备或通过键盘打开弹窗
- **THEN** 弹窗 MUST 不产生水平溢出,且可访问全部输入、取消及确认操作

View File

@@ -1,17 +0,0 @@
## 1. 审批
- [x] 1.1 用户确认修改密码弹窗提案后开始实现。
## 2. 实现
- [x] 2.1 修正 `ChangePasswordParams`,仅包含 `old_password` 和 `new_password`,复用 `PUT /api/auth/password`。
- [x] 2.2 新增修改密码弹窗:旧密码必填、新密码及确认密码 8–32 位、两次新密码一致,支持密码显隐。
- [x] 2.3 加入加载状态、重复提交保护、成功提示及关闭、关闭后清空密码;成功时清除旧的记住密码凭证。
- [x] 2.4 在“个人中心”和“锁定屏幕”之间增加入口,关闭菜单浮层后显示弹窗,补充中英文文案。
## 3. 验证
- [x] 3.1 验证密码长度 7、8、32、33 位边界、必填项和确认密码不一致。
- [x] 3.2 验证请求方法、路径、Bearer 认证及下划线参数,确认请求不含确认密码。
- [x] 3.3 验证成功、失败、认证过期、重复提交和重新打开弹窗的状态清理。
- [x] 3.4 运行相关测试、类型检查及受影响文件代码检查,检查菜单顺序、键盘操作和窄屏布局。

View File

@@ -0,0 +1,31 @@
## Context
- 仓库当前没有归档的 `openspec/specs/`,既有变更统一使用 `## ADDED Requirements` 的 delta,本次沿用。
- OCR 能力由 `POST /api/admin/agent-recharges/payment-voucher-ocr` 提供,语义为「凭证图片对象键 → `external_transaction_no` 预填」,员工代收款核销申请直接复用,不新增后端接口。
- 注册接口 `POST /api/c/v1/agent-distribution-registrations` 契约中的 `shop_code` 仍为必填,改为前端生成后提交。
## Goals / Non-Goals
- Goals: 注册者自主填写店铺信息、店铺编号自动生成、用户名长度校验、免登录页不被存储检查登出、H5 可滚动;两处付款凭证支持上传后自动识别并保留手动识别。
- Non-Goals: 不新增或修改后端接口契约;不做店铺编号前端唯一性保证(由后端唯一性校验兜底);不改变 OCR 结果只预填交易流水号的约束。
## Decisions
- Decision: 店铺编号生成规则为 `S` + `yyyyMMddHHmmss` + 3 位随机数,长度不超过后端字段上限(50)。
- Rationale: 时间戳 + 随机数在客户端生成后碰撞概率低,且保持可读性;唯一性最终由后端校验。
- Decision: 核销申请复用代理充值的 OCR 接口 `POST /api/admin/agent-recharges/payment-voucher-ocr`。
- Rationale: 该接口本质是通用凭证识别,仅返回交易流水号;避免为同一能力重复定义接口。
- Decision: 自动识别以「凭证上传成功」为触发点,取首个已上传凭证对象键,并用 `ocrLoading` 防重复触发;手动按钮逻辑不变。
- Rationale: 首个凭证即用户主凭证,与手动识别取键规则一致,避免自动/手动结果不一致。
- Decision: 存储兼容性检查在免登录路由上直接跳过,不执行登出。
- Rationale: 全新浏览器无任何本地存储时,`validateStorageData()` 会判定需要重新登录并跳转登录页,破坏免登录页。
## Risks / Trade-offs
- 前端生成店铺编号可能撞号 → 采用时间戳 + 随机,后端唯一性校验兜底。
- 复用 `agent-recharges` 路径的 OCR 接口语义略有偏差 → 接口本身为通用凭证识别,后续若后端提供独立接口可平滑替换。
- 上传后自动识别会多一次网络请求 → 仅上传成功时触发一次,识别期间 loading 且禁止重复触发。
## Open Questions
- 无。

View File

@@ -0,0 +1,26 @@
# Change: 代理注册表单调整与付款凭证上传后自动识别
## Why
代理扫码注册页当前把上级店铺的店铺名称与店铺编号从二维码 URL 带入并锁定,注册者无法填写自己的店铺信息;用户名缺少最小长度校验;未登录访问注册页时会被本地存储兼容性检查强制登出并跳转登录页;H5 下页面无法纵向滚动,超出内容不可见。同时,线下代充与员工代收款核销申请虽已支持人工识别付款凭证,但需要上传后再手动点击,且核销申请弹窗尚未提供该能力。
## What Changes
- 代理扫码注册页:店铺名称改为注册者自行填写;店铺编号由前端生成后随注册请求提交,二维码 URL 不再携带 `shop_name` / `shop_code`。
- 代理扫码注册页:用户名校验长度必须大于 2 个字符。
- 修复未登录访问代理注册页被跳转登录页的问题(存储兼容性检查不得对免登录页执行登出)。
- 修复代理注册页 H5 内容超出视口后无法纵向滚动的问题。
- 员工代收款「创建核销申请」弹窗:新增付款凭证「识别凭证」能力,并把付款凭证字段移动到外部交易流水号上方。
- 线下代充与核销申请:付款凭证上传成功后自动识别一次交易流水号,同时保留手动「识别凭证」按钮。
## Impact
- Affected specs: `agent-distribution-registration`、`employee-collection`、`agent-recharge`
- Affected code:
- `src/views/agent-registration/index.vue`
- `src/views/shop-management/detail/index.vue`
- `src/utils/storage/storage.ts`
- `src/assets/styles/app.scss`
- `src/views/finance/employee-collection/applications/components/ApplicationFormDialog.vue`
- `src/views/finance/agent-recharge/index.vue`
- `src/components/business/VoucherUpload.vue`(如需新增上传成功事件)

View File

@@ -0,0 +1,38 @@
## ADDED Requirements
### Requirement: 代理注册店铺信息填写与店铺编号生成
代理注册页 SHALL 由注册者自行填写店铺名称;店铺编号 SHALL 由前端生成并随注册请求提交为 `shop_code`;注册页 MUST NOT 从二维码 URL 带入或锁定店铺名称与店铺编号。
#### Scenario: 扫码进入注册页
- **GIVEN** 用户通过店铺分销二维码进入注册页,URL 携带 `distribution_code`
- **WHEN** 页面初始化
- **THEN** 店铺名称输入框 MUST 为空且可编辑
- **AND** 店铺编号 MUST NOT 由 URL 预填或锁定
- **AND** 分销码 MUST 由 URL 带入并锁定
#### Scenario: 提交注册生成店铺编号
- **GIVEN** 注册者已填写店铺名称与其他必填项
- **WHEN** 其提交注册
- **THEN** 请求体 MUST 携带前端生成的 `shop_code`
- **AND** `shop_code` MUST 非空
- **AND** MUST NOT 因店铺编号为空阻止提交
#### Scenario: 店铺名称必填
- **GIVEN** 注册者未填写店铺名称
- **WHEN** 其提交注册
- **THEN** 前端 MUST 阻止提交并提示填写店铺名称
### Requirement: 代理注册用户名长度校验
代理注册页用户名 SHALL 至少包含 3 个字符;不满足时前端 MUST 阻止提交并提示。
#### Scenario: 用户名长度不足
- **GIVEN** 注册者输入的用户名长度为 1 或 2
- **WHEN** 其提交注册
- **THEN** 前端 MUST 阻止提交
- **AND** MUST 提示用户名长度必须大于 2 个字符

View File

@@ -0,0 +1,26 @@
## ADDED Requirements
### Requirement: 线下代充付款凭证上传后自动识别
线下代充弹窗 SHALL 在支付凭证上传成功后自动识别一次交易流水号,同时保留手动「识别凭证」按钮;自动识别失败 MUST NOT 阻断提交,且 MUST 只预填 `external_transaction_no`。
#### Scenario: 上传支付凭证后自动识别
- **GIVEN** 线下代充弹窗已选择支付凭证
- **WHEN** 凭证上传成功
- **THEN** 前端 MUST 自动调用 `POST /api/admin/agent-recharges/payment-voucher-ocr`
- **AND** 识别成功时 MUST 将返回的 `external_transaction_no` 预填入交易流水号输入框
#### Scenario: 保留手动识别
- **GIVEN** 支付凭证已上传
- **WHEN** 用户点击「识别凭证」
- **THEN** 前端 MUST 支持手动触发识别
#### Scenario: 自动识别失败不阻断
- **GIVEN** 自动识别返回失败或超时
- **WHEN** 识别结束
- **THEN** 前端 MUST NOT 阻断用户手动填写与提交
- **AND** MUST NOT 清空用户已填写内容
- **AND** MUST 只预填 `external_transaction_no`,不得预填金额、付款人、付款时间或备注

View File

@@ -0,0 +1,44 @@
## ADDED Requirements
### Requirement: 核销申请付款凭证识别
创建核销申请弹窗 SHALL 将付款凭证字段置于外部交易流水号字段上方,并 SHALL 支持上传付款凭证后自动识别交易流水号预填,同时保留手动「识别凭证」按钮;识别结果 MUST 只作预填且保持可编辑,识别失败 MUST NOT 阻断提交或清空已填内容。
#### Scenario: 上传凭证后自动识别
- **GIVEN** 用户在创建核销申请弹窗上传付款凭证
- **WHEN** 凭证上传成功
- **THEN** 前端 MUST 自动调用付款凭证识别接口
- **AND** 识别成功时 MUST 将返回的 `external_transaction_no` 预填入交易流水号输入框
#### Scenario: 手动识别
- **GIVEN** 付款凭证已上传
- **WHEN** 用户点击「识别凭证」
- **THEN** 前端 MUST 调用识别接口并预填交易流水号
#### Scenario: 识别失败不阻断
- **GIVEN** 识别接口返回失败或超时
- **WHEN** 自动或手动识别结束
- **THEN** 前端 MUST 只展示提示
- **AND** MUST NOT 清空已填写的交易流水号
- **AND** MUST NOT 阻止用户提交
#### Scenario: 字段顺序
- **GIVEN** 用户打开创建核销申请弹窗
- **WHEN** 表单渲染
- **THEN** 付款凭证字段 MUST 位于外部交易流水号字段之上
### Requirement: 核销申请凭证识别接口契约
核销申请付款凭证识别 SHALL 复用 `POST /api/admin/agent-recharges/payment-voucher-ocr`,请求体 `{ payment_voucher_key }`,响应取 `external_transaction_no`;请求超时 MUST NOT 低于 30 秒,请求期间 MUST 展示 loading 并防止重复触发。
#### Scenario: 识别请求契约
- **GIVEN** 已上传至少 1 个付款凭证
- **WHEN** 前端发起识别
- **THEN** 请求体 MUST 为 `{ payment_voucher_key }`,取首个已上传凭证对象键
- **AND** 响应 MUST 只用于预填 `external_transaction_no`
- **AND** 请求超时 MUST NOT 低于 30 秒

View File

@@ -0,0 +1,27 @@
## 1. 代理注册页表单调整
- [x] 1.1 店铺名称改为注册者自行填写,移除从 URL 带入与锁定逻辑(`src/views/agent-registration/index.vue`)
- [x] 1.2 店铺编号由前端生成后提交为 `shop_code`,移除 URL 带入、锁定与输入框
- [x] 1.3 用户名增加「长度必须大于 2 个字符」校验规则与提示
- [x] 1.4 店铺详情页注册二维码 URL 移除 `shop_name`、`shop_code` 查询参数(`src/views/shop-management/detail/index.vue`)
## 2. 代理注册页缺陷修复
- [x] 2.1 修复未登录访问注册页被跳转登录页:存储兼容性检查排除免登录路由(`src/utils/storage/storage.ts`)
- [x] 2.2 修复 H5 页面溢出后无法纵向滚动(`src/views/agent-registration/index.vue` / `src/assets/styles/app.scss`)
## 3. 核销申请付款凭证识别
- [x] 3.1 将付款凭证字段移动到外部交易流水号字段上方(`ApplicationFormDialog.vue`)
- [x] 3.2 新增付款凭证「识别凭证」按钮与 OCR 调用,复用 `POST /api/admin/agent-recharges/payment-voucher-ocr`
- [x] 3.3 付款凭证上传成功后自动识别一次,保留手动识别
- [x] 3.4 识别期间展示 loading,失败只提示且不清空已填内容、不阻断提交
## 4. 线下代充上传后自动识别
- [x] 4.1 支付凭证上传成功后自动触发一次识别,保留手动「识别凭证」按钮(`src/views/finance/agent-recharge/index.vue`)
## 5. 验证
- [x] 5.1 运行 `eslint`、`vue-tsc --noEmit`、`vite build --mode production` 均通过
- [x] 5.2 运行 `openspec validate update-agent-registration-and-voucher-recognition --strict` 通过

View File

@@ -0,0 +1,92 @@
## Context
AUG26-017 给代理预存款带来两类变化:在线自充的收款方式从「由支付配置自动决定」改为「超管配置允许范围」;线下预存款审批从「金额 + 支付凭证」补齐为「收款方式 + 交易流水号 + 其他凭证」。后端接口边界已经确认:
| 用途 | 接口 |
|---|---|
| 在线可用方式 | `GET /api/admin/agent-self-recharge-payment-methods`,代理/平台可用,超管 403;旧接口 `GET /api/admin/agent-recharges/payment-methods` 保留但前端不再调用 |
| 允许范围读取 | `GET /api/admin/system-configs`(`module`、`page`、`page_size`,返回 `list` / `page` / `page_size` / `total`) |
| 允许范围写入 | `PUT /api/admin/system-configs/{key}`,请求体 `{ key, value }`,`value` 为字符串化配置值 |
| 交易流水号识别 | `POST /api/admin/agent-recharges/payment-voucher-ocr`,请求 `{ payment_voucher_key }`,响应 `{ external_transaction_no }` |
| 线下创建 | `POST /api/admin/agent-recharges`,`payment_method=offline` 时新增 `offline_payment_method_id`、`external_transaction_no`、`other_voucher_key` |
| 列表与详情 | `GET /api/admin/agent-recharges`、`GET /api/admin/agent-recharges/{id}` 新增 5 个响应字段 |
## Goals / Non-Goals
**Goals**
- 在线充值只展示后端返回的实际可用方式,并优雅处理空列表。
- 超管可在既有系统配置页面维护允许范围,无需新增接口或页面。
- 线下预存款申请可提交收款方式、交易流水号与其他凭证,并支持 OCR 预填流水号。
- 列表与详情正确展示两类交易号与收款方式快照。
**Non-Goals**
- 不新增「代理自充设置」独立页面与专用配置接口。
- 不实现允许范围的审计查询接口(后端记录操作者、前后值与时间,前端不查询)。
- 不实现后端接口、商户池交集计算、企微审批回调。
- 不实现 H5/C 端在线充值,不为企业账号做分支。
## Decisions
### 允许范围沿用受控系统配置
允许范围配置项的读取与写入统一走系统配置:读取 `GET /api/admin/system-configs`,写入 `PUT /api/admin/system-configs/{key}`。系统配置页已是元数据驱动的通用渲染器(`value_type` 决定控件、`enum_values` 决定枚举选项、`readonly` 与 `sensitive` 决定保护策略),因此后端的允许范围配置项注册后即可在页面中展示与编辑。
前端 MUST NOT 硬编码该配置项的 `config_key`,也 MUST NOT 新增专用设置写接口。该配置项归属 `c2b.payment` 模块,属于现有 `SystemConfigModule` 取值,无需扩展模块枚举。
允许范围的枚举取值为 `wechat_only`(仅微信支付)、`alipay_only`(仅支付宝支付)、`both`(同时支持微信与支付宝);系统配置页展示与选择时使用中文标签,未命中映射时回退展示原值。
超管入口使用一个「代理自充设置」菜单项,跳转到系统配置页面并带 `module=c2b.payment` 过滤条件;系统配置页面除了既有的 `config_key` query,还需支持从 `route.query.module` 初始化模块筛选,保证跳转后列表已按模块收敛。
### 在线可用方式
| 项 | 取值 |
|---|---|
| 接口 | `GET /api/admin/agent-self-recharge-payment-methods` |
| 响应 | `{ methods: (wechat \| alipay)[], min_amount, max_amount }` |
| 空列表 | 只提示「当前暂无可用的在线支付方式」,禁用提交,不解释被限制还是无可用商户 |
| 超管 | 该接口对超管返回 403,前端在超管视角不请求它,仅通过系统配置查看允许范围 |
| 存量单 | 配置变更不影响已创建的待支付单,前端不在配置变更后刷新待支付单 |
金额上下限优先使用接口返回的 `min_amount` / `max_amount`(单位分),接口未返回时回退既有常量。
### 线下预存款创建字段
| 字段 | 必填 | 说明 |
|---|---|---|
| `offline_payment_method_id` | 是 | 取自 `GET /api/admin/employee-collection-payment-methods` 的启用项(`enabled=true`,`page_size=100`) |
| `external_transaction_no` | 是 | 交易流水号,OCR 预填后人工确认,可编辑;前端不做重复校验 |
| `other_voucher_key` | 否 | 其他凭证对象键数组,最多 5 个 |
| `payment_voucher_key` | 是 | 支付凭证,至少 1 个,与其他凭证分开提交 |
历史线下单的收款方式只用 `offline_payment_method_code` / `offline_payment_method_name` 快照展示,不用 `offline_payment_method_id` 反查字典当前值。
列表筛选保持后端已有参数集合(`page`、`page_size`、`shop_id`、`status`、`recharge_source`、`start_date`、`end_date`),不新增交易流水号筛选,交易流水号只做展示。
### OCR 预填交互
- 入口:线下代充弹窗支付凭证区的「识别凭证」按钮,取已上传的第一个 `payment_voucher_key`;未上传凭证时禁用。
- 请求:`POST /api/admin/agent-recharges/payment-voucher-ocr`;通过 `BaseService.post` 的第三个参数传 `{ timeout: 30000 }`,请求期间按钮与交易流水号字段展示 loading 并防重复点击。
- 成功:把 `external_transaction_no` 写入交易流水号输入框,字段保持可编辑并提示对照凭证核对。
- 失败(凭证不是图片、对象不存在、识别服务异常):只提示,不清空已填内容、不阻断手工填写与提交。
- 只预填交易流水号,金额、付款人、付款时间、备注一律不预填。
### 凭证上传类型
取上传地址时必须显式声明 `content_type` 为 `image/jpeg`,否则 OCR 会以「不是图片」直接拒绝。`VoucherUpload` 新增可选 `contentType` prop,代理充值的支付凭证与其他凭证固定传 `image/jpeg`,并把它透传给 `StorageService.getUploadUrl` 与 `StorageService.uploadFile`。
### 交易流水号展示
`payment_transaction_id` 是在线渠道返回的权威交易号,只有在线单有值;`external_transaction_no` 是线下人工申报的交易流水号。两者独立展示、互不覆盖:在线单只展示前者,线下单只展示后者。
### 详情页保持只读
代理充值详情页只做信息展示,顶部仅保留返回导航;本次新增的交易流水号、收款方式与其他凭证都只读呈现,不引入任何业务操作按钮。创建、确认线下充值、驳回等操作入口仍留在列表页操作列。
## Risks / Trade-offs
- **配置 Key 由后端注册决定**:前端不硬编码,配置项按 `c2b.payment` 模块渲染;若后端最终调整模块归属,只需同步调整菜单跳转的 `module` 参数。
- **OCR 端到端约 15 至 16 秒**:必须配置不低于 30 秒的超时并展示 loading,否则用户容易重复点击。
- **强制声明 `image/jpeg`**:按需求文档要求统一声明为 `image/jpeg`,上传非 JPEG 图片时以声明类型为准。
- **收款方式字典项被引用后会冻结**:展示历史单依赖快照字段,避免字典改名或停用导致历史数据展示漂移。

View File

@@ -0,0 +1,36 @@
# Change: 代理自充收款方式配置与线下预存款审批字段
## Why
8 月迭代 AUG26-017(对应 PRD-008-021 与 PRD-008-013)包含两项要求:代理在线自充的收款方式由超级管理员维护「允许范围」(仅微信 / 仅支付宝 / 同时支持),代理实际可用方式取允许范围与当前可用商户方式的交集,交集为空时不允许创建在线充值单;线下预存款审批需要补齐「收款方式」「交易流水号」「其他凭证」,其中交易流水号支持从付款凭证 OCR 预填。
后台管理端现状与该要求有差距:在线充值直接调用旧接口 `GET /api/admin/agent-recharges/payment-methods`,线下代充表单只有店铺、支付凭证与运营备注,充值列表与详情也没有交易流水号、线下收款方式快照与其他凭证字段。
本次按后端实际 OpenAPI 契约对齐:可用方式改读 `GET /api/admin/agent-self-recharge-payment-methods`;允许范围的读取与写入沿用受控系统配置 `GET /api/admin/system-configs` 与 `PUT /api/admin/system-configs/{key}`;交易流水号识别使用 `POST /api/admin/agent-recharges/payment-voucher-ocr`。
## What Changes
- 在线充值可用支付方式改由 `GET /api/admin/agent-self-recharge-payment-methods` 提供,读取 `methods`、`min_amount`、`max_amount`;旧接口 `GET /api/admin/agent-recharges/payment-methods` 保留但前端不再调用。
- `methods` 为空时只提示「当前暂无可用的在线支付方式」并禁用提交,不解释是被允许范围限制还是无可用商户。
- 代理自充允许范围不新增专用接口与专用页面:配置项归属 `c2b.payment` 模块,超管沿用「系统配置」页面,通过 `GET /api/admin/system-configs` 读取、`PUT /api/admin/system-configs/{key}` 提交字符串化 `value`;前端不硬编码配置 Key,允许范围对代理与平台账号不可见。
- 新增「代理自充设置」菜单(仅超级管理员),跳转到系统配置页面并带 `module=c2b.payment` 过滤条件;系统配置页面支持从路由 query 初始化模块筛选。
- 线下预存款创建弹窗新增:收款方式(数据源 `GET /api/admin/employee-collection-payment-methods` 的启用项,提交 `offline_payment_method_id`)、交易流水号(必填、可编辑)、其他凭证(可选,最多 5 个 `other_voucher_key`);支付凭证 `payment_voucher_key` 仍必填且至少 1 个,与其他凭证分开提交。
- 新增付款凭证 OCR 预填:`POST /api/admin/agent-recharges/payment-voucher-ocr` 请求 `{ payment_voucher_key }`、响应只有 `{ external_transaction_no }`;结果只作预填且始终可编辑,识别失败不阻断人工填写与提交,请求超时不低于 30 秒并展示 loading。
- 充值列表与详情展示新增字段:`external_transaction_no`、`offline_payment_method_id`、`offline_payment_method_code`、`offline_payment_method_name`、`other_voucher_key`;线下单收款方式使用编码/名称快照展示,不用 `id` 反查字典当前值。
- 代理充值列表不新增交易流水号筛选:`GET /api/admin/agent-recharges` 未提供该查询参数,交易流水号仅做展示。
- 付款凭证与其他凭证获取上传地址时显式声明 `content_type` 为 `image/jpeg`。
- 交易流水号 `external_transaction_no` 与在线渠道 `payment_transaction_id` 独立展示、互不覆盖;前端不做交易流水号重复校验。
- 不实现后端接口、商户池逻辑、企微审批回调与 H5/C 端页面。
## Impact
- Affected specs: `agent-recharge`、`system-config-management`
- Affected code:
- `src/types/api/agentRecharge.ts`、`src/api/modules/agentRecharge.ts`、`src/types/api/index.ts`
- `src/views/finance/agent-recharge/index.vue`、`src/views/finance/agent-recharge/detail.vue`
- `src/views/settings/system-configs/index.vue`、`src/types/api/systemConfig.ts`
- `src/router/routesAlias.ts`、`src/router/routes/asyncRoutes.ts`
- `src/components/business/VoucherUpload.vue`
- `src/locales/langs/{zh,en}.json`
- Dependencies: `docs/产品迭代8月份/代理.md`
- Out of scope: 代理自充设置独立页面、允许范围审计查询接口、企业账号分支、H5/C 端在线充值。

View File

@@ -0,0 +1,132 @@
## ADDED Requirements
### Requirement: 代理在线自充可用收款方式
前端 SHALL 通过 `GET /api/admin/agent-self-recharge-payment-methods` 获取代理在线自充的可用支付方式与金额范围,并在该接口返回空 `methods` 时禁止创建在线充值单。
#### Scenario: 读取可用支付方式
- **WHEN** 平台账号或代理账号进入代理充值页面并打开在线充值弹窗
- **THEN** 前端 MUST 调用 `GET /api/admin/agent-self-recharge-payment-methods`
- **AND** 前端 MUST 使用响应 `methods` 渲染可选的微信与支付宝方式
- **AND** 前端 MUST 使用响应 `min_amount` 与 `max_amount` 作为金额上下限
- **AND** 前端 MUST NOT 再调用 `GET /api/admin/agent-recharges/payment-methods`
#### Scenario: 可用方式为空
- **GIVEN** `GET /api/admin/agent-self-recharge-payment-methods` 返回空 `methods`
- **WHEN** 用户打开在线充值弹窗
- **THEN** 前端 MUST 提示「当前暂无可用的在线支付方式」
- **AND** 前端 MUST 禁用在线充值提交
- **AND** 前端 MUST NOT 解释为空的原因是被允许范围限制还是无可用商户
- **AND** 前端 MUST NOT 因空列表报错或阻断页面其余功能
#### Scenario: 超级管理员不通过该接口读取允许范围
- **WHEN** 当前登录账号为超级管理员
- **THEN** 前端 MUST NOT 为读取允许范围调用 `GET /api/admin/agent-self-recharge-payment-methods`
- **AND** 前端 MUST 统一处理该接口对超级管理员返回的 403
#### Scenario: 允许范围变更不影响存量待支付单
- **WHEN** 允许范围配置发生变更
- **THEN** 前端 MUST NOT 刷新或改写已创建待支付充值单的支付方式与商户信息
### Requirement: 线下预存款申请字段
线下预存款创建请求 SHALL 在 `payment_method` 为 `offline` 时提交 `offline_payment_method_id`、`external_transaction_no` 与可选的 `other_voucher_key`,并与既有的 `payment_voucher_key` 分开提交。
#### Scenario: 提交线下预存款申请
- **GIVEN** 用户以平台账号或超级管理员身份打开线下代充弹窗
- **WHEN** 用户提交申请
- **THEN** 请求体 MUST 包含 `amount`、`payment_method` 为 `offline` 与 `shop_id`
- **AND** MUST 包含必填 `offline_payment_method_id`,取值来自 `GET /api/admin/employee-collection-payment-methods` 的启用项
- **AND** MUST 包含必填 `external_transaction_no`
- **AND** MUST 包含至少 1 个 `payment_voucher_key`
- **AND** MAY 包含最多 5 个 `other_voucher_key`
#### Scenario: 支付凭证与其他凭证分开提交
- **WHEN** 用户上传支付凭证与其他凭证
- **THEN** 支付凭证 MUST 通过 `payment_voucher_key` 提交
- **AND** 其他凭证 MUST 通过 `other_voucher_key` 提交
- **AND** 前端 MUST NOT 将两类凭证合并到同一字段
#### Scenario: 交易流水号与在线交易号互不覆盖
- **WHEN** 前端提交或展示线下预存款申请
- **THEN** `external_transaction_no` MUST 只作为线下人工申报的交易流水号
- **AND** 前端 MUST NOT 用 `payment_transaction_id` 覆盖或替代 `external_transaction_no`
- **AND** 前端 MUST NOT 对 `external_transaction_no` 做重复性校验
### Requirement: 付款凭证交易流水号识别预填
前端 SHALL 通过 `POST /api/admin/agent-recharges/payment-voucher-ocr` 以已上传的付款凭证对象键换取交易流水号预填值,识别失败 MUST NOT 阻断人工填写与提交。
#### Scenario: 识别成功预填交易流水号
- **GIVEN** 线下代充弹窗已上传至少 1 个付款凭证
- **WHEN** 用户点击识别凭证
- **THEN** 前端 MUST 调用 `POST /api/admin/agent-recharges/payment-voucher-ocr`,请求体为 `{ payment_voucher_key }`
- **AND** 前端 MUST 将响应 `external_transaction_no` 写入交易流水号输入框
- **AND** 交易流水号输入框 MUST 保持可编辑并提示用户对照凭证核对
#### Scenario: 识别失败不阻断提交
- **GIVEN** OCR 返回失败,包括凭证不是图片、对象不存在或识别服务异常
- **WHEN** 用户点击识别凭证
- **THEN** 前端 MUST 展示失败提示
- **AND** 前端 MUST NOT 阻断用户手动填写交易流水号并提交
- **AND** 前端 MUST NOT 清空用户已填写内容
#### Scenario: 识别请求展示加载态并使用足够超时
- **WHEN** 前端发起 OCR 请求
- **THEN** 前端 MUST 在请求期间展示 loading 并防止重复提交
- **AND** 请求超时 MUST NOT 低于 30 秒
#### Scenario: 只预填交易流水号
- **WHEN** OCR 识别成功
- **THEN** 前端 MUST 只预填 `external_transaction_no`
- **AND** 前端 MUST NOT 预填金额、付款人、付款时间或备注
### Requirement: 代理充值交易流水号与收款方式展示
代理充值列表与详情 SHALL 展示线下预存款的 `external_transaction_no` 与收款方式快照,在线充值只展示 `payment_transaction_id`。
#### Scenario: 列表展示线下补充字段
- **WHEN** 列表返回 `payment_method` 为 `offline` 的充值单
- **THEN** 列表 MUST 展示 `external_transaction_no`
- **AND** 列表 MUST 使用 `offline_payment_method_name` 展示收款方式
#### Scenario: 详情展示收款方式快照
- **WHEN** 详情返回历史线下充值单
- **THEN** 前端 MUST 使用 `offline_payment_method_code` 与 `offline_payment_method_name` 展示收款方式
- **AND** 前端 MUST NOT 用 `offline_payment_method_id` 反查字典当前值
- **AND** 前端 MUST 展示 `other_voucher_key` 对应的其他凭证
#### Scenario: 两类交易号独立展示
- **WHEN** 详情展示在线充值单
- **THEN** 前端 MUST 只展示 `payment_transaction_id`
- **AND** 前端 MUST NOT 把 `external_transaction_no` 当作在线渠道交易号展示
#### Scenario: 列表不新增交易流水号筛选
- **WHEN** 前端实现代理充值列表筛选
- **THEN** 前端 MUST 只使用 `page`、`page_size`、`shop_id`、`status`、`recharge_source`、`start_date` 与 `end_date`
- **AND** 前端 MUST NOT 新增交易流水号筛选条件
### Requirement: 付款凭证上传类型声明
代理充值付款凭证与其他凭证在获取上传地址时 SHALL 显式声明 `content_type` 为 `image/jpeg`。
#### Scenario: 上传地址声明图片类型
- **WHEN** 前端为代理充值线下凭证请求上传地址
- **THEN** 请求 MUST 携带 `content_type` 为 `image/jpeg`
- **AND** 上传请求 MUST 使用相同的内容类型

View File

@@ -0,0 +1,42 @@
## ADDED Requirements
### Requirement: 代理自充允许范围配置项
超级管理员维护的代理自充允许范围 SHALL 作为受控系统配置项,通过既有系统配置页面读取与更新,前端 MUST NOT 新增专用接口或专用页面。
#### Scenario: 通过系统配置读取允许范围
- **WHEN** 超级管理员进入系统配置页面
- **THEN** 前端 MUST 调用 `GET /api/admin/system-configs` 获取配置列表
- **AND** 后端注册的代理自充允许范围配置项 MUST 依据返回元数据渲染
- **AND** 前端 MUST NOT 为读取允许范围调用专用接口
#### Scenario: 以枚举控件编辑允许范围
- **GIVEN** 允许范围配置项返回非空 `enum_values`
- **WHEN** 超级管理员编辑该项
- **THEN** 页面 MUST 使用枚举选择控件渲染允许范围
- **AND** 页面 MUST 以字符串化 `value` 调用 `PUT /api/admin/system-configs/{key}`
- **AND** 页面 MUST 在提交前校验取值属于 `enum_values`
- **AND** 允许范围枚举值 MUST 以中文标签展示,包括仅微信支付、仅支付宝支付与同时支持微信与支付宝
#### Scenario: 不硬编码配置 Key
- **WHEN** 前端实现允许范围配置项的展示与编辑
- **THEN** 前端 MUST NOT 硬编码该配置项的 `config_key`
- **AND** 前端 MUST 依据 `config_key`、`module`、`value_type`、`control` 与 `enum_values` 等元数据驱动渲染
- **AND** 该配置项归属 `c2b.payment` 模块,前端 MUST NOT 扩展模块枚举取值
#### Scenario: 代理自充设置菜单带入模块筛选
- **GIVEN** 当前登录账号为超级管理员
- **WHEN** 用户点击「代理自充设置」菜单
- **THEN** 前端 MUST 跳转到系统配置页面并携带 `module=c2b.payment`
- **AND** 系统配置页面 MUST 使用该 query 初始化模块筛选并据此查询配置列表
- **AND** 非超级管理员 MUST NOT 看到该菜单
#### Scenario: 允许范围对代理与平台不可见
- **WHEN** 当前登录账号不是超级管理员
- **THEN** 前端 MUST NOT 向代理与平台账号展示允许范围配置的入口或当前值
- **AND** 代理与平台账号 MUST 只能通过 `GET /api/admin/agent-self-recharge-payment-methods` 获取实际可用方式

View File

@@ -0,0 +1,55 @@
## 1. Contract and API Types
- [x] 1.1 `src/types/api/agentRecharge.ts`:`AgentRecharge` 新增 `external_transaction_no`、`offline_payment_method_id`、`offline_payment_method_code`、`offline_payment_method_name`、`other_voucher_key`(`string[] | null`),保持 `payment_transaction_id` 与 `payment_voucher_key` 语义不变。
- [x] 1.2 扩展 `CreateAgentRechargeOfflineRequest`:新增必填 `offline_payment_method_id`、必填 `external_transaction_no`、可选 `other_voucher_key`(最多 5 个)。
- [x] 1.3 新增 `AgentRechargePaymentVoucherOcrRequest { payment_voucher_key }` 与 `AgentRechargePaymentVoucherOcrResponse { external_transaction_no }`。
- [x] 1.4 在 `src/types/api/index.ts` 导出新增类型。
## 2. Agent Recharge Service
- [x] 2.1 `src/api/modules/agentRecharge.ts` 新增 `getSelfRechargePaymentMethods()`,请求 `GET /api/admin/agent-self-recharge-payment-methods`。
- [x] 2.2 新增 `recognizePaymentVoucher(data)`,请求 `POST /api/admin/agent-recharges/payment-voucher-ocr`,超时不低于 30000 毫秒。
- [x] 2.3 保留旧 `getPaymentMethods()` 方法,但页面不再调用。
## 3. Online Recharge Available Methods
- [x] 3.1 在线充值弹窗改用 `getSelfRechargePaymentMethods()` 读取 `methods` / `min_amount` / `max_amount`,并把 `wechat`、`alipay` 映射为微信、支付宝选项。
- [x] 3.2 `methods` 为空时提示「当前暂无可用的在线支付方式」并禁用提交,不解释原因。
- [x] 3.3 超管视角不请求该接口(403 兜底);允许范围变更后不刷新已创建的待支付单。
## 4. Super Admin Allow-Range Config
- [x] 4.1 允许范围沿用系统配置页通用渲染:`GET /api/admin/system-configs` 读取、`PUT /api/admin/system-configs/{key}` 提交字符串化 `value`;不新增专用接口与专用页面。
- [x] 4.2 `wechat_only` / `alipay_only` / `both` 在系统配置页展示与选择时显示中文标签,未命中映射时回退原值。
- [x] 4.3 新增「代理自充设置」菜单(仅超级管理员),跳转到系统配置页面并带 `module=c2b.payment`;系统配置页支持从 `route.query.module` 初始化模块筛选。
- [x] 4.4 在 `zh.json`、`en.json` 的 `menus.settings` 下补充 `agentSelfRecharge` 中英文文案,并清理系统配置页预存的空样式块。
## 5. Offline Pre-deposit Create Dialog
- [x] 5.1 新增「收款方式」下拉,数据来自 `GET /api/admin/employee-collection-payment-methods`(`enabled=true`、`page_size=100`),必填,提交 `offline_payment_method_id`。
- [x] 5.2 新增「交易流水号」输入(必填、可编辑),并提示对照凭证核对。
- [x] 5.3 新增「其他凭证」上传(可选,最多 5 个),提交 `other_voucher_key`;支付凭证仍必填且至少 1 个,两者分开提交。
- [x] 5.4 `VoucherUpload` 新增可选 `contentType` prop 并透传给 `getUploadUrl` 与 `uploadFile`;代理充值线下凭证固定传 `image/jpeg`。
- [x] 5.5 线下提交体按契约组装:`{ amount, payment_method: offline, shop_id, offline_payment_method_id, external_transaction_no, payment_voucher_key, other_voucher_key, remark }`,未填写的可选字段不提交。
## 6. Voucher OCR Prefill
- [x] 6.1 支付凭证区新增「识别凭证」按钮,取第一个已上传凭证 Key;未上传凭证时禁用。
- [x] 6.2 识别期间展示 loading(按钮与交易流水号字段)并防重复点击,超时不低于 30 秒。
- [x] 6.3 识别成功写入 `external_transaction_no`,字段保持可编辑;失败只提示,不清空已填内容、不阻断提交。
- [x] 6.4 不预填金额、付款人、付款时间与备注。
## 7. List and Detail Display
- [x] 7.1 列表新增线下交易流水号与线下收款方式(`offline_payment_method_name` 快照)展示,仅线下单展示。
- [x] 7.2 详情新增交易流水号、收款方式(`offline_payment_method_code` 与 `offline_payment_method_name` 快照)与其他凭证预览;在线单只展示 `payment_transaction_id`。
- [x] 7.3 不使用 `offline_payment_method_id` 反查字典当前值,也不做交易流水号重复校验。
- [x] 7.4 列表不新增交易流水号筛选,保持后端已有查询参数集合不变。
## 8. Verification
- [x] 8.1 校验 `methods` 为空、超管调用新接口 403、允许范围变更不影响存量待支付单三种情况。 — 已核验:index.vue:100 空数组提示「当前暂无可用在线支付方式」;设置入口在 system-configs 且受 hasAuth 配置权限管控;允许范围不写回存量待支付单
- [x] 8.2 校验 OCR 成功、失败、超时三条路径均不阻断人工填写与提交。 — 已核验:OCR 仅预填 external_transaction_no,ocrLoading 期间人工输入与提交不被阻断,标注「识别结果仅供参考」
- [x] 8.3 校验线下单与在线单的两类交易号、收款方式快照与其他凭证展示正确。 — 已核验:列表/详情展示 external_transaction_no、offline_payment_method_name/code 快照、other_voucher_key 凭证组
- [x] 8.4 运行 `npm run build`(含 `vue-tsc --noEmit`)与 `npm run check:encoding`。
- [x] 8.5 运行 `openspec validate update-agent-self-recharge-and-offline-approval --strict`。

View File

@@ -0,0 +1,38 @@
## Context
本次变更同时涉及任务导入弹窗、配置管理表单、公共错误处理约定和三类资产展示面。已有解绑导入 API、`VoucherUpload` 组件及 H5 配置页面能力,不新增后端接口或新的上传基础设施。
## Goals / Non-Goals
- Goals:
- 让 CSV 解绑导入沿用已有批量导入的交互模式和共享上传能力。
- 让页面错误提示遵循“公共请求层统一提示、页面不重复提示”的约定。
- 让关联手机号在列表和详情的字段、空值、图标和展示格式一致。
- Non-Goals:
- 不改变解绑导入 API、权限模型、任务处理逻辑或后端手机号数据范围。
- 不删除或迁移历史 H5 运营弹窗配置。
- 不修改其他业务页面中与本次列表加载无关的错误提示。
## Decisions
- Decision: 复用 `VoucherUpload` 作为 CSV 解绑导入的文件入口;通过 `purpose` 和 CSV 校验参数表达业务约束,提交前只使用组件产出的对象存储 key。
- Decision: `asset_detail` 仅从新增/编辑的页面选择项隐藏,历史配置的 `PAGE_NAMES`/回显映射继续保留,避免历史数据无法查看或保存时被静默改写。
- Decision: 关联手机号直接消费 `associated_phones`,使用统一的“、”拼接和 `-` 空值占位,不在前端二次脱敏,以符合接口“按资产数据范围返回完整手机号”的契约。
- Decision: 资产详情图标沿用 `BasicInfoCard` 现有 `asset-label--*` iconfont 伪元素机制,新增关联手机号对应的 class/glyph,不引入新的图标库。
## Risks / Trade-offs
- 共享上传组件的默认文件数量、大小或校验提示可能与旧弹窗不同,需要在弹窗层明确传入参数并回归关闭/重选行为。
- 隐藏 `asset_detail` 后,已存在该值的编辑表单必须允许回显,否则会造成用户误以为配置被清空;实现时需区分“历史值回显”和“新选项列表”。
- 完整手机号展示属于敏感信息,必须保持现有权限和后端资产数据范围,不得通过前端扩大查询范围。
## Migration Plan
1. 先完成组件和页面改造并通过静态检查。
2. 在测试环境验证上传任务、历史弹窗配置回显和关联手机号字段兼容性。
3. 发布前确认公共请求层已覆盖列表接口错误提示;如未覆盖,先补齐公共层再移除页面提示。
## Open Questions
- 无。上传大小上限沿用 `VoucherUpload`/现有解绑导入接口约束,若后端另有上限以接口契约为准。

View File

@@ -0,0 +1,39 @@
# Change: 统一资产导入交互并补充关联手机号展示
## Why
当前 CSV 解绑导入使用独立的弹窗和原生上传实现,与批量导入 IoT 卡的导入体验不一致,也没有复用项目已有的上传组件。H5 运营弹窗配置仍把“资产详情”作为新增配置的可选页面,列表请求失败时还会重复弹出错误提示;核销申请状态文案、设备/IoT 卡列表及资产详情中的关联手机号展示也需要与后端返回契约和现有视觉规范保持一致。
## What Changes
- 将 CSV 解绑导入弹窗调整为与“批量导入 IoT 卡”一致的导入说明、模板入口、表单布局、提交状态和底部操作区。
- CSV 文件上传改用现有通用上传组件,限定单个 `.csv` 文件并沿用 `phone_unbind_import` 上传用途;上传中禁止重复提交,上传结果和校验错误在弹窗内可见。
- 在新增/编辑运营弹窗配置的 `PAGE_OPTIONS` 中隐藏“资产详情”选项;历史配置若已命中 `asset_detail` 仍可正常展示,不因隐藏选项而丢失或改写历史数据。
- 移除 H5 运营弹窗配置列表加载 `try/catch` 中的本地 `ElMessage.error(normalizeApiError(error).message || '获取运营弹窗配置列表失败')`,由公共请求层统一负责错误提示,页面保留必要的日志和加载状态收尾。
- 将核销申请的“已撤销或已关闭”统一改为“已关闭”,同步状态选项、映射和类型注释中的用户可见文案。
- 设备管理和 IoT 卡管理列表消费并展示接口返回的 `associated_phones`,多个手机号使用统一分隔符,无关联时显示稳定占位符;按后端资产数据范围展示完整手机号,不在前端脱敏或截断。
- 在资产信息基础信息区域的“关联手机号”标签前补充与其他字段一致的图标样式,并保持空数组的占位展示。
## Impact
- Affected specs:
- `phone-asset-association-management`
- `h5-popup-configuration-management`
- `employee-collection`
- `device-management`
- `iot-card-management`
- `asset-information`
- Affected code:
- `src/views/asset-management/phone-asset-association/index.vue`
- `src/components/business/VoucherUpload.vue`(仅在需要扩展 CSV 上传参数时调整)
- `src/views/settings/h5-popup-configuration/index.vue`
- `src/views/finance/employee-collection/employeeCollectionDisplay.ts`
- `src/views/asset-management/device-list/index.vue`
- `src/views/asset-management/iot-card-management/index.vue`
- `src/types/api/device.ts`、`src/types/api/card.ts`、相关列表列配置
- `src/views/asset-management/asset-information/components/BasicInfoCard.vue`
- Related changes:
- 衔接已有 `add-phone-asset-unbind-management` 的解绑导入 API 和权限约束。
- 衔接已有 `add-h5-popup-configuration-management` 的页面枚举、历史配置展示和权限约束。
- Breaking changes: 无后端 API 破坏性变更;新增配置页面选项对运营人员的可选范围有意收窄。

View File

@@ -0,0 +1,13 @@
## ADDED Requirements
### Requirement: 资产详情关联手机号标签图标
资产信息基础信息区域展示 `associated_phones` 时,关联手机号标签 MUST 使用与其他资产字段一致的图标前缀样式。
#### Scenario: 展示关联手机号字段
- **WHEN** 资产详情渲染关联手机号字段
- **THEN** “关联手机号”标签前 MUST 显示现有 iconfont 图标
- **AND** 图标样式 MUST 与基础信息区域其他带图标标签的颜色、间距和对齐方式一致
- **AND** 手机号内容 MUST 保持现有完整值拼接和空值占位规则

View File

@@ -0,0 +1,19 @@
## ADDED Requirements
### Requirement: 设备列表展示关联手机号
设备管理列表 MUST 消费接口返回的 `associated_phones` 当前关联手机号列表,并按后端资产数据范围展示完整手机号。
#### Scenario: 设备存在关联手机号
- **GIVEN** 设备列表项包含一个或多个 `associated_phones`
- **WHEN** 设备管理列表渲染
- **THEN** 页面 MUST 展示“关联手机号”列
- **AND** 多个手机号 MUST 使用统一分隔符连接,且 MUST 不在前端脱敏或截断
#### Scenario: 设备没有关联手机号
- **GIVEN** `associated_phones` 为空数组或缺失
- **WHEN** 设备管理列表渲染
- **THEN** “关联手机号”列 MUST 显示稳定的空值占位符

View File

@@ -0,0 +1,12 @@
## ADDED Requirements
### Requirement: 核销申请关闭状态文案
核销申请状态值为关闭/撤销兼容状态时,前端用户可见文案 MUST 统一显示为“已关闭”。
#### Scenario: 显示关闭状态
- **WHEN** 核销申请列表、筛选项或详情返回兼容的关闭状态值
- **THEN** 页面 MUST 显示“已关闭”
- **AND** 页面 MUST NOT 显示“已撤销或已关闭”

View File

@@ -0,0 +1,18 @@
## ADDED Requirements
### Requirement: 运营弹窗新增页面选项与列表错误提示
运营弹窗配置页面 MUST 在新增/编辑表单的 `PAGE_OPTIONS` 中隐藏“资产详情”页面,同时 MUST 由公共请求层统一处理列表接口异常,页面不得重复弹出同一错误提示。
#### Scenario: 新增配置不提供资产详情选项
- **WHEN** 用户打开新增或编辑运营弹窗配置表单
- **THEN** 页面 MUST NOT 在可选页面列表中展示“资产详情”
- **AND** 页面 MUST 继续保留已有配置中 `asset_detail` 的名称映射和历史值回显能力
#### Scenario: 列表请求失败
- **WHEN** 运营弹窗配置列表请求在网络层或接口层失败
- **THEN** 页面 MUST 不再调用 `ElMessage.error(normalizeApiError(error).message || '获取运营弹窗配置列表失败')`
- **AND** 公共请求层 MUST 负责用户可见的错误提示,页面 MUST 仅保留日志记录及 loading 状态收尾

View File

@@ -0,0 +1,19 @@
## ADDED Requirements
### Requirement: IoT 卡列表展示关联手机号
IoT 卡管理列表 MUST 消费接口返回的 `associated_phones` 当前关联手机号列表,并按后端资产数据范围展示完整手机号。
#### Scenario: IoT 卡存在关联手机号
- **GIVEN** IoT 卡列表项包含一个或多个 `associated_phones`
- **WHEN** IoT 卡管理列表渲染
- **THEN** 页面 MUST 展示“关联手机号”列
- **AND** 多个手机号 MUST 使用统一分隔符连接,且 MUST 不在前端脱敏或截断
#### Scenario: IoT 卡没有关联手机号
- **GIVEN** `associated_phones` 为空数组或缺失
- **WHEN** IoT 卡管理列表渲染
- **THEN** “关联手机号”列 MUST 显示稳定的空值占位符

View File

@@ -0,0 +1,19 @@
## ADDED Requirements
### Requirement: CSV 解绑导入弹窗复用批量导入交互
CSV 解绑导入入口 MUST 使用与批量导入 IoT 卡一致的导入说明、模板入口、表单确认和底部操作布局,并复用项目通用上传组件完成文件选择与上传。
#### Scenario: 打开解绑导入弹窗
- **WHEN** 具备权限的用户打开 CSV 解绑导入
- **THEN** 页面 MUST 展示导入说明、模板下载、解绑原因、二次确认和明确的创建任务操作
- **AND** 弹窗 MUST 提供与批量导入 IoT 卡一致的抽屉/弹窗层次和提交状态反馈
#### Scenario: 使用共享组件上传 CSV
- **WHEN** 用户选择解绑 CSV 文件
- **THEN** 页面 MUST 使用通用上传组件,并限制为单个 `.csv` 文件
- **AND** 上传 MUST 使用 `phone_unbind_import` 用途并产出后续任务接口所需的 `file_key`
- **AND** 文件上传中 MUST 禁止重复创建任务,上传失败 MUST 在弹窗内给出可理解的校验或错误反馈

View File

@@ -0,0 +1,27 @@
# Tasks: 统一资产导入交互并补充关联手机号展示
## 1. CSV 解绑导入
- [x] 1.1 对照批量导入 IoT 卡抽屉,重排 CSV 解绑导入说明、模板下载、原因/确认表单和底部操作区。
- [x] 1.2 将 CSV 文件选择替换为通用上传组件,配置单文件、`.csv`、`phone_unbind_import` 用途及文件类型/编码提示。
- [x] 1.3 接入上传中状态、移除/重选文件和提交前校验,确保创建解绑任务仍发送 `file_key`、`reason`、`confirmed`。
- [x] 1.4 验证上传失败、重复选择文件、取消关闭和任务创建成功后的清理行为。
## 2. H5 运营弹窗配置
- [x] 2.1 从新增/编辑表单的 `PAGE_OPTIONS` 隐藏 `asset_detail`,保留历史值的名称映射和只读回显能力。
- [x] 2.2 删除列表加载 `catch` 中重复的运营弹窗配置失败 `ElMessage.error`,保留日志与 loading 状态收尾。
- [x] 2.3 验证全局请求错误提示只出现一次,且成功响应中的业务错误仍按现有响应约定处理。
## 3. 状态文案与关联手机号
- [x] 3.1 将核销申请状态“已撤销或已关闭”改为“已关闭”,同步选项、映射、注释和相关页面筛选显示。
- [x] 3.2 确认设备与 IoT 卡列表类型保留 `associated_phones: string[]`,并在默认列/列管理配置中展示“关联手机号”。
- [x] 3.3 统一多手机号拼接和空数组占位符,确认不做前端脱敏、截断或超出后端数据范围的补查。
- [x] 3.4 为资产详情“关联手机号”标签补充现有 iconfont 图标,并检查卡资产、设备资产及空值场景。
## 4. Verification
- [x] 4.1 运行相关 TypeScript/Vue 检查、编码检查和变更页面 lint。
- [x] 4.2 手工验证 CSV 导入、运营弹窗配置、核销申请、设备列表、IoT 卡列表和资产详情的关键场景。
- [x] 4.3 使用 `openspec validate update-asset-import-popup-and-phone-display --strict` 校验提案格式。

View File

@@ -0,0 +1,21 @@
# Change: 对齐业务用户组成员增量管理接口
## Why
《产品迭代8月份/修改.md》已将业务用户组成员维护从“整体替换”调整为增量增加/迁移和按组移除。当前前端仍调用旧 PUT/全局 DELETE 接口,无法展示候选成员归属和操作提示。
## What Changes
- 对齐成员查询、成员候选、增量增加/迁移、按组移除接口。
- 成员管理弹窗展示当前成员及成员关系信息。
- 候选账号展示 `add`、`already_member`、`move` 操作提示。
- 停用组允许查询和移除,但新增/迁移由后端拒绝并提示。
- 用户组列表使用接口返回的实时成员数。
- 当前成员和候选账号展示当前所属组名称、编码、启用状态,不展示内部组 ID。
- 店铺列表和详情展示业务用户组编码、名称、启用状态和业务线,不展示内部组 ID。
## Impact
- Affected specs: `business-user-group-management`
- Affected code: business user group types/API/page
- Breaking API alignment: 移除前端对旧整体替换 PUT 与全局清空 DELETE 的调用。

Some files were not shown because too many files have changed in this diff Show More