Prefill with VAProfile Contact Information V2 instead of the PCIU

[RachalCassity]

Note: Delete the description statements, complete each step. None are optional, but can be justified as to why they cannot be completed as written. Provide known gaps to testing that may raise the risk of merging to production.

Summary

Contact Information API V2 will be used to prefill data that previously used PCIU. VAProfile phone number methods were created to account for all the different number styles needed. Logs were added to FormProfile.initialize_contact_information to help determine if there is any data dispensary between PCIU and CI. We will be able to see if the data is obtained from the CI service before removing requests for pciu data.

    opt[:email] ||= extract_pciu_data(:pciu_email)
    if opt[:home_phone].nil?
      opt[:home_phone] = pciu_primary_phone
      opt[:us_phone] = pciu_us_phone
    end

Spec Modifications:

Contact Information V2 data is used throughout Vets-API. Contact Info V2 user data will not be cached when skip_va_profile_user is present and was added to the necessary spec files.

When possible, allow(Flipper).to receive(:enabled?) replaced Flipper.disable to prevent flakey tests in the future.

Monitoring

A temporary VAProfile Contact Information Unknown Data monitor was setup in Datadog to track missing data from the Contact Information API. Logs only checking the precense of data, no PII in logs.

      Rails.logger.info("VAProfile Contact Info: Address? #{opt[:address].present?},
        Email? #{opt[:email].present?}, Phone? #{opt[:home_phone].present?}")

Internal local testing was attempted. Did not receive any errors in the console or logs.

Related issue(s)

• PCIU Replacement Step 4b: Replace PCIU calls va.gov-team#98901
• Link to previous change of the code/bug (if applicable)
• Link to epic if not included in ticket

Testing done

• New code is covered by unit tests
• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing
• If this work is behind a flipper:
  • Tests need to be written for both the flipper on and flipper off scenarios. Docs.
  • What is the testing plan for rolling out the feature?

Screenshots

Note: Optional

What areas of the site does it impact?

This impacts Form Profile and forms that use PCIU for prefilled data.

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 (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

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[RachalCassity]

Ensure symbols are converted to string before running camelize.

[RachalCassity]

va_profile_phone and va_profile_mobile_phone are used for ContactInformation V2

[RachalCassity]

No longer used.

[tpharrison]

Can some of this be extracted to reduce duplication? Something like...

module ContactInformationVersioning
  extend ActiveSupport::Concern

  # Determine whether to use the new VAProfile V2 system
  def use_v2_service?(user)
    Flipper.enabled?(:remove_pciu, user)
  end

  # Retrieve the user's contact information
  def contact_information_from(user)
    if use_v2_service?(user)
      VAProfileRedis::V2::ContactInformation.for_user(user)
    else
      VAProfileRedis::ContactInformation.for_user(user)
    end
  end

  # Retrieve mailing address based on conditions
  def mailing_address_from(user)
    redis_prefill = contact_information_from(user)
    use_v2_service = use_v2_service?(user)
    # Only assign mailing address if the feature flag is enabled or the user has a vet360_id
    redis_prefill&.mailing_address if use_v2_service || user.vet360_id.present?
  end
end

Just a suggestion.

[RachalCassity]

I would agree to split this out if there were not steps after this to remove all the Contact Info V1 references. I believe the new version will be replaced soon after being pushed to prod. This would require more files to be removed when we remove PCIU and Contact Information in the later steps of the PCIU migration epic. Both Contact Information V1 and PCIU need to removed after this integration has been tested.

[tpharrison]

I was thinking along the same lines and thought having a module/concern in place could make future upgrades more convenient. But, you're probably right - keeping it as-is for now should simplify clean up.

[tpharrison]

🚀 LGTM

[RachalCassity]

@bosawt These lines are the only changes to the user model. The previous code, quetionable code, was removed. :)