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

Do not use assigned_to_location to sort and filter by assignee in org queues #13914

Closed
1 task
hschallhorn opened this issue Apr 7, 2020 · 6 comments · Fixed by #14263
Closed
1 task

Do not use assigned_to_location to sort and filter by assignee in org queues #13914

hschallhorn opened this issue Apr 7, 2020 · 6 comments · Fixed by #14263
Assignees
Labels
Feature: generic-queue Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue Source: BVA Reported Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Type: Bug

Comments

@hschallhorn
Copy link
Contributor

hschallhorn commented Apr 7, 2020

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.
@hschallhorn hschallhorn added Feature: generic-queue Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue Source: BVA Reported Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Type: Bug Team: Echo 🐬 labels Apr 7, 2020
@ajspotts
Copy link
Contributor

ajspotts commented Apr 9, 2020

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
Copy link
Contributor Author

@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.
Screen Shot 2020-05-12 at 6 23 56 PM

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
Copy link
Contributor Author

hschallhorn commented May 14, 2020

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

Screen Shot 2020-05-15 at 1 25 39 PM

@geronimoramos
Copy link

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

va-bot pushed a commit that referenced this issue May 18, 2020
…14263)

# THIS PR
Resolves #13914

PART 1 of the stack
PART 2 #14264
PART 3 #14265

### Description
Moves `joins(CachedAppeal.left_join_from_tasks_clause)` into a scope on tasks

### Acceptance Criteria
- [x] Tests pass (no changes)

# FULL STACK

### Description
Rather than displaying an appeal's problematic assigned_to_location, show the actual task assignee in task tables.

### Acceptance Criteria
- [ ] Task tables display the name of the org or the name of the user that is assigned the task
- [ ] Organization queues
   - [ ] Can sort by assignee name
   - [ ] Can filter by assignee name
   - [ ] Show the correct assignee filter options

### Testing Plan
#### Tasks assigned to users
1. Sign in as BVALSPORER
1. Navigate to the VLJ support queue http://localhost:3000/organizations/vlj-support
1. Confirm that assignee css_ids appear in the queue table
1. Confirm filter options look correct
1. Confirm filtering works
1. Confirm sorting works

#### Tasks assigned to organizations
1. Sign in as Jolly Postman
1. Navigate to any ama case (I searched for vet 321321321) and add 4 tasks (FOIA, AOD, change of addrress, and Congressional Interest)
1. Update all these tasks to be on hold
```ruby
uuid = ""
appeal = Appeal.find_by_uuid(uuid)
MailTask.where(appeal: appeal).each(&:on_hold!)
appeal.reload.treee
                                              ┌──────────────────────────────────────────────────────────────────────────────┐
Appeal 138 (direct_review) ────────────────── │ ID   │ STATUS  │ ASGN_BY       │ ASGN_TO           │ UPDATED_AT              │
└── RootTask                                  │ 352  │ on_hold │               │ Bva               │ 2020-05-07 16:00:44 UTC │
    ├── DistributionTask                      │ 353  │ on_hold │               │ Bva               │ 2020-05-13 00:46:14 UTC │
    │   ├── CongressionalInterestMailTask     │ 2623 │ on_hold │               │ MailTeam          │ 2020-05-13 00:46:14 UTC │
    │   │   └── CongressionalInterestMailTask │ 2624 │ on_hold │ JOLLY_POSTMAN │ LitigationSupport │ 2020-05-13 00:47:38 UTC │
    │   └── FoiaRequestMailTask               │ 2625 │ on_hold │               │ MailTeam          │ 2020-05-13 00:46:22 UTC │
    │       └── FoiaRequestMailTask           │ 2626 │ on_hold │ JOLLY_POSTMAN │ PrivacyTeam       │ 2020-05-13 00:47:38 UTC │
    ├── AodMotionMailTask                     │ 2627 │ on_hold │               │ MailTeam          │ 2020-05-13 00:46:35 UTC │
    │   └── AodMotionMailTask                 │ 2628 │ on_hold │ JOLLY_POSTMAN │ AodTeam           │ 2020-05-13 00:47:38 UTC │
    └── AddressChangeMailTask                 │ 2629 │ on_hold │               │ MailTeam          │ 2020-05-13 00:47:00 UTC │
        └── AddressChangeMailTask             │ 2630 │ on_hold │ JOLLY_POSTMAN │ Colocated         │ 2020-05-13 00:47:00 UTC │
            └── AddressChangeMailTask         │ 2631 │ on_hold │ JOLLY_POSTMAN │ BVALSPORER        │ 2020-05-13 00:47:38 UTC │
                                              └──────────────────────────────────────────────────────────────────────────────┘
```
1. Go to the mail queue's on hold tab http://localhost:3000/organizations/mail?tab=on_hold
1. Confirm that assignee org names appear in the queue table
1. Confirm filter options look correct
1. Confirm filtering works
1. Confirm sorting works

### User Facing Changes
 - [x] Queues show the actual assignees of each task (no one assignee for all tasks for one case)

 BEFORE|AFTER
 ---|---
![Screen Shot 2020-05-12 at 8 53 39 PM](https://user-images.githubusercontent.com/45575454/81759614-2d56fb80-9493-11ea-9969-35b8a5ba09ff.png)|![Screen Shot 2020-05-12 at 8 52 41 PM](https://user-images.githubusercontent.com/45575454/81759607-292ade00-9493-11ea-984e-54edd4265aa5.png)

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

 BEFORE|AFTER
 ---|---
![Screen Shot 2020-05-12 at 8 55 59 PM](https://user-images.githubusercontent.com/45575454/81759681-5e373080-9493-11ea-958b-b6e9e79e773e.png)|<img width="973" alt="Screen Shot 2020-05-15 at 1 25 39 PM" src="https://user-images.githubusercontent.com/45575454/82078744-a7fc6280-96af-11ea-9e70-a0897a1dd51a.png">



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

 BEFORE|AFTER
 ---|---
![Screen Shot 2020-05-12 at 9 00 31 PM](https://user-images.githubusercontent.com/45575454/81759811-b66e3280-9493-11ea-8e1c-737a69757bb8.png)|<img width="1024" alt="Screen Shot 2020-05-15 at 5 02 39 PM" src="https://user-images.githubusercontent.com/45575454/82095870-ebfe6000-96cd-11ea-8c1d-a0355f150698.png">
@hschallhorn
Copy link
Contributor Author

@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

  • Queues show the actual assignees of each task (no one assignee for all tasks for one case)
BEFORE AFTER
Screen Shot 2020-05-12 at 8 53 39 PM Screen Shot 2020-05-12 at 8 52 41 PM
  • Queues show the css_id of the user assignee, rather than a mix of user id or css_id?
BEFORE AFTER
Screen Shot 2020-05-12 at 8 55 59 PM Screen Shot 2020-05-15 at 1 25 39 PM
  • Queues do not show "Case Storage" unless they are actually assigned to BVA
BEFORE AFTER
Screen Shot 2020-05-12 at 9 00 31 PM Screen Shot 2020-05-15 at 5 02 39 PM

@araposo-tistatech
Copy link

@hschallhorn VLJ Support confirmed this looks good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature: generic-queue Priority: Medium Blocking issue w/workaround, or "second in" priority for new work. Product: caseflow-queue Source: BVA Reported Stakeholder: BVA Functionality associated with the Board of Veterans' Appeals workflows/feature requests Team: Echo 🐬 Type: Bug
Projects
None yet
4 participants