kate522/wordpress-theme-aksrt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,759 Commits 1 Branch 0 Tags
main
Commit Graph
17 Commits
Author SHA1 Message Date
kate522 16b57dcf1c fix(after-sale): 前台售后不再展示「退款金额」字段 
并非每次售后都真的退款——换货、补偿、仅作记录的情况都会把工单标成已完成，
此时退款金额要么是 0 要么没有实际意义，摆在前台只会让人误解钱已经退回去了。
两个前台入口都撤掉该字段：

- 售后详细弹窗：明细行只留「申请时间」，处理记录时间线不受影响
- 订单详情弹窗的售后记录卡片：撤掉退款金额后 meta 的 dl 会空壳，连同
  dl 一起移除；卡片仍保留状态徽章 + 申请时间 + 原因 + 「查看详细」

连带清理死代码：aftersaleAmountText / afterSaleAmount 两个格式化助手各自
只剩这一处调用，orders.css 里 5 条 .aksrt-order-detail__after-sale-meta
规则也随之无人引用。后台售后页与订单明细页的退款金额列不动——那边是运营
核对账目的口径，需要看到金额。

验证：tests/widget-system/ 462 项、tests/admin/ 76 项通过；抽取
buildDetailHtml 跑样例载荷，确认退款金额不再出现、申请时间 / 处理记录 /
再次申请售后按钮都还在。未做浏览器视觉验收。
 2026-10-10 13:04:37 +08:00
kate522 1875470ac7 fix(after-sale): 售后工单已完结仍可再次申请，改由订单是否已退款决定 
上一个提交把「工单 completed」当成了不能再申请售后的判据，方向搞反了：
能否再售后应该看订单有没有被标「已退款」，而不是看工单状态。订单已退款时
status_group 变成 refunded、enabled 直接为 false，那道闸门本来就够用；用工单
状态再判一次，反而把「工单已完结但订单没退款」的用户堵死，售后详细弹窗底部
也只剩下一个「我知道了」死胡同。

- reapplyable_statuses 补上 STATUS_COMPLETED：rejected / cancelled / completed
  一律放行再次申请，售后详细弹窗底部按钮对已完成订单渲染「再次申请售后」
- can_apply 还原为只看有没有进行中的工单（!open），不再二次校验工单状态
- create() 的重复申请闸门还原为 find_active()：只挡仍在流转的工单，
  completed 不挡；订单已退款由上面的 STATUS_PAID 校验先挡掉
- 点「再次申请售后」后清 has_application 落回申请表单，提交走 create()
  新建工单，链路本来就通，无需改动

harness 场景名改为 settled_ticket_still_allows_reapply，断言 completed /
rejected / cancelled 三种已终结状态都能新建工单；待审核工单同因幂等、换因
挡住的场景保留。

验证：tests/widget-system/ 462 项、tests/admin/ 76 项通过；after-sale-log-harness
7/7。未做浏览器视觉验收。
 2026-10-09 18:38:18 +08:00
kate522 c955fd35f2 fix(after-sale): 售后工单已完结即不可再申请，不看订单是否另标已退款 
原来的重复申请闸门只看「进行中」的工单（find_active = pending/processing），
于是工单已 completed、但订单没被另标「已退款」时，订单还能再发起一次售后。
已退款订单之所以不能再申请，是因为 status_group 变了导致 enabled 为 false，
属于间接效果；工单层面的规则一直是漏的。

- create() 改为以 latest_for_order() 为准：completed 直接挡掉；待审核/处理中
  仍走同人同因幂等（返回原工单），rejected / cancelled 放行再次发起
- after_sale_state() 的 can_apply 同步收紧，与 can_reapply 同一口径：
  有工单时只有 rejected / cancelled 才放行，completed 不再漏过去
- 界面上售后详细弹窗的「再次申请」本就只对 rejected / cancelled 渲染，
  这条改动把服务端与 API 口径补齐，堵住绕过前端直接打 REST 的口子

harness 补两个场景：completed 挡住而 rejected / cancelled 放行；待审核工单
同因幂等返回原单、换因挡住。

验证：tests/widget-system/ 462 项、tests/admin/ 76 项通过；after-sale-log-harness
7/7（新增两场景）；dev harness 渲染两个后台页面与 unchecked 处理场景均正常。
未做浏览器视觉验收。
 2026-10-09 18:25:02 +08:00
