AI260626/group_fqcd_jr
13
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
375 Commits 12 Branches 0 Tags
42a330c4c92f93599f8566d18ef5bed1ae6b740b
Commit Graph
5 Commits
Author SHA1 Message Date
lzf_0626 5da2fb5790 投顾代客三项的权限码缺失：整片 403（与 9057-9059 同一个坑的第二批） 
## 现象

投顾工作台（`advisor_t`，9020）一选客户就整片失败，页面只显示
「请求失败，请检查权限或稍后重试」。API 访问日志给出真相：

```
POST /api/v1/advisor/recommendations     403
POST /api/v1/advisor/asset-allocation    403
POST /api/v1/advisor/portfolio-analysis  403
GET  /api/v1/advisor/recommendations/published  200   ← 只有它不需要代客权限
```

## 根因：三个 `*:customer` 权限码在库里根本不存在

三个服务在"代客"（`customer_id != context.user_id`）时要求的是**动态拼出来的
`:customer` 变体**：

- `product_recommendation_service.py:71` → `product-recommendation:generate:customer`
- `asset_allocation_service.py:57`       → `asset-allocation:generate:customer`
- `portfolio_analysis_service.py:46`     → `portfolio-analysis:read:customer`

而 `sys_permission` 里 `:customer` 后缀**只有 4 个**（`memory:read:customer`、
`investment-goal:{read,write,confirm}:customer`）—— 这三个从来没登记过。
`AuthorizationService.require()` 第一步就查不到该码 ⇒ 直接 403。

这与种子里 **9057-9059 的注释是同一个坑**（"动态拼出来的权限码，对账工具抓不到字面量，
于是投顾查/建/确认客户目标全部 403"），前人修了 investment-goal 那三个，这三个漏了。

## 修法（按仓库纪律：种子定义权限码 → grant 脚本绑定角色）

1. `tools/seed_test_rbac.py`：新增 **9066-9068** 三个码，`data_scope=own_customers`
   （`require_customer_scope` 只放行 `all`，或 `own_customers` 且客户确在
   `context.customer_ids` = 归属客户内 —— 这正是投顾该有的最小权限），
   并写明三处调用点，避免后人再漏；
2. `tools/grant_advisor_role.py`：把三个码加入 `ADVISOR_GRANTED_CODES`
   （admin 因 `ADMIN_PERMISSIONS = 全部种子权限` 自动获得）。

已执行：`seed_test_rbac.py` → `grant_advisor_role.py`
（advisor 新增 3 项，共 31 项；admin 62 项）。

## 验证（真实 HTTP，9020 身份）

| 客户 | 推荐方案 | 资产配置 | 组合分析 |
|---|---|---|---|
| 9101（演示客户） | 200 `profile_required` | 200 `profile_required` | 200 `no_positions` |
| **9001（真实客户）** | **200 已生成方案**（content_id=5, pending_review） | **200 ready**（含配置比例） | **200 ready**（7 个持仓，市值 10698.60） |

**403 全部消失**；对真实客户三项均返回真实结果。

## 同时补的归属数据

`sys_customer_assignment` 原有 9020→9001 一行；工作台把演示客户的 id
（9101-9104）当真实 `customer_id` 发给后端，而 `own_customers` 要求客户在投顾名下，
因此用 `tools/assign_customer_scope.py` 补了 4 行（9020 → 9101/9102/9103/9104），
回验 `customer_ids = ('9001','9101','9102','9103','9104')`。

## 仍未解决（属**数据**缺口，不是权限）

1. **9101-9104 在库里没有任何数据**：`advisor-config.js:126` 注释指向的
   `_seed_demo_customers.py` 在仓库、git 历史与桌面上**都不存在**（从未提交），
   所以这四位没有账号 / 风险测评 / 投资目标 / 持仓 —— 只能返回 `profile_required`。
2. **推荐候选恒为 0**：`AdvisorProductRepository.authoritative_tradable_products`
   要求**已验证**的适当性证据与合同快照（`review_status='verified'` 且
   `source_url` / `document_sha256` 非空，fail closed），而
   `advisor_product_suitability_reference` / `advisor_product_contract_snapshot`
   均为 0 行。这需要产品治理线提供可核查证据，**不应伪造**。

## 门禁

`tools/check_rbac_seed_consistency.py` 通过（种子内 id 唯一、各 grant 脚本与种子逐条一致）；
`pytest tests/unit tests/contract` 全绿。
 2026-09-14 22:56:42 +08:00
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