API-25814: Update api_version to "V0" for Segmented Appeals APIs

[kristen-brown]

Summary

This PR updates the Segmented Appeals APIs to save an api_version of "V0" rather than "V2" on HigherLevelReviews, NoticeOfDisagreements, and SupplementalClaims records created from those APIs, since the API versions for the Segmented APIs are all V0.

Related issue(s)

API-25814

Testing done

I updated the controller specs to test for the correct api_version and tested the V0 and V2 create endpoints locally.

Screenshots

None

What areas of the site does it impact?

This PR impacts all Appeals API Segmented (V0) API create endpoints. The V2 Decision Reviews HLR/SC/NOD create endpoints were also updated, but the changes there were refactors only.

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 – N/A
• Documentation has been updated (link to documentation) – N/A
• 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) – N/A
• 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 – N/A

Requested Feedback

Would like an extra set of eyes on the change to modules/appeals_api/app/models/concerns/appeals_api/hlr_status.rb, since that code didn't look like it was working correctly before.

[kristen-brown]

Could I get an extra set of eyes on this? Before this change, api_version.downcase would never have matched "V2," so the V1 statuses would have been returned every time. If you look at the bottom of this file, the status field is validated based on the results of this method, so I want to be sure that we have it right. Will also add some specs for this once we clarify the desired behavior.

[caseywilliams]

What you've said here sounds right to me, too - it seems like it would be nice to settle on consistently using upcase or downcase for all v* strings we work with and convert them all at some point if possible (but not as part of this ticket/PR)

[kristen-brown]

Agreed! I went back and forth on upcase vs. downcase a few times since we use both.

I investigated the supported statuses a bit more and am comfortable with this change now. Before this change, we were technically allowing the "uploaded", "received", and "expired" statuses for V2 and V0 HLRs, even though those statuses are not supported in V2 or V0 according to our documentation. To be extra sure, I also confirmed in Production that we don't have any V2 or V0 HLR records that are in those statuses.

Supported HLR Statuses – Before:
V1 HLR: ["pending", "submitting", "submitted", "processing", "error", "uploaded", "received", "success", "expired", "complete"]
V2 HLR: ["pending", "submitting", "submitted", "processing", "error", "uploaded", "received", "success", "expired", "complete"]
V0 HLR: ["pending", "submitting", "submitted", "processing", "error", "uploaded", "received", "success", "expired", "complete"]

Supported HLR Statuses – After:
V1 HLR: ["pending", "submitting", "submitted", "processing", "error", "uploaded", "received", "success", "expired", "complete"]
V2 HLR: ["pending", "submitting", "submitted", "processing", "success", "complete", "error"]
V0 HLR: ["pending", "submitting", "submitted", "processing", "success", "complete", "error"]

Also, I just added some specs to test that the correct supported HLR statuses are returned for each API version.

[kristen-brown]

I anticipate that we'll be making more changes to reporting in order to report V2 and V0 appeals separately, but for now, I'm including V0 appeals in all existing reporting.

[github-actions]

1 Warning

⚠️

This PR changes 213 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/appeals_api/app/controllers/appeals_api/higher_level_reviews/v0/higher_level_reviews_controller.rb (+2/-0) modules/appeals_api/app/controllers/appeals_api/notice_of_disagreements/v0/notice_of_disagreements_controller.rb (+3/-1) modules/appeals_api/app/controllers/appeals_api/supplemental_claims/v0/supplemental_claims_controller.rb (+2/-0) modules/appeals_api/app/controllers/appeals_api/v2/decision_reviews/higher_level_reviews_controller.rb (+6/-4) modules/appeals_api/app/controllers/appeals_api/v2/decision_reviews/notice_of_disagreements_controller.rb (+6/-5) modules/appeals_api/app/controllers/appeals_api/v2/decision_reviews/supplemental_claims_controller.rb (+6/-4) modules/appeals_api/app/mailers/appeals_api/weekly_error_report_mailer.rb (+2/-2) modules/appeals_api/app/models/appeals_api/higher_level_review.rb (+6/-9) modules/appeals_api/app/models/appeals_api/notice_of_disagreement.rb (+5/-5) modules/appeals_api/app/models/appeals_api/supplemental_claim.rb (+4/-1) modules/appeals_api/app/models/concerns/appeals_api/hlr_status.rb (+5/-2) modules/appeals_api/app/workers/appeals_api/higher_level_review_upload_status_batch.rb (+1/-1) modules/appeals_api/lib/appeals_api/decision_review_report.rb (+2/-2) modules/appeals_api/spec/factories/higher_level_reviews.rb (+15/-0) modules/appeals_api/spec/factories/notice_of_disagreements.rb (+15/-0) modules/appeals_api/spec/factories/supplemental_claims.rb (+15/-0) modules/appeals_api/spec/models/concerns/appeals_api/hlr_status_spec.rb (+5/-0) modules/appeals_api/spec/models/higher_level_review_spec.rb (+20/-0) modules/appeals_api/spec/models/supplemental_claim_spec.rb (+1/-1) modules/appeals_api/spec/requests/higher_level_reviews/v0/higher_level_reviews_controller_spec.rb (+12/-0) modules/appeals_api/spec/requests/notice_of_disagreements/v0/notice_of_disagreements_controller_spec.rb (+15/-3) modules/appeals_api/spec/requests/supplemental_claims/v0/supplemental_claims_controller_spec.rb (+12/-0) modules/appeals_api/spec/requests/v2/higher_level_reviews_controller_spec.rb (+1/-0) modules/appeals_api/spec/requests/v2/notice_of_disagreements_controller_spec.rb (+1/-0) modules/appeals_api/spec/requests/v2/supplemental_claims_controller_spec.rb (+1/-0) modules/appeals_api/spec/workers/higher_level_review_upload_status_batch_spec.rb (+10/-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/ Big PRs are difficult to review, often become stale, and cause delays.

Generated by 🚫 Danger