Rake Generator for Legacy Appeals - department-of-veterans-affairs/caseflow GitHub Wiki

To generate Legacy Appeals in your environment, you can utilize the rake generator bundle exec rake db:generate_legacy_appeals[:add_special_issues]. This generator creates 5 new Legacy Appeals that can be used within Caseflow/DB. The process involves using the LegacyAppealFactory to generate records in FACOLS by providing the required fields such as case_attrs, staff_attrs, and decass_attrs. Once the FACOLS records are created, the generator builds each Legacy Appeal in Caseflow using the corresponding case_record. The rake generator offers additional options through two special arguments. The :add_special_issues argument allows you to include specific issues within the generated Legacy Appeals.

To generate Legacy Appeals with AMA Tasks in your environment, you can utilize the rake generator bundle exec rake db:generate_legacy_appeals_with_tasks. The rake task enables the creation of tasks for the Legacy Appeals based on user input.

In summary, running the db:generate_legacy_appeals[:add_special_issues] rake generator provides a convenient way to generate a set of Legacy Appeals, and customize them with special issues if desired, or you can create legacy appeals with associated AMA tasks by running the db:generate_legacy_appeals_with_tasks rake generator.

Note: This only works for Legacy Appeals

To find if this rake generator is available in your environment you can run the command bundle exec rake -T. If you want to take a closer look at the generator you can find them within the files seed_legacy_appeals.rake & seed_legacy_appeal_tasks.rake.

To create Legacy Appeals, use the command bundle exec rake db:generate_legacy_appeals. The script will ask you to enter the CSS ID of the user that you want to assign the Legacy Appeals to, whether it be a demo user such as "BVASCASPER1" or a UAT user such as "TCASEY_JUDGE". These legacy appeals will appear within the user's Queue.

To create Legacy Appeals with Special Issues, use the command bundle exec rake db:generate_legacy_appeals[true]. The script will ask you to enter the CSS ID of the user that you want to assign the Legacy Appeals to, whether it be a demo user such as "BVASCASPER1" or a UAT user such as "TCASEY_JUDGE". These legacy appeals will be generated with special issues and appear within the user's Queue.

To create Legacy Appeals with Tasks, use the command bundle exec rake db:generate_legacy_appeals_with_tasks. The script will ask you to enter the type of task you want to create for these legacy appeals. If a Judge, Attorney, or Review Task is selected, the script will then ask for the CSS ID of the user that you want to assign the Legacy Appeals to, whether it be a demo user such as "BVASCASPER1" or a UAT user such as "TCASEY_JUDGE".The options include HearingTask, JudgeTask, AttorneyTask, ReviewTask, Scenario1Edge, and Brieff_Curloc_81_Task. There are different requirements and actions for each:

• HearingTask

  • Creates a HearingTask and a child ScheduleHearingTask for the Legacy Appeal
  • Both tasks will be assigned to the BVA
  • Location in FACOLS is set to Location 57, to simulate a case in Vacols with a Hearing attached/requested.

• Brieff_Curloc_81_Task

  • Note: Since this is a Legacy Appeal, a Distribution Task will not be created as Legacy Appeals should not have a Distribution Task attached to them. This option will only set the FACOLS location to "81" which refers to "Case Storage". This location is the equivalent of the distribution pool that we find AMA Appeals in.

• JudgeTask (Judge User Required)

  • Requires the user selected to be a judge within Vacols, will not run otherwise.
  • Creates a JudgeAssignTask and assigns it to the selected Judge

• AttorneyTask ( Attorney User Required )

  • Requires an Attorney to be selected, will not run otherwise
  • Once the option AttorneyTask is selected, the script will ask for the Attorney User
  • Creates a JudgeDecisionReviewTask and assigns it to a Judge
  • Creates an AttorneyTask as a child of the JudgeDecisionReviewTask and assigns it to the selected Attorney

• ReviewTask (Judge User Required)

  • Requires the user selected to be a judge within Vacols, will not run otherwise.
  • Creates a JudgeDecisionReviewTask and assigns it to the selected Judge

• Scenario1Edge

  • Will generate a legacy appeal with a random mix of tasks considered blocking (hearing tasks (with multiple children), transcription tasks, translation tasks, mail tasks, etc..)
  • Both tasks will be assigned to the BVA
  • Location in FACOLS is set to Location 57, to simulate a case in Vacols with a Hearing attached/requested.

• If running the generator on MacOS using zsh, you will need to put quotations around the rake task as follows bundle exec rake "db:generate_legacy_appeals[false]"

• Generating too many legacy appeals for one user can lead to their Queue being unable to load cases.

  • One way to fix this is to bypass the Queue, and enter the case details page using the url. Inputting queue/appeals/[vacols_id] with the corresponding Vacols id into the url will get you to the specified case details page.
  • To get rid of this issue entirely, you must do a database reset. This can be achieved by running the command make reset

• When generating a legacy appeal with hearings to the BVA, the docket filter in the BVA's case queue displays a <<blank>> option that contains all generated appeals. These cases still appear within the queue table but are not added to the legacy docket filter.

• This section is here to address under what conditions we consider a legacy appeals to have a blocking task preventing it from SCM distribution.

• The first criteria for a case to be considered blocking is that it is a legacy appeal that is in location '57' or 'CASEFLOW' in the CURLOC field on the BRIEFF VACOLS table.

• If a case is outside of these 2 locations it should not be considered blocked in anyway shape or form.

• After we have determined the cases current location in VACOLS we can assess if the case has any type of HearingTask active. Inactive HearingTasks are not considered blocking. Some examples of blocking hearing tasks are but not limited to: ScheduleHearingTask, AssignHearingDispositionTask, NoShowHearingTask, HearingAdminActionIncarceratedVeteranTask, ChangeHearingDispositionTask, HearingAdminActionMissingFormsTask, HearingAdminActionFoiaPrivacyRequestTask

• HearingTasks can have a number of children and even nested children below those. All child tasks that are active need to be cancelled while leaving non-active tasks in their current state.

• In addition to HearingTasks there are TranscriptionTasks (which usually occur after a hearing has been heard) as well as TranslationTasks which should be considered blocking and rarely have children with the exception of TimedHoldTask

• Lastly we need to search for blocking MailTasks, unfortunately legacy appeals do not utilized the DistributionTasks which allows us to easily identify which mail tasks are considered blocking so we are approaching this with any mail task to be considered blocking.

• MailTasks that are considered blocking are as follows: PrivacyActTask, FoiaTask, and CongressionalInquiryTasks

• All of these tasks have been marked with a function legacy_blocking which will return true when called. This will help developers identify if any active task on the legacy appeal should be considered a blocking task.