- Shipped
- September 23, 2026 at 10:03 AM UTC
- Author
- Kamo
- Commit
- d9c5480
EsignEnvelopeController's **************** checked org membership only — no document right, no clearance, nothing context-specific. Any authenticated staff member could list every envelope in the org (including EMPLOYMENT_OFFER, and the CLINICAL_CONSENT/ RECORDS_RELEASE_AUTHORIZATION context types reserved for a future EHR module), download the executed PDF and Certificate of Completion, and void or resend someone else's send. Applies the same rule SignatureRequestsController already applies to the collection's signature requests: VIEW_DOCUMENTS to see an envelope, EDIT_DOCUMENTS to void/resend it, both via MemberRightsAppliedService, plus the caller's session clearance as a ceiling on the underlying template's document-security level (COALESCE'd to PUBLIC, matching how every other clearance check in this service treats a missing level). On top of that, an EMPLOYMENT_OFFER envelope additionally needs one of VIEW_EMPLOYEES, EDIT_EMPLOYEES or MANAGE_HRS_SETTINGS — mirroring DocsService's LegalIssuedDocumentAccess, the guard on the same executed artifact reached the other way, through the generic imaging path. "May see this org's e-sign documents" and "may see this employee's offer letter" are different grants, and nothing on the envelope side asked the second question before. **************** are NOT given an equivalent EHR-side right here: grep across the fleet found no live creator for them (EMPLOYMENT_OFFER's is DocsService's LegalEsignClient; these three have none), and RoleRightType's own EHR section notes every clinical right is a SECOND gate behind a care-relationship check this service has no way to evaluate. They get the clearance ceiling like everything else. Whoever wires up their sender has to decide the right then — flagging this rather than guessing it. The internal API (EsignInternalController, APIService/DocsService server-to-server calls, already gated by its own shared secret — see the next commit) is UNCHANGED: its org-only list/get/... methods are kept as separate overloads the staff controller does not call, since that is a different, already-checked trust boundary. Pagination ("Paginate list if trivial" in the finding) was skipped: EnvelopeSummary[] is a plain array today and changing it to a paged shape would break the existing kamo-internal contract for a performance nicety, not a security fix. New tests: EsignEnvelopeControllerTest (VIEW/EDIT_DOCUMENTS gate) and EsignEnvelopeVisibilityTest (clearance ceiling, EMPLOYMENT_OFFER hidden without an HR right, list filters what is not visible). UndeliveredInviteReportingTest updated for the two new constructor dependencies.