Arf.78633/arp mock data

[gabezurita]

See frontend PR: department-of-veterans-affairs/vets-website#29034

Summary

• This work is behind a feature toggle (flipper): YES

Description

While we do not yet have a GET /veteran-service-organizations/power-of-attorney-requests LH Claims API endpoint, we should consider building some mock data that we can use to support further development and staging demos.

Prerequisites/Dependencies

• The LH Team has to confirm the return value of GET /veteran-service-organizations/power-of-attorney-requests. See this issue for more details.
• Take a best guess at the structure of the above endpoint, and mock that data in the ARP engine.
  • Note: this Canvas has a hypothetical response that should serve as a fairly solid guide on what data will be returned by the LH Claims API

Related issue(s)

https://app.zenhub.com/workspaces/accredited-representative-facing-team-65453a97a9cc36069a2ad1d6/issues/gh/department-of-veterans-affairs/va.gov-team/78633

Loosely based on @nihil2501's Dash PR and ongoing LH work

Testing done

• New code is covered by unit tests

What areas of the site does it impact?

The ARP Engine

Acceptance criteria

• The power_of_attorney_requests ARP Engine PowerOfAttorneyRequestsController#index returns mock POA requests.

[github-actions]

1 Warning

⚠️

This PR changes 271 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/accredited_representative_portal/app/controllers/accredited_representative_portal/services/fetch_poa_requests.rb (+50/-0) modules/accredited_representative_portal/app/controllers/accredited_representative_portal/v0/power_of_attorney_requests_controller.rb (+66/-6) modules/accredited_representative_portal/config/routes.rb (+1/-1) modules/accredited_representative_portal/spec/requests/accredited_representative_portal/v0/power_of_attorney_requests_controller_spec.rb (+47/-5) modules/accredited_representative_portal/spec/support/poa_record_generator.rb (+95/-0) 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

[cohnjesse]

This looks great! Small question and some praise, loaded this up locally and looks good there too! Great work👌

[cohnjesse]

Praise - Nice!

[cohnjesse]

Praise - Love these comments, makes figuring out future work much easier!

[cohnjesse]

Should we add this to permitted_params?

[nihil2501]

Refresher on strong params: https://guides.rubyonrails.org/action_controller_overview.html#strong-parameters
I think the framework protects the developer to notice a bunch of cases that there are multiple parameters that haven't explicitly been permitted, but explicitly using a single key is not such a case which makes sense.

Here's one of the cases where it automatically helps you. Getting a slice returns a new Parameter object that is still permitted: false:

irb(main):001* params = ActionController::Parameters.new({
irb(main):002*   person: {
irb(main):003*     name: "Francesco",
irb(main):004*     age:  22,
irb(main):005*     role: "admin"
irb(main):006*   }
irb(main):007> })
=> #<ActionController::Parameters {"person"=>{"name"=>"Francesco", "age"=>22, "role"=>"admin"}} permitted: false>
irb(main):008> params[:person]
=> #<ActionController::Parameters {"name"=>"Francesco", "age"=>22, "role"=>"admin"} permitted: false>
irb(main):009> params[:person].slice(:name)
=> #<ActionController::Parameters {"name"=>"Francesco"} permitted: false>

[nihil2501]

LGTM