Found during the 17.0 GA acceptance sweep on @objectstack/* 17.0.0-rc.2 (current main), permission matrix phase. CRM-side counterpart to the platform findings #703/#705 — these are places where the app's own declarations promise what the platform's actual gates cannot deliver, so either the declaration or the product intent needs to change.
1. marketing_user's crm_contact create grant is unfulfillable as authored
Declared: marketing_user has C on crm_contact (matrix CRU-). Actual: POST /api/v1/data/crm_contact under an account marketing cannot edit → 403 P5 "insert on 'crm_contact' requires edit access to its master record". Since marketing holds no account edit anywhere (and per #705 edit-shares don't work anyway), the create grant is dead on arrival — marketing can only create contacts under accounts it personally created, which for a marketing persona is none.
Resolution options: grant marketing account edit (posture change), relax the master-detail insert rule for this persona (platform ask), or drop the declared C and update the docs — maintainer's call.
2. "agent/mkt can edit contacts/leads" expectations are unimplementable under the actual write gate
The permission docs/matrix expect service_agent to PATCH contacts (update phone/email while on a case) and marketing_user to edit leads it works. Actual: 403 row-level in both cases — the platform write gate is owner_id == caller AND created_by == caller (plus RLS wideners only), and viewAllRecords never writes (#705). No CRM-side declaration can produce "edit records you don't own" today except an RLS update-widener per object — which is exactly how #547 solved it for campaigns/members.
If the product intent stands, each such persona-object pair needs its own RLS widener (as marketing_campaign_member_updates demonstrates works); if not, the docs and the matrix should stop promising it.
Why filed separately from #703/#705
Those track the platform gates being wrong/inert. This tracks the CRM repo's declarations and docs being out of contract with any current platform behavior — it stays actionable (author wideners or fix docs) even if the platform issues sit.
Evidence: acceptance run w4/results.jsonl (M7/M8). Refs #547 #703 #705
Found during the 17.0 GA acceptance sweep on
@objectstack/*17.0.0-rc.2 (currentmain), permission matrix phase. CRM-side counterpart to the platform findings #703/#705 — these are places where the app's own declarations promise what the platform's actual gates cannot deliver, so either the declaration or the product intent needs to change.1. marketing_user's
crm_contactcreate grant is unfulfillable as authoredDeclared: marketing_user has C on crm_contact (matrix
CRU-). Actual:POST /api/v1/data/crm_contactunder an account marketing cannot edit → 403 P5 "insert on 'crm_contact' requires edit access to its master record". Since marketing holds no account edit anywhere (and per #705 edit-shares don't work anyway), the create grant is dead on arrival — marketing can only create contacts under accounts it personally created, which for a marketing persona is none.Resolution options: grant marketing account edit (posture change), relax the master-detail insert rule for this persona (platform ask), or drop the declared C and update the docs — maintainer's call.
2. "agent/mkt can edit contacts/leads" expectations are unimplementable under the actual write gate
The permission docs/matrix expect service_agent to PATCH contacts (update phone/email while on a case) and marketing_user to edit leads it works. Actual: 403 row-level in both cases — the platform write gate is
owner_id == caller AND created_by == caller(plus RLS wideners only), and viewAllRecords never writes (#705). No CRM-side declaration can produce "edit records you don't own" today except an RLS update-widener per object — which is exactly how #547 solved it for campaigns/members.If the product intent stands, each such persona-object pair needs its own RLS widener (as
marketing_campaign_member_updatesdemonstrates works); if not, the docs and the matrix should stop promising it.Why filed separately from #703/#705
Those track the platform gates being wrong/inert. This tracks the CRM repo's declarations and docs being out of contract with any current platform behavior — it stays actionable (author wideners or fix docs) even if the platform issues sit.
Evidence: acceptance run
w4/results.jsonl(M7/M8). Refs #547 #703 #705