- Shipped
- September 2, 2026 at 8:42 PM UTC
- Author
- Kamo
- Commit
- 10e0129
Two tables and two rights. SALES_SCRIPTS hangs off a lead market the way a LeadVendor does; SALES_SCRIPT_BLOCKS holds the parts, each one a Lexical document plus the flattened text the previews and reading-time estimate read. Blocks are rows rather than a JSON array on the script because a block's id is what a member's read-progress is keyed on. As an array, position would be the only identity available, so an author inserting a paragraph near the top would silently shift everyone's place in the script. With stable ids the wording can be rewritten and the blocks reordered while every agent mid-call keeps the ticks they already made — which is why **************** preserves the id of any block the payload still names, and why the test for it is the first one in the file. Saving is a FULL REPLACE: blocks carrying an id update in place, blocks without one are created, and blocks the payload omits are DELETED. Stated on the DTO and covered by a test, because a caller assuming otherwise loses data with nothing to show for it — the same contract, and the same trap, as backgrounds/commit. Omitting `blocks` entirely is the separate, safe case that lets a rename leave them alone. VIEW_SALES_SCRIPTS (300) is a root: reading the pitch is not implied by any other right, least of all VIEW_LEADS, since the trainee who learns the script before being handed a lead is exactly who the grant is for. MANAGE (301) hangs off it so authoring cannot be granted without the ability to read what is being authored, and revoking the read takes the write with it. Both name ServiceType.CRM, which is what puts them in the CRM security group — permissionGroupTree derives groups from serviceType, so no group edit is needed and a right in no group could not be granted at all.