# APPEALS-6277: Investigation Into the Reusability of the Existing "Caregiver Appeals" VhaProgramOffice in New Pre-docket Workflow

## Queue Tabs

### The Tabs List

Existing tabs for `VhaProgramOffice`:

  def queue_tabs
    [
      assigned_tasks_tab,
      in_progress_tasks_tab,
      ready_for_review_tasks_tab,
      on_hold_tasks_tab,
      completed_tasks_tab
    ]
  end

Below is a chart showing the differences between the existing queue tabs for all current VHA Program Offices with what the Caregiver Support Program has requested. An `X` indicates that the queue it is listed beneath does not wish to have the same tab the other organization has specified.
| VhaProgramOffice | CSP |
| ------ | ------|
| X | unassigned |
| assigned | X|
| in_progress | in_progress |
| ready_for_review | X |
| on_hold | X |
| completed | completed |
| --- | --- |
| 5 tabs | 3 tabs |

### Individual Tabs and Their Columns

**Unassigned**: This tab does not exist for VHA POs and will need to be created regardless if we utilzie the existing organization or not.

**In Progress**: ([link to file](https://github.com/department-of-veterans-affairs/caseflow/blob/87364df79e7fa8112d98265d9cd47b0dcc09ab32/app/models/queue_tabs/vha_program_office_in_progress_tasks_tab.rb#L3)) This tab is mostly already in a state that meets the criteria outlined for the CSP. The one change that will need to take place is which columns are shown on this tab for CSP users versus those from other POs:

| Other POs | CSP |
| --- | ---|
| CASE_DETAILS_LINK | CASE_DETAILS_LINK |
| TASK_TYPE | TASK_TYPE |
| TASK_OWNER | X |
| ISSUE_COUNT | X |
| LAST_ACTION | X |
| BOARD_INTAKE | X |
| X | TASK_ASSIGNED_BY |
| X | APPEAL_TYPE |
| X | DOCKET_NUMBER |
| X | DAYS_WAITING |
| X | DOCUMENT_COUNT_READER_LINK |

[def description](https://github.com/department-of-veterans-affairs/caseflow/blob/87364df79e7fa8112d98265d9cd47b0dcc09ab32/app/models/queue_tabs/vha_program_office_in_progress_tasks_tab.rb#L14):

Currently, the string being utilized is:

{"ORGANIZATIONAL_QUEUE_PAGE_IN_PROGRESS_TASKS_DESCRIPTION": "Cases in progress in a %s team member's queue."}

The resultant description for the In Progress tab would then be:

`"Cases in progress in a Caregiver Appeals team member's queue."`

The requested description is:

`"Cases assigned to VHA Caregiver Support Program"`

**Completed**: ([link to file](https://github.com/department-of-veterans-affairs/caseflow/blob/87364df79e7fa8112d98265d9cd47b0dcc09ab32/app/models/queue_tabs/vha_program_office_completed_tasks_tab.rb#L3))
| Other POs | CSP |
| --- | ---|
| CASE_DETAILS_LINK | CASE_DETAILS_LINK |
| TASK_TYPE | TASK_TYPE |
| TASK_OWNER | X |
| ISSUE_COUNT | X |
| LAST_ACTION | X |
| BOARD_INTAKE | X |
| X | TASK_ASSIGNED_BY |
| X | APPEAL_TYPE |
| X | DOCKET_NUMBER |
| X | DAYS_WAITING |
| X | DOCUMENT_COUNT_READER_LINK |

[def description](https://github.com/department-of-veterans-affairs/caseflow/blob/87364df79e7fa8112d98265d9cd47b0dcc09ab32/app/models/queue_tabs/vha_program_office_completed_tasks_tab.rb#L14):

Currently, the string being utilized is:

{"VHA_QUEUE_PAGE_COMPLETE_TASKS_DESCRIPTION": "Cases completed:"}

The desired string will read:
`Cases completed (last 7 days)`

Implementation may be as follows:

def description
  is_caregiver_program ? QUEUE_PAGE_COMPLETE_TASKS_DESCRIPTION : VHA_QUEUE_PAGE_COMPLETE_TASKS_DESCRIPTION
end

[def tasks](https://github.com/department-of-veterans-affairs/caseflow/blob/87364df79e7fa8112d98265d9cd47b0dcc09ab32/app/models/queue_tabs/vha_program_office_completed_tasks_tab.rb#L24): The task filtering that will need to be in place for the CSP queue must limit completed tasks to those that have been closed only within the last 7 days. Currently, the completed implementation does not account for this. The CSP-specific implementation will need to be:

  def tasks
    recently_completed_tasks
  end

## Task(s)

Tasks can easily be assigned to any organization that is desired, which increase the perceived feasibility of reusing the existing CSP organization.

However, due to how task actions are associated with a task, and the differences that exist between existing VHA actions and requested CSP actions for this task, it adds logically complexity towards allowing both organizations to utilize the same task in different manners.

These challenges will be further outlined in the `Task Actions` section.

Task actions aside, there is no reason why the existing task cannot be used for both organizations.

[VhaDocumentSearchTask.rb](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/app/models/tasks/pre_docket/vha_document_search_task.rb#L7)

VhaDocumentSearchTask.update!(assigned_to: VhaCamo.singleton)

VhaDocumentSearchTask.update!(assigned_to: VhaProgramOffice.where(name: "Caregiver Appeals"))

## Task Actions

### Actions available on VHA/CSP task

| VHA CAMO | CSP |
| ---- | ----|
| VHA_ASSIGN_TO_PROGRAM_OFFICE | X |
| VHA_SEND_TO_BOARD_INTAKE | X |
| X | Mark task as in progress |
| X | Docs Ready - Send to Intake for Review |
| X | Return to Board Intake |

There exists only one overlapping task action between the two organizations. The available task actions will need to be conditionally determined based upon if the organization the ask is being assigned to is either VHA CAMO or the CSP.

### TASK_ACTION.json/task_action_repository.rb

**Sending an Appeal Back to BVA Intake**: The task action currently used by VHA CAMO to send an appeal to BVA Intake will be able to be reused ASSUMING that the `VhaDocumentSearchTask` that is assigned to CSP is a direct child of BVA Intake's `PreDocketTask`.

graph TD
    A[RootTask] --> B
    B(PreDocketTask - BVA Intake) --> |Appeal has VHA Benefit Type and Caregiver Issue| C(VhaDocumentSearchTask - CSP)
    B(PreDocketTask - BVA Intake) --> | Appeal has VHA Benefit Type and Non-Caregiver Issue  | D(VhaDocumentSearchTask - VHA CAMO)

This will mean whenever the `VhaDocumentSearchTask` is completed that the `PreDocketTask` will have its status updated to `assigned`. Another assumption is that we want the `VhaDocumentSearchTask`'s status to be `completed`. If we want it to be `cancelled` then this task action being reused becomes far less viable.

This will need to trigger a modal to open that will prompt for a reason as to why the appeal is being returned back to BVA Intake. This will be detailed more closely in the Modal section below.

The [JSON](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/constants/TASK_ACTIONS.json#L402):

  "VHA_SEND_TO_BOARD_INTAKE": {
    "label": "Send to Board Intake",
    "value": "modal/vha_send_to_board_intake",
    "func": "vha_send_to_board_intake"
  },

The method that is called upon execution of the task action will need some conditionals placed within it based on if the caller is a VHA CAMO or CSP user. The `modal_title` and `redirect_after` values differ between the two orgs.

The [Ruby]():

    def vha_send_to_board_intake(*)
      {
        modal_title: COPY::VHA_SEND_TO_BOARD_INTAKE_MODAL_TITLE,
        type: VhaDocumentSearchTask.name,
        redirect_after: "/organizations/#{VhaCamo.singleton.url}"
      }
    end

**Mark task as in progress**:
This task action is already wired up for use in [TASK_ACTIONS.json](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/constants/TASK_ACTIONS.json#L407), [task_action_respository.rb](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/app/repositories/task_action_repository.rb#L578), and in [QueueApp.jsx](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/QueueApp.jsx#L945). Calling this action and sending up the id of the `VhaDocumentSearchTask` as a query parameter to `TasksController#update` will update its status to `in_progress`.

  "VHA_MARK_TASK_IN_PROGRESS": {
    "label": "Mark task in progress",
    "value": "modal/mark_task_in_progress",
    "func": "vha_mark_task_in_progress"
  },

For the backend call, the `type` value will need to become something along the lines of `task.type` instead of being hardcoded to `type: AssessDocumentationTask.name`.

Much to my delight, it appears as all of the copy being referenced in the method matches up with our AC.

The [Ruby]():

    def vha_mark_task_in_progress(task, _user)
      org = Organization.find(task.assigned_to_id)
      queue_url = org.url
      {
        modal_title: COPY::ORGANIZATION_MARK_TASK_IN_PROGRESS_MODAL_TITLE,
        modal_body: COPY::ORGANIZATION_MARK_TASK_IN_PROGRESS_MODAL_BODY,
        message_title: COPY::ORGANIZATION_MARK_TASK_IN_PROGRESS_CONFIRMATION_TITLE,
        message_detail: COPY::ORGANIZATION_MARK_TASK_IN_PROGRESS_CONFIRMATION_DETAIL,
        type: AssessDocumentationTask.name,
        redirect_after: "/organizations/#{queue_url}"
      }
    end

**Docs Ready - Send to Intake for Review**:

We could potentially utilize the same task action that is used to return an appeal to BVA Intake, however the executing of this task action must trigger a modal to appear in the frontend that prompts the user for the location of the located documents.

This will be very similar to how it is done for Education Pre-Docket:

    def emo_send_to_board_intake_for_review(*)
      {
        modal_title: COPY::EDU_SEND_TO_BOARD_INTAKE_FOR_REVIEW_MODAL_TITLE,
        type: EducationDocumentSearchTask.name,
        redirect_after: "/organizations/#{EducationEmo.singleton.url}",
        body_optional: true
      }
    end

In the education pre-docket effort we found it much easier to separate this task action out from its similarly behaved counterpart. I believe that the same will be the case for this feature work as well.

## Modals

**Return to BVA Intake**:

[Route](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/QueueApp.jsx#L1047) | [Component](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/components/CompleteTaskModal.jsx#L29)

There is logic in place from the education pre-docket effort to prompt the user for a reason why they are returning an appeal to BVA Intake.

The logic:

  emo_return_to_board_intake: {
    buildSuccessMsg: (appeal) => ({
      title: sprintf(COPY.EMO_RETURN_TO_BOARD_INTAKE_CONFIRMATION, appeal.veteranFullName)
    }),
    title: () => COPY.EMO_RETURN_TO_BOARD_INTAKE_MODAL_TITLE,
    getContent: ReturnToBoardIntakeModal,
    buttonText: COPY.MODAL_RETURN_BUTTON
  },

The resulting prompt:

const ReturnToBoardIntakeModal = ({ props, state, setState }) => {
  const taskConfiguration = taskActionData(props);

  return (
    <React.Fragment>
      {taskConfiguration && taskConfiguration.modal_body}
      {(!taskConfiguration || !taskConfiguration.modal_hide_instructions) && (
        <div>
          <TextareaField
            label={COPY.EMO_RETURN_TO_BOARD_INTAKE_MODAL_BODY}
            name="instructions"
            id="emoReturnToBoardIntakeInstructions"
            onChange={(value) => setState({ instructions: value })}
            value={state.instructions}
            maxlength={ATTORNEY_COMMENTS_MAX_LENGTH}
            errorMessage={props.highlightInvalid &&
              !validInstructions(state.instructions) ? COPY.EMPTY_INSTRUCTIONS_ERROR : null}
          />
        </div>
      )}
    </React.Fragment>
  );
};

Validation for these fields is already in place. We will need to add an entry in the [validate method](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/components/CompleteTaskModal.jsx#L455) to enforce having to select a reason for returning the appeal.

It is likely that we only need to parameterize some of the EMO/education-specific items within `ReturnToBoardIntakeModal` to be usable in our effort.

**Send to BVA Intake for Review/Docketing**:

[Route](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/QueueApp.jsx#L1076) | [Component](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/components/CompleteTaskModal.jsx#L29)

The modal for this action is actually the same as for returning the appeal to BVA Intake.

Here is how it is set up for education pre-docket:

  emo_send_to_board_intake_for_review: {
    buildSuccessMsg: (appeal) => ({
      title: sprintf(COPY.EDU_SEND_TO_BOARD_INTAKE_FOR_REVIEW_CONFIRMATION_PO, appeal.veteranFullName)
    }),
    title: () => COPY.VHA_COMPLETE_TASK_LABEL,
    getContent: ReadyForReviewModal,
    buttonText: COPY.MODAL_SUBMIT_BUTTON
  },

We could very similarly add our own section to this dictionary for CSP to have the ability to send an appeal to BVA Intake as ready for review.

We will need to have the validation method within this component know to make sure that a CSP user selects a location pertaining to where the located documents exist:

validateForm = () => {
    const { instructions, otherInstructions, radio } = this.state;
    const modalType = this.props.modalType;

    let isValid = true;

    //\\//\\//\\//\\//\\//\\//\\//\\//\\
    // THIS IS WHERE IT NEEDS TO GO!! \\
    //\\//\\//\\//\\//\\//\\//\\//\\//\\
    if (modalType === 'vha_send_to_board_intake' || modalType === 'ready_for_review') {
      isValid = validInstructions(instructions) && validRadio(radio);
    }

    if (modalType === 'emo_return_to_board_intake') {
      isValid = validInstructions(instructions);
    }

    if (modalType === 'emo_send_to_board_intake_for_review' || modalType === 'rpo_send_to_board_intake_for_review') {
      if (radio === 'other') {
        isValid = validInstructions(otherInstructions) && validRadio(radio);
      } else {
        isValid = validRadio(radio);
      }
    }

    return isValid;
  }

**Set In Progress**:

[Route](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/QueueApp.jsx#L945) | [Component](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/client/app/queue/components/InProgressTaskModal.jsx#L14)

This modal will require little-to-no updates in order for it to operate as needed.

# The Verdict

## Organization Class/Queue Tabs
In my opinion, due to the large number of differences in queue tabs and queue tab columns between what VHA Program Offices and the Caregiver Support Program require, it would make the most sense to separate the VhaProgramOffice with the name of "Caregiver Appeals" into its own singleton class. The large amount of conditionals needed to make the organization-queue classes meet the requirements of both types of orgs within singular files would be very cumbersome and inextensible.

By separating out the organization into its own class, it will provide us an option to easily steer behavior in the pre-docket workflow to differentiate between VhaCamo and CSP:

org.is_a?(CaregiverSupportProgram)

This will come in handy for allowing `VhaDocumentSearchTask` to be reused by both VhaCamo and the CSP.

## VhaDocumentSearchTask
It is very common in Caseflow to have a variety of available actions on a task depending on who it is assigned to. The [InformalHearingPresentationTask](https://github.com/department-of-veterans-affairs/caseflow/blob/6ea754dd3254fee25b75c4ba5fdafb41ba3e66a0/app/models/tasks/informal_hearing_presentation_task.rb#L14) is a great example of this where the actions differ depending on whether the assignee is an org, a user, and/or an admin user. Something very similar can be done for our use case with minimal effort.

## Task Actions

The`VHA_MARK_TASK_IN_PROGRESS` task action can easily be repurposed for use by CSP if the task type in its `TaskActionRepository` method is changed from being hardcoded to being the name of the task passed into the method.

As for the `RETURN_TO_BVA_INTAKE` and `SEND_TO_BVA_INTAKE` actions, it may be best to go the course of separating these out into their own task actions. This will allow for the [CompleteTaskModal.jsx](https://github.com/department-of-veterans-affairs/caseflow/blob/87364df79e7fa8112d98265d9cd47b0dcc09ab32/client/app/queue/components/CompleteTaskModal.jsx#L29) component to use the unique values that these new methods will provide to display CSP-specific text to that organization's users. The amount of code that these task actions will add to the codebase is minimal.

## Modals

We will likely want to utilize the existing modals that are in place, and only make slight modifications to them where necessary. These modal components accept titles, descriptions, and tasks as parameters that allow them to operate in a workflow-agnostic fashion, allowing them to be used to cover the additional scenarios brought about by this epic.

The `CompleteTaskModal` component is currently bloated, and it may be that we'd like to instead create a new modal component for our workflow for ease of maintainability.