Appoint should not show in MyVA as a draft, after the experience is complete #102448

oddball-lindsay · 2025-02-04T18:30:18Z

Background

When a user completes the Appoint a Rep experience, the form still shows as "in progress" in MyVA. And clicking on the link directs the user to restart the Appoint experience.

Steps to Reproduce

Visit the Appoint experience in Staging
Login with an LOA3 test user
Go halfway through the Appoint experience - stop at the Authorizations chapter
Go to MyVA and see the Appoint experience "in progress"
Click on the Appoint experience "in progress" - it will drop you back into the Authorizations chapter
Continue on through the rest of the experience, until you're on the Next Steps page
Go back to MyVA and see the Appoint experience "in progress"
Click on the Appoint experience "in progress" - it will drop you to the start of the Appoint experience on the claimant-type screen.

Acceptance Criteria

When a user completes the Appoint experience (MVP or v2), the "in progress" in MyVA no longer should appear.

holdenhinkle · 2025-02-04T22:07:26Z

I spent a couple of hours reading the platform docs and vets-api/vets-website code and haven't really gotten anywhere with this yet.

InProgressForm Model - app/models/in_progress_form.rb

Main thing:

Looking at the InProgressForm Model - app/models/in_progress_form.rb

There's a status field in in_progress_forms that takes an integer that represents an enum for pending or processing:

enum :status, %w[pending processing], prefix: :submission, default: :pending

I'm trying to see how that's updated.

There's also a metadata field that takes json that seems to track if a form has been submitted:

  scope :has_attempted_submit, lambda {
                                 where("(metadata -> 'submission' ->> 'hasAttemptedSubmit')::boolean or " \
                                       "(metadata -> 'submission' ->> 'has_attempted_submit')::boolean")
                               }
  scope :has_errors,           -> { where("(metadata -> 'submission' -> 'errors') IS NOT NULL") }
  scope :has_no_errors,        -> { where.not("(metadata -> 'submission' -> 'errors') IS NOT NULL") }
  scope :has_error_message,    lambda {
                                 where("(metadata -> 'submission' -> 'errorMessage')::text !='false' or " \
                                       "(metadata -> 'submission' -> 'error_message')::text !='false' ")

I'm also trying to see how that's updated.

I found this in vets-website:

src/applications/appeals/995/tests/fixtures/mocks/in-progress-forms.json

{
  "data": {
    "id": "1234",
    "type": "in_progress_forms",
    "attributes": {
      "formId": "20-0995",
      "createdAt": "2023-01-11T21:46:40.395Z",
      "updatedAt": "2023-01-11T21:46:40.417Z",
      "metadata": {
        "version": 1,
        "returnUrl": "/review-and-submit",
        "savedAt": 1673473600090,
        "submission": {
          "status": false,
          "errorMessage": false,
          "id": false,
          "timestamp": false,
          "hasAttemptedSubmit": false
        },
        "expiresAt": 9999999999,
        "lastUpdated": 1673473600,
        "inProgressFormId": 1234
      }
    }
  }
}

To be continued...

holdenhinkle · 2025-02-06T18:02:34Z

So we have to update the metadata on a successful submission.

Some forms delete the SiP form on a successful action in a transaction.

Example:

File: app/controllers/v1/supplemental_claims_controller.rb

    def process_submission
      req_body_obj = request_body_hash.is_a?(String) ? JSON.parse(request_body_hash) : request_body_hash
      saved_claim_request_body = req_body_obj.to_json # serialize before request body is modified
      form4142 = req_body_obj.delete('form4142')
      sc_evidence = req_body_obj.delete('additionalDocuments')
      zip_from_frontend = req_body_obj.dig('data', 'attributes', 'veteran', 'address', 'zipCode5')

      sc_response = decision_review_service.create_supplemental_claim(request_body: req_body_obj, user: @current_user)
      submitted_appeal_uuid = sc_response.body.dig('data', 'id')

      ActiveRecord::Base.transaction do
        appeal_submission_id = create_appeal_submission(submitted_appeal_uuid, zip_from_frontend)
        handle_saved_claim(form: saved_claim_request_body, guid: submitted_appeal_uuid, form4142:)

        ::Rails.logger.info(post_create_log_msg(appeal_submission_id:, submitted_appeal_uuid:))
        handle_4142(request_body: req_body_obj, form4142:, appeal_submission_id:, submitted_appeal_uuid:)
        submit_evidence(sc_evidence, appeal_submission_id, submitted_appeal_uuid) if sc_evidence.present?

        # Only destroy InProgressForm after evidence upload step
        # so that we still have references if a fatal error occurs before this step
        clear_in_progress_form
      end
      render json: sc_response.body, status: sc_response.status
    end

    def clear_in_progress_form
      InProgressForm.form_for_user('20-0995', @current_user)&.destroy!
    end

holdenhinkle · 2025-02-06T22:18:24Z

PR - department-of-veterans-affairs/vets-api#20670

I haven't run my code yet. I'll run it tomorrow, refactor if necessary, then write tests.

holdenhinkle · 2025-02-08T03:08:17Z

I finally got test users working locally so I can test my code. Here are the docs - https://github.com/department-of-veterans-affairs/va.gov-team/blob/d4640bb7398e8b7de94dac54af4273ff27475c46/products/identity/Products/Mocked%20Authentication/readme.md#common-issues-and-solutions

Login URL
http://localhost:3001/sign-in/mocked-auth

holdenhinkle · 2025-02-10T14:23:31Z

Form is in progress locally:

When the form errors, the in progress form record's metadata is updated:

vets-api(dev)> form = InProgressForm.all.first
2025-02-10 09:20:03.202408 D [51021:11660 log_subscriber.rb:164] ActiveRecord::Base --   InProgressForm Load (0.4ms)  SELECT "in_progress_forms".* FROM "in_progress_forms" ORDER BY "in_progress_forms"."id" ASC LIMIT $1  [["LIMIT", 1]]
=> #<InProgressForm id: 1, user_uuid: FILTERED, form_id: FILTERED, created_at: FILTERED, updated_at: FILT...
vets-api(dev)> form.metadata
=> 
{"saved_at"=>1739197087171,
 "submission"=>
  {"status"=>"clientError",
   "error_message"=>"[object Object]",
   "id"=>false,
   "timestamp"=>1739197087169,
   "has_attempted_submit"=>true},
 "createdAt"=>1739196646,
 "expiresAt"=>1744381089,
 "lastUpdated"=>1739197089,
 "inProgressFormId"=>1}
vets-api(dev)>

holdenhinkle · 2025-02-11T21:53:05Z

Lots of notes to add, but I just discovered this on the in_progress_forms tables:

    t.string "user_uuid", null: false
    t.string "form_id", null: false
    t.index ["form_id", "user_uuid"], name: "index_in_progress_forms_on_form_id_and_user_uuid", unique: true

I got everything to working (removed the in-progress/expired form message from the Appoint tool and from the My VA page) but then discovered I couldn't submit another form:

{
    "errors": "PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint \"index_in_progress_forms_on_form_id_and_user_uuid\"\nDETAIL:  Key (form_id, user_uuid)=(SUBMITTED_2122, 88f572d491af46efa393cba6c351e252) already exists.\n"
}

We have to delete the save in progress record which makes all the work I've done pointless. We need to save a copy of the record in another table.

Note: deleting the record will of course prevent the in-progress form from being displayed after submission like it is now.

oddball-lindsay · 2025-02-11T22:15:46Z

Ah! That's a disappointing development given all of your progress, but still an important discovery especially before we open up digital submission. Thanks for documenting everything here @holdenhinkle 👍

oddball-lindsay added the accredited-representation-management-team Accredited Representation Management team label Feb 4, 2025

oddball-lindsay assigned holdenhinkle Feb 4, 2025

oddball-lindsay added the bug Something isn't working label Feb 4, 2025

holdenhinkle linked a pull request Feb 6, 2025 that will close this issue

Update in_progress_form metadata in #create department-of-veterans-affairs/vets-api#20670

Draft

9 tasks

oddball-lindsay mentioned this issue Feb 8, 2025

Confirmation page (new version for digital submission) #99976

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Appoint should not show in MyVA as a draft, after the experience is complete #102448

Appoint should not show in MyVA as a draft, after the experience is complete #102448

oddball-lindsay commented Feb 4, 2025 •

edited

Loading

holdenhinkle commented Feb 4, 2025

holdenhinkle commented Feb 6, 2025

holdenhinkle commented Feb 6, 2025

holdenhinkle commented Feb 8, 2025 •

edited

Loading

holdenhinkle commented Feb 10, 2025

holdenhinkle commented Feb 11, 2025 •

edited

Loading

oddball-lindsay commented Feb 11, 2025

Appoint should not show in MyVA as a draft, after the experience is complete #102448

Appoint should not show in MyVA as a draft, after the experience is complete #102448

Comments

oddball-lindsay commented Feb 4, 2025 • edited Loading

Background

Steps to Reproduce

Acceptance Criteria

holdenhinkle commented Feb 4, 2025

holdenhinkle commented Feb 6, 2025

holdenhinkle commented Feb 6, 2025

holdenhinkle commented Feb 8, 2025 • edited Loading

holdenhinkle commented Feb 10, 2025

holdenhinkle commented Feb 11, 2025 • edited Loading

oddball-lindsay commented Feb 11, 2025

oddball-lindsay commented Feb 4, 2025 •

edited

Loading

holdenhinkle commented Feb 8, 2025 •

edited

Loading

holdenhinkle commented Feb 11, 2025 •

edited

Loading