Caseflow: Do not treat "unidentified" request issues as non-comp BusinessLine

[pkarman]

See https://dsva.slack.com/archives/C2ZAMLK88/p1556644556118700

We should not be attempting to create BusinessLine for unidentified non-comp RequestIssues. That we get to that place in the code smells like a stricter requirement is necessary for tracking unidentified non-comp tasks.

Acceptance

• [ ] Re-assign existing production env tasks to a real Business Line.
• [ ] Prevent automatic creation of BusinessLine organization for unidentified non-comp issues. Alternate behavior (warning to the user, etc) TBD.
• [ ] Delete the existing BusinessLine data in UAT and prod if it exists.

[lowellrex]

This bug popped back up again: https://dsva.slack.com/archives/C4JECDLSE/p1558013859294600

We fixed the immediate issue it was causing by giving a task that did not have an assignee the "unidentified" BusinessLine:

  rails c> t = Task.find(204662)
  rails c> unidentified_business_line = Organization.find(307)
  rails c> t.update!(assigned_to: unidentified_business_line)

[lowellrex]

Same bug again (https://dsva.slack.com/archives/C4JECDLSE/p1558105150001000):

  rails c> tasks = Task.where(assigned_to_id: nil)
  rails c> tasks.count
  # 1
  rails c> task = tasks.first
  rails c> pp task.appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :assigned_to_id)
  # Yup, it's another VeteranRecordRequest task without an assignee.
  # Is it also unknown benefit_type?
  rails c> task.appeal.request_issues.pluck(:benefit_type)
  # ["compensation", "compensation", "unknown", "compensation"]
  # Yup.
  # Temporary fix:
  rails c> unidentified_business_line = Organization.find(307)
  rails c> task = Task.find(206542)
  rails c> task.update!(assigned_to: unidentified_business_line)

[pkarman]

@laurjpeterson @leikkisa we should talk through the desired behavior here. We rely on the benefit_type for a request issue in order to assign a LOB (BusinessLine) org task. However, unidentified issues (neither rating nor non-rating) don't have a benefit_type -- where should they be assigned?

[laurjpeterson]

@laurjpeterson to schedule time to discuss with @pkarman @aroltsch @leikkisa

update: sally scheduled for 5/23

[leikkisa]

This assignment is temporary. Unidentified issues shouldn't be able to go through the process, someone is supposed to go back and update them with real issue. We still need it to show up somewhere for someone to know to do that though.

We have been assuming that unidentified issues are most likely to be rating issues (particularly because the user can freely enter the description for nonrating issues), so we've been putting them onto rating EPs. If there are other rating issues that are all one business line, we could presume they're the same business line.

We have three known reasons for unidentified rating issues at the moment, ratings before 2003, some ratings that are not service connected (don't know the full specifics yet), and PMC ratings.

[lowellrex]

Fixed two more (https://dsva.slack.com/archives/C4JECDLSE/p1558442353031700):

  rails c> tasks = Task.where(assigned_to_id: nil)
  rails c> tasks.count
  # 2
  rails c> first_task = tasks.first
  rails c> first_task.id
  # 208629
  rails c> pp first_task.appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :assigned_to_id)
  # [[208626, nil, "RootTask", 2],
     [208627, 208626, "TrackVeteranTask", 244],
     [208628, 208626, "DistributionTask", 2],
     [208629, 208626, "VeteranRecordRequest", nil]]
  rails c> first_task.appeal.request_issues.pluck(:benefit_type)
  # ["unknown", "compensation", "compensation", "compensation", "compensation", "compensation", "compensation"]
  rails c> unidentified_business_line = Organization.find(307)
  rails c> first_task.update!(assigned_to: unidentified_business_line)

  rails c> tasks = Task.where(assigned_to_id: nil)
  rails c> tasks.count
  # 1
  rails c> second_task = tasks.first
  rails c> second_task.id
  # 209275
  rails c> pp second_task.appeal.tasks.order(:created_at).pluck(:id, :parent_id, :type, :assigned_to_id)
  # [[209270, nil, "RootTask", 2],
     [209271, 209270, "TrackVeteranTask", 14],
     [209272, 209270, "DistributionTask", 2],
     [209274, 209273, "ScheduleHearingTask", 2],
     [209273, 209272, "HearingTask", 2],
     [209275, 209270, "VeteranRecordRequest", nil]]
  rails c> second_task.appeal.request_issues.pluck(:benefit_type)
  # ["unknown", "compensation"]
  rails c> second_task.update!(assigned_to: unidentified_business_line)

[leikkisa]

After looking at the issue, all of the tasks on the "Unidentified" business line are VeteranRecordRequest tasks. I don't think we need to create these for unidentified issues, we should create them once the issue is identified.

So I think for data clean up, we should just cancel all of those tasks.

We should also confirm that unidentified issues still show up in an appeal, so that someone knows they're there and to edit them. I only see 6 that have been removed in Prod, by Ryan Connally, Christopher Banks, and Rachel Sauter - so just want to confirm that these weren't our own manual removals.

[leikkisa]

Peter pointed out that a lot of these were on ineligible issues, so I checked that any issues without a benefit type on those were ineligible and deleted the VeteranRecordRequests for those. There are still two left, we're waiting to hear back from Rachel if it's okay to delete those.

[leikkisa]

Appeal 2525 (b954989a-478a-4bfb-a332-83b39055d144) and appeal 2962 (e5c281fb-4953-4ab9-9c78-86341ec4517a)

[leikkisa]

Rachel confirmed we could delete the last two, and it is done! There have been no new ones in the mean time, so I am closing this ticket.