added threadId prop to ReplyForm from MessageReply

[KyleCardwell]

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.

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
• Yes, I'm removing, renaming or moving a folder

Summary

• fixes a bug where trying to move a message from one folder to another while editing a draft would cause an error.

Related issue(s)

MHV-61588 - User unable to move conversation when a reply draft is started

User unable to move conversation when a reply draft is started

GIVEN A user navigates to a thread
AND Clicks reply button and "Continue to reply" on interstitial page
AND A reply draft message textbox appears
AND Regardless whether a draft is started, saved or not saved
WHEN A user clicks Move button, proceeds with a folder selection and confirms moving a thread
THEN An error banner is displayed "We’re sorry. We couldn’t load this page. Try again later."
AND User is unable to move a thread

API request does not receive a proper thread ID in a request. Example:
https://staging-api.va.gov/my_health/v1/messaging/threads/undefined/move?folder_id=3888068

Feature Flag Y/N ?

DataDog Analytics Y/N ?

Manual Testing Y/N ? Y-Rakesh

Automated Testing Y/N Y-Fazil

Accessibility Testing Y/N Y-Bobby

UCD Validation Y/N N

Acceptance Criteria:

AC1 User is able to move the thread in the above scenario

Testing done

• no new tests added

Screenshots

Note: This field is mandatory for UI changes (non-component work should NOT have screenshots).

	Before	After
Mobile
Desktop

What areas of the site does it impact?

(Describe what parts of the site are impacted if code touched other areas)

Acceptance criteria

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors.
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

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?

[oleksii-morgun]

👍🏻

[vsaleem]

😀