Caseflow: [Tech Spec] Case Movement: Acting on Behalf of Others

[lomky]

Problem

In our user space it is not uncommon for an action to be Officially done by a person, but actually done by a person acting on their behalf. The most common use case for this is the Deputy Vice Chairman (DVC) judges and their team.

The need is for one or more users to be able to act on behalf of one or more other users. My current understanding of the space is the ratio is most often one person has multiple people acting on their behalf.

Followup Work Needed

All proposals here reveal some strain in our existing app around Users, Permissions, & Roles. We have at least two user role systems (Functions and Org Membership/Admin), and Admin/Judge overloading in the JudgeTeam Orgs. This area has many mature tools we should investigate.

After we have fulfilled this user ask, I would highly suggest we undertake a review & refactor of our role system. This would involve researchign available Rails capability, figuring out the best choice for us, implementing and then migrating to it. In return, we could have more robust roles & permissions, all in the same way, without continuing to overload the Org Admin or keeping user lists in github.

Migrating would involve a lot of changes to the code, but hopefully little user-facing changes. This work would be at least an Epic, ballparked at less or about the same level of effort as pagination.

Proposals

DVC Team Organizations

Write Up

As written up in Original DVC Spec (ref 1), this would create an org type specifically for creating a DVC user and their team. Team admin is the DVC who can control membership and can be acted on behalf of, while team members can act on behalf of the admin. The technical implementation of these would follow how JudgeTeams work.

User interaction would look like:

• BVA Admins create the (4?) DVC Teams, initially add the DVCs & their members
• Future team management handled by the DVC team admin(s)
• Team members can flip into & out of acting on behalf of DVC, which effectively swaps their Queue for the DVC's Queue

Engineering Work:

• Create a new Organization type DVC Team
  
  
  
  • admins can control team membership
  
  
  • flag for who is the DVC, and thus is is being acted on behalf of
  
  
  • team members get access to the switch to act on behalf of their DVC.
    
    
    
    
    
    • Their individual queues are not affected.
    
    
    
  
  
• Change User Switch
  
  
  
  • new route to become the user. locked to org membership,
  
  
  • stash real user in session, a la Global Admin (see ref 2)
  
  
  • change session user to the DVC
  
  
  • show option to switch back to their own user based on session var?
  
  
• Record in our papertrail or app logging which user is actually making the change, while the main system credits the acted on behalf user
• Design consideration: How should we communicate to the user that they are in this mode?

Pros

• Clear design that reflects the Board's org structure
• follows established patterns for Global Admin
• membership does not affect other work controlled by those users

Cons

• Higher user ask
  
  
  
  • Requires the user to understand why you need to be both a Judge and a DVC.
  
  
  • Must understand who to put on your JudgeTeam vs DVC Team
  
  
  • Must remember what a DVC team membership does
  
  
  • multiple user groups to manage
  
  
  • Having admin on both a JudgeTeam and a DvcTeam for one user may be confusing
  
  
• Gives _full_ ability to act as the other user, including team admin abilities. Possible issue?
• Does not include the ability for a normal judge's supervisor to reassign tasks

JudgeTeam Refactor

Write up

JugeTeams would be extended to support admins outside of the judge. We would create a new way to track who is the judge (currently relies on being the first admin), and a new way to flag who is an attorney.

Anyone who is Admin on a judge team would have the ability to access the JudgeQueue for that team, request cases, and assign out work. These actions would all report as performed by the Judge on the team. Cases could be assigned to team members marked as Attorneys.

Engineering Work:

• Update JudgeTeam Orgs
  
  
  
  • Specify the Judge
  
  
  • Specify the Attorney
  
  
  • Update existing teams
  
  
  • admins can act as judges
  
  
• Admin UI to switch to their Judge Queue
  
  
  
  • might have to handle more than one?
  
  

Pros

• Relatively straightforward from the users perspective
• Less work to implement
• Good stopgap if we choose to do the followup

Cons

• we are slowly building our own role management system
• introduces a new complexity to our permissions structure
• creates further separation from how we designed orgs to work originally

Admin Function Based

Write Up

Build in a capability sibling to the Global Admin functionality. While this would work well in theory, it would involve updating or duplicating several well functioning interfaces to the config. It would also then fall on us to keep all of the user lists & permissions up to date, rather than allowing the Board to manage their own users. See the deep dive on slack (ref 2).

References

1. Original DVC Tech Spec
2. Deep Dive on Global Admin & New Documentation from that

Work for #11991

[hschallhorn]

11801 calls out some very specific scenarios.

• Reassign judge review tasks
• Assigning cases to attorneys
• Requesting cases for judges

Assigning and reassigning cases reads as if we could simply add users as admins to judge teams and modify some available_actions functions to allow judge team admins these two. Requesting cases for judges is a bit more complex with the way that requesting distributions works (creates a distribution for the current_user), but we could update the requestDistribution method to request for a certain user id, rather than the logged in user. I think these changes, combined with dropdowns to view a judge's assign and review views might hit all of the acceptance criteria for us.

[hschallhorn]

Thoughts in no particular order including some things we talked about yesterday for documentation purposes!

