- Shipped
- August 15, 2026 at 3:43 AM UTC
- Author
- Kamo
- Commit
- 03bb22a
LeadController is one of the better-gated controllers in the platform — VIEW_LEADS, EDIT_LEADS, ASSIGN_LEADS, REASSIGN_LEADS_MANUALLY, VIEW_UNASSIGNED_LEADS and both contact-info rights all checked. CREATE_LEADS and DELETE_LEADS were the two holes, and they now sit beside the rest in the same idiom. Two other authenticated paths create leads and needed the same gate, or the right would have been enforced on the lead form and bypassed by uploading a spreadsheet: **************** and **************** which materialises leads from payloads already received. Three lead-creating paths are deliberately left alone, because none has a member to check: the intake webhook itself, whose caller is the third party posting the lead; SocialLeadConsumer, a NATS consumer; and PublicWebinarService, anonymous registration. Gating those would be an outage, not security. The hasRight helper is copied into the two other controllers rather than shared, matching how getCachedOrganizationId and the other session helpers already live in this package. It keeps LeadController's contract exactly, god bypass included, so the surfaces cannot diverge on who may create a lead. No seeding. CREATE_LEADS tracks VIEW_LEADS exactly — 28 roles, 47 members, nobody holds the parent without it. DELETE_LEADS is granted to 33 members and 14 who can delete today will stop; it is differentially granted, which carries intent, and seeding it would overwrite that. **************** caught createLead becoming guarded and required its baseline line be removed — 371 entries to 370. That is the ratchet working. Verified in a clean origin/main worktree with only these files applied: 632 tests, 0 failures. The working tree's own suite reports 396 errors from a concurrent session's in-flight BranchTypeController and OrganizationController changes, which do not compile against the installed shared-lib and are unrelated to this.