Use HMIS Project Policy for enrollment detail visibility checks

[gigxz]

Merging this PR

• use the squash-merge strategy for PRs targeting main
• use a merge-commit or rebase strategy for PRs targeting staging and production

Description

Related Issues (Does not close):

• https://github.com/open-path/Green-River/issues/9442
• https://github.com/open-path/Green-River/issues/9005

Adds project/client policy methods for enrollment-detail visibility, and migrates GraphQL callers (and warehouse “Open in HMIS” links) off raw permission helpers so permission dependencies apply consistently.

• Add can_view_enrollment_details? / can_edit_enrollments? on project policy
• Add can_view_some_enrollment_details? on client policy
• Resolve selected Project/Client access fields and auth gates via policies
• Add shared scope Project#with_enrollment_detail_visibility_for(user), to remove repeated usage of with_access(user, :can_view_enrollment_details, :can_view_project, mode: :all) across enrollment and household visibility scopes
• Update warehouse HMIS URL resolution to use policy checks rather than raw permission checks

Why now:

• Resolving https://github.com/open-path/Green-River/issues/9442 will include adding can_view_clients as a required permission for enrollment visibility. Enrollment visibility permission checks are sprinkled throughout the codebase; this PR consolidates so we can make the change in fewer places.

Type of change

Code clean-up

Checklist before requesting review

• I performed a self-review of my code
• I ran the OP review skill
• I ran the code that is being changed under ideal conditions, and it doesn't fail
• If adding a new endpoint / exposing data in a new way, I have:
  • ensured the API can't leak data from other data sources
  • ensured this does not introduce N+1s
  • ensured permissions and visibility checks are performed in the right places
• Any major architectural changes are supported by an approved ADR (Architectural Decision Record)
• I updated the documentation (or not applicable)
• I added spec tests (or not applicable)
• I provided testing instructions in this PR or the related issue (or not applicable)

[gigxz]

This is already baked in from permission requirements, just updating the comment to reflect that

[martha]

Looks good to me! Thanks for the cleanup 🙏

[martha]

We could instead gate on hmis_entity.respond_to?(:enrollment) and then we would check permissions on a broader range of enrollment-related records, instead of just Hmis::Hud::CustomAssessment, Hmis::Hud::CustomService.

I don't know the full context of when this is called, so maybe this is irrelevant.

[gigxz]

Hmm good question. It feels like an unsafe pattern to check authorization on a record where we don't know explicitly what it is, that would be my hesitation. I'll leave it as-is for now which has parity with the old behavior

[martha]

Note from AI review:

[warning] app/models/grda_warehouse/data_source.rb:824 — This is a larger behavior change than the description implies. The old known_permissions map required :can_view_projects (plural) for Hmis::Hud::Enrollment and Hmis::Hud::CustomAssessment. can_view_projects is a warehouse Role permission, not an Hmis::Role permission, and Hmis::User is not a subclass of ::User — so Hmis::User#permission_for? hit its respond_to? guard and returned false. With mode: :all, that made the check unconditionally false, meaning the "Open in HMIS" link was always suppressed for enrollments and assessments. The new code will start rendering those links wherever hmis_external_link is used. That is almost certainly the desired outcome, but it should be called out in the PR description and confirmed with someone who knows the intended warehouse UX, since it is a user-visible change rather than a refactor.

This surprised me, but I think it does seem to be true. I checked by viewing an enrollment in my local warehouse that I do have permission to see in HMIS (https://hmis-warehouse.dev.test/source_data/xxxx?type=Enrollment). On main I don't see a link to HMIS, but on your branch, I do.

[gigxz]

Yes this looks like a bug in the old code that is now fixed. "can_view_projects" on lines 825-826 are a typo, it should be "can_view_project" like on line 822. These were always checking HMIS permissions (line 822 hmis_user.permissions_for?(hmis_entity, *perms, mode: :all)) it was just incorrectly returning false because of the typos.

[martha]

Maybe, add a project_access_field_spec.rb mirroring client_access_field_spec.rb. It looks like the underlying policy methods themselves are well tested though, so I think this is optional.