1. Love the callout on future work
2. Admins may find having both a JudgeTeam and a DvcTeam for one user confusing
3. DVC team implementation also does not include the ability for a normal judge's supervisor to reassign tasks. Should probably call out that this implementation doesn't address it and we'd expect VLJs to reassign before they go on leave.
4. I like that the DVC implementation separates the user's normal workflow from acting as another user
5. Building out the judge team raises some other concerns such as
   
   
   
   • Situations where a user is both an attorney and an admin (in the case of DVCs most likely)
   
   
   • Situations where a user is an admin but not an attorney (in the case of judges and their supervisors )
   
   
6. Judge team build out creates further separation from what we think an org is, but this can be addressed in the followup work

[pkarman]

I prefer "JudgeTeam Refactor" and setting aside time to refactor authorization rules generally.

I have used https://github.com/varvet/pundit before on multiple Rails apps and it works pretty well. The hard part is going to be documenting all our different existing systems and overlaying the ideal business rules we'd like to arrive at.

[kevmo]

I also prefer JudgeTeam refactor route. As Kat notes, it's easier to deliver and less of a burden on our users.
I also agree that we should starting thinking about simpler way to organize our authorization rules.

[lomaxap]

Cons
...
creates further separation from how we designed orgs to work originally

My understanding is that organizations generally limit access to queues and actions related to Tasks. Will giving the attorney access to the JudgeTeam give them access to all the functionality they need to act on behalf of a judge for this ask? (e.g: in the LegacyDecisionReviewTask we limit actions based on whether they are a judge in vacols).

In hearings, we limit access based on the role "Hearing Prep" that all judges get. Looking through attorney data, 164/956 attorneys with recent logins have a "Hearing Prep" role. Can we assume that attorneys acting on behalf of Judges have this role? Otherwise, we may need to do a light refactor of how Hearings permissions. Or is changing hearings information outside the scope of "Special Case Movement"

[lomky]

@lomaxap ~the methodology I'm imagining will mirror User Impersonation/Global Admin, giving the user the session value of the user they're acting on behalf of. If anything, I'm worried they will be too able to act as the other user, and we'll want to put checks in place for the session variable storing the acting_on_behalf to check a person is actually themselves, in some places.~

[lomaxap]

@lomky ah, ok. So if you go with the JudgeTeam refactor option, you would also implement part of the "User Switch" from the DVC Team Option?:

• stash real user in session, a la Global Admin (see ref 2)
• change session user to the DVC

[lomky]

Ah, no I had muddled the options. In the JudgeTeam scenario it would be teaching the code to ask if the judge of the team the admin is on has permission, regardless of which admin is actually doing the action. That's part of why this implementation is a bit straining on our existing system

[carodew]

Hi! @lomky reached out to me to get some Design Opinions™ on how this should be implemented in the front end and I'm summarizing my thoughts here for posterity and also for all interested parties.

The question posed to me was, should the UI link to view a DVC's (judge's) Queue be in the user menu (far upper right?) or the Queue actions dropdown?

Simple, right?

Actually it's pretty tricky, because it brings up questions such as – 

• Are users thinking about this work as impersonating the judge (as we are) or are they thinking of it as just a natural part of their own work, that magically happens to look like the judge performed it behind the scenes?
• When users go about this, are they thinking about 'switching' to being the judge first, and then going about the work, or are they going to go straight to Queue and then switch once there?

It gets into mental models around identity and workflow which are fuzzy at the best of times, and without being able to do some usability testing it's pretty much impossible to know for sure. That said, we currently don't have capacity to do usability testing (although I'd be happy to coach someone through the process if someone wants to learn!)

So that leaves us with the option of making a decision based on usability principles, which is pretty risky and doesn't give us a whole lot of clear guidance anyway. Based on the principle of "put similar things near each other" my weak hunch was to suggest that the impersonation actions be located within the Queue dropdown menu, as opposed to the User Menu, because the Queue menu is closer to where the work is going to take place anyway. There's a risk of hiding it in a dropdown making that functionality not discoverable (another usability principle), but that's also true with the other option we discussed.

This then becomes a question of, "how much risk are we willing to take on with this functionality?"

The main risk is that we release something that users find confusing and/or can't find.

Given the relatively small number of users this will impact, and it sounds like we'd like to revisit Caseflow permissions more broadly in the near future, the risk of this might be rather small in the grand scheme of things. Few users for a relatively short amount of time = not so much lost trust in our team or impact to Board of Veterans' Appeals productivity.

However the few users we're talking about are key users, and working directly with processing appeals so there could be some impact to Board of Veterans' Appeals productivity. Additionally, some of them may be using Caseflow for the first time with this functionality, meaning this is a first impression, and we'd probably like that to be a good impression.

At this point how much risk to take on here is a product management decision, so I'm not going to weigh in (and I honestly don't know which factors are more important), but I want to raise these as the concerns we should be considering as we move forward.

Thank you for inviting me to muddy the waters!

[lomky]

Some good lessons from the design notes on this somewhat parallel ticket: #5385

[lomky]

Work to finish this ticket:

• [x] Break out tickets for work under the epic #11801
• [x] Create Epic for the Followup Work