win
|
2a7b731484
|
feat(finance): implement Phase 1 core P&L service + wire into dashboard
- Add internal/service/finance/types.go: AssetType enum, param/result structs
- Add internal/service/finance/service.go: Service interface, read-only ctor
- Add internal/service/finance/query_user.go: QueryUserProfitLoss (4 fan-out scans)
- Add internal/service/finance/query_activity.go: QueryActivityProfitLoss (4 fan-out scans)
- Add internal/service/finance/service_test.go: 22 integration tests (all pass)
- Wire finance.Service into admin handler (admin.go)
- Replace dashboard_activity cost scan with finance.Service call (D-09: value_cents single source of truth)
- Revenue/gamepass/draw-count scans unchanged; response schema fully compatible
Co-Authored-By: claude-flow <ruv@ruv.net>
|
2026-03-21 18:38:33 +08:00 |
|
|
|
5b34972ee3
|
fix(dashboard): 盈亏分析CAST修复+视角改为平台视角(A-B)
1. CAST修复:
MySQL的 / 运算符返回DECIMAL类型,GORM无法将DECIMAL扫描进int64,
导致商品产出静默返回0。添加 CAST(... AS SIGNED) 与排行榜对齐。
2. 视角统一:
盈亏分析原为用户视角(B-A),排行榜为平台视角(A-B),同一用户
一个显示+¥12,130(用户赚了),一个显示-¥12,127(平台亏了),
造成管理员困惑。
修改:
- 净盈亏: Value-Cost → Cost-Value (A-B,平台盈利为正)
- 盈亏比: Value/Cost → Cost/Value (A/B,>1表示平台盈利)
- 趋势图每个数据点同步调整
|
2026-03-20 21:18:02 +08:00 |
|
|
|
fe3141e2b5
|
fix(dashboard): 盈亏分析商品产出对齐排行榜计算口径
问题:
盈亏分析(GetUserProfitLossTrend)和用户画像(GetUserProfile)中的
"商品产出"与玩家消费排行榜(DashboardPlayerSpendingLeaderboard)
计算口径不一致,导致同一用户的商品产出差异巨大。
排行榜显示用户9110商品产出¥16,913.40,盈亏分析显示¥0.00。
差异点:
1. status条件: 盈亏用 status=1(仅待发货),排行榜用 status IN (1,3)
2. 价格回退链: 盈亏缺少 price_snapshot_cents 回退层级
3. 道具卡倍率: 盈亏未计算 reward_multiplier_x1000
4. void排除: 盈亏未排除 remark 含 void 的作废项
修复:
- users_profit_loss.go: 商品产出查询完全对齐排行榜公式
- users_profile.go: 库存价值查询同步对齐
- 公式: COALESCE(value_cents, snapshot_cents, price, 0)
* GREATEST(COALESCE(multiplier, 1000), 1000) / 1000
- 条件: status IN (1,3) AND remark NOT LIKE '%void%'
|
2026-03-20 21:02:21 +08:00 |
|
|
|
ddd66bf4e9
|
fix(dashboard): 修复盈亏分析商品产出只统计待发货库存的bug
问题:
盈亏分析(GetUserProfitLossTrend)和用户画像(GetUserProfile)中的
"商品产出"查询条件为 `ui.status = 1`,只统计了待发货/库存中的商品,
已发货/已兑换(status=3)的商品被完全排除。
示例:用户9110实际累计获得874件商品(价值¥16,279.40),但因为大部分
已发货(status=3),盈亏分析只显示商品产出¥12.50,全资产产出严重偏低。
而 dashboard_user_spending.go 中的同类查询正确使用了
`status IN (1, 3)`,说明此处是遗漏。
修复:
- users_profit_loss.go: 当前资产快照查询改为 `status IN (1, 3)`
- users_profile.go: 库存统计查询改为 `status IN (1, 3)`
- 与 dashboard_user_spending.go 的计算口径对齐
|
2026-03-20 20:39:50 +08:00 |
|
|
|
535106f158
|
fix(coupon): 修复订单超时取消时金额券未退还的bug
问题:
commit b9a40df 修复了 CancelOrder()(用户/管理员主动取消)的券退回逻辑,
去掉了 `AND status = 4` 条件,但遗漏了 order_timeout.go 中超时取消的
同一逻辑,导致次数卡包(game_pass_package)订单超时取消时金额券余额丢失。
根因:
game_pass_package 下单时,金额券(type=1)通过 applyCouponToGamePassOrder()
直接扣减 balance_amount 并保持 status=1(有余额)或 status=2(用完),
不会设置 status=4(预扣中)。而 cancelExpiredOrder() 的 UPDATE 语句带有
`WHERE id = ? AND status = 4` 条件,导致匹配不到行,退券静默失败。
生产已确认影响:用户9110的券1690(订单28229)和券1532(订单26743)
因此bug各丢失10元余额。
修复:
- 去掉 `AND status = 4` 条件,改为 `WHERE id = ?`,兼容所有券状态
- 新增幂等校验:先查 timeout_refund 流水是否已存在,防止重复退还
- 新增兜底逻辑:order_coupons 无记录时,从 user_coupon_ledger 流水
回推预扣金额,与 CancelOrder() 的修复方案完全对齐
|
2026-03-20 20:32:30 +08:00 |
|
|
|
9cb4aaa511
|
fix(admin): 修复订单列表source_type=4/5显示未知的问题
- source_type=4: 区分购买次卡/次卡抽奖/一番赏
- source_type=5: 区分运费订单/直播间抽奖
|
2026-03-20 17:45:19 +08:00 |
|
win
|
a671fc14c6
|
运费
|
2026-03-20 00:57:17 +08:00 |
|
win
|
eaf4af4ba4
|
Merge remote-tracking branch 'origin/zuncle'
|
2026-03-19 22:37:56 +08:00 |
|
|
|
47c36b43cd
|
feat(fragment): add synthesis flow and fragment restrictions with tests
|
2026-03-19 16:26:36 +08:00 |
|
|
|
4ffd8e8326
|
fix: 修复过期优惠券仍可兑换/使用的漏洞
- store.go: 积分商城优惠券列表加 valid_end > now 过滤
- coupons_list.go: 修复 NULL valid_end 被错误排除,无截止日期券正确显示为有效
- activity_order_service.go: 过期/不可用券下单返回明确错误,不再静默跳过
- points_redeem_coupon_app.go: 积分兑换前校验模板 valid_end
- coupon_add.go: 发券前校验模板 valid_end,过期拒绝发放
|
2026-03-18 21:58:25 +08:00 |
|
|
|
9f7a7d29fb
|
fix(admin): 管理端取消订单改为调用 userSvc.CancelOrder,补充优惠券和积分退还逻辑
|
2026-03-18 21:12:46 +08:00 |
|
|
|
0722e515c4
|
feat(shipping): 新增管理端撤销发货功能
- 新增 AdminCancelShipping handler,支持批量撤销待发货记录(status=1→5)
- 事务内同步恢复 user_inventory.status=1 并清空 shipping_no
- 在 remark 记录操作人 adminID,保证审计可追溯
- 注册路由 POST /api/admin/shipping/orders/cancel
|
2026-03-18 20:11:37 +08:00 |
|
|
|
b9a40df5c5
|
fix(coupon): 修复订单取消时金额券未退还的bug
订单取消退券逻辑依赖 used_order_id 匹配,但金额券在下单时
不设置 used_order_id(仅在支付确认后设置),导致未支付订单
取消时 WHERE 条件匹配不到行,退券静默失败。
修复:去掉 used_order_id 条件,按券 ID 直接退还,增加幂等
校验和错误处理,兜底从流水回推预扣金额。
|
2026-03-17 21:15:33 +08:00 |
|
|
|
d1ee319f0e
|
feat(dashboard): 平台有效资产增加优惠券和次卡价值统计
- 新增优惠券总价值统计(关联system_coupons表)
- 新增次卡总价值统计(关联activities表price_draw)
- 使用Raw SQL执行复杂JOIN查询
|
2026-03-17 19:17:56 +08:00 |
|
win
|
8d8f660e34
|
Merge remote-tracking branch 'origin/zuncle'
|
2026-03-17 18:36:24 +08:00 |
|
|
|
c7cd3c21e5
|
feat(shipping): 发货订单超过48小时不允许撤销
- 在cancel_shipping.go中添加48小时限制检查
- 在shipping_groups.go中返回created_at字段供前端判断
- 超过48小时的订单撤销时提示'需要撤销发货请联系客服'
|
2026-03-17 18:11:00 +08:00 |
|
win
|
a450a92673
|
Merge origin/zuncle into main
|
2026-03-17 16:00:23 +08:00 |
|
win
|
c0267c7a33
|
feat(channel): GMV支付方式拆分(现金/优惠券/积分)
后端:
- GMVBreakdown 结构体拆分 total/cash/coupon/points 四个维度
- calcGMVByTotalAmount 返回值改为 GMVBreakdown,SELECT 增加 actual_amount/discount_amount/points_amount
- StatsOverview/StatsDailyItem 新增 cash_cents/coupon_cents/points_cents 字段
- 测试数据增加优惠券场景,新增拆分断言
前端:
- API 接口类型同步增加 3 个拆分字段
- 概览区新增支付构成行:现金/优惠券/积分 各带金额和占比
|
2026-03-16 23:33:48 +08:00 |
|
win
|
8d1eef2f7f
|
fix(channel): 修复渠道统计GMV重复计数和商城直购误计入
1. 排除商城直购(source_type=1):GMV和成本过滤条件从IN(1,2,3,4)改为IN(2,3,4)
2. 排除次卡免费使用订单(actual_amount=0):避免购买次卡和使用次卡双重计入GMV
- source_type=4 一番赏使用次卡:1578单 44032元重复
- source_type=3 对对碰使用次卡:422单 7042元重复
- 合计去除51074元虚增GMV(29.1%)
3. 成本过滤条件同步修正:source_type IN(2,3,4),total_amount>0
修正后:GMV从175600降至124527元,毛利率从37.4%回到真实的11.8%
|
2026-03-16 21:41:39 +08:00 |
|
|
|
fac825245b
|
fix: 修复赠送流程地址归属错误,强制登录后才能填写收货地址
接收者未登录时提交地址会错误保存到赠送者名下,现改为:
- API层:登录态从可选改为必选,未登录返回401
- Service层:始终用提交者ID作为地址归属人
|
2026-03-15 13:23:09 +08:00 |
|
win
|
98694b4e69
|
revert: 移除转赠资产禁止兑换积分的限制
经数据核实,转赠后兑换积分属于合法行为(资产转赠后归接收方所有)。
并发漏洞虽然产生了重复转赠/发货记录,但实际经济损失为 0 元:
- 18 个重复发货资产中,没有任何一个真正被两方都发了货
- 没有任何资产被重复兑换积分
保留前两个并发修复(SELECT FOR UPDATE + RowsAffected 检查),
回退第三个业务限制(禁止转赠资产兑换积分)。
|
2026-03-15 13:23:09 +08:00 |
|
win
|
9cf9f798bb
|
fix(security): 修复赠送资产薅积分三大漏洞
1. SELECT FOR UPDATE 锁定资产行,防止并发转赠竞态条件
2. 检查 RowsAffected 防止 GORM 静默失败导致空壳发货记录
3. 兑换积分时校验转赠来源,禁止转赠资产兑换积分
4. 转赠来源校验改用写库查询,避免主从延迟绕过
5. 转赠来源查询错误不再静默忽略,失败时返回错误
基于 zuncle 分支修复,额外修正了两个安全隐患:
- RedeemInventoryToPoints/RedeemInventoriesToPoints 中
转赠记录查询从 readDB 改为 writeDB
- Count()/Find() 返回的 error 不再丢弃
|
2026-03-15 13:23:09 +08:00 |
|
win
|
749464c03e
|
revert: 移除转赠资产禁止兑换积分的限制
经数据核实,转赠后兑换积分属于合法行为(资产转赠后归接收方所有)。
并发漏洞虽然产生了重复转赠/发货记录,但实际经济损失为 0 元:
- 18 个重复发货资产中,没有任何一个真正被两方都发了货
- 没有任何资产被重复兑换积分
保留前两个并发修复(SELECT FOR UPDATE + RowsAffected 检查),
回退第三个业务限制(禁止转赠资产兑换积分)。
|
2026-03-11 16:51:27 +08:00 |
|
win
|
8229b41382
|
fix(security): 修复赠送资产薅积分三大漏洞
1. SELECT FOR UPDATE 锁定资产行,防止并发转赠竞态条件
2. 检查 RowsAffected 防止 GORM 静默失败导致空壳发货记录
3. 兑换积分时校验转赠来源,禁止转赠资产兑换积分
4. 转赠来源校验改用写库查询,避免主从延迟绕过
5. 转赠来源查询错误不再静默忽略,失败时返回错误
基于 zuncle 分支修复,额外修正了两个安全隐患:
- RedeemInventoryToPoints/RedeemInventoriesToPoints 中
转赠记录查询从 readDB 改为 writeDB
- Count()/Find() 返回的 error 不再丢弃
|
2026-03-11 16:25:11 +08:00 |
|
|
|
bd91c0fad1
|
fix(transfer): 修复赠送资产并发漏洞及转赠积分薅取问题
- SubmitAddressShare 事务内 SELECT FOR UPDATE 锁定资产行,防止并发重复提交
- 检查 UPDATE RowsAffected,静默失败时回滚事务
- 防重检查从 readDB 移入事务内写库,消除主从延迟竞态
- RedeemInventoryToPoints/RedeemInventoriesToPoints 添加转赠来源校验,
禁止通过转赠获得的资产兑换积分
|
2026-03-11 14:14:34 +08:00 |
|
win
|
91dd42ca1c
|
feat(channel): 渠道统计新增盈亏计算并修复成本口径
后端:
- StatsOverview/StatsDailyItem 新增 cost/profit 字段
- 新增 calcPaidByPriceDraw 三路收入分类(抽奖/对对碰/一番赏)
- 新增 calcCostByInventory 成本计算(含道具卡倍数)
- 修复成本统计未过滤 source_type 导致直播间免费发奖资产被错误计入
- remark.go 新增 PkgID 解析支持一番赏订单
前端:
- 渠道统计弹窗新增"总成本"和"盈亏"卡片
- 趋势图新增"盈亏分析"Tab
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
2026-03-11 02:29:19 +08:00 |
|
|
|
d45096d13f
|
fix(refund): 修复退款后翻牌游戏资格未回收的问题
问题描述:
用户退单后,翻牌游戏资格会重新出现(被重置),但用户已经抽过奖了。
这导致用户可以通过退款获得额外的翻牌机会。
根本原因:
退款处理逻辑 reclaimLivestreamAssets 只回收了 user_inventory 中的实物奖品,
但没有回收 user_game_tickets 中的翻牌游戏资格。
解决方案:
在 reclaimLivestreamAssets 函数后添加 reclaimFlipCardTicket 函数,
用于检测并回收翻牌游戏资格:
1. 通过 shop_order_id 查询抖店订单获取商品ID
2. 查询 douyin_product_rewards 表检查商品是否配置了翻牌游戏奖励
- 检查 reward_type = 'game_ticket'
- 检查 payload.game_code = 'flip_card'
3. 如果配置了翻牌奖励,回收用户的翻牌次数
- 扣减 user_game_tickets.available
- 扣减 user_game_tickets.total_earned
4. 在 game_ticket_logs 表中记录回收日志
影响范围:
- 仅影响配置了翻牌游戏奖励的商品订单退款
- 退款时会同步回收翻牌游戏资格
- 已使用过的翻牌次数不会被回收(只回收 available > 0 的记录)
测试建议:
1. 购买配置了翻牌奖励的商品
2. 进行翻牌游戏
3. 申请退款
4. 验证翻牌资格是否被正确回收
|
2026-03-08 16:01:39 +08:00 |
|
|
|
2aa7cdbd61
|
fix(shipping): 使用资产价值快照价格确保发货与分解价格一致
修复改价后发货价格与分解价格不一致的问题:
- 发货时优先使用 user_inventory.value_cents 快照价格
- 后台发货列表使用 shipping_records.price 存储的快照价格
- 确保盈亏统计时价格数据准确一致
|
2026-03-05 17:54:58 +08:00 |
|
win
|
b3b63dcba2
|
admin
|
2026-03-05 12:50:06 +08:00 |
|
win
|
994a7ba0df
|
邀请关系
|
2026-02-27 17:51:38 +08:00 |
|
win
|
e0db8751f3
|
任务中心的问题
|
2026-02-27 16:07:12 +08:00 |
|
win
|
46a7253239
|
fix:订单同步
|
2026-02-27 00:08:02 +08:00 |
|
win
|
9972427cea
|
fix: treat livestream pass orders as ticket price
|
2026-02-24 10:02:11 +08:00 |
|
win
|
8b7af03400
|
feat(prize): freeze value snapshots across grant redeem refund and reports
|
2026-02-21 22:16:20 +08:00 |
|
win
|
70e45b09ab
|
feat(prize): add reward/inventory value snapshot schema
|
2026-02-21 22:16:10 +08:00 |
|
win
|
7e8a2ebb52
|
feat: Add user spending dashboard, update database schema, and refine various API endpoints and service logic.
|
2026-02-21 21:33:19 +08:00 |
|
|
|
ec035ffb53
|
任务大厅,限量显示
|
2026-02-19 19:55:25 +08:00 |
|
|
|
af1c16c7c5
|
优惠券bug
|
2026-02-18 23:23:34 +08:00 |
|
|
|
58baa11a98
|
fix:优惠券购买次卡bug
|
2026-02-10 01:17:15 +08:00 |
|
|
|
e124f8d4ff
|
优化钱
|
2026-02-08 17:19:27 +08:00 |
|
|
|
fbdaf77eda
|
x
|
2026-02-06 16:49:27 +08:00 |
|
|
|
029ed489bc
|
x
|
2026-02-06 15:18:16 +08:00 |
|
|
|
571cb2f4db
|
add: 仪表盘
|
2026-02-04 12:44:37 +08:00 |
|
|
|
9eea272d69
|
统计更新
|
2026-02-03 17:44:02 +08:00 |
|
|
|
25c44c2064
|
x
|
2026-02-02 23:56:01 +08:00 |
|
|
|
55e22086e8
|
201
|
2026-02-01 00:27:38 +08:00 |
|
|
|
1a8f94d7b8
|
fix
|
2026-01-29 19:25:16 +08:00 |
|
|
|
ff404e21f0
|
x
|
2026-01-28 21:38:44 +08:00 |
|
|
|
021ab34c75
|
add:opencode
|
2026-01-28 21:36:36 +08:00 |
|
|
|
6d33cc7fd0
|
fix:盈亏计算
|
2026-01-27 01:33:32 +08:00 |
|