Jira Link

Organizations:

• BVA Intake
• Education
  • EMO
    • RPOs
• VHA
  • Caregiver
  • CAMO
    • POs

Org Chart:

graph TD
    A(BVA Intake)
    A --> B(VHA)
    A --> C(Education)

    B --> |Caregiver Issue|D(VHA Caregiver Support)
    B --> |Non Caregiver Issue|E(VHA CAMO)

    E -->F(Community Care - Payment Operations Management)
    E -->G(Community Care - Veteran and Family Members Program)
    E -->H(Member Services - Health Eligibility Center)
    E -->I(Member Services - Beneficiary Travel)
    E -->J(Prosthetics)

    C --> Z(Executive Management Office)
    Z --> K(Buffalo)
    Z --> L(Central Office)
    Z --> M(Muskogee)

Org	Tab 1	Tab 2	Tab 3	Tab 4	Tab 5	Bulk Assign
BVA Intake	Pending:	Ready for Review:	Completed:	❌	❌	❌
VHA CAMO	Assigned:	In Progress:	Completed:	❌	❌	✅
VHA PO	Assigned:	In Progress:	Ready for Review:	On Hold:	Completed:	❌
Caregiver	Unassigned:	In Progress:	Completed:	❌	❌	❌
EMO	Unassigned:	Assigned:	Completed:	❌	❌	❌ (Should they be able to?) We can if they request this feature.
EDU RPO	Assigned:	In Progress:	Completed:	❌	❌	❌

• BVA Intake
  • Pending on_hold_task_children.open
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
  • Ready for Review active_tasks
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
  • Completed Task.includes(*task_includes).visible_in_queue_table_view.where(assigned_to: assignee).completed
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
• VHA CAMO
  • Assigned active_tasks
    • Badges
    • Case Details
    • Tasks
    • Issues
    • Days Waiting
    • Types
    • Assigned To
  • In Progress on_hold_task_children.active
    • Badges
    • Case Details
    • Tasks
    • Issues
    • Days Waiting
    • Types
    • Assigned To
  • Completed active_tasks (Currently incorrect. See notes below.)
    • Badges
    • Case Details
    • Tasks
    • Issues
    • Days Waiting
    • Types
    • Assigned To
• VHA PO
  • Assigned (Code is too long. Click here to view it.)
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
  • In Progress in_progress_tasks
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
  • Ready for Review (Code is too long. Click here to view it.)
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
  • On Hold (Code is too long. Click here to view it.)
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
  • Completed (Code is too long. Click here to view it.)
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Last Action
    • Board Intake
• Caregiver
  • Unassigned assigned_tasks
    • Badges
    • Case Details
    • Tasks
    • Assigned By
    • Types
    • Docket
    • Days Waiting
    • Veteran Documents
  • In Progress in_progress_tasks
    • Badges
    • Case Details
    • Tasks
    • Assigned By
    • Types
    • Docket
    • Days Waiting
    • Veteran Documents
  • Completed recently_completed_tasks_without_younger_siblings
    • Badges
    • Case Details
    • Tasks
    • Assigned By
    • Types
    • Docket
    • Days Waiting
    • Veteran Documents
• EMO
  • Unassigned active_tasks
    • Badges
    • Case Details
    • Tasks
    • Issues
    • Days Waiting
    • Assigned To
    • Veteran Documents (conditionally appended if tab.show_reader_link_column == true)
  • Assigned (Code is too long. Click here to view it.)
    • Badges
    • Case Details
    • Tasks
    • Issues
    • Days Waiting
    • Assigned To
  • Completed (Code is too long. Click here to view it.)
    • Badges
    • Case Details
    • Tasks
    • Issues
    • Days Waiting
    • Assigned To
• EDU RPO
  • Assigned assigned_tasks
    • Badges
    • Case Details
    • Tasks
    • Task Owner
    • Issues
  • In Progress in_progress_tasks
    • Badges
    • Case Details
    • Tasks
    • Task Owner
    • Issues
    • Days Waiting
    • Days Since Intake
  • Completed recently_completed_tasks
    • Badges
    • Case Details
    • Tasks
    • Task Owner
    • Issues

• 🎨 VHA CAMO's "Assigned" tab description: "Cases assigned to you:". Would it be better as "Cases assigned to VHA CAMO:" to match Caregiver's "Cases assigned to VHA Caregiver Support Program:"? - Yes, proceed with change.

• 🎨 Should VHA CAMO's first tab be titled "Unassigned" like its compatriots? - Leave as is for now, but may revisit.

• 🎨 Should the titles for VHA POs' "On Hold" and "Ready for Review" tabs contain the number of tasks contained within each? - Yes, proceed with change.

• 🎨 Should the EMO's second tab be titled "In Progress" instead of "Assigned"? - Leave as is for now.

• 🎨 Will BVA Intake and VHA POs like to have the Badges column added to their queues? - Yes, proceed with change.

• 🎨 Would BVA Intake be open to having their "Pending" tab renamed to "Assigned"? - Leave as is.

• 🎨 Should the tab description for VHA Caregiver Support Program's "In Progress" tab read something more along the lines of "Cases that are in progress:" to match what what exists for VHA CAMO? - Hold off for now.

• 🎨 VHA CAMO's "Completed" tab description is currently set to "Cases assigned to you:", and that seems incorrect. - Use other completed tab description

• 🎨 CSP Completed tab description: "Cases completed (last 7 days):"; EDU RPO Completed tab description: "Cases completed in the last 7 days:". Which one is preferred? - The one with ()

• 🎨 BVA Intake Completed tab description: "Cases that are complete:"; VHA PO and EMO completed tab descriptions: "Cases completed:". Which one is preferred? - Keep Cases completed

• 🎨 "On hold" versus "On Hold" for tab titles throughout the application. Requires an application-wide audit. - Revisit

• 👨‍💻 Should BVA Intake's completed tab's tasks method be placed into the QueueTab class for use elsewhere?

• 👨‍💻 VHA CAMO is currently the only organization that can bulk assign appeals. It may be that its education counterpart, the EMO, may benefit from this functionality as well.

• 👨‍💻 VHA CAMO's completed tab is set up show active_tasks. Would they instead prefer to use recently_completed_tasks_without_younger_siblings like the Caregiver Support Program? Technically the active_tasks method returns the incorrect set of tasks for this tab, but because this tab shares the same name as the CompletedTasksTab it works:

  def self.tab_name
    Constants.QUEUE_CONFIG.COMPLETED_TASKS_TAB_NAME
  end

See this Slack message for more details.

TLDR: If we want to make the VHA CAMO completed tab behave like CSP's, we need to give the tab_name a unique value that isn't "completed", or anything else already in use before tinkering with the tasks method.

• 👨‍💻 VHA PO is the only organization type to have an On Hold tab. This is because they are the only org with the ability to place tasks on timed holds. See Toggle Timed Hold.

• 👨‍💻 VHA PO tabs' tasks methods are highly specialized and will not easily be able to be made uniform.

• 👨‍💻 With VISNs being disabled in Caseflow at this time, do VHA POs still required the Ready for Review tab? This also begs the question if they require the "Assign to VISN" task action (currently hidden in production).

• 👨‍💻 Will EDU RPOs want to switch their tasks methods to recently_completed_tasks_without_younger_siblings to eliminate repeat entries for the same appeal like what is currently in place for the Caregiver org?

• 👨‍💻 / 🎨 A general audit on all tab columns across the various orgs may be helpful as they are all a tad bit different, and they may not need to be if a consensus could be reached. I'm not entirely sure which columns are absolutely required for each business line and which ones we have wiggle room with. It's possible that they may be better off left as is.

• 🎨 For any success banner in Caseflow, should the banner appear within the border of the Queue table, or should it appear above it?

Place above the outline, but make sure we account for all instances of this banner.

Utilizes the CompleteTaskModal component

Actioning Org	Scenario	Dropdown	Modal	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
BVA Intake	Docketing appeal from VHA CAMO				JSON	Ruby
BVA Intake	Docketing appeal from Caregiver				JSON	Ruby
BVA Intake	Docketing appeal from EMO/EDU RPO				JSON	Ruby

This collection of task actions and modals have already been standardized across all of the pre-docket workflows.

Utilizes the AssignToView component

Actioning Org	Scenario	Dropdown	Modal	Modal Validation Failure	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
BVA Intake	Returning appeal to CAMO					JSON	Ruby
BVA Intake	Returning appeal to Caregiver					JSON	Ruby
BVA Intake	Returning appeal to EMO					JSON	Ruby

• For "Return to VHA", now that we have two VHA organizations that BVA Intake can return appeals to, would be it better to set the label to be instead "Return to VHA CAMO"? - Yes!
• Similarly, would the success banner for "Return to VHA" be better off as "You have successfully returned #{veteran_full_name}'s case to VHA CAMO"?- Yes, and CSP's banner should read "VHA Caregiver Support Program" instead of "Caregiver Support Program".
• The submit button on the "Return appeal to VHA Caregiver Support Program" modal has the text "Return", the class of usa-button, and remains disabled until text is entered into the text field. The other two "Return to X" modals' submit buttons have the text "Submit", the css class usa-button-secondary, and is enabled even without text being entered into the text field-- validation errors appear if modal is attempted to be submit without text. Use blue Return button and Caregiver-style error handling with button being disabled.

Actioning Org	Scenario	Dropdown	Modal	Modal Validation Failure	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
VHA CAMO	Sending appeal to BVA Intake as R4R					JSON	Ruby
VHA PO	Sending appeal to VHA CAMO as R4R					JSON	Ruby
Caregiver	Sending appeal to BVA Intake as R4R					JSON	Ruby
EMO	Sending appeal to BVA Intake as R4R					JSON	Ruby
EDU RPO	Sending appeal to BVA Intake as R4R					JSON	Ruby

• All Ready for Review modals can be standardized to utilize same button color, text, and verbiage - Use 'Send' as button text with usa-button class.

• Validation can be stardized across all the Ready for Review modals with the exception of VHA Camo which is technically a different task action "Send to Board Intake" that covers both Ready for Review and Send to Board Intake Modals. This could be separated into separate modals similar to how Caregiver organization is currently handled. - Validation as it exists for Caregiver

• All Ready for Review Task Actions dropdown language can be standardized. Most say "Ready for Review", CSP say "Documents Ready for Board Intake Review". In addition, it seems preferable to make sure identical task actions appear in the same order across different orgs (eg. Ready for Board Intake always appears before Ready for Review in the list) - Change to "Documents ready for Board Intake review" for all actions in this category.

• All of the Success Banners with the exception of the VHA PO can be standardized. Most use the verbiage "You have successfully sent FN LN's case to Board Intake for Review". VHA Camo has a slight variation of that language which would constitute an immaterial change if made. - Use the wording used for Caregiver R4R for VHA CAMO as well. Make sure "Review" is lowercase if not already.

• Benefits of making these changes include the consolidation of related constants which could allow for use of the ReadyForReviewModal without additional conditionals. This will also begin the process of the overall needed refactor of the CompleteTaskModal.

• We are going to move to sentence case for all modal titles and task action labels.

Actioning Org	Scenario	Dropdown	Modal	Modal Validation Failure	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
VHA CAMO	❌ - CAMO users do not have an "Other" or similar option.	❌	❌	❌	❌	❌	❌
VHA PO	Signaling to CAMO that the appeal is ready for review.			1: 2:		JSON	Ruby
Caregiver	Signaling to BVA Intake that the appeal is ready for review.					JSON	Ruby
EMO	Signaling to BVA Intake that the appeal is ready for review.					JSON	Ruby
EDU RPO	Signaling to BVA Intake that the appeal is ready for review.					JSON	Ruby

• VHA CAMO is willing to have their "Send to Board Intake" modal split into "Documents ready for Board Intake review" and "Return to Board Intake" task actions and modals to be much like Caregiver's.

• For the secondary text box on these modals, would it best to rephrase the label to better encapsulate its intent? Food for thought

• All of the above notes for Ready for Review apply here as well.

• The non-other text box that appears for VHA PO is showing as mandatory where it is displayed as optional for other organizations

• The height of the text boxes can be standardized across the orgs - Yes!

• The pre-existing spacing of the elements in the Ready for Review modal seems to be too large compared to what the designs specify:

• Half the spacing

Actioning Org	Scenario	Dropdown	Modal	Modal Validation Failure	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
VHA CAMO	Bundled into Ready for Review action					JSON	Ruby
VHA PO	Return appeal to CAMO team					JSON	Ruby
Caregiver	Return appeal to Intake					JSON	Ruby
EMO	Return appeal to Intake					JSON	Ruby
EDU RPO	Return appeal to EMO					JSON	Ruby

Dropdown wording for the task action is different between the various offices, but it might not be an issue since they are often being returned to different offices/locations. - This will be dealt whenever CAMO's Send to Board Intake action is split out into "Documents ready for Board Intake review" and "Return to Board Intake"

White space in each modal seems to vary. The use of horizontal line rules also seems to be vary. The disabled submit functionality could be expanded to all modals. The submit button is a secondary button throughout everything that uses the generic flow modal instead of the blue primary button. Caregiver is also missing a colon at the end of the additional context text field label while all the other modals have it present.

• No more colons at the end of textarea labels

• Ideally we would have Education and CAMO have the same modal as VHA CSP. VHA PO will likely differ, and will need clarification from stakeholders.

User validation is handled with a disabled submit button in caregiver, but primarily with red return validation text in the other modals.

• Button should read 'Return', have usa-button class, and error validation should behave as it does on the VHA CSP modal.

The success messages are laregly the same except for VHA Camo which has more detail.

• We will be using the text from CSP's modal once VHA CAMO's task actions are separated

Actioning Org	Scenario	Dropdown	Modal	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
VHA CAMO	Does not have action	❌	❌	❌	❌	❌
EMO	Does not have action	❌	❌	❌	❌	❌
Caregiver	Marking task as in progress				JSON	Ruby
VHA PO	Marking task as in progress				JSON	Ruby
EDU RPO	Marking task as in progress				JSON)	Ruby

The task action dropdowns are consistent except for caregiver which is described as "Mark task as in progress". - Use "Mark task in progress"

The modal text for caregiver is different while still stating the same thing. It should probably be the same text for all three modals. - Retain this difference

The success banner for caregiver is different and less descriptive. It should probably be the same for all three mark task as in progress task actions.

Actioning Org	Scenario	Dropdown	Modal	Modal Validation Failure	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
Caregiver	Does not have action	❌	❌	❌	❌	❌	❌
VHA PO	Does not have action	❌	❌	❌	❌	❌	❌
EDU RPO	Does not have action	❌	❌	❌	❌	❌	❌
VHA CAMO	Assigning appeal to VHA PO					JSON	Ruby
EMO	Assigning appeal to EDU RPO					JSON	Ruby

Differences in VHA Camo Assign to PO and EMO assign to RPO is that all text boxes in CAMO are required fields but not in EMO. We can check with UX/BA to determine if this is desired behavior. Modals can be programmed to accomodate the differences between RPO and Program Office in the Modal title.

For the sake of uniformity, the validation on these modals as well as the button color can be changed to match more recent designs

Actioning Org	Scenario	Dropdown	Modal	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
VHA PO	Placing task "on ice" for a selected period of time.				JSON	Ruby

Currently no other workflow has this action available to them. Would others like to be able to place tasks on timed holds?

Submit button class is usa-button-secondary, and may need to be usa-button.

Utilizes the EndHoldModal Component

Actioning Org	Scenario	Dropdown	Modal	Success Banner	TASK_ACTIONS.json	task_action_repository.rb
VHA PO	Task that is on a timed hold is taken off hold early.				JSON	❌

See the Toggle Timed Hold notes above.

Submit button class is usa-button-secondary, and may need to be usa-button.

This section centers around the formatInstructions method within the CompleteTaskModal (seen here):

Scenario	Case Timeline
CAMO sends appeal directly to BVA Intake
CAMO sends appeal to Program Office
CAMO sends appeal to Program Office, they return it
CAMO sends appeal to Program Office, they return it. CAMO assigns to another PO.
CAMO sends appeal to Program Office, they return it. CAMO assigns to another PO. The second PO also returns it.
CAMO sends appeal to Program Office, they send it back as Ready for Review
CAMO sends appeal to Program Office, they send it back as Ready for Review. CAMO then sends it to Intake as Ready for Review.
CAMO sends appeal to Program Office, they send it back as Ready for Review with 'Other' option
CAMO sends appeal to Program Office, they send it back as Ready for Review, and CAMO sends it to Intake
Intake dockets appeal while it is at CAMO
Intake dockets appeal while it is at a PO	1. 2.
Intake returns appeal to CAMO	1. 2.
CAMO returns appeal to Intake due to error
CAMO returns appeal to Intake due to error after it had been to a PO

• Sending an appeal to a PO creates a node in the "Currently active tasks" tree, but not the Case Timeline.
• This is the only business line that places previous office instructions into its parents case timeline entry.
• "CANCELLED ON: <--DATE-->" shows on one line. "COMPLETED ON:\n <--DATE-->" date is placed on new line.
• The vertical spacing for "CAMO Notes:", "Detail:", "Program Office Notes:", and "Status:" all differ slightly. For an example on how we could standardize them, we could place a space after the colons instead of 1-2 new lines. This image has all 4 sections shown in the same timeline:

Scenario	Case Timeline
CSP returns appeal to BVA Intake due to error
CSP sends appeal to BVA Intake as Ready for Review
CSP sends appeal to BVA Intake as Ready for Review with 'Other' reason
BVA Intake dockets appeal while it is at CSP
Intake returns appeal to CSP that was sent as Ready for Review
Intake returns appeal to CSP that was sent as Return to Intake

• Includes "Reason for return:" and reason on timeline after sending an appeal back to BVA Intake, and the other business lines do not. They may benefit from this tittle being included.
• Should "Reason for return:" be bolded? The other section tiles are bolded, so it seems like it should be as well.
• The "Details:" section that is listed under "Reason for return:" is also not bolded, it uses the plural form of "detail" where the CAMO sections use the singular, and it only has one new line character after the colon where the CAMO counterpart has two (though, this is listed as something to potentially change in the CAMO timeline notes section above).

Scenario	Case Timeline
EMO returns appeal to BVA Intake due to error
EMO sends appeal to BVA Intake as Ready for Review
EMO sends appeal to BVA Intake as Ready for Review with 'Other' reason
EMO sends appeal to RPO
EMO sends appeal to RPO, and they return it
EMO sends appeal to RPO, and they return it. EMO assigns to another RPO.
EMO sends appeal to RPO, they return it. EMO assigns to another RPO. The second RPO also returns it.
EMO sends appeal to RPO. They send it to Intake as Ready for Review
EMO sends appeal to RPO. They send it to Intake as Ready for Review 'Other'
Intake dockets appeal while it is at EMO
Intake dockets appeal while it is at an RPO	1. 2.
Intake returns appeal to EMO that was sent as Ready for Review
Intake returns appeal to EMO that was sent as Return to Intake

• Sending an appeal to an RPO creates a node in the "Currently active tasks" tree, but nothing is added to the Case Timeline. Should the AssignToView component add entries to the Case Timeline similarly to how the CompleteTaskModal component does?
• When RPO sends an appeal to intake, The text box details and/or other instructions do not show in the timeline under the EducationDocumentSearchTask
• Upon completion of EducationAssessDocumentationTask the contents from the various fields are not labeled, making it difficult to determine which piece of information correlates with which field.

flowchart LR
  A[Send to Board Intake] -->|Ready for review| B[Documents ready for Board Intake review]
  A -->|Return due to error| C[Return to Board Intake]

• Existing task action is removed/repurposed
• Two actions are created that are similar to the ones for VHA Caregiver Support Program:

    def vha_caregiver_support_return_to_board_intake(*)
      completed_tab_name = VhaCaregiverSupportCompletedTasksTab.tab_name
      queue_url = "/organizations/#{VhaCaregiverSupport.singleton.url}?tab=#{completed_tab_name}"
      dropdown_options = COPY::VHA_CAREGIVER_SUPPORT_RETURN_TO_BOARD_INTAKE_MODAL_DROPDOWN_OPTIONS.map do |_, value|
        value.transform_keys(&:downcase)
      end
      {
        modal_title: COPY::VHA_CAREGIVER_SUPPORT_RETURN_TO_BOARD_INTAKE_MODAL_TITLE,
        modal_body: COPY::VHA_CAREGIVER_SUPPORT_RETURN_TO_BOARD_INTAKE_MODAL_BODY,
        type: VhaDocumentSearchTask.name,
        options: dropdown_options,
        redirect_after: queue_url
      }
    end

    def vha_caregiver_support_send_to_board_intake_for_review(task, _)
      completed_tab_name = VhaCaregiverSupportCompletedTasksTab.tab_name
      {
        modal_title: COPY::DOCUMENTS_READY_FOR_BOARD_INTAKE_REVIEW_MODAL_TITLE,
        modal_button_text: COPY::MODAL_SEND_BUTTON,
        message_title: format(
          COPY::VHA_CAREGIVER_SUPPORT_DOCUMENTS_READY_FOR_BOARD_INTAKE_REVIEW_CONFIRMATION_TITLE,
          task.appeal.veteran_full_name
        ),
        type: VhaDocumentSearchTask.name,
        redirect_after: "/organizations/#{VhaCaregiverSupport.singleton.url}?tab=#{completed_tab_name}",
        body_optional: true
      }
    end

• Options are provided for reasoning dropdown for the "Return to Board Intake" modal similarly to the action for VHA CSP.
• Once either task action is enacted, the VhaDocumentSearchTask assigned to VHA CAMO is still set to a status of completed from assigned, and the status of the parent PreDocketTask is set from on_hold to assigned.
• Upon sucessfully sending an appeal back to BVA Intake for review, the success banner should read: "You have successfully sent 's case to Board Intake for Review"
• Upon sucessfully returning an appeal back to BVA Intake for due to an error, the success banner should read: "You have successfully returned 's case to Board Intake"

Should more or less appear as below:

• Submission button reads "Send"
• Submission button is disabled until all required fields are populated
  • User must select a radio field
  • If they select "Other", they will need to enter text into an additional text field.
• Upon submission, the VhaDocumentSearchTask is set to a status of completed.

Should more or less appear as below (same as Caregiver):

• Ensure submission populates case timeline correctly.

It has been confirmed that VHA CAMO will be receiving a rework of their "Send to Board Intake" modal to have some of its functionality split off into a "Return to BVA Intake" modal. This modal will include a dropdown of reasons for the user to select why the appeal is being returned. It is possible that we will want to extend this to the EMO's modal.

VHA CSP	EMO

Link to buttons on /styleguide

Button classes are currently set to the bottom class (usa-button-secondary). They need to be changed to the top:

• We can probably remove the submitButtonClassNames prop from FlowModal.jsx and hardcode in the class we'd like for all buttons on all modals to utilize:

render = () => {
    const { title, button, children, error, success, submitDisabled } = this.props;

    return (
      <Modal
        title={title}
        buttons={[
          {
            classNames: ['usa-button', 'cf-btn-link'],
            name: COPY.MODAL_CANCEL_BUTTON,
            onClick: this.cancelHandler
          },
          {
            classNames: [
              'usa-button',  //<-------- Here. Used to be 'usa-button-secondary'.
              'usa-button-hover',
              'usa-button-warning'
            ],
            name: button,
            disabled: submitDisabled,
            loading: this.state.loading,
            onClick: this.submit
          }
        ]}
        closeHandler={this.cancelHandler}
      >
        {error && <Alert title={error.title} type="error">{error.detail}</Alert>}
        {success && <Alert title={success.title} type="success">{success.detail}</Alert>}
        {children}
      </Modal>
    );
  };

