deployed/20210518_150410

Commit: d5451da

Death dismissal task blocking tech spec (#16202)

Resolves Caseflow-1328

Description

Add tech spec for Death Dismissal task blocking

---

Commit: d031ec2

Show unlisted claimant option for veterans without relations (#16252)

Resolves CASEFLOW-1550

Description

This PR allows intake users with non_veteran_claimants enabled to select the "Claimant not listed" option when the veteran has no known dependent relationships.

Rutvi has provided an alternate design with new copy, that makes this read less awkwardly, which I'll defer to a later PR in the interest of getting this one deployed to unblock users.

Acceptance Criteria

• Code compiles correctly

Testing Plan

1. New feature test added

User Facing Changes

Before:

After:

---

Commit: fd8e619

Base Timeslot Visibility on hearingDay Type (CASEFLOW-1504) (#16241)

Resolves CASEFLOW-1504

Description

This makes the Timeslots only visible when scheduling for a virtual hearing day (requestType === 'R').

Acceptance Criteria

• Time slot buttons are only displayed when a user chooses a Virtual hearing day from the Hearing Date dropdown (request_type === "R")
• Time slot buttons are not displayed when a central (requestType === 'C') or Video (requestType === 'V') hearingDay is selected.

Reviewer Notes

The ACs of this PR are captured in the two lines of JS. Most of the work was changing the rspec tests:

• Create virtual hearing_days (we weren't doing this in build_hearsched).
• Schedule using all three options
  1. Time dropdown for video/central hearing days.
  2. Timeslot button for virtual hearing days.
  3. Custom time modal for virtual hearing days.

Testing Plan

1. Go to the scheduling screen for a veteran.
2. Choose any RO that is not the "Virtual Hearings" RO.
3. You should not see the timeslots, even if the hearing type dropdown is set to "Virtual".
4. Change the RO to the "Virtual Hearings" RO.
5. You should now see the timeslots whether you have "Virtual" or "Video" hearing type selected.

---

Commit: c3da79b

Add a review and confirmation page for substitution (#16214)

Resolves Jira issue 1082

Description

This PR adds a review and confirm page where the user can confirm that they have selected a substitute appellant. The user will be able to see the appellant’s information and information the tasks identified for creation. This PR is dependent on PR #16192

Testing Plan

• Navigate to a dispatched appeal where the appeal’s veteran has a date of death
• Create a substitute appeal and ensure that the new appellant’s information (name, relationship, and substitution date) display correctly
• Also, ensure that all automated tests pass

Acceptance Criteria

• Code compiles correctly
• the user is able to see the following on the confirmation page:
• Appellant Name
• Relationship to Veteran
• Granted Substitution Date
• Tasks identified for creation (if applicable)
• if an evidence submission task was selected, the window end date should be calculated with the following formula
• Original Evidence Submission Window End Date (actual) - Appellant Date of Death = number of days remaining + Granted Substitution Date = substitution evidence submission end date

Testing Plan

• Navigate to a dispatched appeal where the appeal’s veteran has a date of death
• Create a substitute appeal and ensure that the new appellant’s information (name, relationship, and substitution date) display correctly
• Also, ensure that all automated tests pass

deployed/20210517_150427

Commit: c3da79b

Add a review and confirmation page for substitution (#16214)

Resolves Jira issue 1082

Description

This PR adds a review and confirm page where the user can confirm that they have selected a substitute appellant. The user will be able to see the appellant’s information and information the tasks identified for creation. This PR is dependent on PR #16192

Testing Plan

• Navigate to a dispatched appeal where the appeal’s veteran has a date of death
• Create a substitute appeal and ensure that the new appellant’s information (name, relationship, and substitution date) display correctly
• Also, ensure that all automated tests pass

Acceptance Criteria

• Code compiles correctly
• the user is able to see the following on the confirmation page:
• Appellant Name
• Relationship to Veteran
• Granted Substitution Date
• Tasks identified for creation (if applicable)
• if an evidence submission task was selected, the window end date should be calculated with the following formula
• Original Evidence Submission Window End Date (actual) - Appellant Date of Death = number of days remaining + Granted Substitution Date = substitution evidence submission end date

Testing Plan

• Navigate to a dispatched appeal where the appeal’s veteran has a date of death
• Create a substitute appeal and ensure that the new appellant’s information (name, relationship, and substitution date) display correctly
• Also, ensure that all automated tests pass

---

Commit: 2d257b7

Fix treee renderer: CLO_DATE, ASSGN_DATE (#16249)

---

Commit: 4b8a298

Revert Video total_slots default to 12 and Central total_slots default to 10 (#16248)

Description

This PR reverts a misunderstanding (that video and central should also have 8 slots by default) in this PR.

As per the comment here, Central and Video HearingDays should continue to have 10 and 12 slots by default. This PR sets that and corrects the tests that depend on that.

Acceptance Criteria

For HearingDays that have number_of_slots == nil nothing stored in the db.

• Central HearingDays (request_type: "C") should have 10 total_slots.
• Video HearingDays (request_type: "V") should have 12 total_slots.
• Also, Virtual HearingDays (request_type: "R") should continue to have 8 total_slots.

Testing Plan

# See the request_type and total_slots for every hearing day, assuming you have not set
# any `number_of_slots` you should get this output
# [[10, "C"], [12, "V"], [8, "R"]]
HearingDay.all.map { |h| [h.total_slots, h.request_type] }.uniq

deployed/20210514_160751

Commit: 4b8a298

Revert Video total_slots default to 12 and Central total_slots default to 10 (#16248)

Description

This PR reverts a misunderstanding (that video and central should also have 8 slots by default) in this PR.

As per the comment here, Central and Video HearingDays should continue to have 10 and 12 slots by default. This PR sets that and corrects the tests that depend on that.

Acceptance Criteria

For HearingDays that have number_of_slots == nil nothing stored in the db.

• Central HearingDays (request_type: "C") should have 10 total_slots.
• Video HearingDays (request_type: "V") should have 12 total_slots.
• Also, Virtual HearingDays (request_type: "R") should continue to have 8 total_slots.

Testing Plan

# See the request_type and total_slots for every hearing day, assuming you have not set
# any `number_of_slots` you should get this output
# [[10, "C"], [12, "V"], [8, "R"]]
HearingDay.all.map { |h| [h.total_slots, h.request_type] }.uniq

---

Commit: 2b327df

CASEFLOW-1070 - Custom Time Modal (#16221)

Resolves CASEFLOW-1070

Description

When scheduling a virtual hearing, clicking the "Choose a custom time" link now opens a modal with a searchable dropdown. Selecting a time from that dropdown and pressing "Create time slot" creates and selects the correct timeslot.

This modal replaces a togglable dropdown that let you select a time.

Code Review Recommendations

• Start with TimeModal.jsx there's only a few things happening in this component.

  • handleConfirm, is the analytics event correct?
  • handleConfirm, is this error handling reasonable?

• Next InfoAlert.jsx, a very small component, some styles, some text.

• The bulk of the work is in TimeSelect.jsx and its imports.

  • Recommend reviewing first in storybook here
  • The values of the various props can be changed easily via storybook controls.
  • The <Select /> tag block makes sense to review with the 'menuOpen' code. The filterOptions and options code should probably be considered separately.
  • The code block referencing menuOpen seems like one concept to me ('when is the dropdown open').
  • getTimezoneAbbreviation is a very small block of moment related code.

• The code compare the input that the user has typed to each option in the list starts in filterOptions

  • This is code I'd like someone to look through carefully.
  • Typing in different things in storybook helps illustrate what the different pieces are doing.
  • matchesAny can be called recursively (utils:841) is this okay? Improvement?

• The code to generate the time options is one concept and starts in the generateOrderedTimeOptions function.

  • This code seems less likely to be wrong in complex/harmful ways since in the end it creates a list of objects like {label: '9:00am', value: [moment object] }

Acceptance Criteria

• Code compiles correctly
• Click "Choose a custom time" to open a modal
  • Modal with an input and an auto-suggest menu that appears when a user types
    • Auto-suggest options are times in RO timezone, starting at 8:30am
    • with an option every 15 minutes after that until 11:45pm
    • then every 15 minutes starting over at 12:00am to 8:15am
• After selecting a value in the input/auto-suggest menu, show a label with selected time in Eastern timezone in modal (if RO is not in Eastern time zone)
• Validate before submitting modal
  • Must have a value
  • Must be a valid time. This does not have a validation, you can't select an invalid time.
• After submitting the modal, show the chosen time as a selected time slot button
• Clicking "Choose a custom time" again reopens the modal and changes the selected time slot button once submitted (but does not allow users to create multiple new time slot buttons that persist after scheduling)
• After submitting the modal, the following Google Analytics event is sent: Category: Hearings, Action: Hearings Schedule Veteran – Choose a custom time, Label: [time chosen]

User Facing Changes

• Screenshots of UI changes added to PR & Original Issue

BEFORE	AFTER

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 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

deployed/20210514_150359

Commit: 2b327df

CASEFLOW-1070 - Custom Time Modal (#16221)

Resolves CASEFLOW-1070

Description

When scheduling a virtual hearing, clicking the "Choose a custom time" link now opens a modal with a searchable dropdown. Selecting a time from that dropdown and pressing "Create time slot" creates and selects the correct timeslot.

This modal replaces a togglable dropdown that let you select a time.

Code Review Recommendations

• Start with TimeModal.jsx there's only a few things happening in this component.

  • handleConfirm, is the analytics event correct?
  • handleConfirm, is this error handling reasonable?

• Next InfoAlert.jsx, a very small component, some styles, some text.

• The bulk of the work is in TimeSelect.jsx and its imports.

  • Recommend reviewing first in storybook here
  • The values of the various props can be changed easily via storybook controls.
  • The <Select /> tag block makes sense to review with the 'menuOpen' code. The filterOptions and options code should probably be considered separately.
  • The code block referencing menuOpen seems like one concept to me ('when is the dropdown open').
  • getTimezoneAbbreviation is a very small block of moment related code.

• The code compare the input that the user has typed to each option in the list starts in filterOptions

  • This is code I'd like someone to look through carefully.
  • Typing in different things in storybook helps illustrate what the different pieces are doing.
  • matchesAny can be called recursively (utils:841) is this okay? Improvement?

• The code to generate the time options is one concept and starts in the generateOrderedTimeOptions function.

  • This code seems less likely to be wrong in complex/harmful ways since in the end it creates a list of objects like {label: '9:00am', value: [moment object] }

Acceptance Criteria

• Code compiles correctly
• Click "Choose a custom time" to open a modal
  • Modal with an input and an auto-suggest menu that appears when a user types
    • Auto-suggest options are times in RO timezone, starting at 8:30am
    • with an option every 15 minutes after that until 11:45pm
    • then every 15 minutes starting over at 12:00am to 8:15am
• After selecting a value in the input/auto-suggest menu, show a label with selected time in Eastern timezone in modal (if RO is not in Eastern time zone)
• Validate before submitting modal
  • Must have a value
  • Must be a valid time. This does not have a validation, you can't select an invalid time.
• After submitting the modal, show the chosen time as a selected time slot button
• Clicking "Choose a custom time" again reopens the modal and changes the selected time slot button once submitted (but does not allow users to create multiple new time slot buttons that persist after scheduling)
• After submitting the modal, the following Google Analytics event is sent: Category: Hearings, Action: Hearings Schedule Veteran – Choose a custom time, Label: [time chosen]

User Facing Changes

• Screenshots of UI changes added to PR & Original Issue

BEFORE	AFTER

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 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

---

Commit: 9d9a2ab

Added scheduled hearings list back to ScheduleVeteran component (#16246)

Description

Adds the scheduled hearing list back to the ScheduleVeteran component to display the filled hearing time slots when scheduling

Acceptance Criteria

• Code compiles correctly

Testing Plan

1. Shadow user BVASYELLOW http://localhost:3000/test/users
2. Navigate to schedule veterans and choose an RO from the list: http://localhost:3000/hearings/schedule/assign
3. Navigate to the AMA Waiting tab and choose one of the veterans
4. On the Case Details page choose the "Schedule Veteran" option from the task actions
5. Ensure that the existing hearings display in the time slots

---

Commit: 8ba1acf

Change Timeslot defaults (CASEFLOW-1507) (#16243)

Resolves CASEFLOW-1507

Description

Please explain the changes you made here.

Acceptance Criteria

When a virtual hearing day does not have values for the time slot columns, they should default to the following

Column	Default value
first_slot_time	8:30 AM (RO time zone)
slot_length_minutes	60 minutes
number_of_slots	8 slots

Testing Plan

1. Find a central office HearingDay:
   • central_day = HearingDay.find_by(request_type: "C", first_slot_time: nil, slot_length_minutes: nil, number_of_slots:nil)
2. For the central_day
   • central_day.begins_at should return 9am eastern on the date of the HearingDay.
   • central_day.slot_length_minutes should return 60.
   • central_day.total_slots should return 8.
3. Find a video HearingDay with the Denver RO
   • video_day = HearingDay.find_by(request_type: "V", regional_office: "RO39", first_slot_time: nil, slot_length_minutes: nil, number_of_slots:nil)
4. For the video_day
   - video_day.begins_at should return 8:30am mountain (-06:00) on the date of the HearingDay.
   - video_day.slot_length_minutes should return 60.
   - video_day.total_slots should return 8.

For the frontend, I think the best way to test is:

• Change: TimeSlot.jsx:29-31 where the three defaults are set so all the values from the backend are ignored. This will make sure we're using the frontend values in hearings/utils setTimeSlots

  // const beginsAt = hearing?.hearingDay?.beginsAt;
  // const numberOfSlots = hearing?.hearingDay?.totalSlots;
  // const slotLengthMinutes = hearing?.hearingDay?.slotLengthMinutes;
  const [beginsAt, numberOfSlots, slotLengthMinutes] = [];

• Visually inspect the results either via storybook or localhost.

---

Commit: 3a040d1

CASEFLOW-1121 | Substitute Appellant | Show Case Timeline Event (#16242)

Connects CASEFLOW-1121

Description

This builds out better support for non-task timeline events (such as decision date, NOD updates, and — specifically for this — substitution dates).

This renames/refactors a couple of existing functions to make clear that certain timeline events are coming from parts of the appeal object other than tasks.

Acceptance Criteria

• Code compiles correctly
• Event is shown on Case Timeline if appeal has a substitution date (via an appellantSubstitution attached to it)

Testing Plan

For new substitution event:

1. Put a binding.pry on line 112 of spec/feature/queue/substitute_appellant/shared_setup.rb
2. Run substitute_appellant_spec.rb
3. See the timeline event

For preserving existing capabilities:

1. Verify that "should sort tasks and nod date updates properly" test runs properly in case_details_spec

User Facing Changes

• Screenshots of UI changes added to PR & Original Issue

BEFORE	AFTER

---

Commit: 996fff1

Caseflow-1406 Substitute Appellant | Task Selection Table (#16192)

Connects CASEFLOW-1406
Related stories:
Github 16214
Github 16184

Description

This implements the TaskSelectionTable component within the existing SubstituteAppellantTasksForm component to allow the user to select which task(s) to reopen during substitution. Behind the FeatureToggle: :recognized_granted_substitution_after_dd

Acceptance Criteria

• Code compiles correctly
• Only tasks that were assigned to Organizations are available tasks.
• Progress bar will advance from "Select substitute appellant" to "Create task"
• There will be "Procedural Details" section that displays "Notice of disagreement received", "Veteran date of Death", and "Substitution granted by the RO".
• Tasks table will have a non-editable "Distribution Task" already checked.
• Tasks are displayed in the order of most recently completed (note: some will have same date and might look out of sequence, but we've notated that this is likely and could be future development work).
• Using the "Back" button pre-populating previosly selected choices.

Testing Plan

Setup your user

RequestStore[:current_user] = User.system_user

Setup an appeal (note: this type here will only be visible ...

deployed/20210513_180518

Commit: d3df512

Correctly handle "reschedule hearing" action on transcription tasks that aren't descendants of hearing tasks (#16239)

Resolves CASEFLOW-986

Description

Correctly handles the "Mark as complete: Reschedule hearing" action on transcription tasks that aren't descendants of hearing tasks.

Technical background

Here's the investigation I did to make sure I was covering all possible task trees, and as inspiration for the task trees in the test cases.

#
#
# what types of parents do transcription tasks have?

TranscriptionTask.open.map { |t| t.parent.type }.reduce(Hash.new(0)) { |a, b| a[b] += 1; a }

{
 "TranscriptionTask"=>25,
 "MissingHearingTranscriptsColocatedTask"=>66,
 "AssignHearingDispositionTask"=>1403,
 "ChangeHearingDispositionTask"=>24
}

#
#
# what does a typical line of descent look like for tasks with each of those parents?

def minitrees(tasks)
  tasks.map do |t|
    parent = t.parent
    tree = [parent.type]
    grandparent = parent.parent
    while grandparent.present?
      tree.push(grandparent.type)
      grandparent = grandparent.parent
    end
    tree.join(" - ")
  end.reduce(Hash.new(0)) { |a, b| a[b] += 1; a }
end

#
# with TranscriptionTask parent

tts = TranscriptionTask.open.select { |t| t.parent.type == TranscriptionTask.name }
puts minitrees(tts)
{
  "TranscriptionTask - AssignHearingDispositionTask - HearingTask - DistributionTask - RootTask"=>25
}

#
# with ChangeHearingDispositionTask parent

tts = TranscriptionTask.open.select { |t| t.parent.type == ChangeHearingDispositionTask.name }
puts minitrees(tts)
{
  "ChangeHearingDispositionTask - HearingTask - DistributionTask - RootTask"=>24
}

#
# with MissingHearingTranscriptsColocatedTask parent

tts = TranscriptionTask.open.select do |t|
  t.parent.type == MissingHearingTranscriptsColocatedTask.name
end
puts minitrees(tts)
{
  "MissingHearingTranscriptsColocatedTask"=>57,
  "MissingHearingTranscriptsColocatedTask - JudgeAssignTask - RootTask"=>1,
  "MissingHearingTranscriptsColocatedTask - AttorneyTask - JudgeDecisionReviewTask - RootTask"=>8
}

# example of the most common tree (it's always a LegacyAppeal)
# appeals with this tree were causing the errors that inspired CASEFLOW-986
                                           ┌────────────────────┐
LegacyAppeal 1452175                       │ ID      │ STATUS   │
├── RootTask                               │ 1588742 │ assigned │
└── MissingHearingTranscriptsColocatedTask │ 1615520 │ on_hold  │
    └── TranscriptionTask                  │ 1615521 │ assigned │
                                           └────────────────────┘

#
# with AssignHearingDispositionTask parent

tts = TranscriptionTask.open.select { |t| t.parent.type == AssignHearingDispositionTask.name }
puts minitrees(tts)

{
  "AssignHearingDispositionTask - HearingTask - DistributionTask - RootTask"=>1401,
  "AssignHearingDispositionTask - HearingTask - RootTask"=>1
}

# example of the most common tree
                                             ┌─────────────────────┐
Appeal 77527                                 │ ID      │ STATUS    │
└── RootTask                                 │ 920164  │ on_hold   │
    └── DistributionTask                     │ 920166  │ on_hold   │
        └── HearingTask                      │ 920167  │ on_hold   │
            ├── ScheduleHearingTask          │ 920168  │ completed │
            └── AssignHearingDispositionTask │ 1478187 │ on_hold   │
                └── TranscriptionTask        │ 1691912 │ assigned  │
                                             └─────────────────────┘

---

Commit: e81a0e0

Put death dismissal streamline behind a feature toggle (#16245)

Follow-up to #16212

Description

Add the death_dismissal_streamlining feature toggle for CASEFLOW-895

Acceptance Criteria

• Code compiles correctly

Testing Plan

1. Affected tests from #16212 updated with before/after blocks to toggle/untoggle

---

Commit: df0af2d

Implement unscheduled hearing notes feature (#16230)

Resolves https://vajira.max.gov/browse/CASEFLOW-500
Resolves https://vajira.max.gov/browse/CASEFLOW-501

This PR is the comination of work done with the following PRs which implement the unschedules note feature:

• #16153
• #16199

The description of work is explained in each PR.

deployed/20210513_150402

Commit: df0af2d

Implement unscheduled hearing notes feature (#16230)

Resolves https://vajira.max.gov/browse/CASEFLOW-500
Resolves https://vajira.max.gov/browse/CASEFLOW-501

This PR is the comination of work done with the following PRs which implement the unschedules note feature:

• #16153
• #16199

The description of work is explained in each PR.

deployed/20210512_150418

Commit: df0af2d

Implement unscheduled hearing notes feature (#16230)

Resolves https://vajira.max.gov/browse/CASEFLOW-500
Resolves https://vajira.max.gov/browse/CASEFLOW-501

This PR is the comination of work done with the following PRs which implement the unschedules note feature:

• #16153
• #16199

The description of work is explained in each PR.

deployed/20210511_150432

Commit: df0af2d

Implement unscheduled hearing notes feature (#16230)

Resolves https://vajira.max.gov/browse/CASEFLOW-500
Resolves https://vajira.max.gov/browse/CASEFLOW-501

This PR is the comination of work done with the following PRs which implement the unschedules note feature:

• #16153
• #16199

The description of work is explained in each PR.

---

Commit: cf0bc85

Don’t show : after updating POA to no POA (#16237)

Description

When refreshing POA, sometimes there is no POA, when this happens a single colon would be left on the page. This PR makes it so that colon isn't displayed in this scenario.

Acceptance Criteria

• Code compiles correctly
• Tests continue to pass

---

Commit: dc68e9f

updated controller (#16234)

Resolves CASEFLOW-1467

Description

Updated appeals controller to include ID in power_of_attorney_data only for recognized appellants

Acceptance Criteria

• Code compiles correctly

Testing Plan

1. Go to ...

• For higher-risk changes: Deploy the custom branch to UAT to test

User Facing Changes

• Screenshots of UI changes added to PR & Original Issue

Unrecognized Appellant - AttorneyPowerOfAttorney

Unrecognized Appellant - UnrecognizedPowerOfAttorney

---

Commit: a383600

Return nil case type for Legacy Apppeals to avoid VACOLS call (#16236)

• return nil case_type for legacy hearings

• do not render case type if it does not exist

• fix a karma test related to import

• code climate fix

deployed/20210510_182634

Commit: a383600

Return nil case type for Legacy Apppeals to avoid VACOLS call (#16236)

• return nil case_type for legacy hearings

• do not render case type if it does not exist

• fix a karma test related to import

• code climate fix

---

Commit: 3adcff5

Avoid bgs call when serializing poa name for upcoming hearings table (#16235)

Resolves https://vajira.max.gov/browse/CASEFLOW-1509

Background

In this PR, we started serializing poa name to display that information on the upcoming hearing days list(example: http://localhost:3000/hearings/schedule/assign?regional_office_key=RO17&tab=unassignedTab). But that call to representative (Hearing and LegacyHearing) can call BGS. This increases to load times by a lot because when user visits this page for example, we load all upcoming hearing days from today to 182 days out and all hearings for those days at once.

Code trails

• Frontend Request for hearings for upcoming hearing days
• Next Step in HearingDayController where most time is spent
• Serializer that is used to serialize above hearings
  • if you git blame this line, you can see that POA name was just added recently
  • this call to representative (Hearing and LegacyHearing) can call BGS
• Rubaiyat's poa_name method that doesn't call BGS

This PR makes changes so that we avoid calling a bgs to grab poa names for hearings and instead always grab the cached values in BgsPowerOfAttorney table.

deployed/20210510_150419

Commit: 3adcff5

Avoid bgs call when serializing poa name for upcoming hearings table (#16235)

Resolves https://vajira.max.gov/browse/CASEFLOW-1509

Background

In this PR, we started serializing poa name to display that information on the upcoming hearing days list(example: http://localhost:3000/hearings/schedule/assign?regional_office_key=RO17&tab=unassignedTab). But that call to representative (Hearing and LegacyHearing) can call BGS. This increases to load times by a lot because when user visits this page for example, we load all upcoming hearing days from today to 182 days out and all hearings for those days at once.

Code trails

• Frontend Request for hearings for upcoming hearing days
• Next Step in HearingDayController where most time is spent
• Serializer that is used to serialize above hearings
  • if you git blame this line, you can see that POA name was just added recently
  • this call to representative (Hearing and LegacyHearing) can call BGS
• Rubaiyat's poa_name method that doesn't call BGS

This PR makes changes so that we avoid calling a bgs to grab poa names for hearings and instead always grab the cached values in BgsPowerOfAttorney table.

---

Commit: 0735972

Substitution: Add columns to capture user's task selections (#16229)

Bumps CASEFLOW-1431

Slack

Description

Add columns to capture more user input: selected_tasks_ids and task_params

Note I'm using jsonb instead of json as recommended by StrongMigrations:

=== Dangerous operation detected #strong_migrations ===

There's no equality operator for the json column type, which
causes issues for SELECT DISTINCT queries. Use jsonb instead.

/Users/yoomlam/dev/caseflow/db/migrate/20210507152437_add_selected_task_ids_to_appellant_substitution_table.rb:9:in `change'
/Users/yoomlam/.rbenv/versions/2.5.3/bin/bundle:23:in `load'
/Users/yoomlam/.rbenv/versions/2.5.3/bin/bundle:23:in `<main>'
Tasks: TOP => db:migrate

https://nandovieira.com/using-postgresql-and-jsonb-with-ruby-on-rails
https://melvinchng.github.io/rails/RailsJSONB.html#chapter-4-rails-jsonb

Acceptance Criteria

• Code compiles correctly

Testing Plan

See RSpec

Database Changes

Only for Schema Changes

• Timestamps (created_at, updated_at) for new tables
• Column comments updated
• Have your migration classes inherit from Caseflow::Migration, especially when adding indexes (use add_safe_index)
• Verify that migrate:rollback works as desired (change supported functions)
• Query profiling performed (eyeball Rails log, check bullet and fasterer output)
• Appropriate indexes added (especially for foreign keys, polymorphic columns, unique constraints, and Rails scopes)
• DB schema docs updated with make docs (after running make migrate)
• #appeals-schema notified with summary and link to this PR
• Any non-obvious semantics or logic useful for interpreting database data is documented at Caseflow Data Model and Dictionary

---

Commit: e5511da

Shalliburton/caseflow 417 hearing day time slots (#16203)

Resolves CASEFLOW-417
Part (1/2)
Part 2

Description

Adds time slot details to hearing days and displays those details in the UI for confirmation from the user building the hearing schedule

Acceptance Criteria

• Build Schedule spreadsheet updated to build Video/In-Person days or Virtual hearing days as described in https://docs.google.com/document/d/1O94ifyf-uhp-g9iCGz1zIeCxis-E4SBfFJDZnp5gO-0/edit
• Add columns for time slot rules in the confirmation step of the Build Schedule workflow
• Write values entered in the new spreadsheet columns into the database columns created in (CASEFLOW-1115)
• All columns require a value
• Number of time slots can't exceed 12
• Duration of time slots can't exceed 60
• Start time has to be able to be interpreted as a time (but flexible on other input requirements)
• 🧘‍♂️ Can we add dropdowns with limited values into the template itself?

Testing Plan

1. Sign in as user BVASYELLOW http://localhost:3000/test/users
2. Navigate to the build hearings schedule: http://localhost:3000/hearings/schedule/build
3. Click the "Upload Files" button
4. Fill out the start date as 04/01/2021 and the end date as 06/30/2021
5. Upload the spreadsheet: RO Assignment Test Q3 FY21 .xlsx
6. Click continue to schedule the assignments
7. Confirm the time slot details and then click confirm assignments and confirm when the dialog pops up
8. Ensure that you get a success message indicating the hearing days were created

User Facing Changes

Before	After

Database Changes

Only for Schema Changes

• Timestamps (created_at, updated_at) for new tables
• Column comments updated
• Have your migration classes inherit from Caseflow::Migration, especially when adding indexes (use add_safe_index)
• Verify that migrate:rollback works as desired (change supported functions)
• Query profiling performed (eyeball Rails log, check bullet and fasterer output)
• Appropriate indexes added (especially for foreign keys, polymorphic columns, unique constraints, and Rails scopes)
• DB schema docs updated with make docs (after running make migrate)
• #appeals-schema notified with summary and link to this PR
• Any non-obvious semantics or logic useful for interpreting database data is documented at Caseflow Data Model and Dictionary

---

Commit: 782a53b

Move logstash config into its own file and fix user (#16223)

Description

This PR fixes logstasher user field and moves logstasher config to its own file for cleanliness

Acceptance Criteria

• Code compiles correctly

Testing Plan

1. Deploy branch to UAT
2. Make sure app is healthy and user info shows up in logstasher logs

User info shows up and is searchable

---

Commit: e8ba5ca

filter out rolled back related remand issues (#16167)

Description

Ensures that remand issues returned by LegacyIssueOptin.related_remand_issues have not been rolled-back and have an opt-in processed at date. Addresses this bat team issue.

---

Commit: b6835a3

Don't exclude Virtual Hearings as a RO option when hearing type is virtual (#16228)

Resolves https://vajira.max.gov/browse/CASEFLOW-1502

Description

• determine excludeVirtualHearingsOption prop based on whether the type is virtual or not

Testing Plan

1. Login as BVSYELLOW
2. Go to http://loca...