Главная Обзор Помощь
Вход
fa88
/
foodie-server
1
0
Ответвить 0
Файлы Задачи 0 Запросы на слияние 0 Вики
Дерево: 9b11e23d20
Ветки Метки
foodie-server
/
specs
/
034-stall-qualification
/
quickstart.md

quickstart.md 9.9 KB
История Исходник

034 摊位审核部署与验收

日期：2026-10-09。后端、商家 PC、平台 PC 均在 test-202609v2 原分支实施，未新建分支；初始功能、商品图片增量及通用组件/文件名规范收口均已提交/推送，具体 SHA 与远端结果以 Git 记录和最终交付回复为准；App 未修改。

上线前准备（必须手动完成）

  1. 备份数据库并告知夜市主：存量与新增摊位必须提交相同材料审核，不提供营业宽限或旧账号审核自动通过。
  2. 手动执行 updatesql/sql.md 中「2026-10-09 034」：两张表及唯一索引、未审核存量摊位闭店、平台菜单/权限；再执行文档末尾「2026-10-16 摊位资料审核补充字段」增量。未认证摊位 state=1，不修改旧订单或发起取消、退款。
  3. 审核角色需要分配 stall:qualification:list、stall:qualification:query、stall:qualification:review；只有列表权限看不到证件图片、不能审核。平台菜单组件为 stallQualification/index，平台列表不展示草稿。
  4. 按最新确认，新材料与商品共用 /utils/Upload，保存在 ruoyi.profile/upload，返回 /profile/upload/... 路径；身份证等图片链接也公开访问，用户已确认。确保商品上传/图片访问路由正常、目录持久化并在多实例共享。原 ruoyi.profile 同级 stall-qualification 目录只用于历史私有附件；须继续保留，不迁移或回写旧申请，也不为兼容旧附件开放该目录的公共映射。
  5. 发布后端及两个 PC 构建。新增 type=4 摊主可正常登录填材料，不用夜市主代填；多个摊主账号共享同一摊位材料。夜市主仍在「摊位列表」只查看申请状态和是否有通过版本。
  6. MyBatis 材料 Mapper 保持 WARN；不额外为材料接口加请求/响应全量日志。Druid 使用唯一的 StallQualificationStatFilter，材料 SQL 的参数同时在慢日志与监控参数缓存中脱敏，其他 SQL 沿用原诊断。部署配置不得另注册普通 StatFilter 或启用会打印原始 JDBC 参数的额外日志过滤器。

SQL、真实数据库、服务重启及上述部署操作本轮均未执行。不要只发布页面而漏执行 DDL，也不要把本机测试通过当作已经上线。

业务操作

  • 摊主：商家 PC「摊位资料审核」填写负责人姓名/电话、证件号码/图片、摊位照片和银行账户户名、银行名称、银行账号、银行证明图片（均必填）；邮箱、摊位介绍、营业登记证明、董监事截图、食品业者登录字号/证明及 UBO 声明选填。摊位名称、地址和夜市 ID 来自服务端绑定；缺少名称或地址时，先在原门店/摊位管理中补齐。
  • 草稿可不完整；提交时负责人、证件及摊位照片、银行账户四项必须齐全，食品业者登录资料选填。每类图片最多 5 张、每张不超过 5MB，仅 JPEG/PNG；上传未完成时不能提交。
  • 待审核不能编辑/重复提交。平台审核通过或填写原因驳回；驳回后修订形成新申请版本，旧材料和审核历史不覆盖。保存使用认证主体 version，审核使用申请 version；冲突需刷新，不能自动重试覆盖别人。
  • 审核通过只开放营业资格，不自动开店；摊主仍通过原营业设置决定是否营业。已有有效材料重新申请时，原有效版本继续有效，直到新版本通过替换。
  • 无记录、草稿、首次待审核或首次驳回均不得开店、新下单；闭店时可以编辑名称/地址来补资料。用户下单、商家创建订单以及仍可调用的旧 /addorder 均校验，不能只信列表或前端。旧订单出餐、配送、支付后续处理不调用此新门禁。
  • 用户端列表标为关闭；夜市摊位详情返回关闭状态；扫码摊位列表隐藏未通过摊位。普通商家的旧审核流程不替换。

本轮自动化验证

使用 JDK 21 C:/Users/99029/.jdks/graalvm-jdk-21.0.12+7.1，仅在命令环境设置 JAVA_HOME/PATH，没有改全局 Java 设置。

mvn -pl ruoyi-admin -am test '-Dtest=StallQualification*Test,PosOrderShOprateControllerTest,UserOrderControllerMerchantIdTest,StallControllerTest,MerchantSessionAuthAnnotationTest' '-Dsurefire.failIfNoSpecifiedTests=false' -q

53 个用例通过（28 个本模块用例 + 25 个受影响既有回归）。覆盖草稿/提交、版本竞争、重复审核、驳回重提、保留已通过版本、身份权限、私有文件、真实 Mapper 解析、门禁与闭店资料编辑、错误绑定隐私、Druid 生产配置替换及上传 data 返回契约。 Druid 配置测试构造未初始化/未连接的数据源，并确认 proxyFilters 中恰好一个脱敏 StatFilter；不连接测试或生产数据库。

mvn -pl ruoyi-admin -am package -DskipTests -q 模块编译和打包通过；该打包命令不运行测试，测试使用前述独立命令执行。

两个 PC 仓库均执行 node --test tests/*.test.cjs：商家 5/5，平台 16/16。四语言各 50 个新 key 完全一致。平台新增 API/页面/辅助代码使用 eslint ... --no-ignore 检查通过。 商家 vue-cli-service build --mode test、平台（命令环境设置 NODE_OPTIONS=--openssl-legacy-provider）vue-cli-service build --mode staging 均通过。 商家构建保留既有 7 个缺 key 提示；平台保留既有两个 .vue~ 文件的构建警告及包体积提示，未修改无关文件。平台本机依赖安装未生成或修改依赖锁文件。

部署后仍需验收（未验证）

  • 真实 MySQL 建表/菜单 SQL、主表首次并发初始化、两摊主同时提交、两管理员同时审核、事务失败回滚和待审核唯一约束。
  • 浏览器真实登录、上传/预览、草稿回显、驳回重提、审核通过后手动开店、存量未认证禁止新单、旧订单继续履约。
  • 生产/测试文件目录持久化、多实例共享、新公共图片可访问、历史私有附件仍鉴权读取；停用账号和跨摊位申请访问拒绝。
  • 实际 Druid 慢查询日志/监控页面脱敏与环境覆盖配置，私有证件不出现在应用、代理或审计日志。
  • 初始功能只运行上述定向 Java 用例和 PC Node 测试；商品上传增量及后续收口已运行后端全量 952 项全部通过（含补齐泰文语言包后的 i18n 契约测试），详见 tasks.md T022–T025。

不得将本页的模拟/配置测试视为上述真实联调的替代。

图片组件调整及故障核对（2026-10-09，历史私有方案记录）

  • 商家上传改为门店管理同款方框加号，每类 5 张，待审核/只读无上传和删除；仍使用私有文件接口，不能改用 /utils/Upload。平台审核材料使用商品管理的 ImagePreview，保留同组放大切换，私有 blob 地址不能拼 /prod-api。
  • 图片 Content-Type 带 charset 等参数时，前端按媒体类型识别 JPEG/PNG；JSON/HTML 错误响应仍显示原占位，不渲染为证件。后端接口及 SQL 无变化。
  • 若部署后仍看不到图片，在浏览器 Network 核对私有文件请求状态和 Content-Type：401/403 检查平台登录及 query 权限；404 检查代理路由、服务实例及私有目录共享/持久化；200 但返回 HTML/JSON 检查代理回退页或业务错误。平台详情能打开不代表图片文件一定在当前服务实例上。
  • 需要同时验证平台和商家读取同一已上传文件。不要粘贴带令牌的请求头、真实证件内容或完整材料引用到公共日志；排障只记录必要的状态和类型。截图本身无法确定线上请求失败原因，本轮本地组件回归不替代真实浏览器和服务器联调。
  • 本次自动验证：两个 PC 全部 Node 测试分别为平台 20/20、商家 11/11；商家 npm run build:test、平台 npm run build:stage（仅本命令设置 OpenSSL 兼容选项）成功。构建保留既有商家 7 项缺 key 警告、平台 2 个 .vue~ 文件与包体积提示。共享 ImagePreview 保持旧风格，未借本任务整体格式化。

商品上传方式（2026-10-09，当前方案）

  • 用户确认包括身份证在内的新材料使用商品公共图片方式，本节覆盖前面的旧私有上传限制。新上传复用 /utils/Upload，保存其 data 返回的 /profile/upload/YYYY/MM/DD/文件名.jpg或png；字段名及数组结构不变。
  • 按用户确认，上传/展示组件换成其他功能通用的实现：商家页直接用商品同款 el-upload（action 为 VUE_APP_BASE_URL + '/utils/Upload'）和 el-image，平台审核页直接用共享 ImagePreview；StallQualificationImages.vue、PrivateImages.vue 已删除。
  • FileUploadUtils 生成存储文件名时把 / \ : * ? " < > | ; # % , 与控制字符替换为 _（CJK 等保留）：身份证#正面.jpg、含逗号文件名上传后仍是合法公共路径，可通过材料保存校验，也不会破坏逗号分隔预览。商品等其他使用该工具的上传同步受益，已存旧文件不受影响。
  • 商家按 VUE_APP_BASE_URL + 图片路径 显示（与商品页一致）；平台路径按现有 VUE_APP_BASE_API 解析。新图片不会再请求 /system/stallQualification/files/...。不能只发布 PC，必须同时发布后端公共路径保存校验。
  • 申请详情、审核、营业门禁及历史版本保护不变。公共图片链接本身无需登录；服务端保存时仍确认是系统实际存在的 JPEG/PNG、最多5MB、2000万像素，拒绝外部 URL 和非法路径。
  • 历史 storeId/UUID.jpg或png 引用不迁移、不回写，继续请求旧鉴权接口（两端页面内保留 blob 兼容读取）。此次更换上传方式不恢复服务器缺失的旧私有文件，也不证明原截图的线上根因已排除；需保留旧目录或由摊主在可编辑的新申请中重新上传。
  • 无新增字段、DDL、数据迁移或 App 修改；不自动部署。当前验证结果见 tasks.md 的 T023–T025，生产/测试真实浏览器上传与图片 GET、目录持久化仍待部署后联调。