|
|
8e0bbdbbd1
|
fix: sqlor占位符语法错——角色IN子句用字面量非参数占位致永远匹配不到角色
部署实测抓到: 工单TK0002状态human_pending且assignee_role=owner.maintainer,
但provider用owner.maintainer角色查待办返回0条。
根因: 动态IN子句拼接时 ph 生成的是字面量 'r0' 而非 sqlor 的参数占位格式,
渲染出的SQL是 assignee_role IN ('r0') 恒不匹配任何真实角色值,
params里设置的 r0=owner.maintainer 从未被SQL引用。
两处同款错:
- todos.py 角色池待办条件(human_pending且assignee_role在我的角色)
- core.py list_staff_tickets 的 pending 队列条件
修法: 占位符改为 sqlor 的标准参数格式(dollar-brace-key-brace-dollar)。
渲染SQL现为 assignee_role IN (参数占位) 正确绑定。
教训: sqlor 动态 IN 子句拼接, 占位符必须用标准参数格式,
裸引号包键名会变成SQL字面量常量, 静默匹配0行不报错——极难排查。
|
2026-09-10 17:07:17 +08:00 |
|
|
|
54f2f2d597
|
feat: 工单管理模块初版——客户提问→agent预处理→人工运维→转派，接入平台待办
- 3表: tk_tickets(状态机+受理角色/人+agent锁)/tk_messages(客户可见/内部备注)/tk_transfers(append-only流水)
- core.py: 8态13迁移状态机全乐观锁; 转派候选动态查owner角色+'0'机构用户(不硬编码);
默认受理角色params可配(ticket_default_role=owner.maintainer)
- agent.py: 异步poller(bid_flow范式), RAG检索'0'机构KB+历史工单, llm_call(org_id=0)
LLM裁决能否回答(严格JSON), 硬门禁reply<20字符转人工, 故障≠答不了(fail_rounds>=3转人工),
stale回收10min; 追问回流(agent_processing+owner空)立即拾取不等stale
- todos.py: 平台待办provider, 状态派生(客户待确认/角色池待认领/受理人待处理)
- init.py: load_ticket注册env+provider+poller(PIPELINE_MODE=web不启动)
- wwwroot: 客户我的工单页+建单表单, 运维工单管理页(队列切换), 详情弹窗(正文与操作同屏,按视角出按钮)
- load_path.py: logined全部API(业务权限服务端按current_role动态校验)+管理页壳owner三角色
- init/data.json: 7组码表+owner.maintainer角色种子(app_audit先例)
|
2026-09-10 16:17:58 +08:00 |
|
