Skip to content

No seeded account carries a billing_address, so both territory sharing rules match zero records on the demo dataset #638

Description

@os-zhuang

Found while fixing #621 (making the two territory sharing rules translatable so they are actually seeded); filed unassigned per Prime Directive #10. Not fixed in #637 — the fix would land in src/data/index.ts, which is claimed by #613 this round.

What happens

#621 / PR #637 fixed the installation half: north_america_territory and europe_territory now seed (seeded: 9, skipped: 0, total: 9) with a real, pushdown-able filter:

"criteria_json": "{\"billing_country\":{\"$in\":[\"UK\",\"DE\",\"FR\",\"IT\",\"ES\"]}}"

But the data half is still empty. Grepping the whole repo, billing_address appears only in object definitions, views, translations, the lead-conversion flow and the sharing rules — never in src/data/index.ts. None of the nine seeded accounts (Acme Corporation, Globex Industries, Initech Solutions, Stark Medical, Wayne Enterprises, Northwind Energy, Vertex Analytics, Lattice Education, Apex Logistics) sets one:

{
  name: 'Globex Industries',
  type: 'prospect',
  industry: 'manufacturing',
  annual_revenue: 12000000,
  number_of_employees: 800,
  phone: '+1-312-555-0200',      // <- a US phone number, and nothing else geographic
  website: 'https://globex.example.com',
  tier: 'enterprise',
  segment: 'net_new',
  last_activity_date: cel`daysAgo(8)`,
},

So on a fresh install both territories evaluate correctly and match 0 accounts. The capability is now real but invisible — a demo or an evaluator clicking through Setup sees two territory rules, two positions, and nothing behind them.

Why it matters

This is the second layer of the same declared-vs-delivered gap #621 was filed for. #621 closed the loud half (the rules are installed); this is the quiet half (the data they filter on does not exist). It also makes the fix un-demoable: there is no way to show territory sharing working without hand-creating an account first.

Note the account phone numbers already imply geography (+1-312, +44-style patterns are absent), so the seed set is currently all-US-by-implication with nothing in the EU territory at all.

Repro

rm -rf .objectstack/data
pnpm exec objectstack dev --fresh -p 38617 --seed-admin
# then, authenticated:
curl -s -b cookies.txt 'http://localhost:38617/api/v1/data/crm_account' \
  | python3 -c "import sys,json;[print(r['name'], r.get('billing_country')) for r in json.load(sys.stdin)['records']]"
# every row prints: <name> None

Suggested fix

Give the seeded accounts a billing_address with a country code, spread across both territories and outside them, so the rules demonstrably partition the set — e.g. Acme/Globex/Initech/Wayne/Vertex/Apex in US, Stark Medical in CA, Northwind Energy in DE, Lattice Education in UK. Two things to check while doing it:

  1. Do hooks run on seed writes? billing_country is a projection maintained by account_protection on beforeInsert/beforeUpdate, so seeded rows only get it if seed writes fire hooks. Seed doctrine says hooks never run over seed rows — they do, and the whole seed file is authored on that premise #617 records that src/data/index.ts's stated "seeds don't fire hooks" premise contradicts the boot log — worth settling here, because if hooks do not fire on seeds, the seed rows need billing_country set explicitly alongside billing_address (and that duplication should be a deliberate, commented decision, not an accident).
  2. Staffing. sys_member on a fresh install holds only the admin, and no position is staffed, so even a matching account materialises no row in sys_record_share. Territory sharing is only end-to-end demoable once some demo user actually holds na_sales_team / eu_sales_team. That may deserve its own issue.

Related: #621 (the rules themselves), #613 (owns src/data/index.ts this round), #617 (whether seeds fire hooks), #549 (sharing coverage on related lists).

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingmetadataDeclarative metadata — schema, security posture, UI surfacespm:dispatchedDispatched to a dev agent by /pm-dispatchpm:queueReady for the PM dispatch loopprio:p1Next in line once P0s clear

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions