The Correspondence Review Package allows MailTeam and MailTeam Supervisor users to view and edit a correspondence.

The user can navigate to this Review Package page from the Correspondence Cases Queue. After clicking on a case from the Correspondence Queue, the ReviewPackageLoadingScreen will render first in order to fetch data and store it in the Correspondence Redux store.

The Correspondence Review Package page is comprised of six sections:

1. ReviewPackageNotificationBanner
2. ReviewPackageCaseTitle
3. ReviewPackageData
4. ReviewForm
5. CmpDocuments
6. Footer

Correspondence Review Package utilizes the ReviewPackageLoadingScreen.jsx to fetch data through GET /queue/correspondence/correspondence_uuid. Information being stored in Redux relates to application state variables that are widely used by all correspondence components, and includes veteran information, correspondence metadata, correspondence documents, and the package document type.

The CorrespondenceReviewPackage.jsx is the root layout component. Additional data fetching occurs here for data specific to Correspondence Review Package. A majority of the logic regarding routing, state management, and handler functions are defined here and passed as props to their respective sections.

When the user is part of the MailTeamSupervisor organization and there is a pending removal request active on a correspondence, the buttons of the Correspondence Review Package will be disabled to prevent further edits.

The ReviewPackageCaseTitle.jsx consists of generic text prompting the user to review the general information, the RemovePackageModal, and a SearchableDropdown component.

The SearchableDropdown is a controlled component containing four different options: Split Package, Merge Package, Remove package, and Reassign Package. When an option is selected, the handlePackageActionModal function is invoked to update packageActionModal in CorrespondenceReviewPackage.jsx.

Depending on the value of packageActionModal, the PackageActionModal.jsx will dynamically render certain form fields. As different actions have different input fields, the RadioFields, TextAreas, and submit buttons are wrapped in conditional statements to suit each actions needs.

The submit button for each form invokes the submitHandler function. This functions handles the submission logic for all available actions. Upon submission, a request is made to POST /queue/correspondence/${correspondence.uuid}/task, and a new ReviewPackageTask is created and assigned to the MailTeamSupervisor organization. After the task is created successfully, the user will be redirected to the Correspondence Cases Queue page.

The RemovePackageModal.jsx is a different modal that replaces the PackageActionModal when there is a pending Remove Package request. After a reason for removal has been submitted, the suer can now click on the submit button, sending a request to POST /queue/correspondence/correspondence_id/remove_package. If successful, the redux store will be updated in order for the success banner to load on the Correspondence Cases Queue Page.

The ReviewPackageData.jsx component displays the general information fetched in the parent component. Field includes the VA Date Of Receipt (VA DOR), Source Type, Package Document Type, CM (Central Mail) Packet Number, CMP (Central Mail Portal) Queue Name, and the Portal Entry Date. These fields represent metadata from the Central Mail Portal, which can be edited through the "Edit" button.

Dates are formatted using the Moment.js library and uses the following format: "MM/DD/YYYY"

The ReviewForm.jsx contains three TextArea fields, a SearchableDropdown component, and a Modal. The onSubmit for submitting changes makes a request to PATCH "queue/correspondence/:correspondence_uuid. If the update is successful, then we will make a state change and re-render the view, otherwise we would set an error message banner.

The CmpDocuments.jsx consists of a table that maps all the documents associated to the correspondence as a table row and an EditDocumentTypeModal.jsx to allow editing of the document type.

Clicking on a document will initiate a state change to set the selectedId. This id will be then be used in the Pdf Previewer to fetch the appropriate document to display

The CorrespondencePdfUI.jsx component serves as the root layout for the Pdf Previewer and used the Pdfjs Javascript library. Although the styles is based off of Caseflow Reader, because original Caseflow Reader was designed specifically as a React Page Route and is not a modularized component, the logic and component hierarchy for the CorrespondencePdfUI is vastly different and more simplified.

Once the component loads, we fetch the document from the Document Controller and retrieve the document content via pdfjs library's PdfDocumentProxy object. See https://mozilla.github.io/pdf.js/api/draft/module-pdfjsLib-PDFDocumentProxy.html for more information. The document and page proxies are saved to state.

In order to make use of the Pdfjs library, the CorrespondencePdfUI uses useRef hooks on the viewport, scrollView, canvas, and grid in order to persist data between re-renders. These references target DOM elements and prevents them from being re-rendered when there is a state change. Additionally, we use useMemo to memoize the mapping of correspondence documents so that they will only trigger when the the selectedId (the document the user selects) changes.

The PdfPreview currently supports the following functionalities: zoom, fit to screen, rotation, external link to Reader.

All PdfPreview related components can be found in the path client/app/queue/correspondence/pdfPreview

There are three buttons, Return to Queue, Intake Appeal, and Create Record.

The Return to Queue button takes the user back to Queue without preserving any unsaved modifications.

The Intake Appeal button only appears if the document is of package_document_type 10182. This button only works for a user with the "Mail Intake" role assigned to them. Upon clicking the button, documents should be uploaded to Claim Evidence only if the ce_api_demo_toggle is enabled. Afterwards, the user should be rerouted to the the Intake page for the 10182 document.

The Create Record button will take the user to the Correspondence Intake page. See (Correspondence Intake)[https://github.com/department-of-veterans-affairs/caseflow/wiki/Intake-Form] for more details

The Correspondence Queue view is currently rendered using React on Rails. See review_package.html.erb for more details.

All routes in the Correspondence Review Package form can be found in the routes.rb file under the scope path: '/queue'.

The primary controller for fetching data and updating state or saving data to the redux store comes from the correspondence_controller.rb file, whereas the logic pertaining to read and write operations of tasks are handled in the correspondence_tasks_controller.rb.

An administrative or System user can access the explain on UAT environment and higher, whereas on demo and local environments all users can access this page for testing. By changing the url from /queue/correspondence/{:correpsondece_uuid}/review_package to /explain/correspondence/{:correpsondece_uuid}/review_package, the user can now access a visual representation of all the tasks associated with a correspondence.

Correspondence is setup to upload documents to Claim Evidence Api files upload endpoint. It uses the correspondence_documents_efolder_uploader.rb service to handle the business logic of connecting with the ruby_claim_evidence_api gem. The primary method of uploading documents is the correspondence_documents_efolder_uploader#do_upload, and in an instance where an upload fails, an EfolderUploadFailedTask is generated.

This is still a work in progress and current UAT environment uses the ce_api_demo_toggle FeatureToggle to mock a successful return response.