Files
junhong_cmp_fiber/.scratch/tech-inapp-notifications/issues/04-dynamic-recipient-resolution.md
2026-07-22 16:14:59 +09:00

2.3 KiB
Raw Blame History

04 — 接入账号、角色与店铺动态接收人解析

What to build: Notification Worker 可以按业务场景把审批申请人、当前平台角色账号或目标店铺解析为一组稳定、去重且当前可用的后台账号接收人。店铺场景只包含当前启用的店铺主账号和当前仍可用的店铺业务员;账号停用、软删除或关系失效时跳过,上级代理不会因为可查看下级数据而自动收到通知。

Blocked by:

  • 01 — 向明确后台账号可靠投递首条站内通知
  • .scratch/ur96-shop-business-owner/issues/06-shop-business-owner-notification-recipient-release.md — 06 — 提供业务员通知接收人解析并完成发布验证

Status: ready-for-agent

架构通道: 主通道为 Infrastructure Adapter辅助通道为简单写 Application。

完整业务边界: 本票收口公共通知 Worker 对明确申请人、平台角色和店铺接收人的解析、可用性复核、去重及无接收人语义。明确不实现 UR#33、UR#97 或企微审批的业务触发规则,不改变账号、角色、店铺层级或业务员归属,不自动转派历史通知,也不发送短信或企微消息。

  • 明确申请人场景只使用业务事件携带的稳定系统账号 ID并在消费时跳过已停用或软删除账号不使用企微代提交身份替代真实业务提交人。
  • 角色场景批量解析当前启用、未删除且仍持有指定平台角色的账号,结果按稳定账号 ID 去重,不按用户名或手机号投递。
  • 店铺场景解析当前启用的店铺主账号,并复用 UR#96 接缝解析当前可用业务员;不沿父店铺、祖先店铺或代理数据权限向上扩散。
  • 同一账号同时以主账号、业务员或角色命中时只生成一条通知,同一事件的其他接收人仍分别拥有独立已读状态。
  • 暂无可用接收人记为 no_recipient 并成功结束,不进入无限重试;数据库等瞬时错误继续返回任务错误。
  • 已生成通知不会因账号关系后续变化而转移给新接收人,历史接收人仍可在自身认证上下文中读取原通知。
  • Application、Worker 和 PostgreSQL 集成测试覆盖申请人、角色批量解析、店铺主账号与业务员去重、停用、软删除、关系失效、无接收人及重复投递。