Add new endpoint to vaos and mobile module for VPG appointment slots

[devin-mccurdy]

Summary

• This work is behind a feature toggle (flipper): YES - va_online_scheduling_enable_OH_slots_search
• Added a new endpoint to the vaos and mobile modules to get available appointment slots facility slots from the new VA Mobile VPG endpoint, which handles both VISTA and Oracle Health facilities.
• A new endpoint was needed in order to remove the clinic_id from the path because it is a field that doesn't exist for Oracle Health facilities. For the new endpoint, either the clinic_id(for a Vista facility) or the clinical_service (for an Oracle Health facility) fields are required.
• Team: Unified Appointment Experience team

Related issue(s)

• Search for open appt slots at OH facility va.gov-team#76083

Testing done

• New code is covered by unit tests
• The available appointment slots from VISTA facilities are returned from the VAOS endpoint.
• Using the current vets-api slots endpoint, slots are returned correctly for facilities. Future vets-website changes will be required to make use of the new endpoint in order to also retrieve available slots for Oracle Health facilities

What areas of the site does it impact?

This affects the vaos and mobile apps. When the feature flag is ON, flags are returned from the va-mobile / MAP vaos endpoint instead of the vaos endpoint, but the slot data structures and source systems are the same for Vista facilities and all existing functionality is supported.

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

[github-actions]

1 Warning

⚠️

This PR changes 367 LoC (not counting whitespace/newlines). In order to ensure each PR receives the proper attention it deserves, we recommend not exceeding 200. Expect some delays getting reviews. File Summary Files modules/mobile/app/controllers/mobile/v0/clinics_controller.rb (+25/-0) modules/mobile/config/routes.rb (+1/-0) modules/mobile/spec/request/clinics_request_spec.rb (+165/-2) modules/vaos/app/controllers/vaos/v2/slots_controller.rb (+22/-0) modules/vaos/app/services/vaos/v2/appointments_service.rb (+2/-2) modules/vaos/app/services/vaos/v2/systems_service.rb (+30/-7) modules/vaos/config/routes.rb (+1/-0) modules/vaos/spec/request/v2/available_slots_request_spec.rb (+94/-0) modules/vaos/spec/services/v2/systems_service_spec.rb (+14/-2) Note: We exclude files matching the following when considering PR size: *.csv, *.json, *.tsv, *.txt, Gemfile.lock, app/swagger, modules/mobile/docs, spec/fixtures/, spec/support/vcr_cassettes/, modules/mobile/spec/support/vcr_cassettes/, db/seeds, modules/vaos/app/docs, modules/meb_api/app/docs, modules/appeals_api/app/swagger/, *.bru Big PRs are difficult to review, often become stale, and cause delays.

Generated by 🚫 Danger

[drewconnelly]

LGTM

[LindseySaari]

for readbility, unless params[:clinic_id] || params[:clinical_service] to me makes it clearer that you're checking for the absence of both parameters

[devin-mccurdy]

Rubocop didn't like an unless with an else, and went with if params[:clinic_id] || params[:clinical_service]. Is that readable enough?

[drewconnelly]

Approved.

[cferris32]

LGTM for the VAOS module

[devin-mccurdy]

@jperk51 could I get a mobile code owner to review this? Thanks!

[jperk51]

LGTM