- Shipped
- 4 Agosti 2026, 04:17 UTC
- Author
- Kamo
- Commit
- 1594aca
The platform's only field mask was **************** applied by LeadController.getLeadById to a caller who is neither god nor the assignee and lacks VIEW_LEAD_CONTACT_INFO_OTHERS (161). It covers e-mail, phones, date of birth and the street parts of the mailing/property addresses — and nothing else. customFormData rode straight through it, which is the one place on the platform a healthcare tenant will actually put intake and symptom questions. LeadFieldMask now owns the decision and the projection: - any org: custom-form answers ride with the contact mask. If you may not see the lead's e-mail you may not see what it answered. - handlesPhi tenants: answers are withheld from anyone the lead is not assigned to even WITH right 161. That right is scoped, by its own name, to contact information; a symptom answer is not contact information. The form title goes too — "Diabetes Intake Questionnaire" discloses the condition on its own. The form entry survives masking carrying only its id, so the UI can say "restricted" rather than draw a blank questionnaire. An org that will not load is treated as PHI-handling, matching PhiTenantStatus's UNKNOWN-denies posture. PUT /leads/{id} gains the symmetric write gate. The form editor PUTs the whole fieldValues map, so without it a member shown a blank questionnaire who pressed Save would have replaced the real answers with {} — the read mask would have become a silent delete. Static utility, no stereotype and no repository: the decision is pure and the caller already holds the org.