Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New task type (Mail Team): 90 Day Letter Correspondence #15239

Closed
10 of 13 tasks
araposo-tistatech opened this issue Sep 15, 2020 · 6 comments · Fixed by #15692
Closed
10 of 13 tasks

New task type (Mail Team): 90 Day Letter Correspondence #15239

araposo-tistatech opened this issue Sep 15, 2020 · 6 comments · Fixed by #15692
Labels
Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Type: New Development New feature development

Comments

@araposo-tistatech
Copy link

araposo-tistatech commented Sep 15, 2020

User or job story

User story: As a Mail Team user, I need to be able to create a new task on a CAVC Remand case, so that when I receive correspondence from an appellant I can send the correspondence to the CAVC Litigation Support Team.

Acceptance criteria

  • Please put this work behind the feature toggle: cavc_remand
  • This feature should be accessible to the following user groups: Mail Team
  • Other conditions:
    • CavcTask is open
    • Appeal is a cavc remand
  • Include screenshot(s) in the Github issue if there are front-end changes
  • Update documentation: CAVC Remand
  • Task is child of CAVC task
  • Verify "Add New Task" link is displayed on the appeal case details page
  • Verify Select Correspondence Type drop down includes CAVC Correspondence
  • Verify the new task 'CavcCorrespondenceTask' is routed to the CAVC Litigation Support team
  • Verify CavcRemandProcessedLetterResponseWindowTask status does not change. Make CavcRemandProcessedLetterResponseWindowTask available when CavcCorrespondenceTask is created #15288

Open questions

  • With the assumption that the correspondence is NOT related to the response window and is just standard mail, what task actions should the CavcCorrespondenceTask have?

Release notes

Out of scope

Designs

image.png

Background/context

Technical notes

This could possibly be similar to the Evidence Submission Task as they are both timed responses.

Other notes

Resources/other links

@araposo-tistatech araposo-tistatech added Product: caseflow-queue Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Type: New Development New feature development labels Sep 15, 2020
@araposo-tistatech araposo-tistatech changed the title Mail Team: 90 Day Letter Response New task type: 90 letter response window task Sep 22, 2020
@hschallhorn
Copy link
Contributor

It sounds like the mail team is not going to to be reading any correspondence about cavc cases.
Instead, if they receive mail related to a cavc case, they want to just send the mail directly to the cavc lit support team by creating a new task. If this is a response to the 90 day letter, the cavc team can be in charge of deciphering that and completing the 90 response window task and moving the case forward.

So the mail team should not be able to manually complete this task, nor have any actions for this task, nor should it be assigned to them.

@geronimoramos
Copy link

@hschallhorn yes! no actions on the Mail team end except to add new mail item task to send it to lit support, and that's it for the mail team. They may not decipher the document(s) but they may look for identifiable information to look up in the system to see the status (CAVC Remand) which will let them know 'oh this needs to go to Lit Support for further processing'

Lit support will be responsible for closing the 90-day response window task

@araposo-tistatech araposo-tistatech changed the title New task type: 90 letter response window task New task type (Mail Team): 90 Day Letter Correspondence Oct 5, 2020
@araposo-tistatech
Copy link
Author

araposo-tistatech commented Oct 5, 2020

@geronimoramos please verify I've captured the new requirements correctly. I am particularly unsure of the last AC.

@hschallhorn
Copy link
Contributor

what is this chart?

1 | 
2 | |||||
3 | |||||||
5 | 
8 | 

Work:
* create CavcCorrespondenceTask class (with MailTask parent) with default available actions
* for the Mail Team, include task action that creates CavcCorrespondenceTask under CavcTask

Why 2?

  • New mail task type that basically follows existing mail task subclasses

Why 3?

  • New unit and feature tests
  • First instance of logic determining if a mail task should be included in list of available tasks

@geronimoramos
Copy link

With the assumption that the correspondence is NOT related to the response window and is just standard mail, what task actions should the CavcCorrespondenceTask have?

This one is tricky. I'm thinking CAVC lit support will want the 90-day timer to time out or wait for correct correspondence so they might want to continue to keep it on hold. Could they send the task back to the mail team and continue the hold? @mbaenatan thoughts?

@mbaenatan
Copy link

Based on discussion, we will move forward with default actions for mail tasks
Screen Shot 2020-11-12 at 4 06 38 PM

va-bot pushed a commit that referenced this issue Dec 21, 2020
Resolves #15239 

### Description
Creates the CavcCorrespondenceMailTask & its behavior.

### Acceptance Criteria
- [ ] work behind the feature toggle: cavc_remand
- [ ] Add task should be accessible to the Mail Team
- [ ] accessible to the following user groups: Mail Team
- [ ] Select Correspondence Type drop down includes CAVC Correspondence
- [ ] requires a CAVC Remand appeal with an open CavcTask
- [ ] Mail Team users have no actions on the created tasks
- [ ] Cavc Lit Admins can act on Organization task or any User task
- [ ] Cavc Lit user can act on a user task assigned to themselves
- [ ]  Verify CavcRemandProcessedLetterResponseWindowTask status does not change.

### Testing Plan
  1. Reset the database with `make reset`
  2. Create a Cavc Appeal at CavcResponseWindow
