- Ya
- 6 Agosti 2026, 21:15 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 7d1170e
isPerPartyRestrictedAssoc covers only ACCOUNT_MEMBER_VAULT and LOAN, so assoc 1 — SERVICE_APPLICATION, what /settings/member/{id}?tab=docs renders — has no per-subject check at all: any member with VIEW_DOCUMENTS at SEC >= 2 could read a colleague's executed employment documents by id, or list them by assocObjectId. Two readers now, and only two: the subject, and a holder of an HR right. A colleague cleared to CONFIDENTIAL is still refused — clearance is not ownership, and conflating them IS the bug. The guard is NARROW on purpose. It covers the artifacts this feature files, identified by executedImgId. A blanket per-subject rule on assoc 1 would break the lead Files tab, which renders DocManager at assoc 1 with a LEAD id in the same unique_rowid() space as a member id and indistinguishable from one; every salesperson would lose every lead's files. The general fix is a dedicated HR assoc type with its own gate, which is a shared-library enum change — reported, not built here. Wired at every door: download, stream, metadata (description IS the package title), converted-pdf, thumbnail, list (silently omitted, matching the access-level skip, because 403ing a page would break HR's view of a member's tab) and bulk-download (excluded, matching the per-party exclusion). The lookup is a DocsService-LOCAL repository over the shared entity so no shared artifact is rebuilt, and it is gated behind a free assoc check so every other collection pays nothing for it.