• Are there any other modal components? If so, it sounds like their buttons should be utilizing this same class as well.
• Is it possible and necessary to get test coverage on all of these buttons to ensure the classes do not regress.

The description should read "Cases assigned to VHA CAMO:"

Change to be made here:

Before:

  def description
    format(COPY::USER_QUEUE_PAGE_ASSIGNED_TASKS_DESCRIPTION, assignee.name)
  end

After:

  def description
    format(COPY::ORGANIZATIONAL_QUEUE_ASSIGNED_TO_DESCRIPTION, assignee.name)
  end

Link to code

• Fix description

Set to:

def description
  COPY::VHA_QUEUE_PAGE_COMPLETE_TASKS_DESCRIPTION
end

• Assign tab a unique URL path

Why we need this

• Fix tasks method
  • Currently returns assigned tasks. The correct tasks are being accidentally displayed due to the URL path not being unique. See the above bullet point.

def tasks
  completed_tasks # <--- This method doesn't exist in the QueueTab class, and it probably should.
end

• Limit view to cases closed in last seven days like VHA CSP? :thinking_face: This will affect the description and tasks method.

Before:

  def description
    COPY::EDUCATION_RPO_QUEUE_PAGE_COMPLETED_TASKS_DESCRIPTION
  end

After:

  def description
    COPY::QUEUE_PAGE_COMPLETE_TASKS_DESCRIPTION
  end

• Delete COPY::EDUCATION_RPO_QUEUE_PAGE_COMPLETED_TASKS_DESCRIPTION to limit number of constants and to help clean up COPY.json

• Currently reads "Cases that are complete:"
• Change to "Cases completed:" (COPY::VHA_QUEUE_PAGE_COMPLETE_TASKS_DESCRIPTION and COPY::EDUCATION_EMO_QUEUE_PAGE_COMPLETED_TASKS_DESCRIPTION) both have this value. Could these be consolidated so all 3 tabs can use the same constant string?

• "On Hold" tab title --> "On Hold (X)" where X is the number of appeals in the tab.
• "Ready for Review" tab title --> "Ready for Review (X)" where X is the number of appeals in the tab.

• Move large alert banners to be outside of outlined components (see above picture).
• Make sure this is implemented consistently across the entire application, and not just Queue.

• Make all task action modals have input validation akin to Caregiver's modals where the submission button is disabled until all required fields are populated.

Yes	No

Link to Code

• "Return appeal to VHA" --> "Return appeal to VHA CAMO"

• Upon successful submission of the modal, the success banner should read "You have successfully returned <appellant's-name>'s case to VHA Caregiver Support Program"

• All buttons have the text "Send"
• Buttons should remain disabled until all required fields are populated.
• Buttons should use the usa-button CSS class, and be solid blue with a hover effect.

• See title 😅

Yes	No

The modal on the right's vertical spacing differs from the designs on the left:

Currently the VhaCaregiverSupportReturnToBoardIntakeModal modal has the correct height spacing for its elements while using a marginTop value of 2:

!

<TextareaField
  label={COPY.VHA_CAREGIVER_SUPPORT_RETURN_TO_BOARD_INTAKE_MODAL_TEXT_FIELD_LABEL}
  name="instructions"
  id="caregiverSupportReturnToBoardIntakeInstructions"
  onChange={(value) => setState({ instructions: value })}
  value={state.instructions}
  styling={marginTop(2)}  //<-------------- Here
  maxlength={ATTORNEY_COMMENTS_MAX_LENGTH}
  optional
/>

In other modals we are using styling={marginTop(4)}. This value should be set to 2 for the other components as well.

Give all textarea components a minimum height of textAreaStyling={setHeight(4.5)} to prevent the grey "resize" icon from appearing in the box. See below for what we want to avoid:

Pass in optional prop to all textarea components that are in fact optional.

For example, the EMO's "Return to Board Intake" modal is currently missing this label:

• All buttons have the text "Return"
• Buttons should remain disabled until all required fields are populated.
• Buttons should use the usa-button CSS class, and be solid blue with a hover effect.

• The task action label for all of these task actions should be "Mark task in progress".
• The accompanying modals should have the same text for their titles.