Caseflow: Do not use assigned_to_location to sort and filter by assignee in org queues

[hschallhorn]

When implementing back end sorting and filtering by assignee in #11780 for pagination, we noticed our front end did not sort or filter with the simple task assignee value. We opted to match what the front end currently did and fix this later. This is the ticket to fix this!

AC

• [ ] Back end sorts and filters based on the name (name for organization and full_name for user) of the assignee of the task

VLJ support comments

1. Appeals are showing in the VLJ Support queue that are assigned to users who are not part of VLJ Support (ex. 484b4e52-1e05-4a81-890c-3408892265fc is assigned to Tecola Plowden, but is showing in VLJ Support’s queue). While this is also assigned to another user who is part of VLJ Support, they are only able to see that it is assigned to Tecola Plowden). Maria wants the VLJ Support queue to only show tasks that are assigned to her employees so she can provide an accurate accounting of all tasks to her DVC.
2. Why are tasks showing as assigned to “VLJ Support” and not an individual user? Maria mentioned that some tasks in VLJ Support’s queue are shown as assigned to “VLJ Support” when they are in fact assigned to an individual user.

[ajspotts]

_what is this chart?_

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

Why 2?

• Implementing a more straightfoward approach and undoing the existing

Why 3?

• No new caching code
• Can replicate some of the sorting and filtering logic for the assigneR of tasks

Why 5?

• Undoing a lot of code in caching
• Touching the database

[hschallhorn]

@geronimoramos or @RyanRoyUX Right now we're using a gross method to display who the assignee of a task is that hardly has anything to do with the task. This could show a vacols location (sometimes a number), an organization's name, a user's css_id, and for some reason a user's database id.

In this ticket, we're moving to showing the actual assignee of a task (either an organization or a user) and am wondering what value to display

1. I think name makes the most sense for tasks that are assigned to an organization ("Litigation Support", "Privacy Team", etc)
2. User is a bit more complicated. We could keep using css_id or switch to full name or even "F. Last". May want to keep space in mind, css_ids are usually a set length and pretty small.
   
   
   
   1. If switching to full name or "F. Last", should we sort on the user's first or last name?
   
   

Thoughts?

[hschallhorn]

@RyanRoyUX and @geronimoramos repinging on this. Opted for css_id to stay mildly consistent with what we already have

• [ ] Queues show the css_id of the user assignee, rather than a mix of user id or css_id?

[geronimoramos]

@hschallhorn CSS ID makes a lot of sense to me especially if it is maintaining consistency - much better than a VACOLs location. I also like the idea of displaying an organization like Lit Support since reaching out to a team lead is more the norm than an individual contributor team member. But happy to experiment with CSS ID first! I don't see any challenges with it.

[hschallhorn]

@araposo-tistatech This fix is in and should be out in next deployment. Can we check in with VLJ support to see if this solves their qualms with the "Assigned to" column in their queue?

User Facing Changes

• [x] Queues show the actual assignees of each task (no one assignee for all tasks for one case)

  BEFORE|AFTER
  ---|---
  |

• [x] Queues show the css_id of the user assignee, rather than a mix of user id or css_id?

  BEFORE|AFTER
  ---|---
  |

• [x] Queues do not show "Case Storage" unless they are actually assigned to BVA

  BEFORE|AFTER
  ---|---
  |

[araposo-tistatech]

@hschallhorn VLJ Support confirmed this looks good.