kate522 36b3ba6f45 fix(after-sale): 订单详情弹窗不再渲染售后状态节点进程 
订单详情弹窗的「售后记录」卡片把整条处理时间线铺在了卡片里，和点开
「查看详细」后的售后详细弹窗重复，卡片本身也被拉得很长。改为只保留状态
徽章 + 申请时间、原因/申请理由、退款金额与「查看详细」入口；完整处理记录
由售后详细弹窗独占呈现，信息不缺、入口也还在。

- 删掉卡片里的 orderDetailHandlingLogHtml(item.handling_log) 调用
- 连带删除随之无人调用的 orderDetailHandlingLogHtml / handlingEntryTitle /
  AFTER_SALE_STATUS_LABELS 三个助手
- recordPayload 仍带 handling_log，点开详情弹窗照旧能看到时间线
- modal-runtime.css 的时间线规则不动：售后详细弹窗还在用，无需重打包

验证：tests/widget-system/ 462 项、tests/admin/ 76 项通过；契约测试改为断言
订单详情弹窗不再出现 timeline 标记与三个助手，同时锁住「查看详细」载荷仍带
handling_log；node --check 通过。未做浏览器视觉验收。
 2026-10-09 18:12:48 +08:00
kate522 039fa6d863 feat(after-sale): 处理记录时间线改为「节点 + 状态 + 时间」同一行 
原实现把状态与时间竖排在节点右侧的 88px 固定列里，状态文字一长就折行、
时间被挤到第三行，和右侧备注也对不齐。改为节点独占一列，状态与时间包在
head 里紧随其后，处理备注另起一行：

- [节点][处理状态][时间] 一行，状态色仍按工单状态走 --as-accent
- 竖线改挂到条目的 ::before（原来是 aside 的），top 从 12px 调到 14px，
  与加了 4px 上边距的节点底部对齐，绳子依旧穿过每个节且末项不收口
- head 用 flex + baseline + gap:8px，状态过长时时间自然换行而不重叠
- 售后详细弹窗与订单详情弹窗共用同一套标记，两侧同步改

验证：tests/widget-system/ 462 项、tests/admin/ 76 项通过；用 node 分别抽取
两个 JS 里的时间线构造函数跑样例载荷，确认输出为
[节点][状态][时间] + 另起一行的备注；重建 public.css / public.min.css，
diff 仅限时间线规则。未做浏览器视觉验收。
 2026-10-09 18:01:16 +08:00
kate522 26ce9a5904 feat(after-sale): 售后处理记录改为每次提交留痕并新增时间线 
工单行内新增 handling_log 列，用户申请、用户撤销与后台每次改状态都落一条
「状态 + 备注 + 来源 + 时间」，按时间正序存放、上限 50 条（对齐
MetaAssetService::MAX_RECORDS）。set_status 因此变成读-改-写，补上
GET_LOCK/RELEASE_LOCK 包裹，并在锁内重读工单快照——锁外取快照仍会被并发
追加覆盖。

三处界面由「只显示最后一条」改为回放整条处理链路：

- 后台订单明细「售后记录」按工单渲染头部（状态/金额/申请时间）+ 原因 +
  完整处理记录
- 售后面板手风琴「处理备注」单独占整行并置于「申请说明」上方，删掉已无
  意义的「审核时间」
- 前台售后详细弹窗与订单详情弹窗的售后记录改为时间线：左列绳结状态条
  （节点 + 状态 + 时间），右列处理备注；样式只在 modal-runtime.css 定义
  一份，两个弹窗共用

清理随之失效的死代码：工单的 admin_note / reviewed_at / completed_at，以及
全仓库无写入方的 gateway_request_id / gateway_refund_id / gateway_result；
连带删掉 gatewayResultText()、uninstall 里从未存在过的 aksrt_after_sale
表项，并把两处后台页面重复的状态标签数组收成 after_sale_status_labels()、
重复的 .aksrt-as-log 样式收成 after_sale_log_css()。

顺带修复 88669f69 重构退款流水线时误删 refund_amount()、却仍在 create()
里调用的问题——此前任何用户提交售后都会直接 fatal。

验证：tests/widget-system/ 462 项、tests/admin/ 76 项通过；新增
after-sale-log-harness.php 驱动真实 AfterSaleService，覆盖首条日志、空备注
也留痕、撤销记录、50 条上限与畸形行规范化；两个后台页面经 dev harness
渲染校验「处理备注」宽行位于「申请说明」之前；未做浏览器视觉验收。
 2026-10-09 13:59:50 +08:00
