Pre Docket Uniformity Research - department-of-veterans-affairs/caseflow GitHub Wiki
Organizations:
- BVA Intake
- Education
- EMO
- RPOs
- EMO
- 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
- Pending
- 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
- Assigned
- 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
- Assigned (Code is too long. Click here to view it.)
- 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
- Unassigned
- 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
- Unassigned
- 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
- Assigned
-
🎨 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 theQueueTab
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 userecently_completed_tasks_without_younger_siblings
like the Caregiver Support Program? Technically theactive_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 torecently_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 classusa-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 ofcompleted
fromassigned
, and the status of the parentPreDocketTask
is set fromon_hold
toassigned
. - 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 ofcompleted
.
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
- Fix description
Set to:
def description
COPY::VHA_QUEUE_PAGE_COMPLETE_TASKS_DESCRIPTION
end
- Assign tab a unique URL path
- 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
andCOPY::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 |
---|---|
- "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 Ready for review Modals' Submit Button Should Have the Text "Send":
- 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.
🎟️ The Labels for All "Ready for review" Task Actions (except for VHA POs) Should Read "Documents ready for Board Intake review"
- 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 Return to X Modals' Submit Button Should Have the Text "Return":
- 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.
🎟️ All Task Actions That, When Enacted, Set a Task to A Status of in_progress
Should Have the Same Label:
- 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.