You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3.8 KiB
3.8 KiB
作废/过期线索的统计口径能否突破「列表可见范围」
Type: grilling Status: resolved Blocked by:
Question
现有硬约束是「统计口径 = 列表口径」——countStats 与 pageLeads 复用同一套 applyViewFilters。但新需求要 我的线索 / 我的关注 统计「线索作废(7)」，而 CONTEXT 明确：作废时清空 owner_user_id。于是：
MY_LEAD视图过滤 =owner_user_id = 当前用户→ 作废线索没有 owner，列表里根本看不到，按现有口径统计恒为 0。- 过期失效(6) 保留领取人，无此问题。
需要决策：
- 我的线索 的「线索作废」到底数什么？
- (a) 现有列表口径，恒 0（等于不做，需求作废）；
- (b) 用「历史归属」维度——曾被我领取过、现已作废的线索（需要一个不同于 owner 的归属来源，如 lead_history 或某冗余字段）；
- (c) 改作废语义，作废时保留 owner（与 CONTEXT 决策冲突，需评估回收/激活流程影响）。
- 一旦某张卡片的口径突破了列表可见范围，「统计口径 = 列表口径」这条硬约束是否整体放弃？还是仅对作废这一张卡片开特例？
- 我的关注 视图（
id IN lead_follow）不看 owner，作废线索若还在关注表里就可见——它的作废口径与 我的线索 是否一致？
这是全图的根决策，DTO 字段形态、每视图口径表、前端契约都等它。
Answer
结论（在路线上 resolve，非踢出 scope）：作废态改为「保留 owner_user_id」；名额与可转商机目录不受影响。用户选 (i)——把这个状态机小改纳入本图，目的地随之扩容。
核实到的事实（代码 + CONTEXT + PRD 三方一致的现状）：
LeadTransitionImpl#applyFeedback（line 211）：反馈=无效自动作废时清空owner_user_id（置 null）；原持有人只留在lead_historyVOID 记录 detail。释放（86）/ 超时回收（268）也清 owner，但那是「退回公海」场景，非作废。- 作废态可被管理员重新分配给新销售（边 #15，作废自环，写入新 owner）。
- PRD §3.4（2026-08-13 定稿）+ 边 #14 + grill G1 明文：「作废清 owner」。
用户诉求经逐层澄清（第 2/4/5 问）收敛为一个精准的语义解耦，而非「重构归属语义」：
- 作废后线索归属仍属当前销售（不清 owner）→ 销售能在「我的线索」看到、回看自己作废的线索；
- 作废线索不占持有上限名额。
关键核实（推翻了「牵动四条链路」的初判）：
- 持有上限
hold_limit（ClaimLimitChecker）：COUNT WHERE owner=? AND pool=? AND status IN (3,4)—— 只数已领取/跟进中，靠 status 排除作废，不靠 owner=null。→ 作废保留 owner 不会占名额。✅ - 每日领取上限：按
claim_time，与 owner 空否无关。✅ - 可转商机目录（
ConvertibleLeadCatalogPort）：owner=? AND status IN (3,4)，同样按 status 卡，作废自动排除。✅ - 结论：清 owner 对「名额/可转商机」是多余的（它们本就用 status 精确排除作废）；清 owner 唯一真正的副作用就是让作废线索从「我的线索」消失 —— 而那正是不想要的。
决定（用户选 i）：作废分支保留 owner_user_id，在本图内做掉。目的地扩为「作废保留 owner 的状态机小改 + stats 改版 spec」。
残留待核实（graduate 为新 ticket 04）：作废保留 owner 后，(a) 回收 N / 激活恢复读 owner 是否出错；(b) @DataScope 是否因作废 owner=me 改变别的视图权限判定；(c) 边 #15「作废自环换 owner」逻辑是否仍自洽；(d) PRD §3.4 / CONTEXT 需改「进入时清空 owner」那句。