kate522 3eb9cc739c style(modal): 售后与订单弹窗底部按钮满幅化并优化悬停反馈 2026-10-07 10:18:48 +08:00
kate522 e9a1a75259 fix(styles): 还原弹窗 footer 相邻按钮分界线并补悬停阴影 
被平铺规则的 border:0 抹掉的 legacy 分隔线按家族色还原，售后四弹窗与订单详情同款；更新构建产物与契约测试。
 2026-10-07 09:53:10 +08:00
kate522 d69e1d33c3 fix(orders): 修复再次申请售后被 has_application 分流回售后详细的问题并对齐底部按钮观感 2026-10-07 09:43:22 +08:00
kate522 8023e2e472 feat(after-sale): 支持撤销售后工单并接入人机验证 2026-10-07 09:20:59 +08:00
kate522 918ca371be chore(repo): 行尾规范化，恢复索引 LF 契约 
远端 9 个文件以 CRLF 入库，违反 .gitattributes「索引一律 LF」声明，
在 autocrlf=true 的工作区产生永久假脏并阻塞合并。仅行尾变化，无内容改动。
 2026-10-07 09:13:42 +08:00
kate522 9e3267fef4 test(payment): 契约测试同步弹窗底部与记录卡片新行为 2026-10-06 23:50:33 +00:00
kate522 c200427358 test(payment): 售后契约测试同步结构化表单与可再次申请新行为 2026-10-06 18:08:08 +00:00
kate522 a0f59826fe fix(payment): 售后弹窗滚动容器改用 no-scrollbar，消除弹窗边缘滚动栏 
mini-scrollbar 是 3px 可见细滚动条（举报弹窗 600px 宽弹窗用的写法）；
modal-mini 这类带炫彩横幅的表单弹窗，主题统一走禁封申诉/记录弹窗的口径：
scroll-y + no-scrollbar 完全隐藏滚动条（含细滚动条）+ 50vh 内层滚动。
申请与售后详细两个滚动容器一并切换，滚动行为不变、只是不再露出滚动栏。
 2026-10-06 23:38:18 +08:00
kate522 93579cbc9f fix(payment): 售后弹窗改为按钮载荷同步弹出，修复首次点击无反馈 
原实现是「点击 → 先请求 /orders/{n} → 再弹窗」，与项目里所有可用弹窗
（含举报链路 report.js）不同构：举报弹窗把数据放在按钮 data-* 属性里同步
弹出。前置请求会让首次点击在请求返回前毫无反应，体感就是"得二次点击"。

- 按钮 data-aksrt-after-sale-apply / -detail 携带订单与售后状态载荷
  （PHP 模板与 order-center.js 的 actionHtml 同构生成），点击当拍即开
  对应弹窗：申请表单 / 超时效提示 / 售后详细，零前置请求
- 「再次申请售后」同样使用已渲染载荷，不再重新拉取订单
- 提交与图片上传仍走 REST，服务端校验不变；列表刷新后载荷随之更新
- jsdom 多脚本环境实测：三种入口均在点击同一拍弹出且 fetch 计数为 0
 2026-10-06 23:29:59 +08:00
kate522 4ea02f25ac fix(payment): 补升 schema 版本使售后举证图片列在已安装站点生效 
order_aftersale 新增 images 列时未同步升 SCHEMA_VERSION，而 dbDelta 只在版本
变化时重跑，已安装站点不会执行 ALTER TABLE，提交售后申请直接报
Unknown column 'images'。SCHEMA_VERSION 2.5.0 -> 2.5.1，并在契约测试中
锁定「列变更必须同步升版本」，部署后进入一次 wp-admin 即自动补列。
 2026-10-06 22:37:32 +08:00
kate522 1a9a2762f3 feat(payment): 新增「售后策略」配置与前台售后弹窗链路 
- 后台「支付&付费 → 售后策略」：售后功能开关、申请时效、超时效提示(HTML)、
  预置原因、申请售后说明、所需材料、申请说明占位文案、可上传图片开关；
  PHP schema 与 SPA schema 1:1 对齐，group 字段支持拖拽排序
- PaymentRuntime 新增售后设置解析（缺键回退 schema 默认、HTML 走 kses、
  中文原因稳定 slug）与 after_sale_expired 时效判定（支付时间起算）
- 售后工单支持举证图片（order_aftersale.images 列，最多 3 张，
  复用评论图片上传校验）与上传路由；订单视图模型输出 after_sale 按钮状态
- 前台申请 / 超时效提示 / 售后详细三个独立弹窗（modal-mini + 蓝色炫彩头），
  订单详情弹窗不再内嵌售后表单并清理相关死代码
- 新增 after-sale-policy 契约测试与运行时 harness，527 项契约测试通过
 2026-10-06 22:21:47 +08:00