Nobody holds any position on a fresh install, so every position-based sharing rule and both approval flows resolve to an empty recipient set

[os-zhuang]

Found while fixing #638 (seeding billing addresses so the territory rules match records); filed unassigned per Prime Directive #10, and deliberately not fixed there — it needs demo-user/member design, not seed data.

What happens

#621 made the two territory rules install. #638 gave them accounts to match. The third layer is still empty: no user holds any position, so a matching account still materialises no share.

Measured on a fresh install (pnpm dev, empty .objectstack/data, 17.0.0-rc.1), reading the SQLite file directly:

sys_position          18 rows   (all 12 declared positions exist, incl. na_sales_team / eu_sales_team)
sys_sharing_rule       9 rows   (all declared rules seeded — seeded: 9, skipped: 0)
crm_account            9 rows   (6 match north_america_territory, 2 match europe_territory, 1 neither)
sys_user_position      0 rows   ← nobody holds anything
sys_member             1 row    (the dev admin, role "owner")
sys_record_share       0 rows   ← so nothing is granted to anyone

So the chain is: rules installed ✅ → criteria match real records ✅ → recipients staffed ❌ → grants 0.

Why it matters

This is the last layer of the same declared-vs-delivered gap as #621 / #638, and it is wider than territories:

• Seven other positions are equally unstaffed (sales_manager, sales_director, executive, service_manager, service_director, marketing_manager, marketing_director), so every position-based sharing rule this app ships grants nobody anything on a fresh install.

• pnpm lint already warns about the same hole on the approval side, at four nodes:

  approval-approvers-may-resolve-empty — flow "opportunity_approval" · node "manager_review": every approver on this node routes to a group (position/team/department) whose members are runtime data — if none is staffed, the request resolves to an empty slate and waits forever, and (lockRecord) the record stays locked with no in-product recovery.

  So an evaluator who submits a deal for approval on a fresh demo locks the record with nobody able to act on it.

Why it is not a one-liner in demo_bootstrap

The obvious patch — have the bootstrap sweep put the first user into na_sales_team and eu_sales_team — is a fix in appearance only:

1. On a fresh install there is exactly one user, and demo_bootstrap has already claimed every seeded record for them (owner + platform owner_id, Seeded contracts are ownerless at the platform level (owner_id null) — nobody, admin included, can edit one #622). A share to that same user widens nothing: the OWD baseline already admits the record's owner, and an admin bypasses sharing anyway. sys_record_share would gain rows nobody can observe the effect of.
2. Demonstrating territory sharing requires a user who does not own the accounts — i.e. at least one non-admin NA rep and one non-admin EU rep, which means creating demo users, deciding who holds which of the twelve positions, and reckoning with the fact that the same decision drives the other seven positions, the four approval nodes and lead_assignment's sales_rep pool (lead.hook.ts already documents its empty-pool fallback).

That is a design decision about the demo org's people, not a seed record, which is why #638 stops at the data.

What is needed

Roughly, and for a maintainer to confirm before anyone builds it:

1. Whether the demo org should ship synthetic users at all (e.g. na.rep@objectos.ai, eu.rep@objectos.ai, a sales manager, a service agent), given that seeds cannot name a user — creation would have to happen in demo_bootstrap or an equivalent first-boot path, the same constraint that forced that flow to exist (see the note at the foot of src/data/index.ts).
2. Which positions each demo user holds, so the sharing rules and the approval routes both become demonstrable.
3. Whether staffing should be dev/demo-only (a real deployment staffs its own people, and shipping fake users into a customer org would be worse than shipping none).

Related: #621 (the rules), #638 (the data they match), #488 (a position no rule and no permission set names grants nothing), #622 (demo_bootstrap and the two ownership columns).

[os-zhuang]

认领:PM 循环第 9 轮
会话:session_019SS7C5SXpniKeCApxgARyf
分支:claude/issue-640-demo-org-staffing
Worktree:hotcrm-issue-640

---

needs-user-decision 已摘掉,按否决窗口推进。 该问的两轮前问过、没收到反对,而且下面这个约束把最要紧的那一半风险直接消掉了,剩下的不再是产品语义分歧:

决定(可否决):

1. 发合成用户,但只发到 dev/demo 路径,真实部署一个都不装。 这正是 issue 第 3 条自己点出的顾虑——"把假用户塞进客户 org 比不塞更糟"——而它同时也是解法:只要装配只发生在 demo 引导路径上、真实部署走不到,这条顾虑就不成立,问题也就从产品决策降级成实现细节。这一点是硬约束,不是偏好:任何让合成用户可能出现在客户 org 的实现方式都要打回。
2. 三个非管理员用户:一个 NA rep(持 na_sales_team)、一个 EU rep(持 eu_sales_team)、一个销售经理(持 sales_manager)。为什么恰好是这三个:前两个让领地共享第一次可被观察(必须是不拥有这些客户的人,否则 OWD 基线本来就放行、什么都证明不了——issue 里已经算过这笔账);第三个让 opportunity_approval 的 manager_review 节点第一次解析出非空审批人,pnpm lint 那条 approval-approvers-may-resolve-empty 才有东西可指。
3. 另外七个职位这轮不配人。 配人的目的是让机制可被观察,不是把组织架构填满;sales_director / executive 等留空是如实反映"真实部署自己配人"这一事实。但要留下可观察的痕迹:装配逻辑必须是数据驱动的表,加一个人是加一行,不是再写一段代码。

验收要能看见三层都通了,而不只是 sys_user_position 有了行:

• sys_record_share 在 fresh install 后非零,且授予的对象是不拥有该客户的那个 rep;
• 拿 NA rep 的身份查 crm_account,能看到 6 条 NA 的、看不到 2 条 EU 的——No seeded account carries a billing_address, so both territory sharing rules match zero records on the demo dataset #638 特意留了 1 条两边都不属于的记录,它必须两个 rep 都看不到(这条是防"匹配全部"回归的探针,不要动它);
• 提一个高额商机走审批,manager_review 解析出的审批人非空(今天是空名单 + lockRecord,记录会被锁死且产品内无法恢复)。

**文件边界(本轮三件并行,严格分工):**你拥有 src/flows/demo-bootstrap.flow.ts、职位/成员装配所需的新增 seed、src/permissions/。不要动 src/data/sales.seed.ts 的商机行(#593 本轮拥有它)、不要动 src/objects/account.object.ts / account.hook.ts / src/flows/lead-conversion.flow.ts(#626 本轮拥有)、不要动 i18n 语言包(本轮归 #593 独占)。若装配确实需要调整记录归属,在引导流程里做,不要改 seed。

已知会踩的坑,先说:demo_bootstrap 现在把所有 seed 记录都认领给第一个用户(owner + owner_id,见 #622),它的清扫过滤器对每个对象跑两遍(缺 owner 一遍、缺 owner_id 一遍)。多用户之后"第一个用户"这个概念要重新定义清楚,但归属模型本身是 #548 的范围,不要在这里顺手改 ——本件只负责"人存在且持有职位",不负责重新分配所有权。

---

Generated by Claude Code