 lzf_0626
|
615032ab00
|
fix: 修 POST /api/v1/conversations 的 MissingGreenlet（会话建不出来导致转人工 404）
- public_platform_service: 创建 ConversationSession 时显式赋值四个 server_default 时间列，
否则 flush() 后需回读数据库生成值，在 async session 里以同步属性访问触发
MissingGreenlet，接口 500，连带转人工一直报会话不存在
- portal: 客服改用 C001 真实建会话；转人工改传 reason_code/reason_detail（原 reason 属额外字段 422）
- portal: 投顾查客户投资目标走 customers/{id} 变体
- seed/grant: 补 investment-goal:{read,write,confirm}:customer 三个动态拼出的权限码
（data_scope=own_customers，投顾只看名下客户）
|
2026-09-12 15:37:36 +08:00 |
|
|
lzf_0626
|
bfd622b592
|
feat: 统一登录门户（按角色分流五套工作台）+ 补齐权限覆盖缺口
- tools/portal.py：客户/风控/运营/管理员/投顾五个工作台，走真实登录与真实接口
- 新增 6 个此前从未建过的权限码（promotion:* 4 个 / financial:nl2sql:read / probe:read），
它们让推广材料与金融 NL2SQL 两条线对所有角色都是 403
- 投顾权限 10 → 25 项：补投资目标创建确认、agent:run、行情、知识检索、客户画像、推广材料
- 运营补 financial:nl2sql:read；create_test_user.py 不再硬编码角色 id（改按 role_code 查库）
- portal 的写请求补 Idempotency-Key 头（漏了会被 AGENT_INPUT_INVALID 拒）
- 新增 tools/check_permission_coverage.py 做权限对账
|
2026-09-12 15:21:34 +08:00 |
|
|
lzf_0626
|
cdb2de3e45
|
chore: 权限号段根治——9041-9046 并进种子；修正 grant 脚本与种子 9020-9034 的 id 映射冲突
|
2026-09-12 12:09:55 +08:00 |
|
|
lzf_0626
|
5018f11843
|
增加投顾（advisor）角色；修正登录测试的错误假设；修投顾带入的 2 处文档重号
## 投顾角色
投顾线合并后，bootstrap.py 有 10 处 allowed_roles 引用 advisor，
financial_nl2sql_service.py:272 还硬编码检查 {"advisor","operator","admin","super_admin"}，
promotion_material_service.py:164 按 "advisor" in context.roles 走业务分支 ——
但 sys_role 里没有这个角色、sys_permission 里也没有投顾那 16 个权限码（种子只建到 9019）。
表现是所有投顾接口 403，而报错看起来像"权限配错了"，实际是角色根本不存在。
- tools/grant_advisor_role.py：建 advisor 角色（id=9004，避开种子的 9001-9003 重建范围）
+ 16 个投顾权限（id 9020-9035）+ 授权（advisor 拿 10 项工作流、admin 补齐 16 项）。
只增不删、可重复执行、带 --dry-run。
- tools/create_test_user.py：ROLE_IDS 加 advisor。
- 先跑 alembic upgrade head：补 21 张 advisor_* 表，业务表 68 → 89，审计通过。
权限划分：投顾工作流 10 项（read:self / generate:self / review / publish）给 advisor；
治理类 6 项（product-governance:*、profile-governance:*、asset-allocation:backtest）只给 admin。
review/publish 也给 advisor，与既有决策一致（此前已裁定不做双人复核）。
验证：advisor_t 登录 200，roles=['advisor'] data_scope=all 权限 10 项；
用它查 RBAC 清单得 403（没有 audit:read），边界正确。
⚠️ 与种子的冲突：seed_test_rbac.py 是 DELETE 重建语义，其
DELETE FROM sys_permission WHERE id BETWEEN 9001 AND 9099 会清掉本脚本建的权限。
要把投顾权限固化，应并进 seed_test_rbac.py 的 PERMISSIONS 常量。
## 修正登录测试的一个错误假设
test_issued_token_actually_works_on_a_real_endpoint 原本用客户的
/users/me/memory-profile 验证令牌可用，投顾合并后它返回 403。追下去发现**与令牌无关**：
那个接口对客户有业务前置"请先完成开户风险测评问卷"，而演示客户 9001 没有测评记录。
是我的测试选错了验证端点，把"业务前置未满足"误判成"令牌坏了"。
- 改用管理员令牌调 /api/v1/admin/roles（需要 audit:read，走完整鉴权链路），
并补一条反向对照：不带令牌必须 401，否则那个 200 说明不了令牌有效。
- 把那个业务前置单独写成一个用例，让后来者一眼看到条件，而不是反复怀疑令牌。
过程里我先按控制台乱码猜了两次失败原因，都不对；最后把响应抓成 UTF-8 文件才看到真实
消息。教训记下：不要读乱码猜消息。
## 修投顾带入的 2 处文档重号
21-投顾Agent迁移TODO.md → 30-…、22-投顾Agent灰度与回滚操作手册.md → 31-…
（沿用 NL 那次让号的先例：既有文档更早、引用更多；且这两份新文档没有被任何地方引用。）
文档守卫：40 份无编号冲突。
验证：ruff 干净 / mypy 228 文件 0 错 / 文档守卫 40 份无冲突 /
unit+contract 1207 passed（0 failed）/ integration 99 passed / 业务表 89 张。
|
2026-09-11 21:49:46 +08:00 |
|