```ruby
appeal = FactoryBot.create(:appeal, :cavc_response_window_open)
appeal.reload.treee
appeal.uuid
FeatureToggle.disable!(:cavc_remand)
```
  3. Load up [caseflow](http://localhost:3000/test/users) and sign in as Jolly Postman
  4. Navigate to the appeal you created
  5. Click `+ Add a new task`
   - [x] CAVC Correspondence is not available
  6. Enable the flag: `FeatureToggle.enable!(:cavc_remand)`
  7. Reload and Click `+ Add a new task`
   - [x] CAVC Correspondence is available
   - [x] Creating a CAVC Correspondence task autoassigns to CAVC Lit Support
   - [x] No actions are available on the task for the mail user
  8. Change to be a CAVC Lit Support admin user
  9. Navigate to the appeal
   - [x] Check the actions exist and do what you want (TK)
  10. Create another appeal & mail task
  11. Navigate to the appeal and assign it to a Cavc Lit support user
   - [x] confirm you have admin have actions on the user task
  12. Sign in as a Cavc Lit user you didn't assign the task to 
   - [x] No actions are available
  13. Sign in as the assigned Cavc Lit user
   - [x] Check the actions exist and do what you want (TK)

Expected Behavior on Actions:
  - [x] Confirm none of this affects the CavcResponseWindowTask status!
  - [x] Change Task Type: Cancels the CavcCorrespondence subtree, creates a sibling of the new type
  - [x] (Re)Assign to person: creates a user task
  - [x] Place on hold: places a hold
  - [x] Mark task complete: completes the subtree
  - [x] Cancel task: cancels the subtree
 
### Documentation Updates
- [x] Add or update code comments at the top of the class, module, and/or component.

### UI Changes
![image](https://user-images.githubusercontent.com/6129479/102548342-840b6000-4088-11eb-99ed-3aa1c1e6968b.png)
alisan16 added a commit that referenced this issue Jan 4, 2021
* Selectively show cavc decision types and remand subtypes based on feature toggles (#15677)

Followup to #15597

### Description
Does not show options for mdr, death dismissal, or straight reversal unless those features are enabled.

### Acceptance Criteria
- [x] MDR can only be selected if the feature toggle is on (mdr_cavc_remand)
- [x] Death dismissal can only be selected if the feature toggle is on (dismissal_cavc_remand)
- [x] Straight reversal can only be selected if the feature toggle is on (reversal_cavc_remand)

### Testing Plan
1. Enable cavc_remand feature toggle(`FeatureToggle.enable!(:cavc_remand)`)
1. Find a dispatched appeal (search for vet 500000000)
1. Click "+ Add CAVC Remand"
1. Confirm mrd, death dismissal, and straight reversal are not available to be selected
1. Enable mdr_cavc_remand feature toggle(`FeatureToggle.enable!(:mdr_cavc_remand)`)
1. Confirm mdr is now selectable
1. Repeat with `dismissal_cavc_remand` and `reversal_cavc_remand`

### User Facing Changes
 - [x] Screenshots of UI changes added to PR & Original Issue

 BEFORE|AFTER|mdr_cavc_remand enabled|dismissal_cavc_remand enabled|reversal_cavc_remand enabled
---|---|---|---|---
![Screen Shot 2020-12-07 at 12 58 24 PM](https://user-images.githubusercontent.com/45575454/101387041-ee075680-388b-11eb-9239-61ac3514ab3f.png)|![Screen Shot 2020-12-07 at 12 57 46 PM](https://user-images.githubusercontent.com/45575454/101387042-ee075680-388b-11eb-9cea-9b3690daaa6f.png)|![Screen Shot 2020-12-07 at 12 57 39 PM](https://user-images.githubusercontent.com/45575454/101387044-ee9fed00-388b-11eb-85f4-a7db71ef47d3.png)|![Screen Shot 2020-12-07 at 12 57 31 PM](https://user-images.githubusercontent.com/45575454/101387045-ee9fed00-388b-11eb-934b-c120f551c1c7.png)|![Screen Shot 2020-12-07 at 12 57 27 PM](https://user-images.githubusercontent.com/45575454/101387046-ee9fed00-388b-11eb-8fb4-1d1eb12979ce.png)

### Code Documentation Updates
- [ ] Add or update code comments at the top of the class, module, and/or component.

### Storybook Story
*For Frontend (Presentationa) Components*
* [ ] Add a [Storybook](https://github.com/department-of-veterans-affairs/caseflow/wiki/Documenting-React-Components-with-Storybook) file alongside the component file (e.g. create `MyComponent.stories.js` alongside `MyComponent.jsx`)
* [ ] Give it a title that reflects the component's location within the overall Caseflow hierarchy
* [ ] Write a separate story (within the same file) for each discrete variation of the component

![Screen Shot 2020-12-07 at 1 06 58 PM](https://user-images.githubusercontent.com/45575454/101387900-23f90a80-388d-11eb-8157-767303f43fe1.png)

* Adds CavcCorrespondenceMailTask  (#15692)

Resolves #15239 

### Description
Creates the CavcCorrespondenceMailTask & its behavior.

### Acceptance Criteria
- [ ] work behind the feature toggle: cavc_remand
- [ ] Add task should be accessible to the Mail Team
- [ ] accessible to the following user groups: Mail Team
- [ ] Select Correspondence Type drop down includes CAVC Correspondence
- [ ] requires a CAVC Remand appeal with an open CavcTask
- [ ] Mail Team users have no actions on the created tasks
- [ ] Cavc Lit Admins can act on Organization task or any User task
- [ ] Cavc Lit user can act on a user task assigned to themselves
- [ ]  Verify CavcRemandProcessedLetterResponseWindowTask status does not change.

### Testing Plan
  1. Reset the database with `make reset`
  2. Create a Cavc Appeal at CavcResponseWindow
```ruby
appeal = FactoryBot.create(:appeal, :cavc_response_window_open)
appeal.reload.treee
appeal.uuid
FeatureToggle.disable!(:cavc_remand)
```
  3. Load up [caseflow](http://localhost:3000/test/users) and sign in as Jolly Postman
  4. Navigate to the appeal you created
  5. Click `+ Add a new task`
   - [x] CAVC Correspondence is not available
  6. Enable the flag: `FeatureToggle.enable!(:cavc_remand)`
  7. Reload and Click `+ Add a new task`
   - [x] CAVC Correspondence is available
   - [x] Creating a CAVC Correspondence task autoassigns to CAVC Lit Support
   - [x] No actions are available on the task for the mail user
  8. Change to be a CAVC Lit Support admin user
  9. Navigate to the appeal
   - [x] Check the actions exist and do what you want (TK)
  10. Create another appeal & mail task
  11. Navigate to the appeal and assign it to a Cavc Lit support user
   - [x] confirm you have admin have actions on the user task
  12. Sign in as a Cavc Lit user you didn't assign the task to 
   - [x] No actions are available
  13. Sign in as the assigned Cavc Lit user
   - [x] Check the actions exist and do what you want (TK)

Expected Behavior on Actions:
  - [x] Confirm none of this affects the CavcResponseWindowTask status!
  - [x] Change Task Type: Cancels the CavcCorrespondence subtree, creates a sibling of the new type
  - [x] (Re)Assign to person: creates a user task
  - [x] Place on hold: places a hold
  - [x] Mark task complete: completes the subtree
  - [x] Cancel task: cancels the subtree
 
### Documentation Updates
- [x] Add or update code comments at the top of the class, module, and/or component.

### UI Changes
![image](https://user-images.githubusercontent.com/6129479/102548342-840b6000-4088-11eb-99ed-3aa1c1e6968b.png)

* Update engineering issue template with impact (#15720)

### Description
Adds and "impact" section to engineering task issues so that teams can more easily prioritize tech debt or quickly provide justification to stakeholders for pulling these tickets into sprints.

* CAVC extension request action (#15697)

* Modal creation speedrun results

* Modal cleanup

* Add custom on hold duration field

* Start js tests for modal

* Undo debugging changes

* Add cavc rextension request action and modal cancel functionality

* Fix tests

* Update words

* Do not build components we won't actually render

* Add error handling to the modal

* Add submit request and error handling

* Actually create hold for granted extension requests

* do not add task action yet

* Add tasks to record grant and denials of extension requests

* Remove focus

* Full grant/deny extension walkthrough changes

* Update snapshots and add task action

* Fix test

* Coverage

* Apply suggestions from code review

Co-authored-by: Kat Tipton <kat@navapbc.com>

* Fix test to check for specific error

* Fix copy in snapshots

* Add actions to CavcRemandProcessedLetterResponseWindowTask (#15694)

* Add actions to CavcRemandProcessedLetterResponseWindowTask

* No dupe hearings tasks

* Verify schedule hearing uniq only from cavc creation

* Allow users with CavcRemandProcessedLetterResponseWindowTasks assigned to them create admin actions and add verify_org_task_uniq tests

* Start working on tests

* Spacing

* Fix tests

* Shuffle tests, code climate, fix tests

* Fix merge

* Add extension feature requests

* Apply suggestions from code review

Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>

* More code review suggestions!

Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>

* cc

Co-authored-by: Kat Tipton <kat@navapbc.com>
Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>

* CASEFLOW-126 #done Copy AOD state to CAVC Remand Appeal (#15717)

* Add JudgeTeam admin method (#15696)

Resolves #13993

### Description
We already [do not allow](https://github.com/department-of-veterans-affairs/caseflow/blob/fafdf207a62977510b3e5a2a7ce542885f8f6edc/client/app/queue/OrganizationUsers.jsx#L253) users via FE code the ability to add/remove admin status for judge teams once they are created (check below screenshot).

However when queried, we want a JudgeTeam to be aware that there is only a single admin for the team, and that admin is the judge lead. In addition, we would like to add BE validation to prevent additional admins being added to JudgeTeams.

![Screen Shot 2020-12-15 at 10 05 39 AM](https://user-images.githubusercontent.com/18618189/102250729-e5d59980-3ed1-11eb-9349-01059a54b33d.png)

### Acceptance Criteria
- [ ] Tests pass

* create a virtual hearing conference id sequence (#15713)

* new sequence for virtual hearing conference ids

* service to return virtual hearing conference ids

* these updates are unrelated to my change...

...but were neglected when committing a past migration

* add IF EXISTS to down

* don't use subject to call the tested method

* test for sequence cycle

* create the sequence if it doesn't exist

The sequence is created by a migration, but it isn't recorded in
the schema. This means that databases created with db:schema:load
won't include the sequence. We call this method before accessing
the sequence to make sure it exists.

* Create virtual hearing url service (#15714)

* git ignore credstash.log

* new service for generating virtual hearing links

* don't try to assign a value to presence

* fail if host & path aren't provided

* test for the link service

* initialize @conference_id to nil to quiet reek

* Add pre-AMA date error validation to Edit NOD Date Modal (#15725)

* Parse BGS death date format and coerce to iso8601 (#15730)

### Description
When a veteran has a date of death, this data may be returned to the frontend directly from a BGS call, or from the cached value in the Postgres `veterans` table. BGS uses `mm/dd/yyyy`-formatted strings, whereas ActiveRecord provides `Date` objects from Postgres which get automatically serialized in ISO-8601 `yyyy/mm/dd`.

This PR ensures that we use ISO-8601 whenever possible (including in the frontend) and parses the date format coming from BGS.

### Acceptance Criteria
- [ ] Code compiles correctly

### Testing Plan
1. Go to any case details page with a veteran without a date of death
    - Normally `appeal = Appeal.last` is fine
    - Get `appeal.uuid` and point your browser to `/queue/appeals/{UUID}`
2. At `app/models/veteran.rb:130`, append `.tap { |h| h[:date_of_death] = "12/21/2020" }`
    - This ensures that the data from "BGS" comes with a DoD.
3. Refresh the page and confirm DoD shows properly
4. In Rails console, `appeal.veteran.update!(date_of_death: "2020-12-22")`
5. Refresh the page and confirm DoD shows the changed value properly

### User Facing Changes
Before, when attempting to render a date in the wrong format:
<img width="668" src="https://user-images.githubusercontent.com/282869/102925854-239e6900-4462-11eb-9c08-14813f1c7a2b.png">

After:
<img width="667" src="https://user-images.githubusercontent.com/282869/102925875-2b5e0d80-4462-11eb-835c-0151eb8fc75d.png">

* New edit NOD metadata table (#15705)

Resolves #15511 

### Description
Model and migration for edit NOD date metadata. Enables storage of NOD date changes.

### Acceptance Criteria
- [x] Code compiles correctly

### Database Changes

* [x] Timestamps (created_at, updated_at) for new tables
* [x] Column comments updated
* [x] Have your migration classes inherit from `Caseflow::Migration`, especially when adding indexes (use `add_safe_index`)
* [x] Verify that `migrate:rollback` works as desired ([`change` supported functions](https://edgeguides.rubyonrails.org/active_record_migrations.html#using-the-change-method))
* [x] Query profiling performed (eyeball Rails log, check bullet and fasterer output)
* [x] Appropriate indexes added (especially for foreign keys, polymorphic columns, unique constraints, and Rails scopes)
* [x] DB schema docs updated with `make docs` (after running `make migrate`)
* [x] #appeals-schema notified with summary and link to this PR
* [x] Any non-obvious semantics or logic useful for interpreting database data is documented at [Caseflow Data Model and Dictionary](https://github.com/department-of-veterans-affairs/caseflow/wiki/Caseflow-Data-Model-and-Dictionary)

* CASEFLOW-486 Add judges and attorneys to those that can edit DOD date (#15731)

Description
* The ability to edit NOD dates was previously restricted to BvaIntake.singleton.users and ClerkOfTheBoard.singletone.users. 
* Permissions have been expanded to include attorneys and judges.
* Displaying the "Edit NOD Date" link in the Queue Timeline section needs to be restricted to attorneys in addition to BvaIntake.singleton.users and ClerkOfTheBoard.singletone.users.

Acceptance Criteria
 * Code compiles correctly
 * NOD exists and the "Edit NOD Date" link displays for Attorneys, Judges, ClerkOfTheBoard, and BvaIntake users.
  * NOD exists and the "Edit NOD Date" link does not display for other user types.
 
Testing Plan
* Login to Queue as each of the following:  COB_User (Clerk of the Board user), BVAOSHOWAL (judge), BVACASPER1 (attorney), BVASHAW (Intake)
* Make sure "edit_nod_date" featuretoggle is enabled.
* Choose an appeal that has an existing NOD (123456789) and confirm that the link displays.
* Switch user to someone without permission (BVAGBLACK)
Choose an appeal that has an existing NOD and confirm that the link does not display (123456789)

User Facing Changes
* See screenshots from [#15672 ](#15672)
* No additional changes from this PR

* Integrate new virtual hearing link generation (#15732)

* create migration to add two new fields to virtual hearing: host_link and guest_link

* modify create_conference_job to use new link generation; add new method to linkservice class; add new logic to virtual hearing

* ensure delete_conferences_job won't try to delete this type of virtual hearing and virtual hearing checker will not flag this virtual hearing as stuck

* inherit from Caseflow::Migration

* tests for create_conference_job and virtual_hearing_repository

* fix some existing tests

* remove unused serialized variable

* small styling and codeclimate fixes

* changes based on feedback

* some further changes based on feedback

* add new test link

* add schema and a small change

* add the new fields to factory

* discard job when errors are encountered and fix a method call

* add env variables for development

* add new tests for test link and status

* fix a failing test

* some tests for checker

* remove focus true

* refactor virtual hearing status

* syntax fixes based on feedback

Co-authored-by: Tomas Apodaca <45415133+tomas-nava@users.noreply.github.com>

* Restructured IntakeFrame (#15708)

Enabler for #15566

### Description
This restructures `IntakeFrame` to utilize `IntakeLayout`, allowing us to better encapsulate the steps and better handle button behavior.

There should be no functional differences between this and `master`.

### Acceptance Criteria
- [ ] Code compiles correctly
- [ ] Everything in Intake works just as it did previously

* check user that updated virtual hearing for featuretoggle (#15734)

Co-authored-by: Tomas Apodaca <45415133+tomas-nava@users.noreply.github.com>

* Intake | Docket Change | Inputting docket switch information (Grant)  (#15729)

Connects  #15097

### Description
As a BVA Attorney at the Office of the Clerk of the Board, I need a way to enter the necessary information from the Veteran's request to switch dockets, so that I best represent the veteran's request to switch dockets.

### Acceptance Criteria
- [x] Please put this work behind the feature toggle: `docket_change`
- [x] This feature should be accessible to the following user groups: `ClerkOfTheBoard`
- [x] When a user selects "Switch docket" from their action drop-down menu, they should be taken to this screen
- [x] Please format the header and instructions as shown in the designs
- [x] The user should see a progress bar on the top as shown in the designs (this is the first step) 
- [x] The user should be able to select a date in the receipt date field (following the existing date selector component)
- [x] The user should be able to select "grant all issues" or "grant a partial switch"
- [x] "Grant a partial switch" should have the following help text: "e.g. if the Board is only granting a few issues"
- [x] There should be 3 docket options (Direct Review, Evidence Submission, Hearing) – please disable the current docket type (for e.g. if the current docket type is Hearing, the user should only be able to select Direct Review or Evidence Submission)
- [x] If a user selects "Grant a partial switch", they should be able to see a list of issues and select them (multi-select checkboxes) 
- [x] All fields are required and once the user has made all their selections, the continue button should become active
- [x] Selecting "cancel" will take the user back to the Case Details page
- [x] Implement form validation using `react-hook-form` (see prev docket change forms for ref)
- [ ] Include screenshot(s) in the Github issue if there are front-end changes
- [x] Include Jest tests
- [x] Include Storybook story

### User Facing Changes
**Empty state**
<img width="1668" alt="Screen Shot 2020-12-21 at 9 27 50 PM" src="https://user-images.githubusercontent.com/23080951/102912461-6e60b680-444b-11eb-848f-b28312bd79d5.png">

**Full Switch**
<img width="1679" alt="Screen Shot 2020-12-21 at 9 27 11 PM" src="https://user-images.githubusercontent.com/23080951/102912477-76b8f180-444b-11eb-96e5-e29df35a36a9.png">

**Partial Switch**
<img width="1672" alt="Screen Shot 2020-12-21 at 9 27 31 PM" src="https://user-images.githubusercontent.com/23080951/102912494-7ddfff80-444b-11eb-8bcd-a8f18703a4a9.png">


### Storybook Story
*For Frontend (Presentationa) Components*
* [ ] Add a [Storybook](https://github.com/department-of-veterans-affairs/caseflow/wiki/Documenting-React-Components-with-Storybook) file alongside the component file (e.g. create `MyComponent.stories.js` alongside `MyComponent.jsx`)
* [ ] Give it a title that reflects the component's location within the overall Caseflow hierarchy
* [ ] Write a separate story (within the same file) for each discrete variation of the component

* Non-Veteran Claimants | Adding "Claimant not listed" Option (#15724)

Connects #13964

### Description
This adds a "Claimant not listed" radio option to `SelectClaimant` component. This is limited to Appeals, and only if `non_veteran_claimants` feature toggle is enabled.

### Acceptance Criteria
- [ ] Code compiles correctly

* Add new tables for unrecognized appellants and their POAs (#15710)

* Add new tables for unrecognized appellants and their POAs

* Fix a few linter complaints

* Fix typo in comment

* Remove extraneous unrecognized POAs table

* Match OtherClaimant behavior to that of other claimants

* Rename entity to party

* Use FullName utility rather than reinvent the wheel

* Tweak database comment

* Add factories and specs

* Address code climate complaints

* Fix feature tests

* Use rails association for unrecognized appellant

Co-authored-by: Sally Maki <sallymaki@gmail.com>

Co-authored-by: Hunter Schallhorn <45575454+hschallhorn@users.noreply.github.com>
Co-authored-by: Kat Tipton <kat@navapbc.com>
Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>
Co-authored-by: Alec Spottswood <ajspottswood@gmail.com>
Co-authored-by: Tomas Apodaca <45415133+tomas-nava@users.noreply.github.com>
Co-authored-by: Meckila <68879427+meckilabritt-navapbc@users.noreply.github.com>
Co-authored-by: YANG YANG <yangyang@navapbc.com>
Co-authored-by: Brian Gantick <briangantick@navapbc.com>
Co-authored-by: pbradin <pbradin@tistatech.com>
Co-authored-by: Rubaiyat Rashid <Rubaiyat.Rashid51@myhunter.cuny.edu>
Co-authored-by: jcq <2581274+jcq@users.noreply.github.com>
Co-authored-by: Sandra Jones <sjones@tistatech.com>
Co-authored-by: Sally Maki <sallymaki@gmail.com>
leikkisa added a commit that referenced this issue Jan 5, 2021
* Added IntakeLayout;
Refactored IntakeFrame to use IntakeLayout;

* refactored IntakeProgressBar;

* For now, pass along `history` prop to `ReviewButtons`

* added history prop to a few more items in IntakeFrame

* added AddClaimantForm & stories;

* added `ADD_CLAIMANT` to `PAGE_PATHS` constants;
added AddClaimantPage & stories;
added AddClaimantButtons;
moved form schema, etc to intake/addClaimant/utils.js;

* updated IntakeFrame & IntakeProgressBar to handle add claimant section

* Selectively show cavc decision types and remand subtypes based on feature toggles (#15677)

Followup to #15597

### Description
Does not show options for mdr, death dismissal, or straight reversal unless those features are enabled.

### Acceptance Criteria
- [x] MDR can only be selected if the feature toggle is on (mdr_cavc_remand)
- [x] Death dismissal can only be selected if the feature toggle is on (dismissal_cavc_remand)
- [x] Straight reversal can only be selected if the feature toggle is on (reversal_cavc_remand)

### Testing Plan
1. Enable cavc_remand feature toggle(`FeatureToggle.enable!(:cavc_remand)`)
1. Find a dispatched appeal (search for vet 500000000)
1. Click "+ Add CAVC Remand"
1. Confirm mrd, death dismissal, and straight reversal are not available to be selected
1. Enable mdr_cavc_remand feature toggle(`FeatureToggle.enable!(:mdr_cavc_remand)`)
1. Confirm mdr is now selectable
1. Repeat with `dismissal_cavc_remand` and `reversal_cavc_remand`

### User Facing Changes
 - [x] Screenshots of UI changes added to PR & Original Issue

 BEFORE|AFTER|mdr_cavc_remand enabled|dismissal_cavc_remand enabled|reversal_cavc_remand enabled
---|---|---|---|---
![Screen Shot 2020-12-07 at 12 58 24 PM](https://user-images.githubusercontent.com/45575454/101387041-ee075680-388b-11eb-9239-61ac3514ab3f.png)|![Screen Shot 2020-12-07 at 12 57 46 PM](https://user-images.githubusercontent.com/45575454/101387042-ee075680-388b-11eb-9cea-9b3690daaa6f.png)|![Screen Shot 2020-12-07 at 12 57 39 PM](https://user-images.githubusercontent.com/45575454/101387044-ee9fed00-388b-11eb-85f4-a7db71ef47d3.png)|![Screen Shot 2020-12-07 at 12 57 31 PM](https://user-images.githubusercontent.com/45575454/101387045-ee9fed00-388b-11eb-934b-c120f551c1c7.png)|![Screen Shot 2020-12-07 at 12 57 27 PM](https://user-images.githubusercontent.com/45575454/101387046-ee9fed00-388b-11eb-8fb4-1d1eb12979ce.png)

### Code Documentation Updates
- [ ] Add or update code comments at the top of the class, module, and/or component.

### Storybook Story
*For Frontend (Presentationa) Components*
* [ ] Add a [Storybook](https://github.com/department-of-veterans-affairs/caseflow/wiki/Documenting-React-Components-with-Storybook) file alongside the component file (e.g. create `MyComponent.stories.js` alongside `MyComponent.jsx`)
* [ ] Give it a title that reflects the component's location within the overall Caseflow hierarchy
* [ ] Write a separate story (within the same file) for each discrete variation of the component

![Screen Shot 2020-12-07 at 1 06 58 PM](https://user-images.githubusercontent.com/45575454/101387900-23f90a80-388d-11eb-8157-767303f43fe1.png)

* Adds CavcCorrespondenceMailTask  (#15692)

Resolves #15239 

### Description
Creates the CavcCorrespondenceMailTask & its behavior.

### Acceptance Criteria
- [ ] work behind the feature toggle: cavc_remand
- [ ] Add task should be accessible to the Mail Team
- [ ] accessible to the following user groups: Mail Team
- [ ] Select Correspondence Type drop down includes CAVC Correspondence
- [ ] requires a CAVC Remand appeal with an open CavcTask
- [ ] Mail Team users have no actions on the created tasks
- [ ] Cavc Lit Admins can act on Organization task or any User task
- [ ] Cavc Lit user can act on a user task assigned to themselves
- [ ]  Verify CavcRemandProcessedLetterResponseWindowTask status does not change.

### Testing Plan
  1. Reset the database with `make reset`
  2. Create a Cavc Appeal at CavcResponseWindow
```ruby
appeal = FactoryBot.create(:appeal, :cavc_response_window_open)
appeal.reload.treee
appeal.uuid
FeatureToggle.disable!(:cavc_remand)
```
  3. Load up [caseflow](http://localhost:3000/test/users) and sign in as Jolly Postman
  4. Navigate to the appeal you created
  5. Click `+ Add a new task`
   - [x] CAVC Correspondence is not available
  6. Enable the flag: `FeatureToggle.enable!(:cavc_remand)`
  7. Reload and Click `+ Add a new task`
   - [x] CAVC Correspondence is available
   - [x] Creating a CAVC Correspondence task autoassigns to CAVC Lit Support
   - [x] No actions are available on the task for the mail user
  8. Change to be a CAVC Lit Support admin user
  9. Navigate to the appeal
   - [x] Check the actions exist and do what you want (TK)
  10. Create another appeal & mail task
  11. Navigate to the appeal and assign it to a Cavc Lit support user
   - [x] confirm you have admin have actions on the user task
  12. Sign in as a Cavc Lit user you didn't assign the task to 
   - [x] No actions are available
  13. Sign in as the assigned Cavc Lit user
   - [x] Check the actions exist and do what you want (TK)

Expected Behavior on Actions:
  - [x] Confirm none of this affects the CavcResponseWindowTask status!
  - [x] Change Task Type: Cancels the CavcCorrespondence subtree, creates a sibling of the new type
  - [x] (Re)Assign to person: creates a user task
  - [x] Place on hold: places a hold
  - [x] Mark task complete: completes the subtree
  - [x] Cancel task: cancels the subtree
 
### Documentation Updates
- [x] Add or update code comments at the top of the class, module, and/or component.

### UI Changes
![image](https://user-images.githubusercontent.com/6129479/102548342-840b6000-4088-11eb-99ed-3aa1c1e6968b.png)

* added support for `nonVeteranClaimants` feature toggle to intake

* updated SelectClaimant to render differently with nonVeteranClaimants feature toggle set;
added story for SelectClaimant;

* Updated SelectClaimant;

* ensure we pass featureToggles in `SelectClaimantConnected`

* Update engineering issue template with impact (#15720)

### Description
Adds and "impact" section to engineering task issues so that teams can more easily prioritize tech debt or quickly provide justification to stakeholders for pulling these tickets into sprints.

* CAVC extension request action (#15697)

* Modal creation speedrun results

* Modal cleanup

* Add custom on hold duration field

* Start js tests for modal

* Undo debugging changes

* Add cavc rextension request action and modal cancel functionality

* Fix tests

* Update words

* Do not build components we won't actually render

* Add error handling to the modal

* Add submit request and error handling

* Actually create hold for granted extension requests

* do not add task action yet

* Add tasks to record grant and denials of extension requests

* Remove focus

* Full grant/deny extension walkthrough changes

* Update snapshots and add task action

* Fix test

* Coverage

* Apply suggestions from code review

Co-authored-by: Kat Tipton <kat@navapbc.com>

* Fix test to check for specific error

* Fix copy in snapshots

* Add actions to CavcRemandProcessedLetterResponseWindowTask (#15694)

* Add actions to CavcRemandProcessedLetterResponseWindowTask

* No dupe hearings tasks

* Verify schedule hearing uniq only from cavc creation

* Allow users with CavcRemandProcessedLetterResponseWindowTasks assigned to them create admin actions and add verify_org_task_uniq tests

* Start working on tests

* Spacing

* Fix tests

* Shuffle tests, code climate, fix tests

* Fix merge

* Add extension feature requests

* Apply suggestions from code review

Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>

* More code review suggestions!

Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>

* cc

Co-authored-by: Kat Tipton <kat@navapbc.com>
Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>

* CASEFLOW-126 #done Copy AOD state to CAVC Remand Appeal (#15717)

* Add JudgeTeam admin method (#15696)

Resolves #13993

### Description
We already [do not allow](https://github.com/department-of-veterans-affairs/caseflow/blob/fafdf207a62977510b3e5a2a7ce542885f8f6edc/client/app/queue/OrganizationUsers.jsx#L253) users via FE code the ability to add/remove admin status for judge teams once they are created (check below screenshot).

However when queried, we want a JudgeTeam to be aware that there is only a single admin for the team, and that admin is the judge lead. In addition, we would like to add BE validation to prevent additional admins being added to JudgeTeams.

![Screen Shot 2020-12-15 at 10 05 39 AM](https://user-images.githubusercontent.com/18618189/102250729-e5d59980-3ed1-11eb-9349-01059a54b33d.png)

### Acceptance Criteria
- [ ] Tests pass

* fuller handling of nonVeteranClaimants feature toggle in SelectClaimant;

* added initial feature test for new Add Claimant functionality

* added stories for SelectClaimant based on feature toggle

* create a virtual hearing conference id sequence (#15713)

* new sequence for virtual hearing conference ids

* service to return virtual hearing conference ids

* these updates are unrelated to my change...

...but were neglected when committing a past migration

* add IF EXISTS to down

* don't use subject to call the tested method

* test for sequence cycle

* create the sequence if it doesn't exist

The sequence is created by a migration, but it isn't recorded in
the schema. This means that databases created with db:schema:load
won't include the sequence. We call this method before accessing
the sequence to make sure it exists.

* Create virtual hearing url service (#15714)

* git ignore credstash.log

* new service for generating virtual hearing links

* don't try to assign a value to presence

* fail if host & path aren't provided

* test for the link service

* initialize @conference_id to nil to quiet reek

* Add pre-AMA date error validation to Edit NOD Date Modal (#15725)

* Parse BGS death date format and coerce to iso8601 (#15730)

### Description
When a veteran has a date of death, this data may be returned to the frontend directly from a BGS call, or from the cached value in the Postgres `veterans` table. BGS uses `mm/dd/yyyy`-formatted strings, whereas ActiveRecord provides `Date` objects from Postgres which get automatically serialized in ISO-8601 `yyyy/mm/dd`.

This PR ensures that we use ISO-8601 whenever possible (including in the frontend) and parses the date format coming from BGS.

### Acceptance Criteria
- [ ] Code compiles correctly

### Testing Plan
1. Go to any case details page with a veteran without a date of death
    - Normally `appeal = Appeal.last` is fine
    - Get `appeal.uuid` and point your browser to `/queue/appeals/{UUID}`
2. At `app/models/veteran.rb:130`, append `.tap { |h| h[:date_of_death] = "12/21/2020" }`
    - This ensures that the data from "BGS" comes with a DoD.
3. Refresh the page and confirm DoD shows properly
4. In Rails console, `appeal.veteran.update!(date_of_death: "2020-12-22")`
5. Refresh the page and confirm DoD shows the changed value properly

### User Facing Changes
Before, when attempting to render a date in the wrong format:
<img width="668" src="https://user-images.githubusercontent.com/282869/102925854-239e6900-4462-11eb-9c08-14813f1c7a2b.png">

After:
<img width="667" src="https://user-images.githubusercontent.com/282869/102925875-2b5e0d80-4462-11eb-835c-0151eb8fc75d.png">

* New edit NOD metadata table (#15705)

Resolves #15511 

### Description
Model and migration for edit NOD date metadata. Enables storage of NOD date changes.

### Acceptance Criteria
- [x] Code compiles correctly

### Database Changes

* [x] Timestamps (created_at, updated_at) for new tables
* [x] Column comments updated
* [x] Have your migration classes inherit from `Caseflow::Migration`, especially when adding indexes (use `add_safe_index`)
* [x] Verify that `migrate:rollback` works as desired ([`change` supported functions](https://edgeguides.rubyonrails.org/active_record_migrations.html#using-the-change-method))
* [x] Query profiling performed (eyeball Rails log, check bullet and fasterer output)
* [x] Appropriate indexes added (especially for foreign keys, polymorphic columns, unique constraints, and Rails scopes)
* [x] DB schema docs updated with `make docs` (after running `make migrate`)
* [x] #appeals-schema notified with summary and link to this PR
* [x] Any non-obvious semantics or logic useful for interpreting database data is documented at [Caseflow Data Model and Dictionary](https://github.com/department-of-veterans-affairs/caseflow/wiki/Caseflow-Data-Model-and-Dictionary)

* CASEFLOW-486 Add judges and attorneys to those that can edit DOD date (#15731)

Description
* The ability to edit NOD dates was previously restricted to BvaIntake.singleton.users and ClerkOfTheBoard.singletone.users. 
* Permissions have been expanded to include attorneys and judges.
* Displaying the "Edit NOD Date" link in the Queue Timeline section needs to be restricted to attorneys in addition to BvaIntake.singleton.users and ClerkOfTheBoard.singletone.users.

Acceptance Criteria
 * Code compiles correctly
 * NOD exists and the "Edit NOD Date" link displays for Attorneys, Judges, ClerkOfTheBoard, and BvaIntake users.
  * NOD exists and the "Edit NOD Date" link does not display for other user types.
 
Testing Plan
* Login to Queue as each of the following:  COB_User (Clerk of the Board user), BVAOSHOWAL (judge), BVACASPER1 (attorney), BVASHAW (Intake)
* Make sure "edit_nod_date" featuretoggle is enabled.
* Choose an appeal that has an existing NOD (123456789) and confirm that the link displays.
* Switch user to someone without permission (BVAGBLACK)
Choose an appeal that has an existing NOD and confirm that the link does not display (123456789)

User Facing Changes
* See screenshots from [#15672 ](#15672)
* No additional changes from this PR

* added featureToggles to connect fns for SelectClaimant for HLRs and SCs

* slight tweaks to SelectClaimant

* linting

* Integrate new virtual hearing link generation (#15732)

* create migration to add two new fields to virtual hearing: host_link and guest_link

* modify create_conference_job to use new link generation; add new method to linkservice class; add new logic to virtual hearing

* ensure delete_conferences_job won't try to delete this type of virtual hearing and virtual hearing checker will not flag this virtual hearing as stuck

* inherit from Caseflow::Migration

* tests for create_conference_job and virtual_hearing_repository

* fix some existing tests

* remove unused serialized variable

* small styling and codeclimate fixes

* changes based on feedback

* some further changes based on feedback

* add new test link

* add schema and a small change

* add the new fields to factory

* discard job when errors are encountered and fix a method call

* add env variables for development

* add new tests for test link and status

* fix a failing test

* some tests for checker

* remove focus true

* refactor virtual hearing status

* syntax fixes based on feedback

Co-authored-by: Tomas Apodaca <45415133+tomas-nava@users.noreply.github.com>

* initial work on Jest tests for SelectClaimant w/ nonVeteranClaimant
(based off code from tests written for death dismissals, where code has yet to be merged; currently those tests are commented out here)

* updated CancelButton to allow for additional props to be passed along to Button

* Updated AddClaimantButtons;
updated AddClaimantPage to support "Back" button as well as cancel;
updated AddClaimantPage stories to use MemoryRouter instead of StaticRouter;

* updated submit handler for review page to account for adding new claimant

* Restructured IntakeFrame (#15708)

Enabler for #15566

### Description
This restructures `IntakeFrame` to utilize `IntakeLayout`, allowing us to better encapsulate the steps and better handle button behavior.

There should be no functional differences between this and `master`.

### Acceptance Criteria
- [ ] Code compiles correctly
- [ ] Everything in Intake works just as it did previously

* added copy to AddClaimantPage

* added `strongLabel` to `relationship` field on AddClaimantForm

* added testUtils.js in test/app/intake
(sets up barebones providers to allow testing of connected components)

* updated AddClaimantForm stories to account for need for form context

* added initial Jest test structure for AddClaimantForm and AddClaimantPage

* linting

* linting

* linting

* Add navigation to new page to feature test

Co-authored-by: Hunter Schallhorn <45575454+hschallhorn@users.noreply.github.com>
Co-authored-by: Kat Tipton <kat@navapbc.com>
Co-authored-by: Yoom Lam <Dung.Lam1@va.gov>
Co-authored-by: Alec Spottswood <ajspottswood@gmail.com>
Co-authored-by: Tomas Apodaca <45415133+tomas-nava@users.noreply.github.com>
Co-authored-by: Meckila <68879427+meckilabritt-navapbc@users.noreply.github.com>
Co-authored-by: YANG YANG <yangyang@navapbc.com>
Co-authored-by: Brian Gantick <briangantick@navapbc.com>
Co-authored-by: pbradin <pbradin@tistatech.com>
Co-authored-by: Rubaiyat Rashid <Rubaiyat.Rashid51@myhunter.cuny.edu>
Co-authored-by: Sally Maki <sallymaki@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Type: New Development New feature development
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants