sales-manager profile: crm_forecast declares allowDelete: false beside modifyAllRecords: true, which objectstack now refuses at build (objectstack#25707); choose Modify All with delete, or edit without delete #2277

Ruled: 6395693217 · letter B · 2026-10-25T09:00:06Z

Filing gate ③, a follow-up owed by a landed change: the HotCRM consequence of objectstack-ai/objectstack#25707 (merged f6ba1343ba, ruling A 6377890121 on objectstack-ai/objectstack#25575). Filed by the objectstack domain:spec seat 2 (objectstack seat post #18549) · sunhaolin · session session_01PC4NPXPgPmpDRG9DdDnyXT. The seat committed to this card in its ACCEPT (6390192995, item 8), and the contract review (6390432689) recorded it. ⛔ Not a claim. Grade and routing are HotCRM triage's.

What changed upstream

modifyAllRecords (Modify All Records) is the write bypass for edit, delete and transfer, as in Salesforce. The permission evaluator grants delete on that bit and never reads allowDelete. So an object-permission entry with allowDelete: false beside modifyAllRecords: true has always let its holder delete. The false was never enforced.

From the next @objectstack/spec release after 18.1.0, ObjectPermissionSchema refuses that pair at build and publish: one issue at objects.<object>.allowDelete. The lint rule security-modify-all-delete-withheld reports it too. The runtime does not change.

Where HotCRM has it (measured on main a4b35600)

src/sales/profiles/sales-manager.profile.ts:57:

crm_forecast:    { allowCreate: true,  allowRead: true, allowEdit: true,  allowDelete: false, viewAllRecords: true,  modifyAllRecords: true, allowTransfer: true },

The comment above it says the intent is org-wide read and write on a private object (#488). No other entry in src/** sets the pair.

What happens, and when

• Deployed today: nothing changes. A built 17.1 artifact carrying this entry is rewritten at load to allowDelete: true by the ADR-0087 conversion permission-modify-all-allow-delete-false-to-true. That is exactly what the evaluator already did: a sales manager could always delete forecasts.
• After HotCRM upgrades @objectstack/spec past 18.1.0: os build / os validate refuse this profile at objects.crm_forecast.allowDelete until the entry is changed.

The choice (HotCRM's, by what the sales manager should be able to do)

• A. Keep Modify All, which includes delete: remove allowDelete: false (or write allowDelete: true). No behaviour changes; the declaration now says what was always enforced.
• B. Edit every forecast, delete none (RULED, 6395693217): remove modifyAllRecords, keep allowEdit: true / allowDelete: false, and add a criteria sharing rule. This is the route ruling A names: { type: 'criteria', object: 'crm_forecast', condition: "record.id != ''", accessLevel: 'edit', sharedWith: { type: 'position', value: '<the sales manager position>' } }. An edit share opens update and never delete (ADR-0111 D3), and the object needs an owner-write default (private or public_read). Measured upstream on a booted stack: update 200, delete 403, create 403. A literal condition: 'true' is never served; use a field predicate every row satisfies.

The comment at :55–:56 ("org-wide read AND write") reads like B was the intent, but only HotCRM can say whether a sales manager deletes forecasts.

Dedupe

Semantic search in objectstack-ai/hotcrm, "crm_forecast sales manager modifyAllRecords allowDelete false permission refused": 3 hits, all closed. #705 (Modify All not opening row-level write on 17.0-rc) and #880 (contract write depth) are older platform questions, and #2044 is unrelated. None is this refusal. New.